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

251–260 of 278 posts

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

#251

Post by 9wzYQbTYsAIc »

blharr wrote: post #249
andersmurphy wrote: post #228

Earlier quoted context omitted.

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.

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

#253

Post by hperrin »

NetOpWibby wrote: post #120

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

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.

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

#254

Post by hperrin »

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.

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

#255

Post by hperrin »

vitalikpie wrote: post #242

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

I mean, look at the source. This is from an AI company.

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

#256

Post by NetOpWibby »

hperrin wrote: post #253
NetOpWibby wrote: post #120

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

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.

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

#257

Post by chrismorgan »

kjksf wrote: post #247
chrismorgan wrote: post #148

Earlier quoted context omitted.

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

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

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.

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

#259

Post by makapuf »

leptons wrote: post #53
encoderer wrote: post #10

Earlier quoted context omitted.

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

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

#260

Post by insensible »

sigmoid10 wrote: post #138
ezst wrote: post #115

Earlier quoted context omitted.

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

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.

Post reply on HN