Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We rewrote JSONata with AI in a day, saved $500k/year

reco.ai

Post reply on HN
Print view View original

261–270 of 278 posts

Re: We rewrote JSONata with AI in a day, saved $500k/year

#261

Post by lossoth »

grey-area wrote: post #136
hrmtst93837 wrote: post #111

Earlier quoted context omitted.

[flagged]

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#262

Post by zar1048576 »

andersmurphy wrote: post #228
9wzYQbTYsAIc wrote: post #177

Earlier quoted context omitted.

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.

+1 This is the core question to ask.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#263

Post by zar1048576 »

kjksf wrote: post #230
sarchertech wrote: post #169

Earlier 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…

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#264

Post by helpfulfrond »

wouldbecouldbe wrote: post #182
Aurornis wrote: post #19

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…

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 proje…

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#265

Post by wouldbecouldbe »

helpfulfrond wrote: post #264
wouldbecouldbe wrote: post #182

Earlier quoted context omitted.

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 proje…

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#266

Post by spiderfarmer »

sarchertech wrote: post #190
spiderfarmer wrote: post #188

Earlier quoted context omitted.

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#267

Post by leptons »

makapuf wrote: post #259
leptons wrote: post #53

Earlier quoted context omitted.

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 dat…

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#268

Post by viktorianer »

wouldbecouldbe wrote: post #182
Aurornis wrote: post #19

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…

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 proje…

[flagged]

Re: We rewrote JSONata with AI in a day, saved $500k/year

#269

Post by nitwit005 »

stevepotter wrote: post #178
sigmoid10 wrote: post #138

Earlier quoted context omitted.

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…

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.

Re: We rewrote JSONata with AI in a day, saved $500k/year

#270

Post by crazygringo »

hperrin wrote: post #254
crazygringo wrote: post #49

> 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 th…

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.
Post reply on HN