[Aurornis]

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.

[ezst]

>> 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.

[sigmoid10]

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.

[stevepotter]

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.

[johnisgood]

In an ideal world, you would have gotten those extra bucks. :P

[wongarsu]

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

[nitwit005]

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.

[xnx]

Managers love big cloud spend so the vendors take them on fancy golf trips ... er ... "Conferences".

[insensible]

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.

[mbrumlow]

I am always having these arguments. We are paying this other company x a year for something we should build if we really need it.

The rebuttals I always get are “I want you working on something that I can’t pay another company for”. I think it sounds good, but in the long run we always end up a budget conversations and head count limits because we spend so much money on external services and software we should just build.

Every company ever has this problem.

But now with AI. The cost of showing the company “yes we can” is so cheap. I worry for companies who have promotable replacements.

[hansvm]

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?

[Aurornis]

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.

[kitd]

But that k8s engineer's cost is spread over all the functions the cluster is doing, not just the rpc setup.

[hansvm]

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."

[brookst]

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.

[arjie]

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.

[cryptonym]

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.

[otabdeveloper4]

> 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.)

[andai]

Yeah, it's like those posts "we made it 5,000x faster by actually thinking about what the code is doing."

[therealdrag0]

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?”

[selcuka]

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.)

[guzfip]

> 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.

[anon7000]

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

[9wzYQbTYsAIc]

If LLMs do nothing but clear enterprise technical debt, the consumer might benefit from that alone…

[throwaway2037]

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.

[xnorswap]

Perhaps it's specific because it's Opus 4.6, released February 5th.

https://www.anthropic.com/news/claude-opus-4-6

[macNchz]

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.

[danso]

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

[macNchz]

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.

[collinmanderson]

Yes, for me I think it was around Nov/Dec 2025, along with harness improvements, and hearing about lots of successes with agenic programming. Having the agent managing its own context and doing the full software engineering loop with writing code, running it, and seeing if it works. That was already there before February 9th.

[wongarsu]

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...

[sarchertech]

4.5 is a big jump, but there’s no way 4.5 to 4.6 is what convinced this person.

[shafyy]

I feel like 4.6 is worse than 4.5 lol

[g19fanatic]

i actually agree for opus... but sonnet 4.6 is like magic ime

[jmaker]

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).

[DrBazza]

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.

[hperrin]

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.

[dpark]

> 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.

[sarchertech]

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.

[antonvs]

> that management won't moan at you about.

That seems unlikely.

[hobofan]

> 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.

[SkyPuncher]

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.

[andersmurphy]

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.

[9wzYQbTYsAIc]

If the only thing LLMs did was clear enterprise technical debt backlogs, the end consumer would still benefit from the technology.

[andersmurphy]

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.

[blharr]

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?

[9wzYQbTYsAIc]

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.

[zar1048576]

+1 This is the core question to ask.

[deckar01]

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.

[parpfish]

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.

[ahtihn]

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.

[swiftcoder]

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.

[nextaccountic]

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

[usrusr]

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.

[Snafuh]

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.

[pascahousut]

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.

[CalRobert]

"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.

[asa400]

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.”

[endofreach]

> 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.

[jlarocco]

> 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.

[dpark]

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.

[jlarocco]

That's pretty optimistic. First of all, the people who were manually toiling are getting laid off - LLMs aren't exactly making their lives better.

And I'm not talking about cases where an AI can do things faster. We have a few tech debt tickets at work right now where using an AI will take the same amount of time, because the "hard part" isn't writing the code but working with other teams to organize or roll out the changes. But since we can use AI, management is suddenly interested.

It's silly, and I can't wait for the AI bubble to burst.

[dpark]

> First of all, the people who were manually toiling are getting laid off

I was referring to the sort of work that just never gets funded. Cleanup, refactoring.

If you have business critical toil being done by people who now get laid off, that is obviously a cause for concern.

> the "hard part" isn't writing the code but working with other teams to organize or roll out the changes. But since we can use AI, management is suddenly interested.

So AI has convinced your management to let you pay down tech debt? Seems like a win.

[heavyset_go]

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.

[raincole]

> 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.

[sarchertech]

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.

[kjksf]

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.

[hperrin]

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.

[kjksf]

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.

[zar1048576]

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.

[jackkinsella]

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.

[wouldbecouldbe]

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.

[helpfulfrond]

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.

[wouldbecouldbe]

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.

[arjie]

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.

[hiyer]

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?

[coredog64]

JSONata is present in AWS Step Functions, it's possible they want portability on-prem and into the cloud.

[antonvs]

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.

[mewpmewp2]

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.

[antonvs]

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.

[faangguyindia]

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.

[karel-3d]

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.

[staticassertion]

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".

[cogogo]

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

[otherme123]

>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."

[mewpmewp2]

Yeah that checks out to me, 1 hour of active Claude Code usage has been around $50 per hour for me.

[Psyonic]

Also don't miss that he had to do this work on the weekend...

[pshirshov]

Engineers are afraid of writing custom parsers and interpreters.

[hparadiz]

I've been refactoring stuff with a $20 ChatGPT account.

[pepa65]

I've been refactoring stuff with anonymous ChatGPT usage..!

[stronglikedan]

I've been refactoring stuff without ChatGPT usage..!

[neya]

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.

[mewpmewp2]

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?

[neya]

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.

[mewpmewp2]

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?

[neya]

Sounds like a bad business model then - if you have to depend on one single customer to make or break your company.

[otterley]

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.

[PunchyHamster]

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.

[hperrin]

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.