The numbers are striking: one day of engineering time, one reimplemented language interpreter, $500K in annual savings. Simon Willison’s link-blog picked up the story of the Vine team porting JSONata using AI assistance, and the combination of “in a day” and “half a million dollars” sounds like marketing copy until you understand why JSONata specifically made this tractable.
What JSONata Is and Why It Gets Embedded in Expensive Platforms
JSONata is a query and transformation language for JSON data, created by Andrew Coleman at IBM and released as open source under the MIT license. The reference implementation is pure JavaScript, roughly 5,000-8,000 lines depending on the version. It sits in the same space as XPath/XQuery but for JSON: you navigate nested structures with dot notation, filter arrays with predicates, apply built-in functions, and construct transformed output.
Account.Order.Product[Price > 50].{
"name": Name,
"total": Price * Quantity
}This expression traverses Account.Order.Product, filters products where Price exceeds 50, and constructs a new object for each match. It is readable, compact, and expressive enough to handle most data transformation tasks in integration pipelines.
JSONata itself is MIT-licensed and free. The cost comes from where JSONata lives. IBM’s App Connect Enterprise, the integration platform where JSONata is the native expression language, is a commercial product with per-core licensing that runs into hundreds of thousands of dollars annually at enterprise scale. IBM’s cloud-hosted Node-RED offerings carry similar commercial terms. When you build transformation pipelines on these platforms, JSONata expressions become embedded in your infrastructure, and the platform license is the cost of evaluating them.
This creates a dependency that has nothing to do with the language. You are not paying for JSONata. You are paying for the runtime environment that evaluates it, and that environment happens to be a licensed IBM product. The Vine port severs that dependency by running JSONata on self-owned infrastructure.
Why JSONata Is Not Trivial to Reimplement
The reference implementation looks approachable. It is JavaScript, reasonably well-structured, and the core evaluation loop is a readable recursive interpreter. But JSONata has several semantic properties that make faithful reimplementation genuinely difficult.
The most distinctive is its sequence semantics. JSONata does not have a clean distinction between a value and a one-element array. A path expression that matches a single item returns that item directly; one that matches multiple items returns a sequence that behaves like an array in most contexts. This has cascading effects on function behavior:
$count("hello") // returns 1
$count([1, 2, 3]) // returns 3
$count(Account.Orders) // depends on how many Orders exist at runtimeThe $count() of a singleton is 1, but the singleton itself is not an array. This distinction matters when constructing output, when calling functions that expect arrays, and when applying predicates. Any implementation that conflates “one element” with “array of length one” will pass most tests and fail on exactly the edge cases that production payloads hit.
Undefined propagation is another trap. JSONata follows an XPath-like convention where referencing a nonexistent key silently returns undefined, and undefined propagates through most operators rather than throwing an error. This is intentional and useful, but it means every operator in the implementation needs to handle the undefined case. A port that throws null exceptions or substitutes empty strings on missing keys will produce wrong output on common inputs without any obvious test failures during development.
Regex semantics present a third challenge. JSONata’s regex literals use JavaScript’s regex engine behavior, including \b word boundary definitions, named capture groups, and lookahead/lookbehind semantics. Porting to a language with a different regex engine, such as Go’s RE2 or Rust’s regex crate, requires either bridging to a JS-compatible engine or carefully mapping the semantic differences. RE2 notably does not support lookahead/lookbehind at all, which JSONata expressions in the wild do use.
The reference implementation also uses JavaScript Promises internally for async evaluation and relies on JavaScript’s dynamic type system for dispatch in ways that do not translate directly to statically-typed languages. Preserving the semantics while changing the substrate is the real engineering work, not the surface-level syntax translation.
The Test Suite as Specification
What made this port tractable in a day is that JSONata ships a comprehensive test suite as part of the repository. The test-suite/ directory contains hundreds of test cases in JSON format, each specifying an expression, an input document, and the expected output or error. These cases cover the sequence semantics, undefined propagation, function edge cases, and a significant portion of the regex behavior.
When your correctness target is “pass this test suite,” the problem changes shape. You are not working from a prose specification that requires interpretation. You are working from a corpus of input/output pairs that constrain the implementation precisely. An AI assistant with access to the test corpus can generate code, run the tests, observe failures, revise the implementation, and iterate. The feedback loop is fast and objective.
This is the mechanism behind “rewrote it in a day.” The AI did not invent a JSONata implementation from first principles. It ported the reference implementation, ran the test suite against the port, fixed failures, and iterated until the suite passed. The test cases were the specification; the AI was the implementation engine; the human was the architect and reviewer who kept the process coherent.
This approach requires the test suite to be comprehensive enough to serve as a specification. JSONata’s test suite is unusually good in this regard, which is partly why it already has multiple community implementations in Go, Java, and other languages, each built primarily against those tests. The Vine port is a faster version of a process that has happened before, compressed by current AI tooling.
The Economics of the Port Threshold
The $500K/year figure represents a build-vs-buy decision where the math is obvious. At that scale, a one-day engineering effort is worth it without further analysis, even accounting for ongoing maintenance of a self-owned implementation.
The more illuminating case is what happens below that threshold. Consider a team saving $50K/year in platform licensing against a six-week port. That calculation rarely clears a prioritization bar. The project sits in the backlog, the dependency persists, and the license renews. This is the structural reason so many platform dependencies survive long past the point where alternatives are technically viable.
AI-assisted porting shifts that threshold substantially. Work that takes six weeks without AI assistance and one day with it changes the economics of marginal cases. The $50K savings case now clears easily. The $20K case becomes plausible. Projects that were structurally unattractive become routine engineering tasks.
This effect is not specific to JSONata. Any embedded language runtime, domain-specific language, or proprietary data format with an existing test suite and reference implementation is now cheaper to self-host than it was two years ago. The compression ratio is highest when the test suite is comprehensive, the reference implementation is readable, and the target language has clear semantics. JSONata meets all three conditions, which is why it made such a clean case study.
Where AI-Assisted Implementation Actually Delivers
The Vine story illustrates the conditions under which AI-assisted implementation genuinely works. A well-specified target, in the form of a test suite; a reference implementation to port from rather than invent from scratch; a clear feedback signal in the form of test pass/fail; and a problem scope that fits within an AI’s iteration cycle. These conditions do not always hold, but when they do, the compression ratio is real and compounding.
The harder AI coding problems remain design work: choosing the right architecture for an underspecified problem, making trade-offs that require understanding a codebase’s history, implementing behavior that has no existing reference to learn from. The Vine port was none of those things. It was a well-bounded translation task with a comprehensive correctness oracle, and that is where AI assistance produces dramatic speedups rather than marginal ones.
For anyone maintaining infrastructure with expensive embedded language runtimes, the practical implication is worth sitting with. If your platform dependency evaluates a language with a published test suite and an open-source reference implementation, the barrier to self-hosting dropped significantly over the past two years, and the Vine port is a concrete measure of how much.