What a JSONata Rewrite Actually Requires (The AI Did the Easy Part)

When Reco.ai posted that they rewrote JSONata with AI in a day and saved half a million dollars a year in compute costs, the Hacker News thread did what Hacker News threads do: split between people impressed by the number and people skeptical of the framing. Both reactions make sense. The headline compresses something genuinely interesting into something that reads like a product demo. The interesting part is not that AI wrote the code fast; it is what you actually have to get right when you rewrite an expression language, and why the test suite is the real engineering artifact.

What JSONata Does

JSONata is a query and transformation language for JSON, created by Andrew Coleman at IBM and first released around 2016. Think of it as XPath for JSON, layered on top of a functional programming model. An expression like this:

Account.Order.Product[Price > 50].`Product Name`

navigates nested structure, applies a predicate filter, and extracts a field, all in one expression. More complex expressions reshape documents, aggregate sequences, define inline lambda functions, and apply a library of built-in functions covering string manipulation, math, date handling, and higher-order operations like $map(), $filter(), and $reduce().

That expressiveness made it the default expression language inside Node-RED, IBM’s flow-based automation tool, and it spread through integration platforms and API management layers because it lets non-engineers write transformation logic without needing JavaScript. For a cloud security product like Reco.ai, which ingests and queries API responses from dozens of enterprise SaaS platforms, JSONata is plausible as a core evaluation primitive. You want a portable, evaluatable expression language you can apply dynamically to whatever JSON your integrations return.

Why It Gets Expensive

JSONata is an interpreter written in JavaScript. When you call jsonata(expression).evaluate(data), the library parses the expression string into an AST and then walks that AST recursively in V8, making JavaScript function calls at each node. The library does give you a way to cache the compiled form:

const expr = jsonata('Account.Order.Product[Price > 50].`Product Name`');
// later, repeatedly:
const result = await expr.evaluate(data);

With caching, you skip re-parsing. But you are still running V8-interpreted JavaScript to evaluate every node of the AST against your data, with dynamic type checks and coercions at each step.

For the use cases JSONata was designed for, that cost is noise. In a Node-RED flow, you are waiting on HTTP round trips and message queue latency; a few milliseconds of expression evaluation does not matter. At cloud scale, the picture changes. If you are running JSONata on every event from every connected SaaS tenant across a fleet of Lambda functions or containerized workers, the constant factor multiplies continuously. AWS Lambda bills per GB-second. If JSONata evaluation sits on the critical path of your event processor and accounts for a meaningful fraction of your execution time, cutting that fraction by 5x directly cuts that fraction of your bill.

The $500k/year figure implies a specific scale of operation, but it is not implausible for an enterprise security platform processing millions of events per day. The math is straightforward even if the exact numbers are not verifiable from outside the company.

What a Rewrite Actually Means

Translating JSONata to a compiled language, Go or Rust being the obvious candidates, is the kind of work that has a clear shape: read the JavaScript implementation, produce equivalent code in the target language, run the tests, fix failures, repeat. It is tedious rather than conceptually hard, which is precisely the category of work where large language models perform well. The AI handles the mechanical translation. A human engineer would need weeks to do the same thing carefully. The AI produces a candidate in hours.

But there is a crucial precondition: you need a test suite that actually specifies the behavior you need to preserve. JSONata’s npm repository has exactly this. The test-suite directory contains a large collection of JSON files, each defining an expression, an input document, and the expected output. These are not unit tests for the implementation internals; they are conformance tests for the language semantics. If your new implementation evaluates each expression against each input and produces the expected output, you have evidence that you preserved the semantics correctly.

This is what makes JSONata a good candidate for AI-assisted porting in particular. The conformance tests serve as a correctness oracle that does not depend on reading or understanding the implementation. The AI can generate the translation without understanding JSONata’s semantics deeply; the tests surface the failures.

The Part the Tests Might Miss

JSONata has some semantics that are genuinely unusual and that a mechanical translation can get subtly wrong. The most important is its sequence model.

In JSONata, arrays and singletons are context-sensitive. A path expression that happens to match a single item returns that item directly, not a single-element array. A path expression that matches multiple items returns a sequence. Functions applied to sequences often iterate implicitly. The $ operator refers to the current evaluation context, while $$ refers to the root input document. These behaviors interact in ways that produce correct results for simple cases and surprising results for edge cases.

Consider:

$sum(Account.Order.Product.Price)

This works because Account.Order.Product.Price produces a sequence of all prices across all orders, and $sum aggregates a sequence. But:

Account.Order.Product.Price

if there is only one order with one product, returns a scalar, not a one-element array. Code that expects an array will break on single-result inputs. This is a deliberate design choice, not a bug, but it is the kind of thing that catches implementations that were not written with this model in mind.

A rewrite that passes the existing test suite for the common cases but silently produces arrays where JSONata would produce scalars, or vice versa, is producing wrong output for real queries. Whether the existing test suite covers enough of these edge cases to catch such a regression is the real question the Hacker News skeptics were asking, and it is the right one.

What the AI Did and Did Not Replace

The pattern Reco.ai used will become more common: AI-assisted translation of performance-critical library code from interpreted to compiled environments, with the original test suite as the correctness gate. It is a sensible division of labor. The AI handles volume; the test suite handles correctness.

What the AI cannot substitute for is judgment about what the test suite does not cover. If the conformance tests are comprehensive, the rewrite is probably correct. If they have gaps, those gaps survive into production silently. For a security platform, silent query evaluation errors are worse than performance problems; they mean your policy enforcement logic is producing wrong answers about access and risk.

The investment that enables a fast, confident rewrite is the investment in the tests, not the translation. Reco.ai presumably had enough operational confidence in their implementation, or enough production telemetry to validate it, to ship. The one-day framing is about the translation step alone, and for that step, AI is genuinely effective now.

For the broader engineering community, this story is most useful as a template: if you have a performance-critical dependency that is bottlenecking your compute costs, and that dependency has a comprehensive test suite, AI-assisted porting to a compiled target is now a realistic project rather than a multi-quarter initiative. The bottleneck shifts from code generation to test coverage. If your tests are good, the translation is fast. If your tests have gaps, you will find out in production regardless of how fast the translation was.

The original post is worth reading for the specifics. The $500k headline is the marketing layer. Underneath it is a straightforward story about what happens when interpreted evaluation costs compound at scale and you finally have tools that make the porting effort proportionate to the payoff.