211–220 of 278 posts
The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
>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…
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.
The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
"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 t…
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.”
The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
> 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…
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.
Earlier quoted context omitted.
Spot on. This is excellent analysis. I was also bothered by this: > Until recently, I was rather skeptical of agentic code. February 2026, however, has been a sort of inflection point even stubborn developers like myself can’t ignore. "February 2026" is just way to specific. It feels like a PR/marketing team wrote it. It acts like a jump scare in the post for any normie programmer.
Perhaps it's specific because it's Opus 4.6, released February 5th. https://www.anthropic.com/news/claude-opus-4-6
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.
Earlier quoted context omitted.
But if the ai built solution is slightly less stupid, then it's still a win isnt it?
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?
> 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…
But if the ai built solution is slightly less stupid, then it's still a win isnt it?
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,…
Earlier quoted context omitted.
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.)
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.