Earlier quoted context omitted.
But if the ai built solution is slightly less stupid, then it's still a win isnt it?
If you start with something really really horrible, chances are even an accidental change by an intern can improve it.
We rewrote JSONata with AI in a day, saved $500k/year
231–240 of 278 posts
Re: We rewrote JSONata with AI in a day, saved $500k/year
#232Re: We rewrote JSONata with AI in a day, saved $500k/year
#233The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
Re: We rewrote JSONata with AI in a day, saved $500k/year
#234The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
Most of the other replies to this hit the nail on the head. A human writing some poor, but working code that is supposed to be a demo, goes to production 9 times out of 10. Then it becomes critical infrastructure. Then management cannot understand why something working needs a rewrite because there's no tangible numbers attached to it. The timeless classic developer problem. We were here ^^^^ up to 2024-2025. Now, wi…
LLMs will only ever be as good as an average programmer, and average programmers usually get stuff wrong.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#235Think of the gigawatts wasted on this nonsense.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#236Earlier quoted context omitted.
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 wri…
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…
I feel like you’re probably just a worse engineer than you think you are if you needed Claude for this.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#237Earlier quoted context omitted.
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.
In an ideal world, you would have gotten those extra bucks. :P
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
Re: We rewrote JSONata with AI in a day, saved $500k/year
#238Earlier quoted context omitted.
> 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…
> 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…
Re: We rewrote JSONata with AI in a day, saved $500k/year
#239Earlier quoted context omitted.
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 notic…
1: https://marginlab.ai/trackers/claude-code-historical-perform...
Re: We rewrote JSONata with AI in a day, saved $500k/year
#240This article does not do much to improve their standing.