Rewriting JSONata at Cloud Scale: What $500k in Compute Reveals About Interpreter Overhead
Source: hackernews
When Reco.ai posted that they rewrote JSONata with AI in a single day and saved $500,000 per year in the process, the reactions split predictably: some people impressed by the productivity story, others skeptical of the cost claim. Both groups largely skipped the more interesting question, which is what it takes to run an expression language interpreter continuously at cloud security scale, and why that situation makes you care about interpreter overhead in ways most software teams never have to.
What JSONata Is and Why It Ends Up in Policy Engines
JSONata is a query and transformation language for JSON data, created by Andrew Coleman at IBM. If you have worked with Node-RED or IBM App Connect, you have seen it. The syntax draws heavily from XPath: you navigate object hierarchies with dot notation (Account.Order.Product), filter with inline predicates (Account.Order.Product[Price > 10]), and aggregate with built-in functions ($sum(Account.Order.Product.Price)). It is expressive, readable, and the JavaScript reference implementation has been available on npm since around 2016.
For a cloud security posture management platform, JSONata is a natural fit for writing policy conditions. You need to express things like “which S3 buckets have public ACLs and no server-side encryption enabled” as declarative queries against JSON documents representing cloud resource configurations. JSONata lets security engineers write those conditions without writing code. The expressions are readable enough to be audited, flexible enough to handle the variety of cloud resource schemas, and the runtime is small enough to embed.
The catch is what happens when you evaluate those policies not once or twice per request, but continuously and at volume.
The Interpreter’s Performance Model
JSONata’s reference implementation is a pure JavaScript recursive evaluator. When you call jsonata(expression).evaluate(data), the library parses the expression string into an AST, then recursively walks that AST against the input data, and returns the result. The grammar is non-trivial: operator precedence, function calls, lambda expressions, conditional logic, partial application, and a fairly unusual path navigation model that is context-sensitive in ways that XPath is not.
Parsing has a cost even when expressions are cached. The evaluate step involves repeated JavaScript function calls, closure allocations, and prototype chain lookups for every node in the AST on every call. In a typical web application, you evaluate a handful of expressions per request and the overhead disappears into rounding error. In a CSPM platform running continuous posture checks, the arithmetic changes.
If you have 500 policy conditions and you are evaluating them against 50,000 cloud resources per scan cycle, you are running 25 million individual evaluations. If each evaluation takes 2ms in the JavaScript interpreter, that is 50,000 seconds of single-threaded CPU time per cycle. You parallelize heavily, but the interpreter’s constant factor determines how much compute you need to maintain a given scan frequency. A rewrite that delivers a 5x speedup does not just make things faster; it directly reduces the fleet size or serverless compute spend needed to keep the system running.
What a Rewrite Actually Involves
Rewriting an interpreter is well-defined work, which is part of why it is a good candidate for AI assistance. JSONata has a published specification, a comprehensive test suite in its GitHub repository, and semantics that are largely derivable from reading the reference implementation. The components you need to port are a lexer and parser producing an equivalent AST, an evaluator handling all of JSONata’s operator semantics, and the full standard library: string functions, numeric functions, array and object manipulation, date formatting, $merge, $spread, $each, the transform operator, and so on.
A human developer doing this port in Go or Rust would spend most of their time on the standard library and on edge cases. How does $sum behave on an empty array versus a non-array argument? What does path navigation return when an intermediate node is null versus absent? What does the bind operator (:=) do in a closure that outlives its binding context? JSONata has answers to all of these, scattered across its test suite and documentation, but finding and correctly implementing them all from scratch takes time.
This is where LLMs produce their most reliable results in software work. The task has a clear specification in the form of the reference implementation, a correctness signal in the form of the test suite, and the semantics, while complex, are compositional rather than requiring novel reasoning. The model reads the JavaScript source, generates equivalent code in the target language, and the test suite catches behavioral divergence. The engineer’s job shifts from writing implementation code to reviewing generated code and ensuring the test coverage is comprehensive enough to catch the cases that matter in production.
The “in a day” framing is plausible for exactly this reason. The workflow maps well onto how current LLMs work: read context, generate, run tests, feed failures back, iterate. The part that takes longer than a day, and is probably understated in the headline, is maintaining the test suite that makes this kind of rewrite trustworthy.
What $500k Implies About the System
The cost number says more about Reco’s infrastructure than it says about JSONata. At AWS Lambda pricing in 2026, $500,000 per year represents an enormous sustained compute workload. On containerized or EC2 compute the number implies something running continuously at significant scale. The inference is that policy evaluation was genuinely CPU-bound, that the bottleneck was the interpreter itself rather than I/O or network, and that the team had enough observability to know this with confidence before committing to a rewrite.
That last point matters. Most teams considering a rewrite do not have good enough profiling to know that the interpreter is the bottleneck rather than, say, the JSON deserialization step, the database queries fetching resource state, or the scheduling overhead coordinating parallel scans. The $500k savings claim implies not just a successful rewrite but a team that understood their own cost model well enough to pick the right optimization target.
The Limits of the Pattern
JSONata has some genuinely subtle behaviors that require careful review even when an LLM generates the initial implementation. The partial application semantics, the way the transform operator (~>) chains functions, and the late-binding behavior of certain path expressions are places where a generated implementation can look correct and pass most of the test suite while getting an edge case wrong. In a CSPM context, a behavioral divergence between the original and the rewrite is not an annoying bug; it is a policy evaluation gap that could mean a misconfigured resource goes unreported.
The broader pattern of AI-assisted rewrites is sound. Using an LLM to translate a well-tested library into a faster implementation language, with the test suite as the correctness oracle, is a legitimate use of the technology. What it does not do is remove the need for thorough testing; it moves that need earlier in the process and makes the quality of the test suite the binding constraint on how fast and safely you can move. Teams that have invested in comprehensive test coverage get the productivity gain. Teams that have not find that the LLM generates plausible-looking code that is wrong in non-obvious ways.
Reco’s story is worth paying attention to not because AI wrote code fast, but because it illustrates a specific situation where that workflow produces real economic value: a well-specified library with a comprehensive test suite, a clear performance gap between the interpreted original and a compiled equivalent, and a cost model where that gap translates directly into infrastructure spend. When all three conditions are met, the math on an AI-assisted rewrite is hard to argue with.