The JSONata interpreter has a performance problem that has nothing to do with its algorithm. The logic is sound; it is the runtime that costs money. When Reco.ai published their account of rewriting JSONata in a single day with AI assistance and cutting $500k in annual compute, the Hacker News thread filled with skepticism about the timeline. That reaction misses what is genuinely interesting: this is the kind of task where AI translation tools are strong for structural reasons, and understanding those reasons is more useful than debating whether a day is an exaggeration.
What JSONata Is and Why It Runs Slow at Scale
JSONata is a declarative query and transformation language for JSON, created at IBM by Andrew Coleman around 2016 and now maintained as an independent open-source project at jsonata.org. The reference implementation is JavaScript, roughly 15,000 lines, and it operates as a pure tree-walking interpreter. The pipeline is: tokenize the expression string, parse it into an AST using a Pratt parser (top-down operator precedence), annotate the AST in a static analysis pass, then walk the tree recursively to evaluate against a JSON input document.
There is no bytecode compilation, no JIT, no optimization passes. Every time you evaluate an expression like Account.Order[Price > 10].Product, the evaluator traverses the AST node by node, allocating JavaScript objects for every intermediate result along the way.
For occasional use, that is fine. JSONata was designed to be embedded in applications, not to process millions of documents per second. The performance problem compounds in two ways when you run it as a service component at scale.
First, the reference implementation is asynchronous throughout. The evaluator returns Promises even for expressions that involve no async operations. This was a deliberate design choice to support user-defined async callback functions, but it means every node evaluation pays Promise overhead in the common case where everything is synchronous. In high-throughput paths this creates a dense chain of microtask queue entries that V8 has to resolve, adding latency that sits entirely in the JavaScript engine rather than in any work the evaluator is doing.
Second, JavaScript’s garbage collector causes stop-the-world pauses under allocation pressure. JSONata evaluations allocate heavily: intermediate arrays, path step results, function argument lists, cloned JSON subtrees. At scale, GC pauses inflate p99 latency in ways that are difficult to tune away without restructuring the allocations themselves, which means rearchitecting the evaluator. Scaling out horizontally is the practical response, which is why compute cost grows linearly with traffic rather than being absorbed by available headroom.
IBM App Connect Enterprise, the primary enterprise consumer of JSONata at significant throughput, has encountered this behavior in production integration flows. When a high-volume flow runs complex JSONata transforms, the Node.js workers spend a meaningful portion of their time in GC rather than transforming data.
Why a Tree-Walking Interpreter Is a Good AI Translation Target
A tree-walking interpreter is close to ideal as a target for AI-assisted language translation, for reasons that are worth spelling out.
The code structure is highly regular. Each AST node type maps to a handler function. The handler reads a few fields from the node, recurses into child nodes, and combines results. This structure is isomorphic across languages: a function in JavaScript that dispatches on node.type translates directly to a match expression in Rust, a type switch in Go, or a visitor pattern in Java. The AI does not need to invent any structure; it translates existing structure into an equivalent form.
The logic is computationally simple relative to the codebase size. JSONata’s evaluator does tree traversal, JSON value manipulation, and function dispatch. These operations have direct idiomatic equivalents in statically typed systems languages. There are no concurrent data structures to reason about, no lock hierarchies, no platform-specific code paths requiring expertise in the target environment.
Most importantly, the test suite serves as a complete specification. The JSONata project maintains over 2,000 test cases covering the full language, including edge cases in path navigation semantics, array-singleton coercion (JSONata automatically wraps or unwraps single-element arrays in specific contexts, which is one of its less obvious behaviors), regex handling, and numeric precision. A rewrite that passes those tests is spec-compliant by definition. The test suite is the oracle.
This combination, regular structure, simple per-node logic, and a comprehensive oracle, is where AI-assisted translation is genuinely strong. The model does not need a deep understanding of what the code accomplishes; it needs to produce structurally equivalent code in the target language. That is a tractable translation problem, not an invention problem.
What “One Day” Actually Means
Skepticism about the one-day timeline is understandable but focuses on the wrong variable. “One day” is wall-clock time, and it presupposes significant surrounding infrastructure: an existing test suite, a decision about the target language, familiarity with both source and target codebases, and a CI pipeline that runs tests on each translated module.
The AI-assisted workflow for a project like this operates file by file. You feed the model a source file, the type definitions it depends on, and the idiomatic conventions of the target language. The model produces a translated file. You run the relevant tests. You iterate on failures. For a roughly 15,000-line interpreter with a comprehensive test suite, this loop is highly parallelizable; different modules can be translated simultaneously by different agent invocations, with tests as the convergence criterion.
The bottleneck in manual translation is human review. A developer reading translated code line by line to verify correctness is slower than generation. AI translation sidesteps this by making the test suite the reviewer. If tests pass, the translation is correct enough to ship. For a project with this level of test coverage, that is a meaningful and defensible equivalence.
The prior art here is instructive. The blues/jsonata-go port, done by hand, covers a significant subset of JSONata but is not fully spec-compliant and has not tracked recent versions of the language spec. The dashjoin/jsonata-java port is more complete and more actively maintained, but still took substantially longer than a day and required careful attention to the subtler behaviors of path semantics and array handling. Manual porting of a complex interpreter is genuinely difficult; JSONata’s edge cases require careful reading of test output to get right. AI translation, validated against the same test suite, navigates those edge cases by construction.
The Economics of Runtime Choice
$500,000 per year in compute savings is a number that requires context. At the traffic and data volume where JSONata transforms are on the hot path of a SaaS security platform’s data pipeline, the compute profile is dominated by CPU time in the evaluator and GC pauses in the V8 heap.
A Go implementation of the same interpreter eliminates both. Go’s garbage collector is designed for low-latency applications and runs concurrently rather than stopping all goroutines. The per-evaluation memory overhead is a fraction of V8’s, goroutines make concurrent evaluations cheap, and there is no async overhead for synchronous work. Benchmarks from comparable JS-to-Go migrations of CPU-intensive services consistently show 3 to 10x throughput improvements and 60 to 80 percent compute cost reductions at equivalent traffic levels.
At the scale where $500k/year of compute is a real budget line, this migration makes financial sense with or without AI assistance. What AI assistance changes is the cost of doing the migration. A rewrite that previously required weeks of engineering time, careful manual translation, and multiple rounds of debugging edge cases now costs a day. Tech debt that would have persisted for another year because the engineering cost exceeded the savings timeline becomes worth addressing immediately.
That shift in decision threshold is the substantive claim in the Reco.ai story. The question is no longer whether the rewrite is worth doing but whether you have the test coverage to validate the result.
What This Does Not Tell Us
AI-assisted translation of a well-specified interpreter is not the same as AI designing an interpreter from scratch. The model worked from an existing specification, the JSONata JavaScript source, toward an existing oracle, the test suite. Both are prerequisites. Remove either and the workflow breaks down.
Services without comprehensive test suites cannot replicate this approach cleanly. If your JavaScript service has modest branch coverage and informal documentation, an AI translation will produce something that runs and fails subtly in production rather than obviously in tests. The test suite is doing as much work as the AI; it is not an optional component of the story.
There is also a category of behaviors that are tested incorrectly or not tested at all in any test suite. JSONata’s array-singleton coercion is documented but frequently misunderstood; if a test case encodes the wrong expectation, the AI translation will faithfully reproduce that misunderstanding. Any rewrite, AI-assisted or manual, inherits the blind spots of its oracle.
The harder parts of interpreter work, designing a bytecode compiler, implementing optimization passes, reasoning about evaluation semantics for a new language feature, are not what happened here. The model translated a known design to a new language; it did not produce a new design. The distinction matters when evaluating what this technique generalizes to.
Where This Points
The practical implication is a shift in how engineering teams should think about performance migrations for interpreted services. The standard calculation has always been: compute cost saved per year versus engineering cost of the rewrite. When the rewrite costs weeks of engineering time, many migrations that are economically sensible on paper stay on the backlog. When the rewrite costs a day, the breakeven point drops substantially.
This shifts investment priority toward test coverage for performance-critical code paths. A service with 80 percent branch coverage and a thorough integration test suite is now an AI-portable artifact; the tests are not just quality assurance but infrastructure for future migrations. That framing makes the investment in test coverage easier to justify than it was when the coverage only served its immediate purpose.
It also suggests that the value of AI coding tools is not uniformly distributed across software tasks. Translation of well-structured code toward a comprehensive oracle is near the top of the distribution. Generating novel algorithmic logic from vague requirements is near the bottom. The JSONata rewrite sits firmly in the first category, which is why the one-day claim, skepticism aside, is probably accurate.