[dead]
We rewrote JSONata with AI in a day, saved $500k/year
201–210 of 278 posts
Re: We rewrote JSONata with AI in a day, saved $500k/year
#202The 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…
[deleted]
Re: We rewrote JSONata with AI in a day, saved $500k/year
#203Earlier quoted context omitted.
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.
Perhaps it's specific because it's Opus 4.6, released February 5th. https://www.anthropic.com/news/claude-opus-4-6
4.5 is a big jump, but there’s no way 4.5 to 4.6 is what convinced this person.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#204Earlier quoted context omitted.
The customer could be on the fence between you and a competitor and this customer could be potentially paying 10x more than all your existing customers together. It could make or break your company. They would go to the competitor immediately if you make it complicated for them and have delays with the setup. What do you do then?
Sounds like a bad business model then - if you have to depend on one single customer to make or break your company.
That’s the story of every early stage startup. Your first customer is the “make or break” customer. Once you’ve “made” it the first time, you then have to continue to “make” it to achieve growth.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#205Hey 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…
Oh, I don't disagree. The original vision and what the product ended up doing are light years apart. Likely, had we known what it would evolve into, we would have decided on a different solution (perhaps not JSONata at all, for example).
Having said that, My opinion still is that the previous solution had valid business merit. Though inefficient, the fact that it was infinitely scalable and the only limit was pure dollar cost is pretty valuable. It enables business stakeholders / managers to objectively quantify the value of the feature (for X dollars we get Y business, scaling linearly). I've worked in many systems where this was not at all the case, and there was a hard-limit at some point where the feature simply shut down.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#206Re: We rewrote JSONata with AI in a day, saved $500k/year
#207The 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…
> I don't know what to think. These blog articles are supposed to be a showcase of engineering expertise, but bragging about having AI vibecode a replacement for a critical part of your system that was questionably designed and costing as much as a fully-loaded FTE per year raises a lot of other questions.
I agree. But most of the time the people responsible for the codebase / architecture do not want those questions raised. AI is greatly appreciated emergency exit for those situations. Apparently.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#208this seems to be the way. make great technical improvement in a way that's nothing to do with AI. the only way to make executives happy is to then tenuously link it to AI usage.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#209The 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…
I could easily see this as a case where the team had a legacy area of code in a language that no one was familiar with anymore so no one felt great about actually contributing to it, so it languished, and now AI let them go "fuck it, let's just rewrite it".
Re: We rewrote JSONata with AI in a day, saved $500k/year
#210The 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…
I was thinking the same - if JSONata was a priority for them, why not choose a language with good support, like JS or Java? OTOH if development language was a priority why not choose a format that is well supported in it?
JSONata is present in AWS Step Functions, it's possible they want portability on-prem and into the cloud.