Porting JSONata in a Day: What the $500K Savings Actually Tells You

Simon Willison linked to a post this week about a team behind a system called Vine who rewrote their JSONata implementation with AI assistance in about a day and saved $500,000 per year in the process. The headline numbers are designed to be eye-catching, and they are. But the more interesting question is why the cost was that high in the first place, and what it means that the fix took one day.

What JSONata Is and Why It Matters

If you haven’t run into JSONata, it’s a query and transformation language for JSON data, something like XPath but designed for the JSON world. The reference implementation lives at jsonata-js/jsonata on GitHub, written in JavaScript, and it powers a wide range of enterprise integration tooling. IBM App Connect uses it as the primary expression language for mapping data between systems. Node-RED uses it for message transformation in IoT workflows. Various no-code and low-code platforms have adopted it because it strikes a reasonable balance: expressive enough to handle real data wrangling, simple enough that non-engineers can write basic expressions.

The language is more capable than it first appears. Beyond basic path navigation like Account.Order.Product.Price, JSONata handles predicate filtering, aggregation with functions like $sum() and $count(), higher-order functions including $map(), $filter(), and $reduce(), lambda expressions, regular expressions, sorting, grouping, and a transformation syntax using $ that lets you construct new objects from input data. The specification covers all of this in detail, and the JavaScript implementation backs it with a comprehensive test suite of several hundred test cases covering edge cases, type coercion behavior, and error conditions.

That test suite is crucial context for understanding the Vine story.

The Cost Structure Behind $500K/Year

To understand where half a million dollars per year goes when you depend on JSONata, you need to understand how it tends to get deployed in production systems.

IBM App Connect Enterprise, the platform most associated with JSONata, is enterprise integration software. It was formerly IBM Integration Bus, and before that WebSphere Message Broker. IBM’s pricing for enterprise integration software is notoriously opaque and tends to scale with processor value units, volume, and support tiers. A serious production deployment can easily run into six figures annually when you account for licensing, support, and the cloud variants. IBM App Connect on cloud charges per flow execution; at meaningful transaction volumes, those per-call costs compound quickly.

Beyond IBM’s platform, managed services that expose JSONata evaluation as an API or as part of a workflow engine can carry similar cost profiles. When a team is running millions of JSONata evaluations per day through a paid service, eliminating that dependency by owning the implementation converts a variable per-unit cost into a fixed engineering cost. $500K is the kind of number you see when a team was running at enterprise scale through a commercial platform and then replaced it with a self-hosted implementation.

The insight here is not “JSONata is expensive.” JSONata itself is MIT licensed and free. The cost was the layer around it.

Why JSONata Is a Good Candidate for AI-Assisted Porting

The “in a day” claim is where the AI angle becomes technically interesting, and JSONata has several properties that make it well-suited for this kind of work.

First, the source implementation is clean. The jsonata-js codebase is structured, well-documented, and the JavaScript is idiomatic without being particularly exotic. There is no clever runtime tricks, no heavy macro usage, no platform-specific assembly. It is straightforward parsing and evaluation logic that any capable LLM can read and reason about.

Second, the specification is precise. JSONata has documented semantics for every operator and function. When you ask an LLM to port code that implements a well-defined specification, the spec serves as a ground truth you can reason against. Ambiguities in the source code can be resolved by consulting the spec rather than inferring intent from variable names.

Third, and most importantly, the test suite exists and is comprehensive. This is the factor that actually makes a one-day port credible. The workflow for an AI-assisted port of a well-tested codebase looks roughly like this: translate the implementation into the target language with the LLM handling the mechanical translation, run the existing test suite against the result, feed failures back to the LLM with context, iterate. When the test suite is thorough, you get fast signal on whether the translation is semantically correct, not just syntactically valid. You don’t need to invent test cases or rely on manual review to catch behavioral differences. The suite already encodes the expected behavior of several hundred inputs.

Contrast this with porting a library that has sparse test coverage, a vague spec, or implementation-defined behavior. Those ports take weeks, not because the code is longer, but because every ambiguity requires investigation and every correctness question requires human judgment. JSONata is a good AI porting target because most of the correctness questions have already been answered by whoever wrote the test suite.

The Broader Pattern: Specifications as Porting Infrastructure

This story fits a pattern that has been emerging across the ecosystem over the past few years. Specification-complete languages and protocols, the ones with formal test suites and precise documented semantics, are disproportionately amenable to AI-assisted implementation.

You see this in WinterTC and the Winter CG web-interop test suites, where the goal is making different JavaScript runtimes pass the same suite of tests. You see it in SQLite’s testing philosophy, where the project famously has more test code than implementation code, and where independent implementations can verify themselves against a known-correct baseline. Languages and protocols with formal test suites become, in effect, infrastructure for porting.

JSONata joins a list of embedded query and expression languages where the reference implementation is in JavaScript but the deployment context increasingly demands something else. Go, Rust, and Python ports of these languages are valuable for teams that want to avoid shipping a Node.js runtime dependency alongside their service, or who want predictable memory behavior, or who simply want everything in one language. Previously, writing a compliant port required weeks of careful work matching the reference behavior. AI-assisted porting with a comprehensive test suite compresses that substantially.

The caveat worth noting is that JSONata’s JavaScript implementation does rely on JavaScript’s own type coercion semantics in some places, and those don’t translate trivially. Numbers in JavaScript are IEEE 754 doubles; string-to-number coercion has JS-specific behavior; the undefined versus null distinction matters for how JSONata handles missing fields. A port that passes the test suite is not automatically correct for every edge case the test suite doesn’t cover. The teams doing these ports are typically investing additional time in property-based testing and fuzzing against the reference implementation to catch the gaps.

What the Day Counts

One day is a marketing-friendly framing, but it also reflects something real about what AI tooling has changed in this kind of work. The bottleneck in porting a well-specified library was never reading the code. It was the mechanical translation work: converting function signatures, adapting data structures, handling library differences between the source and target language ecosystem. That work is genuinely tedious, requires sustained concentration, and does not require much judgment. It is exactly the kind of task that current LLMs handle well.

What still requires a human is the test infrastructure setup, the integration with the target project’s build system, the investigation of semantic differences in edge cases, and the judgment calls about where to diverge from the reference behavior intentionally. A day probably means the mechanical translation was handled in hours, and the rest of the day went to making it fit properly into Vine’s codebase and verifying the semantics held.

$500K per year is a strong incentive to spend a day on something. The interesting thing is that a year ago, that same day of work would have taken closer to six weeks.