Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We rewrote JSONata with AI in a day, saved $500k/year

reco.ai

Post reply on HN
Print view View original

161–170 of 278 posts

Re: We rewrote JSONata with AI in a day, saved $500k/year

#161

Post by zozbot234 »

rozzie wrote: post #77

Some background on one of the other two golang implementations mentioned in the comments. Years ago I hired an Upwork contractor to port v1.5.3 to golang as best he could. He did a great job and it served us well, however it was far, far from perfect and it couldn't pass most of the JS test suite. The worst was that it had several recursion bugs that could segfault with bad expressions. That was the now-deprecated im…

Why not issue a pull request to the JSONata Github project mentioning your implementation in the docs/READMEs? That goes for OP's port too of course.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#162

Post by Snafuh »

usrusr wrote: post #122
deckar01 wrote: post #65

Earlier quoted context omitted.

You aren’t accounting for managerial politics. A product manager won’t gamble on a large project to lower operating cost, when their bonus is based on customer acquisition metrics.

A bit sarcastic, but still too close to reality for comfort: For the managers, it's about a bonus. For engineers it's the existential question of future hirability: every future employer will love the candidate with experience in operating a $500k/a cluster. They guy who wrote a library that got linked into a service... Yeah, that's the kind they already have, not interested, move along.

The engineer who identified 500k in savings is a great candidate I'd say. But solving a problem requires a problem to be there in the first place.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#163

Post by pascahousut »

Aurornis wrote: post #19

The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…

My understanding is that it is a common and sad phenomenon of the cloud era that systems are unnecessarily complex and costly relative to the actual computational requirements mandated by the actual volume at which the system is realistically going to be used. For example, it is very easy to have more microservices than users because bootstrapping complicated systems has never been as easy as it is now, but architecting good systems and finding the correct problems to solve is just as hard as it has ever been.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#164

Post by kikimora »

simonw wrote: post #18
torben-friis wrote: post #16

>The approach was the same as Cloudflare’s vinext rewrite: port the official jsonata-js test suite to Go, then implement the evaluator until every test passes. the first question that comes to mind is: who takes care of this now? You had a dependency with an open source project. now your translated copy (fork?) is yours to maintain, 13k lines of go. how do you make sure it stays updated? Is this maintainance factored…

That's only important if the plan is to stay feature-compatible with the original going forward. For this case, where it's used as an internal filtering engine, I expect the goal is fixing bugs that show up and occasionally adding a feature that's needed by this organization.

In practice the biggest issue will be documentation and tutorials. If JSONata diverges from their fork users will have problems reconciling what they see online with their engine capabilities.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#165

Post by sarchertech »

DrBazza wrote: post #154
Aurornis wrote: post #19

The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…

Most of the other replies to this hit the nail on the head. A human writing some poor, but working code that is supposed to be a demo, goes to production 9 times out of 10. Then it becomes critical infrastructure. Then management cannot understand why something working needs a rewrite because there's no tangible numbers attached to it. The timeless classic developer problem. We were here ^^^^ up to 2024-2025. Now, wi…

Except if you’ve only spent a morning on it, no one has verified any of it, and it almost definitely has more bugs and technical debt than the original solution.

They might be different bugs and technical debt than the original, so it might take you long enough to run into them that the engineer who did it can take the credit for solving the original problem without taking the blame for the new ones.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#166

Post by throwaway2037 »

Aurornis wrote: post #19

The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…

Spot on. This is excellent analysis.

I was also bothered by this:

    > Until recently, I was rather skeptical of agentic code. February 2026, however, has been a sort of inflection point even stubborn developers like myself can’t ignore.
"February 2026" is just way to specific. It feels like a PR/marketing team wrote it. It acts like a jump scare in the post for any normie programmer.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#167

Post by vovavili »

pravetz259 wrote: post #33

Congrats! This author found a sub-optimal microservice and replaced it with inline code. This is the bread and butter work of good engineering. This is also part of the reason that microservices are dangerous. The bad engineering part is writing your own replacement for something that already exists. As other commenters here have noted, there were already two separate implementations of JSONata in Go. Why spend $400…

If I were in the author's shoes, I would have tried first to fork the other Go implementation of this JSON library, then use AI to pull it up to the modern standard and make it pass all his tests. Still, good job on him - this is what data engineering actually looks like.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#169

Post by sarchertech »

raincole wrote: post #130
Aurornis wrote: post #19

The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…

> Those same engineers will have to review and understand all of the AI-generated code now and then improve it, which will take time too. Will they? What makes you think so? If no one cared to improve it when it costed $300k/year, no one will care it when it's cheaper now.

They’ll be forced to work on it when then the bugs in the new system are uncovered.

If the system is simple enough someone might take enough time to understand and verify the test suite to the point where they can keep adding regression tests to it and maybe mostly call it done.

They probably won’t do this though (based on the situation the company was in in the first place) and people will have Claude fix it and write tests that no one verified. And in a while the test suite will be so full tests that reimplement the code instead of testing it that it will be mostly useless.

Then someone else will come in and vibe code a replacement that won’t have the bugs the current system does but will have a whole new set.

And the cycle will continue.

The same cycle that I’ve seen in the bottom 80% of companies I’ve worked for, just faster.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#170

Post by haspok »

nirb89 wrote: post #117

Hey all, I'm the author of the blog post. I'm honestly loving the discussion this is generating (including the less flattering comments here). I'll try to answer some of the assumptions I've seen, hopefully it clears a few things. First off - some numbers. We're a near real-time cybersecurity platform, and we ingest tens of billions of raw events daily from thousands of different endpoints across SaaS. Additionally,…

To me, the odd part is when you compare the performance of RPC vs inline code. You present it as if you found something new and foundational, only possible thanks to AI, when in fact, it has nothing to do with AI, and the results should be no surprise to anyone.

Your original architecture was a kludge to start with, it was a self-inflicted wound. This is probably the craziest part:

> We’d tried a few things over the years - optimizing expressions, output caching, and even embedding V8 directly into Go (to avoid the network hop).

I know hindsight is 20/20 - but still, you made the wrong decision at the start, and then you kept digging the hole deeper and deeper. Hopefully a good lesson for everyone working with microservices.

To end on a more positive note, I think this (porting code to other languages/platforms) is one use-case where AI code generation really shines, and will be of immense value in the future. Great reporting, just let's not confuse code generation with architectural decisions.

Post reply on HN