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, evaluate, serialize the result, and finally send it back.
> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added.
For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year.
The fact that this only took $400 of Claude tokens to completely rewrite makes it even more baffling. I can make $400 of Claude tokens disappear quickly in a large codebase. If they rewrote the entire thing with $400 of Claude tokens it couldn't have been that big. Within the range of something that engineers could have easily migrated by hand in a reasonable time. 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.
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.
Eh. If you get into enterprise business, this is the accepted management style. AI will now mix this up a little, but before you basically needed to ask if you want to blow 300k on developer salaries to maybe fix something that is already working and generating money, or add more features to the roadmap you can pin on your chest. Scaling infrastructure is the best choice for 90% of managers, especially since they are not the ones paying for it and this kind of technical debt doesn't matter on typical bonus check timeframes.
I used to work for AWS on a service team. I noticed we were spending way too much on provisioned concurrency for dynamo and would benefit from on-demand provisioning. After proving it worked, making the change, deploying, was rather pleased with myself. "Saved $2M in costs by switching to on-demand provisioning" barely made it onto my performance review lol.
They might just not have believed it. At the management level everyone is busy claiming to be delivering huge numbers all the time, and people stop trusting that sort of claim.
- the possibility of only partial success creating an even messier situation than the existing one
Having a way to do the whole thing on a much smaller timescale and budget lets decision makers focus more on those externalities, and also can simplify them. This kind of bit rot is somewhere (often everywhere) in many fast-moving businesses, as a natural consequence of the value tradeoffs we have had up to now. Now there are machines that can speedrun the grunt work of clearing them.
I mostly agree, but it's more appropriate to weigh contributions against an FTE's output rather than their input. If I have a $10m/yr feature I'm fleshing out now and a few more lined up afterward, it's often not worth the time to properly handle any minor $300k/yr boondoggle. It's only worth comparing to an FTE's fully loaded cost when you're actually able to hire to fix it, and that's trickier since it takes time away from the core team producing those actually valuable features and tends to result in slower progress from large-team overhead even after onboarding. Plus, even if you could hire to fix it, wouldn't you want them to work on those more valuable features first?
They were running a big kubernetes infrastructure to handle all of these RPC calls.
That takes a lot of engineer hours to set up and maintain. This architecture didn't just happen, it took a lot of FTE hours to get it working and keep it that way.
Kube is trivial to run. You hit a few switches on GKE/EKS and then a few simple configs. It doesn't take very many engineer hours to run. Infrastructure these days is trivial to operate. As an example, I run a datacenter cluster myself for a micro-SaaS in the process of SOC2 Type 2 compliance. The infra itself is pretty reliable. I had to run some power-kill sims before I traveled and it came back A+. With GKE/EKS this is even easier.
Over the years of running these I think the key is to keep the cluster config manual and then you just deploy your YAMLs from a repo with hydration of secrets or whatever.
The cost is not just tokens, you need an actual human contributor looking into the issue, prompting, checking output, validating, deploying,... Difficult to compute the actual AI ROI. If $300K didn't matter without AI, it probably still doesn't matter with AI.
Exactly. Reddit did one last year like: “We migrated from python to golang and fixed a bunch of non-performant SQL queries. It was so fast, isn’t golang awesome?”
I was once asked to migrate a Microsoft Access application to C#/MS SQL Server because it was too slow. I just added a few database indexes to make it an order of magnitude faster.
(They still wanted to go ahead with the migration, but that's a different story.)
I have about a dozen projects I’d love to tackle in this vein. (Not as low hanging fruit, but enough effort they’re languishing in the backlog.) we’ll actually be able to get to more those projects with agents and good specs
> 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.
Opus 4.5 to 4.6 was pretty incremental, I didn't see much of a difference.
The big coding model moments in recent recollection, IMO, were something like:
- Sonnet 3.5 update in October 2024: ability to generate actually-working code using context from a codebase became genuinely feasible.
- Claude 4 release in May 2025: big tool calling improvements meant that agentic editors like Claude Code could operate on a noticeably longer leash without falling apart.
- Gemini 3 Pro, Claude 4.5, GPT 5.2 in Nov/Dec 2025: with some caveats these were a pretty major jump in the difficulty and scale of tasks that coding assistants are able to handle, working on much more complex projects over longer time scales without supervision, and testing their own work effectively.
Maybe they're like me, who didn't spend a lot of time investigating Claude until 4.6 launched and the hype was enough to be the tipping point to invest energy. I do know that I've been having good/great results with Opus 4.6 and the CLI, but after an hour or so, it'll suddenly forget that the codebase has tab-formatted files and burn up my quota trying to figure out how to read text files. And apparently this snafu has been around since at least late last year [0]. Again, I can't complain about the overall speed and quality for my relatively light projects, I'm just fascinated by people who say their agents can get through a whole weekend without supervision, when even 4.6 appears to randomly get tripped up in a very rookie way?
There's definitely a productivity curve element to getting it to behave effectively within a given codebase. Certainly in the codebases I work with most frequently I find Claude will forget certain key aspects (how to run the tests or something) after a while and need a reminder, otherwise it gets into a loop like that trying to figure out how to do it from first principles with slightly incorrect commands.
I think a lot of the noise about letting Claude run for very extended periods involves relatively greenfield projects where the AI is going to be using tools and patterns and choices that are heavily represented in training data (unless you tell it not to), which I think are more likely to result in a codebase that lends itself to ongoing AI work. People also just exaggerate and talk about the one time doing that actually worked vs the 37 times Claude required more handholding.
The bigger problem I see with the "leave it running for the weekend" type work is that, even if it doesn't get caught up on something trivial like tabs vs spaces (glad we're keeping that one alive in the AI era, lol), it will accumulate bad decisions about project structure/architecture/design that become really annoying to untie, and that amount to a flavor of technical debt that makes it harder for agents themselves to continue to make forward progress. Lots of insidious little things: creating giant files that eventually create context problems, duplicating important methods willy nilly and modifying them independently so their implementations drift apart, writing tests that are..."designed to pass" in a way that creates a false sense of confidence when they're passing, and "forest for the trees" kind of issues where the AI gets the logic right inside a crucial method so it looks good at a glance, but it misses some kind of bigger picture flaw in the way the rest of the code actually uses that method.
This is also supported by the Opus degradation tracker [1]. The dotted line is when they switched from Opus 4.5 to 4.6. There's no difference on statistically significant difference the tested benchmark.
Whatever I used Sonnet 4.6 for, including Claude Code and Claude Chat, it made so many mistakes and totally awkward assumptions that I can’t fathom what it’s supposed to be good at. The mistakes were so blatant. Plan mode, several passes, couple grand in API costs… just disappointing at every task in every session over the past few weeks. Opus 4.6 has been good, still quite a few unexpected, silly mistakes, a few subtle but critical mistakes, but produced workable increments and code reviews, vastly subpar to GPT-5.x in chat mode (with and without identical customization).
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, with LLMs, you can at least come up with a vibe coded, likely correct, likely faster, solution in a morning, that management won't moan at you about.
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.
> If they rewrote the entire thing with $400 of Claude tokens it couldn't have been that big.
The original is ~10k lines of JS + a few hundred for a test harness. You can probably oneshot this with a $20/month Codex subscription and not even use up your daily allowance.
In my experience, a lot of these types of migrations aren't incredibly deep in terms of actual code being written. It's about being able to assess all of the affected facets accurately. Once that's all mapped out, it's pretty straight forward to migrate.
Wonder if the real value of LLMs/AI is similar to microservices in that it solves an organisational/culture problem.
In this case AI allowed the developer to make a change that the organisation would not have allowed. Regular rewrites don't let you signal to investors that you are AI ready/ascendant/agentic (whatever the latest AI hype term is) so would have been blocked. But, an AI rewrite.
That assumes they don't accelerate the accumulation of technical debt. For each item cleared how many new ones are added. LLMs accelerate your good engineers and your bad ones. So the slop likely increase faster than it can be cleared.
And it will affect good engineers and turn them into worse engineers too
AI benefits rely on these good engineers having 5, 10, 20 years of experience pre-AI designing (and fully, thoroughly understanding) these systems. What's going to happen to that engineering skill after 15 years of AI use?
It ought to only get better as it gets honed at an even faster pace than before, utilizing techniques and algorithms that would have been out of reach due to outside constraints.
> 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.
> But most of the time the people responsible for the codebase / architecture do not want those questions raised.
I don't know if that matches my experience. I've seen plenty of places where the dev teams complain about tech debt and other kludges costing too much, slowing them down and causing other problems, but management don't want to "waste time re-writing working code".
But now that management read on linkedin they can jump on the AI bandwagon by having the team use AI to fix tech debt, there's suddenly time to work on it.
Eliminating manual toil seems like a huge win for LLMs. There are a ton of straightforward-but-tedious projects that no one wants to fund because they take 2 dev weeks to implement and the result is a hard to quantify quality of codebase improvement. Some of these can now be handled by an LLM in a day and so they suddenly become extremely tractable. You don’t have to embrace vibe coding to benefit from cheap debt pay down.
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.
"For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year."
You build something that's a dirty hack but it works, then your company grows, and nobody ever gets around to building it.
I was at a place spending over $4 million a year on redshift basically because someone had slapped together some bad (but effective!) queries when the company was new, and then they grew, and so many things had been built on top they were terrified to touch anything underneath.
This was amazingly common in the 2010s during the Big Data craze. I know, because I was the one slapping the bad queries together.
Most startups didn’t care (to a point) because at that point in their lifecycle, the information they needed to get from those queries (and actions they could take based on it, like which customers were likely to convert and worth spending sales time on, etc) was more important than the money spent on the insane redshift clusters.
The mantra was almost always some version of, “just do it now, as fast as possible, and if we’re still alive in a year we’ll optimize then.”
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.
The original author said he built this on the weekend, so my assumption is that this was something engineers had advocated for before but were shut down because management wanted them elsewhere.
The use of ai agents allowed them to shrink the problem down to the point where it was small enough to fit in their free time and not interrupt their assigned work.
Why are engineers spending their week-end on saving their company money especially if the company clearly doesn't care to allocate resources to the problem?
I get that it's fun and there's personal satisfaction in it, but it just reinforces to management that they don't need to care about allocating resources to optimisation, the problem will just take care of itself for free.
At some point it's hard not to care about the work you do everyday. And if you care, then you are going to find yourself donating a Saturday here or there to solving big DevEx papercuts that you can't convince management to care about.
Should it be this way? No. Is it this way in practice? Unfortunately often.
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.
I wonder how much it would have cost them if they weren't paying cloud rates for all of that, and they kept the same general inefficient architecture, sans the Kubernetes bloat.
Doubt they'd have a blog post to write about that, though.
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.
I have a crash reporting system that sends me crash information in text file: callstack of crashed thread, basic os info and logs of this execution.
The way I (well, claude) fixed this bug is: I said "analyze crash report: <paste crash report>" and it does it in under a minute.
Recently I've fixed at least 30 bugs with this process (you can view recent checkins).
Those are crashes that I found hard to fix because even though by human standard I'm both expert developer and expert Windows API developer.
But I'm not an autistic machine that can just connect the dots between how every windows api works and how it ties to the callstack and information from the log, in under a minute.
Fixing a bug is in the wheelhouse of AI to the extent that the fix can be verified — since there is a clear objective function. The real question is whether there are unintended side effects (e.g., new bugs that get introduced) or whether the test cases are comprehensive enough to determine whether the fix worked.
There's nothing I love more than unfounded arrogance.
How about you try to make a change to SumatraPDF code base.
Let's see how good of an engineer you are when you actually have to write a line of C++ code in complex codebase as opposed to commenting on a check in with an explanation of the issue and a fix.
A more charitable explanation would be that they were under product pressure for more features and were never given the slack time to even explore this angle. Happens a lot.
The practical key point is: if you want to do a large migration is to have a very good & extensive test suite that Claude is not allowed to change during the migration. Then Claude is extremely impressive and accurate migrating your codebase and needs minimal handholding. If you don't have a test suite, claude will be freewheeling all the way. Just did an extensive migration project, and should have focused on the test suite much more.
Yeah, apparently the original library has nearly 4,000 tests. This would have been impossible without those. This speaks to the power of testing. The lack of discussion here also shows how under-valued it is.
I've seen it happen and it's usually just Normalization of Deviance in an organization that is focusing on something else. Someone needs some kind of functionality and Kube makes creating services trivial so they launch it into a different service[0]. Over time, while people are working on important things this thing occasionally has load issues so someone goes and bumps the maxReplicas up periodically. Eventually you come back to it a year later and maxReplicas is at 24 and you've removed the code paths for almost everything that is hitting the server except some inexplicable hot-loop.
Then you look at it and you're like "Jesus! What the fuck, I meant to have this be a stop-gap". I've done as bad when at near 100% duty-cycle. Often you're targeting just the primary thing that's blocking some revenue and if you get caught yak-shaving you're screwed. A year ago, I did one of these things because I was in the middle of two projects that were blocking a potential hundred-million in revenue.
A year down the line, Claude Opus 4.6 could have live-solved it. But Claude of that time would have required some time and attention and I was doing something else.
That engineering team is some 15 people strong and the company is at $400m+ revenue. If you saw the code, you'd wonder why anyone would have done something like this.
0: I once did this because some inscrutable code/library was tying us to an old runtime so I just encapsulated it in HTTP and moved it into a service.
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?
Completely agree. We have > $50m from our most recent funding round, and even a cloud expense of $50k/year (in our case for storage) is considered a high priority to address. If it was $300k, our CTO would be running around with a butane torch setting everyone’s hair on fire until the problem was resolved.
But, venture funding does create a lot of weird inefficiencies which vary from company to company.
But what is your income? How important it is to address should be compared to that and current profits too if any, and whether you have to be profitable right now.
First, I have to make a major correction: the cost I was thinking of is over $50k/month, not year, so over $600k/year. But it was still considered a big issue when it was at $300k, which wasn’t that long ago.
The reason it matters is (1) because it’s directly relevant to profitability projections, i.e. cost per customer, and (2) because management looks at those numbers and sees potential headcount.
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".
Think this is pure piggyback marketing on what cloudflare did with next.js. In my experience a company that raised $30MM a month ago is extremely unlikely to be investing energy in cost rationalization/optimization.
edit: saw the total raise not the incremental 30MM
No offence, but inexperienced JS fanatics always do this because of some weird affectionado they have for the language itself. Otherwise, even a decently qualified CTO would have chosen to keep everything in Go from the beginning or might have not waited until they were bleeding $300k. JS is also the worst possible language choice for this problem. So, it definitely sounds a bunch of script kiddies with fancy titles bought with VC money rather than actual experience.
What if you are about to get a potentially really high paying customer, but they might go elsewhere unless you deliver X feature immediately and it is so much quicker to do it with the JS script?
Given that the potential high paying customer is just that - a potential, one must always keep the long term platform stability in mind as it affects every other customer, not just this potential customer. Hence, it boils down to opportunity cost and setting the right expectations:
We can deliver feature X for you - incrementally broken down into sub-features x1, x2, x3 over a period of Y weeks/months
The other way to do this would be to build a custom integration on top of your existing APIs and beta test it alongside the customer, bill them accordingly and eventually merge the changes into the main platform, once you can guarantee stability.
But, both these methods will sound boring to VC funded companies as they are under constant pressure from VCs to show something in their weekly graphs - meaningful or not.
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?
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.
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.
Early in 2025 I used Claude Code and Codex to do a proper, compliant port that passes the full set of tests and is safe. It was most certainly not a trivial task for AI, as many nuances of JSONata syntax derive from its JS roots.
Regardless, it was a great experience and here's the 2.0.6 AI port, along with a golang exerciser that lets you flip back and forth between the implementations. We did a seamless migration and it's been running beautifully in prod in Blues' Notehub for quite a while - as a core transformation capability used by customers in our JSON message pipeline.
I was also involved in writing a clean-slate port of JSONata after finding issues in the jsonata-go repo and not wanting to run the javascript version in a sandbox. It was relatively easy until we stressed it with 20 layers of nested context and 5000 line expressions and suddenly we had memory explosions not present in the JS version.
JSONata is too tied to the language. Looking back, we should have slightly altered the spec and written some code mods. we didn't have customers bringing their existing JSONata over so they wouldn't notice the differences.
> At Reco, we have a policy engine that evaluates JSONata expressions against every message in our data pipeline - billions of events, on thousands of distinct expressions.
The original architecture choice and price almost gave me a brain aneurysm, but the "build it with AI" solution is also under-considered.
This looks like a perfect candidate for existing, high quality, high performance, production grade solutions such quamina (independent successor to aws/event-ruler, and ancestor to quamina-rs).
There's going to be a lot of "we were doing something stupid and we solved it by doing something stupid with AI [LLM code]" in our near future. :-|
As far as I see it, AI is the reason they're unnecessarily paying 300k/year in the first place. A human engineer was the one that identified the problem with this JS dependency, and the human told then made AI fix its' original mistake.
>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 in?
I know nothing about JSONata or the problem it solves, but I took a look at the repo and there's 15PRs and 150 open issues.
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.
>expect the goal is fixing bugs that show up and occasionally adding a feature that's needed by this organization.
Even if we assume a clean and bug free port, and no compatibility required moving forward, and a scope that doesn't involve security risks, that's already non trivial, since it's a codebase no one has context of.
Probably not 500k worth of maintainance (because wtf were they doing in the first place) but I don't buy placing the current cost at 0.
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.
The full translation took 7hrs and $400 in tokens. Applying diffs every quarter using AI is much easier and cheaper. Software engineering has completely changed.
except there are 2 go implementations already, and he burnt 500k per year to have a kubernetes clusters to parse json (???), so the total gain is -500000*year - 400 + 1 (deducting prompt to use existing implementation)
The headline seems to be flashy indeed, but ai didn't really solve this imo.
They just seemed to fix their technology choices and got the benefits.
There's existing golang versions of jsonata, so this could have been achieved with those libraries too in theory. There's nothing written about why the existing libraries aren't good enough and why a new one needed to be written. Usually you need to do some due diligence in this area, but no mentions of it in this post
In order to measure the real efficiency, gnata should've been benchmarked against the existing golang libraries. For all we know, the ai implementation is much slower.
The benchmarks in the blog are also weird. The measurement is done within the app, but you're meant to measure the calls within the library itself (e.g calling the js version in its isolated benchmark vs go version in its isolated benchmark). So you don't actually know what the actual performance of the ai written version is?
The only benefit, again, is that they fixed their existing bad technology choice, and based on what is observed, with a lesser bad technology choice. Then it's layered with clickbait marketing titles for others to read.
I'll probably need to expect more of these types of posts in the future.
> There's existing golang versions of jsonata, so this could have been achieved with those libraries too in theory
The only one I found (jsonata-go) is a port of JSONata 1.x, while the gnata library they've published is compatible with the 2.x syntax. Guess that's why.
Looking at the releases, it looks like JSONata's 2.1.0 release from July 2025 added the `?:` and `??` syntax, and there hasn't been an update to the syntax since January 2020's 1.8.0 release that added `%`
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 to have Claude rewrite something when you can just use an already existing, already supported library?
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.
They said in the article that they were running up to 200 pods at a time. Doing some back of the envelope math, 200 pods at $300,000 year is about $0.17/hour, which is exactly what an EC2 c5.xlarge costs per hour (on demand). That has 4 vCPUs, so about 800 vCPUs during peak, with $0.0425/CPU-hour.
I do have some questions like:
* Did they estimate cost savings based on peak capacity, as though it were running 24x7x365?
* Did they use auto scaling to keep costs low?
* Were they wasting capacity by running a single-threaded app (Node-based) on multi-CPU hardware? (My guess is no, but anything is possible)
It is, by orders of magnitude, larger than any deployment that I have been a part of in my work experience, as a 10-year data scientist/Python developer.
This is larger than the resources I have available at Medium-Size-Fabless-Semi-Inc, and larger than the time I had two racks of C++ build farm. It is of course way larger than StackOverflow, which ran for years on two large machines.
>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, evaluate, serialize the result, and finally send it back.
But either way, we're talking $25k/mo. That's not even remotely difficult to believe.
First I thought they were AWS lambda functions, perhaps possible if they are over-provisioned for very concurrency or something similar $25k/month is in realm of possibility.
But no, the the post is talking about just RPC calls on k8s pods running docker images, for saving $300k/year, their compute bill should be well above $100M/year.
Perhaps if it was Google scale of events for billions of users daily, paired with the poorest/inefficient processing engine, using zero caching layer and very badly written rules, maybe it is possible.
Feels like it is just an SEO article designed to catch reader's attention.
It has to be satire right? Like, you aren't out of touch on this. I get engineers maybe making the argument that $300k / year on cloud is the same as 1.5 devops engineers managing in-house solutions, but for just json parsing????
For numbers like that, I can never tell whether it's just a vastly larger-scale dataset than any that I've seen as a non-FAANG engineer, OR, a hilariously-wasteful application of "mAnAgEd cLoUd sErViCeS" to a job that I could do on a $200/month EC2 instance with one sinatra app running per core. This is a made-up comparison of course, not a specific claim. But I've definitely run little $40 k8s clusters that replaced $800/month paid services and never even hit 60% CPU.
It can be, but $500k/year is absurd. It's like they went from the most inefficient system possible to create, to a regular normal system that an average programmer could manage.
I have no idea if they are doing orders of magnitude more processing, but I crunch through 60GB of JSON data in about 3000 files regularly on my local 20-thread machine using nodejs workers to do deep and sometimes complicated queries and data manipulation. It's not exactly lightning fast, but it's free and it crunches through any task in about 3 or 4 minutes or less.
The main cost is downloading the compressed files from S3, but if I really wanted to I could process it all in AWS. It also could go much faster on better hardware. If I have a really big task I want done quickly, I can start up dozens or hundreds of EC2 instances to run the task, and it would take practically no time at all... seconds. Still has to be cheaper than what they were doing.
Curious about the workload, but as Im trying to make a tool about json, what are those files compressed with? What is the size of the average file ? What is their structure (ndjson ? Dict with some huge data structure a few level deep?)
In S3 the JSON is stored in plain-old .zip files. While downloading to local the files are unzipped to plain old JSON. It's basically an object containing tons of data about each website I manage including all fragments of HTML and metadata used on the sites. It can get quite large, some sites have thousands of pages. We often need to find things stored many levels deep in the JSON that may be tricky to find, it isn't usually a specific path, and lots of iterable arrays and objects are involved. The files range from ~20MB to ~400MB, depending on how much content each site has. And we have ~9000 total sites.
Well, for starters, they replace the RPC call with an in-process function call. But my point is anybody who's surprised that working with JSON at scale is expensive (because hey it's just JSON!) shouldn't be surprised.
Well everything is expensive at scale, and any deserialization/serialization step is going to be expensive if you do it enough. However
yes i would be surprised. JSON parsing is pretty optimized now, i suspect most "json parsing at scale is expensive" is really the fault of other parts of the stack
You didn't say it was stupid. If you had, I would have just ignored the comment. But you expressed a level of surprised that led me to believe you're unfamiliar with how much of a pain in the ass JSON parsing is.
I think OP’s point was surprise that a company would spend so much on such inefficient json parsing. I’m agreeing. I get that JSON is not the fastest format to parse, but the overarching point is that you would expect changes to be made well before you’re spending $300k on it. Or in a slightly more ideal world, you wouldn't architect something so inefficient in the first place.
But it's common for engineers to blow insane amounts of money unnecessarily on inefficient solutions for "reasons". Sort of reminds me of saas's offering 100 concurrent "serverless" WS connections for like $50 / month - some devs buy into this nonsense.
Because his prompt said to implement in go, not to check if an go implementation already exists.
They have been running kubernetes clusters to parse json, this is not suprising.
With legacy systems, at least the complexity was somewhat anticipated early in the design process (even if it was incorrect).
With automatically generated code, you get something that "works" but with a much vaguer underlying model, which makes it harder to understand when things start to go wrong.
In both cases, the real cost comes later, when you're forced to debug under pressure.
If they're vendoring the dependency anyway, that wouldn't matter much if they're not using features that were added since 2021.
The last release of jsonata was mid 2025, and there hasn't been new features since the last 2022 release until the latest, so it's likely those other ports are fine.
This isn’t the first time I’ve read a ridiculous story like this on hackernews. It seems to be a symptom of startups who suddenly get a cash injection with no clue how to properly manage it. I have been slowly scaling a product over the past 12 years, on income alone, so I guess I see things differently, but I could never allow such a ridiculous spend on something so trivial reach even 1% of this level before squashing it.
I'm just kind of confused what took them so long. So it was costing 300k a year, plus causing deployment headaches, etc.
But its a realitively simple tool from the looks of it. It seems like their are many competitors, some already written in go.
Its kind of weird why they waited so long to do this. Why even need AI? This looks like the sort of thing you could port by hand in less than a week (possibly even in a day).
Not saying it is a good thing, but an organization, especially if there has been a lot of turnover, can enter a state of status quo.
> it must have that architecture for a reason, we don't enough knowledge about it to touch it, etc.
That or they simply haven't had the time, cost can creep up over time. 300k is a lot though. Especially for just 200 replicas.
Seems wildly in-efficient. I also don't understand why you wouldn't just bundle these with the application in question. Have the go service and nodejs service in the same pod / container. It can even use sockets, it should be pretty much instant (sub ms) for rpc between them.
My takeaway is almost the opposite. A company that has scaled to the point that they need 200 replicas of JSONata costing 300k/yr must be spending so much on compute that the difference is absolutely peanuts.
> 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.
> This was costing us ~$300K/year in compute
Wooof. As soon as that kind of spend hit my radar for this sort of service I would have given my most autistic and senior engineer a private office and the sole task of eliminating this from the stack.
At any point did anyone step back and ask if jsonata was the right tool in the first place? I cannot make any judgements here without seeing real world examples of the rules themselves and the ways that they are leveraged. Is this policy language intentionally JSON for portability with other systems, or for editing by end users?
And no, there are no dependencies in package.json either (other than devDependencies for tests).
Which cumulatively means a competent developer could probably port it in less than one day.
They almost certainly spent longer working out how to deploy and integrate the original JS and ironing out the problems, than it would have taken to port it in the first place.
That’s sad.
And then they definitely spent much longer making their optimised fast path for simple expressions. Which they probably wouldn’t have bothered with if they had just ported the whole thing.
As for trying things like embedding V8… this is getting ridiculous.
I strongly suspect no one had actually looked at the code, but had just assumed all along that it was much more complex than it actually was.
Java => Go is easier than JavaScript => Go because languages are more similar. That was a very line-by-line port.
Because I was paid by hour I took detailed notes.
I spent 601 hours to port it.
50k / 601 = 83 lines ported per hour, 665 per 8 hour day, but really 500 per 6 working hours a day. No one does sustained 8 hours of writing code daily.
I would consider that very fast and yet order of magnitude slower than your 5.5 k per day.
10x is not a mis-estimation, it's a full blown delusion.
I stand by my estimate, also having done interlanguage ports. I’m not saying any project of such size could be ported in one day, but this very much looks to be one of the more straightforward ones. Being a small project also accelerates things, as there are far fewer moving parts, concepts, &c. to keep in order.
I wouldn’t say that Java → Go is inherently easier than JavaScript → Go. There are more features in JavaScript that, if used, will make porting much harder, but they may well not be used. There’s a bit of async in this project, that’s probably the hardest bit, and maybe a little variadic calling. But comparing with your case, some challenges just aren’t there, such as inheritance and access control.
From a quick skim, I think perhaps 2000 lines will need no change beyond removing semicolons. And since this is mostly parser and AST sort of stuff, a lot of the rest is mechanical repetition and application of regular expression replacements or editor macros.
One note from your article, on fluent function chaining:
> This only works in languages that communicate errors via exceptions. When a function additionally returns an error, it’s no longer possible to chain it like that.
This is a Go limitation, not fundamental. (And Go is well known to be bad or at least verbose at error propagation.) Rust’s ? operator is an easy counterexample.
If they were paying $500k/year, why haven't they paid someone to rewrite it? Surely would be cheaper still.
But above everything else, this is a great example of how much JavaScript inefficiency actually costs us, as humanity. How many companies burn money through like this?
On top of that there are probably a few more hits for the containers, vm and hypervisor, all those pods have monitoring etc. All the layers of abstraction are just stacks of turtles giving the illusion of being easier but adding complexity and cost/overhead.
It is a security product, so unless they want to deal with the exfiltration charges on the data it's probably better to keep it in AWS. Thats the nasty double edge sword of "cloud", and how we're all getting locked in.
All the bits on their own seem to make perfect sense, but it's become apparent that the orchestra has been blind folded and given noise canceling head phones.
Anyone who ships a k8s cluster to make a JS library available over RPC needs to have a long hard look in the mirror. Should have bundled node, quickjs, anything into the go nodes for the first pass. k8s truly is a cancer for many teams.
I’ve predicted the future and I’ve figured out where vibe coding is going to go based on this article.
1. People are going to come in and vibe code a replacement for some shitty component in a morning. They aren’t going to take time to verify and understand the code.
2. The new code will fix most of the problems with the original component, but it will have a whole new set of issues.
3. People will use AI to fix the bugs, but they won’t take the time to understand the fixes or the regression tests that they tell AI to add.
4. The new system will get so complicated that it’s hard for even AI to work on it. The “test suite” will be so full of tests that are redundant, and nonsensical that the run time will be too high to meaningfully guide AI. And even in the cases where AI does use it, many of the tests are just reimplementing the code under test in the test (Claude does this about 25% of the time based on what I’ve seen if you don’t catch it).
5. Goto 1
This is the same cycle I’ve seen in 90% of companies I’ve worked at, it will just be on a faster cadence.
And that is how we’ll get to a place where we output 100x lines of code, and spend 2x developers salaries on tokens, with little meaningful impact on the outside world.
> The new system will get so complicated that it’s hard for even AI to work on it.
I used AI to refactor several of my own "move fast and break things" projects and it worked absolutely GREAT. So if that's what you're concerned about, you're not seeing where the puck is going.
> I shared the numbers internally and someone asked about the ROI. Production cost for jsonata-js in the previous month was about $25K - now it was 0. That conversation ended up being pretty short.
I'm obviously projecting from my own experience, but it echoes so clearly how power can be wielded without actual insight and an almost arrogantly: "OK, all very nice, but the ROI...?"
The article seems to come from a company with stellar engineering so maybe doesn't apply to this case. But, the tone I imagine from that comment still stands out. To me more, precisely because of the mature engineering.
Of course ROI is important and a company exists to build it. I'm extrapolating from something tiny and thinking of the Boeing culture shift: https://news.ycombinator.com/item?id=25677848
In short, why can't good engineering just be good engineering fostered with trust and then profits?
In my mind, this "observation" (if I can call it that) may explain or at least relate to what other commenters bring:
> 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.
As others have said, the title is bollocks. For any mismanaged infrastructure you can make these crazy claims. If they did it today it would be ”saved $100/year”.
The thing is, if it took them a day with AI it would’ve been _at most_ a week without it. So why did they wait? Someone is not being responsible with the company funds.
how many billions of compute are wasted because this industry can't align on some binary format across all languages and APIs and instead keep serializing and deserializing things
ASN.1 and its on the wire format BER and DER have been available for close to 30+ years and it is running on billions of devices(cryptography, SSL, etc) and other critical infrastructures.
but, it is very boring stable, which means I can't tell the world about my wartime stories and write a blog about it.
JSON is not really the core issue which is the expression parser. "user.name = foo and user.id > 1000". Even if you were operating on binary data, turning an arbitrary pseudocode string into actual function logic + executing it would be the slow part.
See Next.js, over a decade of iterative development. Countless vulnerabilities discovered internally, and externally, which got patches with tribal knowledge acquired by core contributors, security reviewers.
Now Joe shows off he rewrote it with Vite at its core, for just 1,100 dollars worth of token. Performance improvement and no licensing liability.
Outcome: more money for Nvidia, and even more money into the pockets of your next hackers.
One day a kid came home breathing heavily, to his father’s surprise face he tells, daddy daddy, I saved a dollar fifty!
How did you do it? ask the father
Instead of taking the bus, I ran after it all the way home.
If you were smarter, you could have save us $22 by running after a taxi!
This old joke came to mind while reading this post.
A tech company spends hundreds of thousands of dollars per year, “for years”, on a piece of software that could have been replaced by a month of coding top? (prior to LLM and all), you sit and write and save the money.
If I was an investor in this company I would have hire a team to look through their entire stack. See, if this JSON thingy alone is half a million a year, their entire cloud is at least $35MM annually.
Perhaps this is not even a bad business idea. One can offer companies to provide drop-in replacement for their costly “micro services that no one dares to touch” and share the cost savings.
These articles remind me so much of those old internet debates about "teleportation" and consciousness.
Your physical form is destructively read into data, sent via radio signal, and reconstructed on the other end. Is it still you? Did you teleport, or did you die in the fancy paper shredder/fax machine?
If vibe code is never fully reviewed and edited, then it's not "alive" and effectively zombie code?
> 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.
This makes me wonder, for reimplementation projects like this that aren't lucky enough to have super-extensive test suites, how good are LLM's at taking existing code bases and writing tests for every single piece of logic, every code path? So that you can then do a "cleanish-room" reimplementation in a different language (or even same language) using these tests?
Obviously the easy part is getting the LLM's to write lots of tests, which is then trivial to iterate until they all pass on the original code. The hard parts are how to verify that the tests cover all possible code paths and edge cases, and how to reliably trigger certain internal code paths.
I've found Claude Code with Opus 4.5+ to be excellent at generating test cases that exercise the different features, and even push into the edge cases. You sometimes need to nudge it into generating more convoluted cases when necessary, but then it is just nudging. I now routinely generate more LOCs of test cases than actual core code, while I used to only write very limited test cases just for the most complex areas amenable to automated testing.
I've been successful at using Claude Code this way:
1. get it to generate code for complex data structures in a separate library project
2. use the code inside a complex existing project (no LLM here)
3. then find a bug in the project, with some fuzzy clues as to causes
4. tell CC about the bug and ask it to generate intensive test cases in the direction of the fuzzy clues
5. get the test cases to reproduce the bug and then CC to fix it by itself
6. take the new code back to the full project and see the issue fixed
All this using C++. I've been a pretty intensive developer for ~35 years. I've done this kind of thing by hand a million times, not any more. We really live in the future now.
Yeah, that's why I said clean-ish room. I'm thinking more about open source projects here that you just want available in a new language, without any architectural "cruft" copied from the original (since different language idioms may imply different architectures), than trying to evade copyright on something commercial. Most commercial stuff isn't making its code base public in the first place anyways.
As long as you are using JSON, you will be able to optimize.
Did you know that you can pass numbers up to 2 billion in 4 constant bytes instead of as a string of 20 average dynamic bytes? Also, fun fact, you can cut your packets in half by not repeating the names of your variables in every packet, you can instead use a positional system where cardinality represents the type of the variable.
And you can do all of this with pre AI technology!
Like other commenters already said, there are numerous ways they could have avoided/reduced the $500k/yr cost pre LLM, including simply paying someone to do port the code.
With my favorite database (Gel) effectively dead (team acquihire by Vercel), I told Claude to reimplement it in Deno/TypeScript. While I haven't tested it on a real project yet (on my TODO for tmrw), hundreds of tests pass so we'll see.
If it does work I'll do a Show HN in a few months. One thing I always do with LLM-code though is review every single line (mainly because I'm particular with formatting). disc.sh is gonna be the domain when I launch the marketing site.
You also really need to review its logic too, because it has a tendency to lack the full context of the code it’s working on, and make very silly logic mistakes.
Huh, I just did basically the same thing. My requirements were not due to spending $300k/yr on parsing (lol), but I was amazed how far I got just asking the AI for progressively more functionality.
My use case is a bit different. I wanted JSONata as the query language to query Flatbuffers data (via schema introspection) in Rust, due to its terseness and expressiveness, which is a great combination for AI generated queries.
This problem existed for years, so at some point decided it wasn't worth fixing and that decision just stuck. I wonder how many companies have multiple of these types of problems that they aren't addressing.
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, a significant subset of our customers are quite large (think Fortune 500 and up). For the engine, that means a few things:
- It was designed to be dynamic by nature, so that both out-of-the-box and user-defined expressions evaluate seamlessly.
- Schemas vary wildly, of which there are thousands, since they are received from external sources. Often with little documentation.
- A matching expression needs to be alerted on immediately, as these are critical to business safety (no use triggering an alert on a breached account a day later).
- Endpoints change and break on a near-weekly basis, so being able to update expressions on the fly is integral to the process, and should not require changes by the dev team.
Now to answer some questions:
- Why JSONata: others have mentioned it here, but it is a fantastic and expressive framework with a very detailed spec. It fits naturally into a system that is primarily NOT maintained by engineers, but instead by analysts and end-users that often have little coding expertise.
- Why not a pre-existing library: believe me, we tried that first. None actually match the reference spec reliably. We tried multiple Go, Rust and even Java implementations. They all broke on multiple existing expressions, and were not reliably maintained.
- Why JSON at all (and not a normalized pipeline): we have one! Our main flow is much more of a classic ELT, with strongly-defined schemas and distributed processing engines (i.e. Spark). It ingests quite a lot more traffic than gnata does, and is obviously more efficient at scale. However, we have different processes for separate use-cases, as I suspect most of the organizations you work at do as well.
- Why Go and not Java/JS/Rust: well, because that's our backend. The rule engine is not JUST for evaluating JSONata expressions. There are a lot of layers involving many aspects of the system, one of which is gnata. A matching event must pass all these layers before it even gets to the evaluation part. Unless we rewrote our backend out in JS, no other language would have really mitigated the problem.
Finally, regarding the $300k/year cost (which many here seem to be horrified by) - it seems I wasn't clear enough in the blog. 200 pods was not the entire fleet, and it was not statically set. It was a single cluster at peak time. We have multiple clusters, each with their own traffic patterns and auto-scaling configurations. The total cost was $25k/month when summed as a whole.
Being slightly defensive here, but that really is not that dramatic a number when you take into account the business requirements to get such a flexible system up and running (with low latency). And yes, it was a cost sink we were aware of, but as others have mentioned - business ROI is just as important as pure dollar cost. It is a core feature that our customers rely on heavily, and changing its base infrastructure was neither trivial nor cost-effective in human-hours. AI completely changed that, and so I took it as a challenge to see how far it could go. gnata was the result.
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.
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.
I wonder whether this was your first attempt to solve this issue with LLMs, and this was the time you finally felt they were good enough for the job. Did you try doing this switch earlier on, for example last year when Claude Code was released?
Honestly, I was very adverse to agentic code up until Opus came out. The hallucinations and false confidence it had in objectively wrong answers just broke more things than it fixed.
However after it came out it suddenly behaved closely to what they marketed it as being. So it was my first real end-to-end project relying on AI at the front seat. Though design wise it is nowhere near perfect, I was holding it's hand the entire way throughout.
> Finally, regarding the $300k/year cost (which many here seem to be horrified by) - it seems I wasn't clear enough in the blog. 200 pods was not the entire fleet, and it was not statically set. It was a single cluster at peak time. We have multiple clusters, each with their own traffic patterns and auto-scaling configurations. The total cost was $25k/month when summed as a whole.
So, then, what do you estimate the actual savings of the transition to be, taking into account only the component in question and its actual resource needs? (i.e. not simply projecting based on a linear multiple of peak utilization).
I'm going to be a little harsh here, and please forgive me: intellectual dishonesty, especially when the hard numbers are easily determinable, is something I've denied engineers' promotions for. It's genuinely impressive that you've saved the company money, but $500k/year based on peak projections is a very different number than, say, $100k/year in actual resources saved over the full course of it.
200 pods was peak allocation on a specific cluster, not total sustained cost for all of prod. The savings are taken by quite literally looking at the last month's bill on the cloud, compared to the new one after all optimizations applied and resources were aligned.
They say "embedding V8 directly into Go (to avoid the network hop)" was only an "incremental improvement"
I'm very curious why this didn't help more. That was my first thought. Maybe they didn't get the result they wanted immediately so gave up before evaluating this fully?
JS runtimes are fatty, so embedding one instantly adds at least 30-50 Mb of RAM usage. Imagine that you do this for just for a specific function (JSON processing) and your total RAM budget for a whole pod is around 256 Mb.
No doubt, this approach would work reasonably well for machines with plenty of RAM, but I can see why it can be a bottleneck when scaled to N instances. RAM is expensive, and when you multiply those 50 extra megabytes by N, your total costs quickly climb up.
These "solutions" place a lot of faith in a "complete" set of test cases. I'm not saying don't do this, but I'd feel more comfortable doing this plus hand-generating a bunch of property tests. And then generating code until all pass. Even better, maybe Claude can generate some / most of the property tests by reading the standard test suite.
Well they also shadowed production traffic and fixed some bugs that were causing mismatching results. Not saying that stuff can't still slip through, but it's a good way to evaluate it against real data in a way you can't from just test cases alone
parallel execution that auto-generates test cases from exceptions is very slick. That being said, you still need humans in the loop as sometimes the oracle is not THE oracle.
Everyone is surprised at the $300k/year figure, but that seems on the low end. My previous work place spends tens of millions a year on GPU continuous integration tests.
Well I'm seriously jealous about these posts. I rewrote this and that. One 10x engineer + Claude did everything in an hour.
It feels like I'm getting gaslighted.
I use AI at work with C#/Python - it fine. It can write some glue code and sometimes even pretty well. But I have to hand-hold it a lot.
My own project in Swift. Boy, AI can't handle Apple quirks - multiple iterations, code does not compile or missing crucial pieces (there are navigation links but not navigation stack).
I'm trying to be not picky. I want AI to do my job. But it's so far away.
Am I alone and everyone rewriting Linux in Rust over a weekend?
this 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.
If "AI" is the poor man's (unhygienic) macro system, then a lot of such token software builders are going to viscerally know what it is to plumb the darketst depths of the "Lisp Curse".
A principal engineer spending his week end vibe coding some slop at a rate of 13k lines of code in 7h to replace a vendor. Is this really the new direction we want to set for our industry? For the first time ever, I have had a CTO vibe conding something to replace my product [1] even though it cost less than a day of his salary. The direction we are heading makes me want to quit, all points to software now being worthless
What vendor? My understanding is that they replaced one piece of software with similar one that allows them to simplify system and save a lot of money.
And looks like they are happy with quality and have a good test coverage.
In AI era not everything should be npm dependency or 3rd party. Small things are easier to make in house and tailor to one’s needs.
> Is this really the new direction we want to set for our industry?
I think the better question is whether it’s avoidable. I share the concern but is there a real alternative? “Say no to AI!” is fine until your competitors decide they don’t share your concerns. Or at least not enough to stop using it.
Congrats to the team. Unfortunately many comments here are missing the big picture by attacking the previous architectural decisions with no context about why they were taken. It's always easy to say so in retrospect.
Also, I have to comment on the many commenters that spent time researching existing Go implementations just to question everything, because "AI bad". I don't know how much enterprise experience the average HN commenter these days have, but it's not usually easy to simply swap a library in a production system like that, especially when the replacement lib is outdated and unmaintened (which is the case here). I remember a couple of times I was tasked with migrating a core library in a production system only to see everything fall apart in unexpected ways the moment it touched real data. Anyway, the case here seems to be even simpler: the existing Go libs, apart from being unmaintened and obscure, don't support current feature of the JSONata 2.x, which gnata does. Period.
The article missed anticipating such critics and explaining this in more detail, so that's my feedback to the authors. But congrats anyway, this is one of the best use cases for current AI coding agents.
the real lesson is that Jsonata should have been written in C so anyone could link to it and keep the parser resident in memory, to avoid $300k vCPU costs spent on marshalling & RPC
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, evaluate, serialize the result, and finally send it back.
> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added.
For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year.
The fact that this only took $400 of Claude tokens to completely rewrite makes it even more baffling. I can make $400 of Claude tokens disappear quickly in a large codebase. If they rewrote the entire thing with $400 of Claude tokens it couldn't have been that big. Within the range of something that engineers could have easily migrated by hand in a reasonable time. 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.
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.
>> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added.
> For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year.
And this, this is the core/true/insightful story the executives will never hear about.
Eh. If you get into enterprise business, this is the accepted management style. AI will now mix this up a little, but before you basically needed to ask if you want to blow 300k on developer salaries to maybe fix something that is already working and generating money, or add more features to the roadmap you can pin on your chest. Scaling infrastructure is the best choice for 90% of managers, especially since they are not the ones paying for it and this kind of technical debt doesn't matter on typical bonus check timeframes.
I used to work for AWS on a service team. I noticed we were spending way too much on provisioned concurrency for dynamo and would benefit from on-demand provisioning. After proving it worked, making the change, deploying, was rather pleased with myself. "Saved $2M in costs by switching to on-demand provisioning" barely made it onto my performance review lol.
They might just not have believed it. At the management level everyone is busy claiming to be delivering huge numbers all the time, and people stop trusting that sort of claim.
In an ideal world, you would have gotten those extra bucks. :P
Or even just 10% of them, or 50% of the first year savings
In the world of manufacturing this is known as a gain-sharing plan. Not sure I'd call it common, but it certainly isn't unheard of
Managers love big cloud spend so the vendors take them on fancy golf trips ... er ... "Conferences".
Yes, the factors to consider include:
- cost of the effort
- probability of success
- trade-offs in the case of success or of failure
- the possibility of only partial success creating an even messier situation than the existing one
Having a way to do the whole thing on a much smaller timescale and budget lets decision makers focus more on those externalities, and also can simplify them. This kind of bit rot is somewhere (often everywhere) in many fast-moving businesses, as a natural consequence of the value tradeoffs we have had up to now. Now there are machines that can speedrun the grunt work of clearing them.
I mostly agree, but it's more appropriate to weigh contributions against an FTE's output rather than their input. If I have a $10m/yr feature I'm fleshing out now and a few more lined up afterward, it's often not worth the time to properly handle any minor $300k/yr boondoggle. It's only worth comparing to an FTE's fully loaded cost when you're actually able to hire to fix it, and that's trickier since it takes time away from the core team producing those actually valuable features and tends to result in slower progress from large-team overhead even after onboarding. Plus, even if you could hire to fix it, wouldn't you want them to work on those more valuable features first?
They were running a big kubernetes infrastructure to handle all of these RPC calls.
That takes a lot of engineer hours to set up and maintain. This architecture didn't just happen, it took a lot of FTE hours to get it working and keep it that way.
But that k8s engineer's cost is spread over all the functions the cluster is doing, not just the rpc setup.
Yeah, the situation from TFA doesn't make a lot of sense; I was just highlighting that it's not as clear-cut as "costs > 1 FTE => fix it."
Yep. Opportunity cost is the importantly thing. Though a well-managed org will scale capacity against some ROI threshold.
If you’re skipping 8 $300k projects a year that could be done by one fully-burdened $400k developer, something is wrong.
Kube is trivial to run. You hit a few switches on GKE/EKS and then a few simple configs. It doesn't take very many engineer hours to run. Infrastructure these days is trivial to operate. As an example, I run a datacenter cluster myself for a micro-SaaS in the process of SOC2 Type 2 compliance. The infra itself is pretty reliable. I had to run some power-kill sims before I traveled and it came back A+. With GKE/EKS this is even easier.
Over the years of running these I think the key is to keep the cluster config manual and then you just deploy your YAMLs from a repo with hydration of secrets or whatever.
The cost is not just tokens, you need an actual human contributor looking into the issue, prompting, checking output, validating, deploying,... Difficult to compute the actual AI ROI. If $300K didn't matter without AI, it probably still doesn't matter with AI.
> it's often not worth the time to properly handle any minor $300k/yr boondoggle
No, because you can use that 300k to solve some real problem instead of literally lighting it on fire.
(Hell, just give employees avocado toasts or pingpong tables instead.)
Yeah, it's like those posts "we made it 5,000x faster by actually thinking about what the code is doing."
Exactly. Reddit did one last year like: “We migrated from python to golang and fixed a bunch of non-performant SQL queries. It was so fast, isn’t golang awesome?”
I was once asked to migrate a Microsoft Access application to C#/MS SQL Server because it was too slow. I just added a few database indexes to make it an order of magnitude faster.
(They still wanted to go ahead with the migration, but that's a different story.)
> They still wanted to go ahead with the migration, but that's a different story.
Yeah I would too lol. During Covid I found myself in the odd situation of developing a new Access DB product and man was it miserable.
I have about a dozen projects I’d love to tackle in this vein. (Not as low hanging fruit, but enough effort they’re languishing in the backlog.) we’ll actually be able to get to more those projects with agents and good specs
If LLMs do nothing but clear enterprise technical debt, the consumer might benefit from that alone…
Spot on. This is excellent analysis.
I was also bothered by this:
"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
Opus 4.5 to 4.6 was pretty incremental, I didn't see much of a difference.
The big coding model moments in recent recollection, IMO, were something like:
- Sonnet 3.5 update in October 2024: ability to generate actually-working code using context from a codebase became genuinely feasible.
- Claude 4 release in May 2025: big tool calling improvements meant that agentic editors like Claude Code could operate on a noticeably longer leash without falling apart.
- Gemini 3 Pro, Claude 4.5, GPT 5.2 in Nov/Dec 2025: with some caveats these were a pretty major jump in the difficulty and scale of tasks that coding assistants are able to handle, working on much more complex projects over longer time scales without supervision, and testing their own work effectively.
Maybe they're like me, who didn't spend a lot of time investigating Claude until 4.6 launched and the hype was enough to be the tipping point to invest energy. I do know that I've been having good/great results with Opus 4.6 and the CLI, but after an hour or so, it'll suddenly forget that the codebase has tab-formatted files and burn up my quota trying to figure out how to read text files. And apparently this snafu has been around since at least late last year [0]. Again, I can't complain about the overall speed and quality for my relatively light projects, I'm just fascinated by people who say their agents can get through a whole weekend without supervision, when even 4.6 appears to randomly get tripped up in a very rookie way?
[0] https://github.com/anthropics/claude-code/issues/11447
There's definitely a productivity curve element to getting it to behave effectively within a given codebase. Certainly in the codebases I work with most frequently I find Claude will forget certain key aspects (how to run the tests or something) after a while and need a reminder, otherwise it gets into a loop like that trying to figure out how to do it from first principles with slightly incorrect commands.
I think a lot of the noise about letting Claude run for very extended periods involves relatively greenfield projects where the AI is going to be using tools and patterns and choices that are heavily represented in training data (unless you tell it not to), which I think are more likely to result in a codebase that lends itself to ongoing AI work. People also just exaggerate and talk about the one time doing that actually worked vs the 37 times Claude required more handholding.
The bigger problem I see with the "leave it running for the weekend" type work is that, even if it doesn't get caught up on something trivial like tabs vs spaces (glad we're keeping that one alive in the AI era, lol), it will accumulate bad decisions about project structure/architecture/design that become really annoying to untie, and that amount to a flavor of technical debt that makes it harder for agents themselves to continue to make forward progress. Lots of insidious little things: creating giant files that eventually create context problems, duplicating important methods willy nilly and modifying them independently so their implementations drift apart, writing tests that are..."designed to pass" in a way that creates a false sense of confidence when they're passing, and "forest for the trees" kind of issues where the AI gets the logic right inside a crucial method so it looks good at a glance, but it misses some kind of bigger picture flaw in the way the rest of the code actually uses that method.
This is also supported by the Opus degradation tracker [1]. The dotted line is when they switched from Opus 4.5 to 4.6. There's no difference on statistically significant difference the tested benchmark.
1: https://marginlab.ai/trackers/claude-code-historical-perform...
4.5 is a big jump, but there’s no way 4.5 to 4.6 is what convinced this person.
I feel like 4.6 is worse than 4.5 lol
i actually agree for opus... but sonnet 4.6 is like magic ime
Whatever I used Sonnet 4.6 for, including Claude Code and Claude Chat, it made so many mistakes and totally awkward assumptions that I can’t fathom what it’s supposed to be good at. The mistakes were so blatant. Plan mode, several passes, couple grand in API costs… just disappointing at every task in every session over the past few weeks. Opus 4.6 has been good, still quite a few unexpected, silly mistakes, a few subtle but critical mistakes, but produced workable increments and code reviews, vastly subpar to GPT-5.x in chat mode (with and without identical customization).
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, with LLMs, you can at least come up with a vibe coded, likely correct, likely faster, solution in a morning, that management won't moan at you about.
I don’t know where you got “likely correct” from. Likely working? Sure. Likely correct? Absolutely not.
LLMs will only ever be as good as an average programmer, and average programmers usually get stuff wrong.
> LLMs will only ever be as good as an average programmer
What do you base this claim on?
> average programmers usually get stuff wrong.
All programmers get stuff wrong.
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.
> that management won't moan at you about.
That seems unlikely.
> If they rewrote the entire thing with $400 of Claude tokens it couldn't have been that big.
The original is ~10k lines of JS + a few hundred for a test harness. You can probably oneshot this with a $20/month Codex subscription and not even use up your daily allowance.
In my experience, a lot of these types of migrations aren't incredibly deep in terms of actual code being written. It's about being able to assess all of the affected facets accurately. Once that's all mapped out, it's pretty straight forward to migrate.
Wonder if the real value of LLMs/AI is similar to microservices in that it solves an organisational/culture problem.
In this case AI allowed the developer to make a change that the organisation would not have allowed. Regular rewrites don't let you signal to investors that you are AI ready/ascendant/agentic (whatever the latest AI hype term is) so would have been blocked. But, an AI rewrite.
If the only thing LLMs did was clear enterprise technical debt backlogs, the end consumer would still benefit from the technology.
That assumes they don't accelerate the accumulation of technical debt. For each item cleared how many new ones are added. LLMs accelerate your good engineers and your bad ones. So the slop likely increase faster than it can be cleared.
And it will affect good engineers and turn them into worse engineers too
AI benefits rely on these good engineers having 5, 10, 20 years of experience pre-AI designing (and fully, thoroughly understanding) these systems. What's going to happen to that engineering skill after 15 years of AI use?
It ought to only get better as it gets honed at an even faster pace than before, utilizing techniques and algorithms that would have been out of reach due to outside constraints.
+1 This is the core question to ask.
> 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.
> But most of the time the people responsible for the codebase / architecture do not want those questions raised.
I don't know if that matches my experience. I've seen plenty of places where the dev teams complain about tech debt and other kludges costing too much, slowing them down and causing other problems, but management don't want to "waste time re-writing working code".
But now that management read on linkedin they can jump on the AI bandwagon by having the team use AI to fix tech debt, there's suddenly time to work on it.
Eliminating manual toil seems like a huge win for LLMs. There are a ton of straightforward-but-tedious projects that no one wants to fund because they take 2 dev weeks to implement and the result is a hard to quantify quality of codebase improvement. Some of these can now be handled by an LLM in a day and so they suddenly become extremely tractable. You don’t have to embrace vibe coding to benefit from cheap debt pay down.
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.
"For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year."
You build something that's a dirty hack but it works, then your company grows, and nobody ever gets around to building it.
I was at a place spending over $4 million a year on redshift basically because someone had slapped together some bad (but effective!) queries when the company was new, and then they grew, and so many things had been built on top they were terrified to touch anything underneath.
This was amazingly common in the 2010s during the Big Data craze. I know, because I was the one slapping the bad queries together.
Most startups didn’t care (to a point) because at that point in their lifecycle, the information they needed to get from those queries (and actions they could take based on it, like which customers were likely to convert and worth spending sales time on, etc) was more important than the money spent on the insane redshift clusters.
The mantra was almost always some version of, “just do it now, as fast as possible, and if we’re still alive in a year we’ll optimize then.”
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.
The original author said he built this on the weekend, so my assumption is that this was something engineers had advocated for before but were shut down because management wanted them elsewhere.
The use of ai agents allowed them to shrink the problem down to the point where it was small enough to fit in their free time and not interrupt their assigned work.
Why are engineers spending their week-end on saving their company money especially if the company clearly doesn't care to allocate resources to the problem?
I get that it's fun and there's personal satisfaction in it, but it just reinforces to management that they don't need to care about allocating resources to optimisation, the problem will just take care of itself for free.
At some point it's hard not to care about the work you do everyday. And if you care, then you are going to find yourself donating a Saturday here or there to solving big DevEx papercuts that you can't convince management to care about.
Should it be this way? No. Is it this way in practice? Unfortunately often.
A cynical take is that this makes them more hireable, so they can more easily get to a better company with not-so-brain-dead management
This also explains this blog post
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.
I wonder how much it would have cost them if they weren't paying cloud rates for all of that, and they kept the same general inefficient architecture, sans the Kubernetes bloat.
Doubt they'd have a blog post to write about that, though.
> 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.
Fixing bugs is the goldilocks zone for ai. Especially if you have a test that the agent can use to test their fix.
AI is not a junior developer, as some analogise, but Rain Man. Ultra autistic entity that can chew through way more logical conditions that you.
As long as you can describe the bug well ai will likely fix it. Logs help.
Let me give you specific example.
Here's a fix made by claude to my SumatraPDF: https://github.com/sumatrapdfreader/sumatrapdf/commit/a571c0...
I have a crash reporting system that sends me crash information in text file: callstack of crashed thread, basic os info and logs of this execution.
The way I (well, claude) fixed this bug is: I said "analyze crash report: <paste crash report>" and it does it in under a minute.
Recently I've fixed at least 30 bugs with this process (you can view recent checkins).
Those are crashes that I found hard to fix because even though by human standard I'm both expert developer and expert Windows API developer.
But I'm not an autistic machine that can just connect the dots between how every windows api works and how it ties to the callstack and information from the log, in under a minute.
Fixing a bug is in the wheelhouse of AI to the extent that the fix can be verified — since there is a clear objective function. The real question is whether there are unintended side effects (e.g., new bugs that get introduced) or whether the test cases are comprehensive enough to determine whether the fix worked.
That fix is just the same code from earlier in that function pasted in again after another asynchronous procedure.
I feel like you’re probably just a worse engineer than you think you are if you needed Claude for this.
There's nothing I love more than unfounded arrogance.
How about you try to make a change to SumatraPDF code base.
Let's see how good of an engineer you are when you actually have to write a line of C++ code in complex codebase as opposed to commenting on a check in with an explanation of the issue and a fix.
Claude fixed this crash in a minute: https://gist.github.com/kjk/d22af052499f70a45708c311eef201ff
Why don't you tell me, smart man, what the fix it and how long it took you to figure out.
If you can do it in less than a day, then we can talk about how better of an engineer you are than me.
A more charitable explanation would be that they were under product pressure for more features and were never given the slack time to even explore this angle. Happens a lot.
Yeah that's the skeptical key point.
The practical key point is: if you want to do a large migration is to have a very good & extensive test suite that Claude is not allowed to change during the migration. Then Claude is extremely impressive and accurate migrating your codebase and needs minimal handholding. If you don't have a test suite, claude will be freewheeling all the way. Just did an extensive migration project, and should have focused on the test suite much more.
Yeah, apparently the original library has nearly 4,000 tests. This would have been impossible without those. This speaks to the power of testing. The lack of discussion here also shows how under-valued it is.
Testing in the human era I think was less usefull. Too many tests would lead to high maintenance costs. In the AI era its a lot more easy to manage.
[dead]
I've seen it happen and it's usually just Normalization of Deviance in an organization that is focusing on something else. Someone needs some kind of functionality and Kube makes creating services trivial so they launch it into a different service[0]. Over time, while people are working on important things this thing occasionally has load issues so someone goes and bumps the maxReplicas up periodically. Eventually you come back to it a year later and maxReplicas is at 24 and you've removed the code paths for almost everything that is hitting the server except some inexplicable hot-loop.
Then you look at it and you're like "Jesus! What the fuck, I meant to have this be a stop-gap". I've done as bad when at near 100% duty-cycle. Often you're targeting just the primary thing that's blocking some revenue and if you get caught yak-shaving you're screwed. A year ago, I did one of these things because I was in the middle of two projects that were blocking a potential hundred-million in revenue.
A year down the line, Claude Opus 4.6 could have live-solved it. But Claude of that time would have required some time and attention and I was doing something else.
That engineering team is some 15 people strong and the company is at $400m+ revenue. If you saw the code, you'd wonder why anyone would have done something like this.
0: I once did this because some inscrutable code/library was tying us to an old runtime so I just encapsulated it in HTTP and moved it into a service.
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.
Completely agree. We have > $50m from our most recent funding round, and even a cloud expense of $50k/year (in our case for storage) is considered a high priority to address. If it was $300k, our CTO would be running around with a butane torch setting everyone’s hair on fire until the problem was resolved.
But, venture funding does create a lot of weird inefficiencies which vary from company to company.
But what is your income? How important it is to address should be compared to that and current profits too if any, and whether you have to be profitable right now.
First, I have to make a major correction: the cost I was thinking of is over $50k/month, not year, so over $600k/year. But it was still considered a big issue when it was at $300k, which wasn’t that long ago.
The reason it matters is (1) because it’s directly relevant to profitability projections, i.e. cost per customer, and (2) because management looks at those numbers and sees potential headcount.
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".
I've worked many companies
Kubernetes, app engine, beanstalk all are huge money sink
All managed services like cloud datastore, firestore all tend to accure lots of costs if you've good size app.
These are quick to start when you don't have any traffic. Once traffic comes, you the cost drastically goes up.
You can always do better running your own services.
Think this is pure piggyback marketing on what cloudflare did with next.js. In my experience a company that raised $30MM a month ago is extremely unlikely to be investing energy in cost rationalization/optimization.
edit: saw the total raise not the incremental 30MM
>If they rewrote the entire thing with $400 of Claude tokens it couldn't have been that big.
It was "A few iterations and some 7 hours later - 13,000 lines of Go with 1,778 passing test cases."
Yeah that checks out to me, 1 hour of active Claude Code usage has been around $50 per hour for me.
Also don't miss that he had to do this work on the weekend...
Engineers are afraid of writing custom parsers and interpreters.
I've been refactoring stuff with a $20 ChatGPT account.
I've been refactoring stuff with anonymous ChatGPT usage..!
I've been refactoring stuff without ChatGPT usage..!
No offence, but inexperienced JS fanatics always do this because of some weird affectionado they have for the language itself. Otherwise, even a decently qualified CTO would have chosen to keep everything in Go from the beginning or might have not waited until they were bleeding $300k. JS is also the worst possible language choice for this problem. So, it definitely sounds a bunch of script kiddies with fancy titles bought with VC money rather than actual experience.
What if you are about to get a potentially really high paying customer, but they might go elsewhere unless you deliver X feature immediately and it is so much quicker to do it with the JS script?
Given that the potential high paying customer is just that - a potential, one must always keep the long term platform stability in mind as it affects every other customer, not just this potential customer. Hence, it boils down to opportunity cost and setting the right expectations:
We can deliver feature X for you - incrementally broken down into sub-features x1, x2, x3 over a period of Y weeks/months
The other way to do this would be to build a custom integration on top of your existing APIs and beta test it alongside the customer, bill them accordingly and eventually merge the changes into the main platform, once you can guarantee stability.
But, both these methods will sound boring to VC funded companies as they are under constant pressure from VCs to show something in their weekly graphs - meaningful or not.
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.
Normally I'd say "Good architecture is far from requirement for profitable product, good enough is good enough, you can optimize later"
...but this is VC funded AI startup, the product might still be burning VC money on each customer ever after optimizing it.
The result is literally on github
https://github.com/RecoLabs/gnata
I have no idea what is JSONata. It seems it is not THAT hard to rewrite to go, just very tedious, and would cost more than 400 USD in developer time.
Don’t forget that by using an AI, they don’t actually own the code. That’s public domain code now, since it can’t be protected by copyright.
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 implementation at
https://github.com/blues/jsonata-go
Early in 2025 I used Claude Code and Codex to do a proper, compliant port that passes the full set of tests and is safe. It was most certainly not a trivial task for AI, as many nuances of JSONata syntax derive from its JS roots.
Regardless, it was a great experience and here's the 2.0.6 AI port, along with a golang exerciser that lets you flip back and forth between the implementations. We did a seamless migration and it's been running beautifully in prod in Blues' Notehub for quite a while - as a core transformation capability used by customers in our JSON message pipeline.
https://github.com/jsonata-go/jsonata
I was also involved in writing a clean-slate port of JSONata after finding issues in the jsonata-go repo and not wanting to run the javascript version in a sandbox. It was relatively easy until we stressed it with 20 layers of nested context and 5000 line expressions and suddenly we had memory explosions not present in the JS version.
JSONata is too tied to the language. Looking back, we should have slightly altered the spec and written some code mods. we didn't have customers bringing their existing JSONata over so they wouldn't notice the differences.
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.
> At Reco, we have a policy engine that evaluates JSONata expressions against every message in our data pipeline - billions of events, on thousands of distinct expressions.
The original architecture choice and price almost gave me a brain aneurysm, but the "build it with AI" solution is also under-considered.
This looks like a perfect candidate for existing, high quality, high performance, production grade solutions such quamina (independent successor to aws/event-ruler, and ancestor to quamina-rs).
There's going to be a lot of "we were doing something stupid and we solved it by doing something stupid with AI [LLM code]" in our near future. :-|
But if the ai built solution is slightly less stupid, then it's still a win isnt it?
As far as I see it, AI is the reason they're unnecessarily paying 300k/year in the first place. A human engineer was the one that identified the problem with this JS dependency, and the human told then made AI fix its' original mistake.
That's a win for human engineers, not AI.
but they saved $500k. Before some humans knew about constraints in it. Now nobody knows.
Jokes aside, we will probably see everyone doing this, trying to remove human hands off of code, because they corrupt and AI does not.
Joke jokes aside why did we even code until AI?
I don't understand if you're joking or not. I hope you are...
If you start with something really really horrible, chances are even an accidental change by an intern can improve it.
it can ALWAYS get worse...
>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 in?
I know nothing about JSONata or the problem it solves, but I took a look at the repo and there's 15PRs and 150 open issues.
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.
>expect the goal is fixing bugs that show up and occasionally adding a feature that's needed by this organization.
Even if we assume a clean and bug free port, and no compatibility required moving forward, and a scope that doesn't involve security risks, that's already non trivial, since it's a codebase no one has context of.
Probably not 500k worth of maintainance (because wtf were they doing in the first place) but I don't buy placing the current cost at 0.
This case looks like pure marketing fluff rather than sound engineering tho.
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.
If the original released a bunch more features that you wanted why wouldn't you just redo the conversion against the latest version?
The full translation took 7hrs and $400 in tokens. Applying diffs every quarter using AI is much easier and cheaper. Software engineering has completely changed.
except there are 2 go implementations already, and he burnt 500k per year to have a kubernetes clusters to parse json (???), so the total gain is -500000*year - 400 + 1 (deducting prompt to use existing implementation)
[dead]
it is all yolo from here on out ... every major ai decision we're making today feels like a bet that agi will eventually show up and clean up the mess
There is a choice, yet.
> the first question that comes to mind is: who takes care of this now?
probably another AI agent at their company, who I'm sure won't make any mistakes
I mean, my first question would be how good the test suite on this project is.
The headline seems to be flashy indeed, but ai didn't really solve this imo.
They just seemed to fix their technology choices and got the benefits.
There's existing golang versions of jsonata, so this could have been achieved with those libraries too in theory. There's nothing written about why the existing libraries aren't good enough and why a new one needed to be written. Usually you need to do some due diligence in this area, but no mentions of it in this post
In order to measure the real efficiency, gnata should've been benchmarked against the existing golang libraries. For all we know, the ai implementation is much slower.
The benchmarks in the blog are also weird. The measurement is done within the app, but you're meant to measure the calls within the library itself (e.g calling the js version in its isolated benchmark vs go version in its isolated benchmark). So you don't actually know what the actual performance of the ai written version is?
The only benefit, again, is that they fixed their existing bad technology choice, and based on what is observed, with a lesser bad technology choice. Then it's layered with clickbait marketing titles for others to read.
I'll probably need to expect more of these types of posts in the future.
> There's existing golang versions of jsonata, so this could have been achieved with those libraries too in theory
The only one I found (jsonata-go) is a port of JSONata 1.x, while the gnata library they've published is compatible with the 2.x syntax. Guess that's why.
Looking at the releases, it looks like JSONata's 2.1.0 release from July 2025 added the `?:` and `??` syntax, and there hasn't been an update to the syntax since January 2020's 1.8.0 release that added `%`
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 to have Claude rewrite something when you can just use an already existing, already supported library?
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.
> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added.
Maybe I’m out of touch, but I cannot fathom this level of cost for custom lambda functions operating on JSON objects.
They said in the article that they were running up to 200 pods at a time. Doing some back of the envelope math, 200 pods at $300,000 year is about $0.17/hour, which is exactly what an EC2 c5.xlarge costs per hour (on demand). That has 4 vCPUs, so about 800 vCPUs during peak, with $0.0425/CPU-hour.
I do have some questions like:
* Did they estimate cost savings based on peak capacity, as though it were running 24x7x365?
* Did they use auto scaling to keep costs low?
* Were they wasting capacity by running a single-threaded app (Node-based) on multi-CPU hardware? (My guess is no, but anything is possible)
This is a helpful breakdown, thanks, @otterley.
It is, by orders of magnitude, larger than any deployment that I have been a part of in my work experience, as a 10-year data scientist/Python developer.
This is larger than the resources I have available at Medium-Size-Fabless-Semi-Inc, and larger than the time I had two racks of C++ build farm. It is of course way larger than StackOverflow, which ran for years on two large machines.
All for .. a meta-SaaS?
This is where the cost came from.
>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, evaluate, serialize the result, and finally send it back.
But either way, we're talking $25k/mo. That's not even remotely difficult to believe.
First I thought they were AWS lambda functions, perhaps possible if they are over-provisioned for very concurrency or something similar $25k/month is in realm of possibility.
But no, the the post is talking about just RPC calls on k8s pods running docker images, for saving $300k/year, their compute bill should be well above $100M/year.
Perhaps if it was Google scale of events for billions of users daily, paired with the poorest/inefficient processing engine, using zero caching layer and very badly written rules, maybe it is possible.
Feels like it is just an SEO article designed to catch reader's attention.
It has to be satire right? Like, you aren't out of touch on this. I get engineers maybe making the argument that $300k / year on cloud is the same as 1.5 devops engineers managing in-house solutions, but for just json parsing????
For numbers like that, I can never tell whether it's just a vastly larger-scale dataset than any that I've seen as a non-FAANG engineer, OR, a hilariously-wasteful application of "mAnAgEd cLoUd sErViCeS" to a job that I could do on a $200/month EC2 instance with one sinatra app running per core. This is a made-up comparison of course, not a specific claim. But I've definitely run little $40 k8s clusters that replaced $800/month paid services and never even hit 60% CPU.
Right, this is roughly my mental situation, too. I guess that streaming JSON things can eat up compute way faster than I had any intuition for!
I wonder if you've ever worked on a web service at scale. JSON serialization and deserialization is notoriously expensive.
It can be, but $500k/year is absurd. It's like they went from the most inefficient system possible to create, to a regular normal system that an average programmer could manage.
I have no idea if they are doing orders of magnitude more processing, but I crunch through 60GB of JSON data in about 3000 files regularly on my local 20-thread machine using nodejs workers to do deep and sometimes complicated queries and data manipulation. It's not exactly lightning fast, but it's free and it crunches through any task in about 3 or 4 minutes or less.
The main cost is downloading the compressed files from S3, but if I really wanted to I could process it all in AWS. It also could go much faster on better hardware. If I have a really big task I want done quickly, I can start up dozens or hundreds of EC2 instances to run the task, and it would take practically no time at all... seconds. Still has to be cheaper than what they were doing.
Curious about the workload, but as Im trying to make a tool about json, what are those files compressed with? What is the size of the average file ? What is their structure (ndjson ? Dict with some huge data structure a few level deep?)
In S3 the JSON is stored in plain-old .zip files. While downloading to local the files are unzipped to plain old JSON. It's basically an object containing tons of data about each website I manage including all fragments of HTML and metadata used on the sites. It can get quite large, some sites have thousands of pages. We often need to find things stored many levels deep in the JSON that may be tricky to find, it isn't usually a specific path, and lots of iterable arrays and objects are involved. The files range from ~20MB to ~400MB, depending on how much content each site has. And we have ~9000 total sites.
They got a 1000x speed up just by switching languages.
I highly doubt the issue was serialization latency, unless they were doing something stupid like reserializing the same payload over and over again.
Well, for starters, they replace the RPC call with an in-process function call. But my point is anybody who's surprised that working with JSON at scale is expensive (because hey it's just JSON!) shouldn't be surprised.
Well everything is expensive at scale, and any deserialization/serialization step is going to be expensive if you do it enough. However yes i would be surprised. JSON parsing is pretty optimized now, i suspect most "json parsing at scale is expensive" is really the fault of other parts of the stack
Would it be better or worse if I had that experience and still said it's stupid?
You didn't say it was stupid. If you had, I would have just ignored the comment. But you expressed a level of surprised that led me to believe you're unfamiliar with how much of a pain in the ass JSON parsing is.
I think OP’s point was surprise that a company would spend so much on such inefficient json parsing. I’m agreeing. I get that JSON is not the fastest format to parse, but the overarching point is that you would expect changes to be made well before you’re spending $300k on it. Or in a slightly more ideal world, you wouldn't architect something so inefficient in the first place.
But it's common for engineers to blow insane amounts of money unnecessarily on inefficient solutions for "reasons". Sort of reminds me of saas's offering 100 concurrent "serverless" WS connections for like $50 / month - some devs buy into this nonsense.
The docs indicate there are already 2 other go implementations. Why not just use one of those? https://docs.jsonata.org/overview.html
Because his prompt said to implement in go, not to check if an go implementation already exists. They have been running kubernetes clusters to parse json, this is not suprising.
Because otherwise they wouldn't have written this meaningless article and contributed to the AI hype.
And to market their AI security product.
Rewrites happen because nobody wants to debug someone else's half-finished mess, and "just use X" often means inheriting its quirks and gaps.
Now they have 13k lines of someone else’s mess (the AIs) to manage instead.
But this is a different kind of problem.
With legacy systems, at least the complexity was somewhat anticipated early in the design process (even if it was incorrect).
With automatically generated code, you get something that "works" but with a much vaguer underlying model, which makes it harder to understand when things start to go wrong.
In both cases, the real cost comes later, when you're forced to debug under pressure.
Those are compatible with the 1.x syntax while the gnata is compatible with the 2.x. Also, the repos haven't seen new commits in a long time.
Last commits in those repos are 5 and 7 years ago.
If they're vendoring the dependency anyway, that wouldn't matter much if they're not using features that were added since 2021.
The last release of jsonata was mid 2025, and there hasn't been new features since the last 2022 release until the latest, so it's likely those other ports are fine.
This isn’t the first time I’ve read a ridiculous story like this on hackernews. It seems to be a symptom of startups who suddenly get a cash injection with no clue how to properly manage it. I have been slowly scaling a product over the past 12 years, on income alone, so I guess I see things differently, but I could never allow such a ridiculous spend on something so trivial reach even 1% of this level before squashing it.
I'm just kind of confused what took them so long. So it was costing 300k a year, plus causing deployment headaches, etc.
But its a realitively simple tool from the looks of it. It seems like their are many competitors, some already written in go.
Its kind of weird why they waited so long to do this. Why even need AI? This looks like the sort of thing you could port by hand in less than a week (possibly even in a day).
Not saying it is a good thing, but an organization, especially if there has been a lot of turnover, can enter a state of status quo.
> it must have that architecture for a reason, we don't enough knowledge about it to touch it, etc.
That or they simply haven't had the time, cost can creep up over time. 300k is a lot though. Especially for just 200 replicas.
Seems wildly in-efficient. I also don't understand why you wouldn't just bundle these with the application in question. Have the go service and nodejs service in the same pod / container. It can even use sockets, it should be pretty much instant (sub ms) for rpc between them.
If I had to guess… The same thing happening to a lot of the industry… the era of cheap money is over.
My takeaway is almost the opposite. A company that has scaled to the point that they need 200 replicas of JSONata costing 300k/yr must be spending so much on compute that the difference is absolutely peanuts.
> 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.
> This was costing us ~$300K/year in compute
Wooof. As soon as that kind of spend hit my radar for this sort of service I would have given my most autistic and senior engineer a private office and the sole task of eliminating this from the stack.
At any point did anyone step back and ask if jsonata was the right tool in the first place? I cannot make any judgements here without seeing real world examples of the rules themselves and the ways that they are leveraged. Is this policy language intentionally JSON for portability with other systems, or for editing by end users?
Your most autistic and senior engineer is now named Claude. Point him at nearly any task, pair-program with codex, and review the results.
For context, JSONata's reference implementation is 5.5k lines of javascript.
And no, there are no dependencies in package.json either (other than devDependencies for tests).
Which cumulatively means a competent developer could probably port it in less than one day.
They almost certainly spent longer working out how to deploy and integrate the original JS and ironing out the problems, than it would have taken to port it in the first place.
That’s sad.
And then they definitely spent much longer making their optimised fast path for simple expressions. Which they probably wouldn’t have bothered with if they had just ported the whole thing.
As for trying things like embedding V8… this is getting ridiculous.
I strongly suspect no one had actually looked at the code, but had just assumed all along that it was much more complex than it actually was.
The entire thing is a tragedy.
> port it in less than one day
There's confidence and there's barking mad delusion.
Here's the reality.
I once ported 50k loc from Java to Go. Here are details: https://blog.kowalczyk.info/article/19f2fe97f06a47c3b1f118fd...
Java => Go is easier than JavaScript => Go because languages are more similar. That was a very line-by-line port.
Because I was paid by hour I took detailed notes.
I spent 601 hours to port it.
50k / 601 = 83 lines ported per hour, 665 per 8 hour day, but really 500 per 6 working hours a day. No one does sustained 8 hours of writing code daily.
I would consider that very fast and yet order of magnitude slower than your 5.5 k per day.
10x is not a mis-estimation, it's a full blown delusion.
I stand by my estimate, also having done interlanguage ports. I’m not saying any project of such size could be ported in one day, but this very much looks to be one of the more straightforward ones. Being a small project also accelerates things, as there are far fewer moving parts, concepts, &c. to keep in order.
I wouldn’t say that Java → Go is inherently easier than JavaScript → Go. There are more features in JavaScript that, if used, will make porting much harder, but they may well not be used. There’s a bit of async in this project, that’s probably the hardest bit, and maybe a little variadic calling. But comparing with your case, some challenges just aren’t there, such as inheritance and access control.
From a quick skim, I think perhaps 2000 lines will need no change beyond removing semicolons. And since this is mostly parser and AST sort of stuff, a lot of the rest is mechanical repetition and application of regular expression replacements or editor macros.
One note from your article, on fluent function chaining:
> This only works in languages that communicate errors via exceptions. When a function additionally returns an error, it’s no longer possible to chain it like that.
This is a Go limitation, not fundamental. (And Go is well known to be bad or at least verbose at error propagation.) Rust’s ? operator is an easy counterexample.
I'm with the other commenter. There's no way to port 5k lines in a day with confidence unless using LLMs + strong unit tests.
I won't even ask for an example of otherwise, but feel free to provide a repo where a human did that.
So it doubled LOC
Go is very verbose.
Golang is a bit more basic and explicit.
If they were paying $500k/year, why haven't they paid someone to rewrite it? Surely would be cheaper still.
But above everything else, this is a great example of how much JavaScript inefficiency actually costs us, as humanity. How many companies burn money through like this?
On top of that there are probably a few more hits for the containers, vm and hypervisor, all those pods have monitoring etc. All the layers of abstraction are just stacks of turtles giving the illusion of being easier but adding complexity and cost/overhead.
It is a security product, so unless they want to deal with the exfiltration charges on the data it's probably better to keep it in AWS. Thats the nasty double edge sword of "cloud", and how we're all getting locked in.
All the bits on their own seem to make perfect sense, but it's become apparent that the orchestra has been blind folded and given noise canceling head phones.
Next maybe they will use a binary format instead of JSON.
Stop reading ahead.
Anyone who ships a k8s cluster to make a JS library available over RPC needs to have a long hard look in the mirror. Should have bundled node, quickjs, anything into the go nodes for the first pass. k8s truly is a cancer for many teams.
I’ve predicted the future and I’ve figured out where vibe coding is going to go based on this article.
1. People are going to come in and vibe code a replacement for some shitty component in a morning. They aren’t going to take time to verify and understand the code.
2. The new code will fix most of the problems with the original component, but it will have a whole new set of issues.
3. People will use AI to fix the bugs, but they won’t take the time to understand the fixes or the regression tests that they tell AI to add.
4. The new system will get so complicated that it’s hard for even AI to work on it. The “test suite” will be so full of tests that are redundant, and nonsensical that the run time will be too high to meaningfully guide AI. And even in the cases where AI does use it, many of the tests are just reimplementing the code under test in the test (Claude does this about 25% of the time based on what I’ve seen if you don’t catch it).
5. Goto 1
This is the same cycle I’ve seen in 90% of companies I’ve worked at, it will just be on a faster cadence.
And that is how we’ll get to a place where we output 100x lines of code, and spend 2x developers salaries on tokens, with little meaningful impact on the outside world.
> The new system will get so complicated that it’s hard for even AI to work on it.
I used AI to refactor several of my own "move fast and break things" projects and it worked absolutely GREAT. So if that's what you're concerned about, you're not seeing where the puck is going.
Did you take the time to review the code?
Yes, it's for a Laravel project and Laravel Boost + Pint makes both Claude and Codex write great code.
The trick is to make a good plan first. And to not rewrite your entire codebase all at once. But that advice is older than my all of my kids combined.
If you’re taking the time to review the code, none of the the above applies to you.
Yeah, but I'm still using AI to do the things you seem to think it's not able to do.
> I shared the numbers internally and someone asked about the ROI. Production cost for jsonata-js in the previous month was about $25K - now it was 0. That conversation ended up being pretty short.
I'm obviously projecting from my own experience, but it echoes so clearly how power can be wielded without actual insight and an almost arrogantly: "OK, all very nice, but the ROI...?"
The article seems to come from a company with stellar engineering so maybe doesn't apply to this case. But, the tone I imagine from that comment still stands out. To me more, precisely because of the mature engineering.
Of course ROI is important and a company exists to build it. I'm extrapolating from something tiny and thinking of the Boeing culture shift: https://news.ycombinator.com/item?id=25677848
In short, why can't good engineering just be good engineering fostered with trust and then profits?
In my mind, this "observation" (if I can call it that) may explain or at least relate to what other commenters bring:
> 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.
https://news.ycombinator.com/item?id=47537229
As others have said, the title is bollocks. For any mismanaged infrastructure you can make these crazy claims. If they did it today it would be ”saved $100/year”.
The thing is, if it took them a day with AI it would’ve been _at most_ a week without it. So why did they wait? Someone is not being responsible with the company funds.
how many billions of compute are wasted because this industry can't align on some binary format across all languages and APIs and instead keep serializing and deserializing things
ASN.1 and its on the wire format BER and DER have been available for close to 30+ years and it is running on billions of devices(cryptography, SSL, etc) and other critical infrastructures.
but, it is very boring stable, which means I can't tell the world about my wartime stories and write a blog about it.
JSON is not really the core issue which is the expression parser. "user.name = foo and user.id > 1000". Even if you were operating on binary data, turning an arbitrary pseudocode string into actual function logic + executing it would be the slow part.
These examples of rewrite are fallacy.
See Next.js, over a decade of iterative development. Countless vulnerabilities discovered internally, and externally, which got patches with tribal knowledge acquired by core contributors, security reviewers.
Now Joe shows off he rewrote it with Vite at its core, for just 1,100 dollars worth of token. Performance improvement and no licensing liability.
Outcome: more money for Nvidia, and even more money into the pockets of your next hackers.
One day a kid came home breathing heavily, to his father’s surprise face he tells, daddy daddy, I saved a dollar fifty!
How did you do it? ask the father
Instead of taking the bus, I ran after it all the way home.
If you were smarter, you could have save us $22 by running after a taxi!
This old joke came to mind while reading this post.
A tech company spends hundreds of thousands of dollars per year, “for years”, on a piece of software that could have been replaced by a month of coding top? (prior to LLM and all), you sit and write and save the money.
If I was an investor in this company I would have hire a team to look through their entire stack. See, if this JSON thingy alone is half a million a year, their entire cloud is at least $35MM annually.
Perhaps this is not even a bad business idea. One can offer companies to provide drop-in replacement for their costly “micro services that no one dares to touch” and share the cost savings.
If the first commit was two weeks ago, how did it ended up saving 500k a year already? Did they mean expected to save?
You'll never get an impressive resume with an attitude like that.
they probably got paid 500k for sponsored content
These articles remind me so much of those old internet debates about "teleportation" and consciousness.
Your physical form is destructively read into data, sent via radio signal, and reconstructed on the other end. Is it still you? Did you teleport, or did you die in the fancy paper shredder/fax machine?
If vibe code is never fully reviewed and edited, then it's not "alive" and effectively zombie code?
Darn, I'd wished they improved one of the existing Go or Rust implementations.
> Correctness: 1,778 test cases from the official jsonata-js test suite + 2,107 integration tests in the production wrapper.
The AI generated code can still introduce subtle bugs that lead to incorrect behaviour.
One example of this is the introduction of functions into the codebase (by AI) that have bugs but no corresponding tests.
EDIT: correct quotation characters
AI will happily update tests to be wrong or miss the intention of the code and test the wrong things.
> 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.
This makes me wonder, for reimplementation projects like this that aren't lucky enough to have super-extensive test suites, how good are LLM's at taking existing code bases and writing tests for every single piece of logic, every code path? So that you can then do a "cleanish-room" reimplementation in a different language (or even same language) using these tests?
Obviously the easy part is getting the LLM's to write lots of tests, which is then trivial to iterate until they all pass on the original code. The hard parts are how to verify that the tests cover all possible code paths and edge cases, and how to reliably trigger certain internal code paths.
I've found Claude Code with Opus 4.5+ to be excellent at generating test cases that exercise the different features, and even push into the edge cases. You sometimes need to nudge it into generating more convoluted cases when necessary, but then it is just nudging. I now routinely generate more LOCs of test cases than actual core code, while I used to only write very limited test cases just for the most complex areas amenable to automated testing.
I've been successful at using Claude Code this way:
1. get it to generate code for complex data structures in a separate library project
2. use the code inside a complex existing project (no LLM here)
3. then find a bug in the project, with some fuzzy clues as to causes
4. tell CC about the bug and ask it to generate intensive test cases in the direction of the fuzzy clues
5. get the test cases to reproduce the bug and then CC to fix it by itself
6. take the new code back to the full project and see the issue fixed
All this using C++. I've been a pretty intensive developer for ~35 years. I've done this kind of thing by hand a million times, not any more. We really live in the future now.
That is _definitely_ copyright infringement.
Yeah, that's why I said clean-ish room. I'm thinking more about open source projects here that you just want available in a new language, without any architectural "cruft" copied from the original (since different language idioms may imply different architectures), than trying to evade copyright on something commercial. Most commercial stuff isn't making its code base public in the first place anyways.
Imagine how many tests were frauded and fake passed by claude on this project
Wait could I have written a JSONata parser and sold it to reco.ai for $499k/yr?
As long as you are using JSON, you will be able to optimize.
Did you know that you can pass numbers up to 2 billion in 4 constant bytes instead of as a string of 20 average dynamic bytes? Also, fun fact, you can cut your packets in half by not repeating the names of your variables in every packet, you can instead use a positional system where cardinality represents the type of the variable.
And you can do all of this with pre AI technology!
Neat trick huh?
> Did you know that you can pass numbers up to 2 billion in 4 constant bytes
And up to 4 billion if you're not bothered about those pesky negative nancies!
I too have used a similar strategy of packing variables together. I even came up with a name for it. I called it a "building."
Like other commenters already said, there are numerous ways they could have avoided/reduced the $500k/yr cost pre LLM, including simply paying someone to do port the code.
So I don't see there is any point in the article.
The point of the article is that that was his way to do it. To show that it is possible to save money with AI rewrites.
Then I have learned nothing new.
Since at least November 2022, everyone in the software industry knows that "it is possible to save money with AI rewrites".
I found nothing I don't already know from the article.
The only way this specific article gained attention is with the number in the headline.
With my favorite database (Gel) effectively dead (team acquihire by Vercel), I told Claude to reimplement it in Deno/TypeScript. While I haven't tested it on a real project yet (on my TODO for tmrw), hundreds of tests pass so we'll see.
If it does work I'll do a Show HN in a few months. One thing I always do with LLM-code though is review every single line (mainly because I'm particular with formatting). disc.sh is gonna be the domain when I launch the marketing site.
You also really need to review its logic too, because it has a tendency to lack the full context of the code it’s working on, and make very silly logic mistakes.
1000%
People who claim AGI from these chatbots don't doublecheck the work.
I'm going to be the contrarian here. I have looked at the code. I suspect quite a few nil deref panics in their future.
Huh, I just did basically the same thing. My requirements were not due to spending $300k/yr on parsing (lol), but I was amazed how far I got just asking the AI for progressively more functionality.
My use case is a bit different. I wanted JSONata as the query language to query Flatbuffers data (via schema introspection) in Rust, due to its terseness and expressiveness, which is a great combination for AI generated queries.
This problem existed for years, so at some point decided it wasn't worth fixing and that decision just stuck. I wonder how many companies have multiple of these types of problems that they aren't addressing.
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, a significant subset of our customers are quite large (think Fortune 500 and up). For the engine, that means a few things:
- It was designed to be dynamic by nature, so that both out-of-the-box and user-defined expressions evaluate seamlessly.
- Schemas vary wildly, of which there are thousands, since they are received from external sources. Often with little documentation.
- A matching expression needs to be alerted on immediately, as these are critical to business safety (no use triggering an alert on a breached account a day later).
- Endpoints change and break on a near-weekly basis, so being able to update expressions on the fly is integral to the process, and should not require changes by the dev team.
Now to answer some questions:
- Why JSONata: others have mentioned it here, but it is a fantastic and expressive framework with a very detailed spec. It fits naturally into a system that is primarily NOT maintained by engineers, but instead by analysts and end-users that often have little coding expertise.
- Why not a pre-existing library: believe me, we tried that first. None actually match the reference spec reliably. We tried multiple Go, Rust and even Java implementations. They all broke on multiple existing expressions, and were not reliably maintained.
- Why JSON at all (and not a normalized pipeline): we have one! Our main flow is much more of a classic ELT, with strongly-defined schemas and distributed processing engines (i.e. Spark). It ingests quite a lot more traffic than gnata does, and is obviously more efficient at scale. However, we have different processes for separate use-cases, as I suspect most of the organizations you work at do as well.
- Why Go and not Java/JS/Rust: well, because that's our backend. The rule engine is not JUST for evaluating JSONata expressions. There are a lot of layers involving many aspects of the system, one of which is gnata. A matching event must pass all these layers before it even gets to the evaluation part. Unless we rewrote our backend out in JS, no other language would have really mitigated the problem.
Finally, regarding the $300k/year cost (which many here seem to be horrified by) - it seems I wasn't clear enough in the blog. 200 pods was not the entire fleet, and it was not statically set. It was a single cluster at peak time. We have multiple clusters, each with their own traffic patterns and auto-scaling configurations. The total cost was $25k/month when summed as a whole.
Being slightly defensive here, but that really is not that dramatic a number when you take into account the business requirements to get such a flexible system up and running (with low latency). And yes, it was a cost sink we were aware of, but as others have mentioned - business ROI is just as important as pure dollar cost. It is a core feature that our customers rely on heavily, and changing its base infrastructure was neither trivial nor cost-effective in human-hours. AI completely changed that, and so I took it as a challenge to see how far it could go. gnata was the result.
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.
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.
I appreciated the writeup and your clarification.
I wonder whether this was your first attempt to solve this issue with LLMs, and this was the time you finally felt they were good enough for the job. Did you try doing this switch earlier on, for example last year when Claude Code was released?
Honestly, I was very adverse to agentic code up until Opus came out. The hallucinations and false confidence it had in objectively wrong answers just broke more things than it fixed.
However after it came out it suddenly behaved closely to what they marketed it as being. So it was my first real end-to-end project relying on AI at the front seat. Though design wise it is nowhere near perfect, I was holding it's hand the entire way throughout.
> Finally, regarding the $300k/year cost (which many here seem to be horrified by) - it seems I wasn't clear enough in the blog. 200 pods was not the entire fleet, and it was not statically set. It was a single cluster at peak time. We have multiple clusters, each with their own traffic patterns and auto-scaling configurations. The total cost was $25k/month when summed as a whole.
So, then, what do you estimate the actual savings of the transition to be, taking into account only the component in question and its actual resource needs? (i.e. not simply projecting based on a linear multiple of peak utilization).
I'm going to be a little harsh here, and please forgive me: intellectual dishonesty, especially when the hard numbers are easily determinable, is something I've denied engineers' promotions for. It's genuinely impressive that you've saved the company money, but $500k/year based on peak projections is a very different number than, say, $100k/year in actual resources saved over the full course of it.
200 pods was peak allocation on a specific cluster, not total sustained cost for all of prod. The savings are taken by quite literally looking at the last month's bill on the cloud, compared to the new one after all optimizations applied and resources were aligned.
They say "embedding V8 directly into Go (to avoid the network hop)" was only an "incremental improvement"
I'm very curious why this didn't help more. That was my first thought. Maybe they didn't get the result they wanted immediately so gave up before evaluating this fully?
JS runtimes are fatty, so embedding one instantly adds at least 30-50 Mb of RAM usage. Imagine that you do this for just for a specific function (JSON processing) and your total RAM budget for a whole pod is around 256 Mb.
No doubt, this approach would work reasonably well for machines with plenty of RAM, but I can see why it can be a bottleneck when scaled to N instances. RAM is expensive, and when you multiply those 50 extra megabytes by N, your total costs quickly climb up.
Bad decision making. Lack of code ownership. Absence of confidence.
Is what made this exaggerated cost even possible.
Or: the peter principle.
These "solutions" place a lot of faith in a "complete" set of test cases. I'm not saying don't do this, but I'd feel more comfortable doing this plus hand-generating a bunch of property tests. And then generating code until all pass. Even better, maybe Claude can generate some / most of the property tests by reading the standard test suite.
Well they also shadowed production traffic and fixed some bugs that were causing mismatching results. Not saying that stuff can't still slip through, but it's a good way to evaluate it against real data in a way you can't from just test cases alone
parallel execution that auto-generates test cases from exceptions is very slick. That being said, you still need humans in the loop as sometimes the oracle is not THE oracle.
I rereleased this as public domain, since it’s all AI generated, so it is public domain:
https://github.com/hperrin/gnata
The moment the amount of savings surpassed the annual salary of a good programmer you know you made the wrong investment.
The future of open source will be to never publish tests because of things like this.
> then pointed AI at it and had it implement code until every test passed.
You used to have two problems. Now you have three.
> No longer just vibe coding
It is, by definition.
AI company selling AI products claims to have solved a problem using AI when it could've solved it with better code and engineering foundations
So they used an ai trained on the original source code to "rewrite" the original source code.
It was trained on the two existing open source Go implementations of JSONata.
The most baffling thing here is that they allowed a very very simple JSON expression language to become a 500k/year cost burden on their business
My god. But I am happy that they finally realised their error and put it right.
Everyone is surprised at the $300k/year figure, but that seems on the low end. My previous work place spends tens of millions a year on GPU continuous integration tests.
The $300K/year figure is surprising because it was for something that didn't need to exist (RPC calls).
https://github.com/blues/jsonata-go hmmm
Well I'm seriously jealous about these posts. I rewrote this and that. One 10x engineer + Claude did everything in an hour.
It feels like I'm getting gaslighted.
I use AI at work with C#/Python - it fine. It can write some glue code and sometimes even pretty well. But I have to hand-hold it a lot.
My own project in Swift. Boy, AI can't handle Apple quirks - multiple iterations, code does not compile or missing crucial pieces (there are navigation links but not navigation stack).
I'm trying to be not picky. I want AI to do my job. But it's so far away.
Am I alone and everyone rewriting Linux in Rust over a weekend?
I mean, look at the source. This is from an AI company.
If you can incorporate Quamina or similar logic in there, you might be able to save even more… worth looking into, at least
this 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.
Why not use FFI from Go to something in C/C++ that is faster than Go's JSON stuff?
Is JSONata to JSON what Xpath is to XML?
My opinion of the median webdev is… impolite at best.
This article does not do much to improve their standing.
If "AI" is the poor man's (unhygienic) macro system, then a lot of such token software builders are going to viscerally know what it is to plumb the darketst depths of the "Lisp Curse".
A principal engineer spending his week end vibe coding some slop at a rate of 13k lines of code in 7h to replace a vendor. Is this really the new direction we want to set for our industry? For the first time ever, I have had a CTO vibe conding something to replace my product [1] even though it cost less than a day of his salary. The direction we are heading makes me want to quit, all points to software now being worthless
[1] https://github.com/mickael-kerjean/filestash
What vendor? My understanding is that they replaced one piece of software with similar one that allows them to simplify system and save a lot of money. And looks like they are happy with quality and have a good test coverage. In AI era not everything should be npm dependency or 3rd party. Small things are easier to make in house and tailor to one’s needs.
> Is this really the new direction we want to set for our industry?
I think the better question is whether it’s avoidable. I share the concern but is there a real alternative? “Say no to AI!” is fine until your competitors decide they don’t share your concerns. Or at least not enough to stop using it.
I mean, great, but which CTO gave greenlight to such a weird architectural choice. Sorry for the rant!
Congrats to the team. Unfortunately many comments here are missing the big picture by attacking the previous architectural decisions with no context about why they were taken. It's always easy to say so in retrospect.
Also, I have to comment on the many commenters that spent time researching existing Go implementations just to question everything, because "AI bad". I don't know how much enterprise experience the average HN commenter these days have, but it's not usually easy to simply swap a library in a production system like that, especially when the replacement lib is outdated and unmaintened (which is the case here). I remember a couple of times I was tasked with migrating a core library in a production system only to see everything fall apart in unexpected ways the moment it touched real data. Anyway, the case here seems to be even simpler: the existing Go libs, apart from being unmaintened and obscure, don't support current feature of the JSONata 2.x, which gnata does. Period.
The article missed anticipating such critics and explaining this in more detail, so that's my feedback to the authors. But congrats anyway, this is one of the best use cases for current AI coding agents.
the real lesson is that Jsonata should have been written in C so anyone could link to it and keep the parser resident in memory, to avoid $300k vCPU costs spent on marshalling & RPC
Think of the gigawatts wasted on this nonsense.
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
$500k for JSON files LOL OK