Reco.ai published a post that’s been circulating on Hacker News with 249 points and more than 200 comments. The claim is straightforward: using AI assistance, they rewrote JSONata in a single day, and the result is saving them $500,000 per year in cloud infrastructure costs.
The Hacker News thread predictably separates into two camps. Some readers are skeptical of the “one day” framing, treating it as marketing compression around a much longer effort. Others are more curious about the mechanics. Both reactions have merit, but neither quite gets at the part of this story worth thinking through carefully: the reason this specific rewrite worked is rooted in properties of JSONata itself, not in anything special about the AI tooling.
What JSONata Is
JSONata is a query and transformation language for JSON. Think of it as XPath for JSON: you write expressions that navigate, filter, and reshape structured data without writing loops or intermediate variables. IBM developed it internally and open-sourced it; it became the transformation language inside Node-RED and IBM App Connect, and from there spread to dozens of integration platforms and data pipelines.
A simple expression looks like this:
Account.Order.Product.(Price * Quantity)That single line navigates into a nested JSON structure, selects all Product entries within all Orders within Account, and computes a derived value for each. More complex expressions can filter by condition, aggregate with functions like $sum() and $count(), manipulate strings, and even define local bindings. The reference implementation is the jsonata package on npm. It works by parsing the expression string into an abstract syntax tree, then walking that tree against your input JSON to produce a result. For interactive use or modest workloads, this is perfectly adequate.
The Performance Problem With the JavaScript Implementation
When you move from “running JSONata occasionally” to “running JSONata against millions of records per day as part of a continuous data pipeline,” the cost model changes. Every evaluation goes through V8’s JavaScript runtime: heap allocation for intermediate objects, garbage collection pressure, and the overhead inherent in a dynamically typed interpreter executing over structured data.
This is not a criticism of the jsonata package specifically. It is the nature of interpreted, dynamic execution. The same workload in a compiled language with static types, stack-allocated structures, and no GC pauses will use a fraction of the CPU. At cloud pricing, that fraction is money.
Reco is a SaaS security platform whose core function involves ingesting structured data from SaaS APIs and evaluating it against rules and transformations continuously. If JSONata expressions are doing the transformation work in that pipeline, the compute cost accumulates across every invocation, every record, every hour. Getting to $500k/year in compute for a single component is plausible for a company processing SaaS telemetry at scale.
Implementations of JSONata in compiled languages already exist. The jsonata-go library from Blues Wireless implements a subset of the specification in Go. A full-fidelity implementation covering the complete spec gives you Go’s allocation characteristics, no GC pauses at inopportune moments, and tighter memory layout than JavaScript objects. The cost reduction from switching a high-throughput pipeline to that kind of implementation can be substantial; a 5x CPU reduction on a $600k/year compute line is $480k in annual savings.
How AI-Assisted Translation Works Here
The “one day” claim does not mean an AI was handed a blank prompt and produced a working JSONata evaluator from nothing. What AI-assisted code translation involves is mechanical transformation of well-understood code from one language to another, with a verification loop driven by an existing test suite.
JSONata has a comprehensive test suite in its GitHub repository. That suite covers expression parsing, path navigation, filtering, numeric and string functions, aggregation, error cases, and specification edge cases across hundreds of test cases encoding the expected behavior of every significant part of the language.
That test suite is the key ingredient. The workflow for an AI-assisted port of this kind goes roughly: translate each source module to the target language using the model, run the test suite, collect the failures, feed them back to the model with context about what broke and why, and iterate. The developer’s role in this loop is triage and context-provision, not line-by-line implementation. For a codebase with good test coverage, this loop converges faster than writing an implementation from scratch.
This pattern was possible before LLMs existed; the difference is that mechanical translation previously took weeks of careful reading and manual rewriting. Now it takes hours of iteration against test failures. The test suite does the same job it always did. The model makes the initial translation fast and largely correct on the first pass for well-structured source code.
Why JSONata Was a Good Candidate
Not every codebase is amenable to this treatment. JSONata has several properties that make it nearly ideal.
It is pure computation. A JSONata expression evaluator takes an expression string and a JSON document; given the same inputs, it always produces the same output. There are no side effects, no I/O, no network calls, no state that persists between evaluations. This makes correctness cheap to verify and easy to reason about. Compare that with rewriting a component that manages database connections or handles concurrent requests; correctness there depends on timing, network behavior, and resource lifecycle, none of which test suites fully capture.
The language is fully specified. JSONata has a published specification describing the semantics of every operator and function. Ambiguity in source behavior is a major hazard for AI-assisted rewrites; when the source code does something the tests do not fully cover, the translation can silently diverge in production. JSONata’s spec provides a reference for resolving those ambiguities during the translation process.
The JavaScript source code is relatively idiomatic. A recursive descent parser written in straightforward JS maps cleanly to equivalent structures in Go or TypeScript. Closures that carry evaluation context become function signatures with explicit context parameters. The translation does not require understanding architectural intent, only mechanical correspondence between constructs in two languages that share broadly similar computational models.
The Honest Limitation
The Hacker News discussion surfaced a real concern: test suite coverage is not the same as specification completeness. JSONata has edge cases in numeric precision, Unicode handling within string functions, and the behavior of $eval() for dynamic expression execution that do not always appear in the main test suite. An implementation that passes every test case may still diverge from the JavaScript reference on specific production inputs.
This is the correct skeptical framing. “Passes the test suite” and “behaviorally equivalent in all production cases” are different claims. Whether the gap between them matters depends on which parts of the JSONata specification your workload exercises. If your production expressions never invoke $eval() and your inputs are all ASCII, you may never encounter a divergence. If your workload is broader and exercises more of the specification’s surface area, additional validation is warranted.
Reco shipped this and is observing the cost reduction. That is meaningful evidence that the gap has not caused problems for their specific workload, but it is not a universal guarantee about the approach.
What This Pattern Requires
The general lesson from this case is about preconditions. AI-assisted rewrites are reliable when: the source behavior is deterministic, a comprehensive test suite exists, the language is fully specified, and the translation is across implementation languages rather than across architectural paradigms.
The pattern is fragile when test coverage is weak, when source behavior is implicit or poorly documented, when the rewrite requires design decisions beyond mechanical translation, or when correctness depends on environmental factors the tests do not exercise. Rewriting a distributed consensus algorithm or a stateful network protocol handler with the same approach would be a very different proposition.
JSONata sits at the favorable end of all four dimensions. That combination, not the specific AI tooling used, is what made a one-day rewrite credible. The economics closed because the performance difference between a JavaScript interpreter and a compiled evaluator is real and significant at scale. The development cost was low because the problem was well-specified and cheaply verifiable. Put those together and you get the kind of outcome that looks remarkable from the outside but follows straightforwardly from the conditions that made it possible.