[HN Gopher] We rewrote JSONata with AI in a day, saved $500k/year
___________________________________________________________________
We rewrote JSONata with AI in a day, saved $500k/year
Author : cjlm
Score : 255 points
Date : 2026-03-26 22:36 UTC (1 days ago)
(HTM) web link (www.reco.ai)
(TXT) w3m dump (www.reco.ai)
| captn3m0 wrote:
| For context, JSONata's reference implementation is 5.5k lines of
| javascript.
| therealdrag0 wrote:
| So it doubled LOC
| vova_hn2 wrote:
| Go is very verbose.
| pepa65 wrote:
| Golang is a bit more basic and explicit.
| chrismorgan wrote:
| 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 longer making their
| optimised fast path for simple expressions. Which they probably
| wouldn't have bothered with if they had just ported the whole
| thing.
|
| As for trying things like embedding V8... this is getting
| _ridiculous_.
|
| I strongly suspect no one had actually looked at the code, but
| had just assumed all along that it was much more complex than
| it actually was.
|
| The entire thing is a tragedy.
| kjksf wrote:
| > 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: http
| s://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.
|
| 50k / 601 = 83 lines ported per hour, 665 per 8 hour day, but
| really 500 per 6 working hours a day. No one does sustained 8
| hours of writing code daily.
|
| I would consider that very fast and yet order of magnitude
| slower than your 5.5 k per day.
|
| 10x is not a mis-estimation, it's a full blown delusion.
| ebb_earl_co wrote:
| > This was costing us ~$300K/year in compute, and the number kept
| growing as more customers and detection rules were added.
|
| Maybe I'm out of touch, but I cannot fathom this level of cost
| for custom lambda functions operating on JSON objects.
| slopinthebag wrote:
| It has to be satire right? Like, you aren't out of touch on
| this. I get engineers maybe making the argument that $300k /
| year on cloud is the same as 1.5 devops engineers managing in-
| house solutions, but for just json parsing????
| encoderer wrote:
| I wonder if you've ever worked on a web service at scale.
| JSON serialization and deserialization is notoriously
| expensive.
| bawolff wrote:
| They got a 1000x speed up just by switching languages.
|
| I highly doubt the issue was serialization latency, unless
| they were doing something stupid like reserializing the
| same payload over and over again.
| encoderer wrote:
| Well, for starters, they replace the RPC call with an in-
| process function call. But my point is anybody who's
| surprised that working with JSON at scale is expensive
| (because hey it's just JSON!) shouldn't be surprised.
| bawolff wrote:
| Well everything is expensive at scale, and any
| deserialization/serialization step is going to be
| expensive if you do it enough. However yes i would be
| surprised. JSON parsing is pretty optimized now, i
| suspect most "json parsing at scale is expensive" is
| really the fault of other parts of the stack
| slopinthebag wrote:
| Would it be better or worse if I had that experience and
| still said it's stupid?
| encoderer wrote:
| You didn't say it was stupid. If you had, I would have
| just ignored the comment. But you expressed a level of
| surprised that led me to believe you're unfamiliar with
| how much of a pain in the ass JSON parsing is.
| slopinthebag wrote:
| I think OP's point was surprise that a company would
| spend so much on such inefficient json parsing. I'm
| agreeing. I get that JSON is not the fastest format to
| parse, but the overarching point is that you would expect
| changes to be made well before you're spending $300k on
| it. Or in a slightly more ideal world, you wouldn't
| architect something so inefficient in the first place.
|
| But it's common for engineers to blow insane amounts of
| money unnecessarily on inefficient solutions for
| "reasons". Sort of reminds me of saas's offering 100
| concurrent "serverless" WS connections for like $50 /
| month - some devs buy into this nonsense.
| leptons wrote:
| 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 data manipulation. It's not exactly lightning fast, but
| it's free and it crunches through any task in about 3 or 4
| minutes or less.
|
| The main cost is downloading the compressed files from S3,
| but if I really wanted to I could process it all in AWS. It
| also could go much faster on better hardware. If I have a
| really big task I want done quickly, I can start up dozens
| or hundreds of EC2 instances to run the task, and it would
| take practically no time at all... seconds. Still has to be
| cheaper than what they were doing.
| xp84 wrote:
| For numbers like that, I can never tell whether it's just a
| vastly larger-scale dataset than any that I've seen as a non-
| FAANG engineer, OR, a hilariously-wasteful application of
| "mAnAgEd cLoUd sErViCeS" to a job that I could do on a
| $200/month EC2 instance with one sinatra app running per
| core. This is a made-up comparison of course, not a specific
| claim. But I've definitely run little $40 k8s clusters that
| replaced $800/month paid services and never even hit 60% CPU.
| ebb_earl_co wrote:
| Right, this is roughly my mental situation, too. I guess
| that streaming JSON _things_ can eat up compute way faster
| than I had any intuition for!
| manquer wrote:
| First I thought they were AWS lambda functions, perhaps
| possible if they are over-provisioned for very concurrency or
| something similar $25k/month is in realm of possibility.
|
| But no, the the post is talking about just RPC calls on k8s
| pods running docker images, for saving $300k/year, their
| compute bill should be well above $100M/year.
|
| Perhaps if it was Google scale of events for billions of users
| daily, paired with the poorest/inefficient processing engine,
| using zero caching layer and very badly written rules, maybe it
| is possible.
|
| Feels like it is just an SEO article designed to catch reader's
| attention.
| jcims wrote:
| This is where the cost came from.
|
| >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.
|
| But either way, we're talking $25k/mo. That's not even remotely
| difficult to believe.
| otterley wrote:
| They said in the article that they were running up to 200 pods
| at a time. Doing some back of the envelope math, 200 pods at
| $300,000 year is about $0.17/hour, which is exactly what an EC2
| c5.xlarge costs per hour (on demand). That has 4 vCPUs, so
| about 800 vCPUs during peak, with $0.0425/CPU-hour.
|
| I do have some questions like:
|
| * Did they estimate cost savings based on peak capacity, as
| though it were running 24x7x365?
|
| * Did they use auto scaling to keep costs low?
|
| * Were they wasting capacity by running a single-threaded app
| (Node-based) on multi-CPU hardware? (My guess is no, but
| anything is possible)
| ebb_earl_co wrote:
| This is a helpful breakdown, thanks, @otterley.
|
| It is, by orders of magnitude, larger than any deployment
| that I have been a part of in my work experience, as a
| 10-year data scientist/Python developer.
| pjc50 wrote:
| This is larger than the resources I have available at
| Medium-Size-Fabless-Semi-Inc, and larger than the time I
| had two racks of C++ build farm. It is of course way larger
| than StackOverflow, which ran for years on two large
| machines.
|
| All for .. a meta-SaaS?
| cjonas wrote:
| The docs indicate there are already 2 other go implementations.
| Why not just use one of those?
| https://docs.jsonata.org/overview.html
| aniceperson wrote:
| Because his prompt said to implement in go, not to check if an
| go implementation already exists. They have been running
| kubernetes clusters to parse json, this is not suprising.
| g947o wrote:
| Because otherwise they wouldn't have written this meaningless
| article and contributed to the AI hype.
| zer00eyz wrote:
| And to market their AI security product.
| vova_hn2 wrote:
| Last commits in those repos are 5 and 7 years ago.
| heavyset_go wrote:
| If they're vendoring the dependency anyway, that wouldn't
| matter much if they're not using features that were added
| since 2021.
|
| The last release of jsonata was mid 2025, and there hasn't
| been new features since the last 2022 release until the
| latest, so it's likely those other ports are fine.
| leonidasv wrote:
| Those are compatible with the 1.x syntax while the gnata is
| compatible with the 2.x. Also, the repos haven't seen new
| commits in a long time.
| hrmtst93837 wrote:
| Rewrites happen because nobody wants to debug someone else's
| half-finished mess, and "just use X" often means inheriting its
| quirks and gaps.
| grey-area wrote:
| Now they have 13k lines of someone else's mess (the AIs) to
| manage instead.
| cosmotic wrote:
| Next maybe they will use a binary format instead of JSON.
| jujube3 wrote:
| Stop reading ahead.
| TZubiri wrote:
| As long as you are using JSON, you will be able to optimize.
|
| Did you know that you can pass numbers up to 2 billion in 4
| constant bytes instead of as a string of 20 average dynamic
| bytes? Also, fun fact, you can cut your packets in half by not
| repeating the names of your variables in every packet, you can
| instead use a positional system where cardinality represents the
| type of the variable.
|
| And you can do all of this with pre AI technology!
|
| Neat trick huh?
| g947o wrote:
| Like other commenters already said, there are numerous ways
| they could have avoided/reduced the $500k/yr cost pre LLM,
| including simply paying someone to do port the code.
|
| So I don't see there is any point in the article.
| hootz wrote:
| The point of the article is that that was his way to do it.
| To show that it is possible to save money with AI rewrites.
| g947o wrote:
| Then I have learned nothing new.
|
| Since at least November 2022, everyone in the software
| industry knows that "it is possible to save money with AI
| rewrites".
|
| I found nothing I don't already know from the article.
|
| The only way this specific article gained attention is with
| the number in the headline.
| jkercher wrote:
| I too have used a similar strategy of packing variables
| together. I even came up with a name for it. I called it a
| "building."
| zimpenfish wrote:
| > Did you know that you can pass numbers up to 2 billion in 4
| constant bytes
|
| And up to 4 billion if you're not bothered about those pesky
| negative nancies!
| whalesalad wrote:
| > 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.
|
| > This was costing us ~$300K/year in compute
|
| Wooof. As soon as that kind of spend hit my radar for this sort
| of service I would have given my most autistic and senior
| engineer a private office and the sole task of eliminating this
| from the stack.
|
| At any point did anyone step back and ask if jsonata was the
| right tool in the first place? I cannot make any judgements here
| without seeing real world examples of the rules themselves and
| the ways that they are leveraged. Is this policy language
| intentionally JSON for portability with other systems, or for
| editing by end users?
| encoderer wrote:
| Your most autistic and senior engineer is now named Claude.
| Point him at nearly any task, pair-program with codex, and
| review the results.
| bawolff wrote:
| I'm just kind of confused what took them so long. So it was
| costing 300k a year, plus causing deployment headaches, etc.
|
| But its a realitively simple tool from the looks of it. It seems
| like their are many competitors, some already written in go.
|
| Its kind of weird why they waited so long to do this. Why even
| need AI? This looks like the sort of thing you could port by hand
| in less than a week (possibly even in a day).
| schumpeter wrote:
| If I had to guess... The same thing happening to a lot of the
| industry... the era of cheap money is over.
| kjuulh wrote:
| Not saying it is a good thing, but an organization, especially
| if there has been a lot of turnover, can enter a state of
| status quo.
|
| > it must have that architecture for a reason, we don't enough
| knowledge about it to touch it, etc.
|
| That or they simply haven't had the time, cost can creep up
| over time. 300k is a lot though. Especially for just 200
| replicas.
|
| Seems wildly in-efficient. I also don't understand why you
| wouldn't just bundle these with the application in question.
| Have the go service and nodejs service in the same pod /
| container. It can even use sockets, it should be pretty much
| instant (sub ms) for rpc between them.
| delecti wrote:
| My takeaway is almost the opposite. A company that has scaled
| to the point that they need 200 replicas of JSONata costing
| 300k/yr must be spending so much on compute that the difference
| is absolutely peanuts.
| kace91 wrote:
| >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 in?
|
| I know nothing about JSONata or the problem it solves, but I took
| a look at the repo and there's 15PRs and 150 open issues.
| simonw wrote:
| That's only important if the plan is to stay feature-compatible
| with the original going forward.
|
| For this case, where it's used as an internal filtering engine,
| I expect the goal is fixing bugs that show up and occasionally
| adding a feature that's needed by this organization.
| shimman wrote:
| This case looks like pure marketing fluff rather than sound
| engineering tho.
| kace91 wrote:
| >expect the goal is fixing bugs that show up and occasionally
| adding a feature that's needed by this organization.
|
| Even if we assume a clean and bug free port, and no
| compatibility required moving forward, and a scope that
| doesn't involve security risks, that's already non trivial,
| since it's a codebase no one has context of.
|
| Probably not 500k worth of maintainance (because wtf were
| they doing in the first place) but I don't buy placing the
| current cost at 0.
| PetahNZ wrote:
| If the original released a bunch more features that you
| wanted why wouldn't you just redo the conversion against the
| latest version?
| kikimora wrote:
| In practice the biggest issue will be documentation and
| tutorials. If JSONata diverges from their fork users will
| have problems reconciling what they see online with their
| engine capabilities.
| delijati wrote:
| it is all yolo from here on out ... every major ai decision
| we're making today feels like a bet that agi will eventually
| show up and clean up the mess
| 52-6F-62 wrote:
| There is a choice, yet.
| bawolff wrote:
| I mean, my first question would be how good the test suite on
| this project is.
| Herring wrote:
| 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.
| aniceperson wrote:
| except there are 2 go implementations already, and he burnt
| 500k per year to have a kubernetes clusters to parse json
| (???), so the total gain is -500000*year - 400 + 1 (deducting
| prompt to use existing implementation)
| saadn92 wrote:
| > the first question that comes to mind is: who takes care of
| this now?
|
| probably another AI agent at their company, who I'm sure won't
| make any mistakes
| amazingamazing wrote:
| how many billions of compute are wasted because this industry
| can't align on some binary format across all languages and APIs
| and instead keep serializing and deserializing things
| kanbankaren wrote:
| ASN.1 and its on the wire format BER and DER have been
| available for close to 30+ years and it is running on billions
| of devices(cryptography, SSL, etc) and other critical
| infrastructures.
|
| but, it is very boring stable, which means I can't tell the
| world about my wartime stories and write a blog about it.
| whalesalad wrote:
| JSON is not really the core issue which is the expression
| parser. "user.name = foo and user.id > 1000". Even if you were
| operating on binary data, turning an arbitrary pseudocode
| string into actual function logic + executing it would be the
| slow part.
| Aurornis wrote:
| 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.
| cogogo wrote:
| 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
| hobofan wrote:
| > 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.
| hansvm wrote:
| 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 wrote:
| 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.
| hansvm wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kitd wrote:
| But that k8s engineer's cost is spread over all the
| functions the cluster is doing, not just the rpc setup.
| cryptonym wrote:
| 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 wrote:
| > 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 wrote:
| Yeah, it's like those posts "we made it 5,000x faster by
| actually thinking about what the code is doing."
| therealdrag0 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| If LLMs do nothing but clear enterprise technical debt, the
| consumer might benefit from that alone...
| deckar01 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hiyer wrote:
| 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 wrote:
| JSONata is present in AWS Step Functions, it's possible they
| want portability on-prem and into the cloud.
| hparadiz wrote:
| I've been refactoring stuff with a $20 ChatGPT account.
| pepa65 wrote:
| I've been refactoring stuff with anonymous ChatGPT usage..!
| stronglikedan wrote:
| I've been refactoring stuff without ChatGPT usage..!
| SkyPuncher wrote:
| 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.
| heavyset_go wrote:
| 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.
| arjie wrote:
| 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.
| neya wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Sounds like a bad business model then - if you have to
| depend on one single customer to make or break your
| company.
| otterley wrote:
| 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.
| antonvs wrote:
| 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 wrote:
| 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 wrote:
| 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.
| otherme123 wrote:
| >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 wrote:
| Yeah that checks out to me, 1 hour of active Claude Code
| usage has been around $50 per hour for me.
| ezst wrote:
| >> 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 wrote:
| 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.
| xnx wrote:
| Managers love big cloud spend so the vendors take them on
| fancy golf trips ... er ... "Conferences".
| stevepotter wrote:
| 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 wrote:
| In an ideal world, you would have gotten those extra
| bucks. :P
| wongarsu wrote:
| 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
| jackkinsella wrote:
| 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.
| raincole wrote:
| > 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 wrote:
| 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 wrote:
| 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://githu
| b.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 wrote:
| 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 wrote:
| 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.
| andersmurphy wrote:
| 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 wrote:
| If the only thing LLMs did was clear enterprise technical
| debt backlogs, the end consumer would still benefit from the
| technology.
| andersmurphy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| CalRobert wrote:
| "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 wrote:
| 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."
| DrBazza wrote:
| 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.
| sarchertech wrote:
| 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 wrote:
| > that management won't moan at you about.
|
| That seems unlikely.
| hperrin wrote:
| 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 wrote:
| > 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.
| faangguyindia wrote:
| 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.
| pshirshov wrote:
| Engineers are afraid of writing custom parsers and
| interpreters.
| pascahousut wrote:
| 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.
| throwaway2037 wrote:
| 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 wrote:
| Perhaps it's specific because it's Opus 4.6, released
| February 5th.
|
| https://www.anthropic.com/news/claude-opus-4-6
| sarchertech wrote:
| 4.5 is a big jump, but there's no way 4.5 to 4.6 is what
| convinced this person.
| shafyy wrote:
| I feel like 4.6 is worse than 4.5 lol
| g19fanatic wrote:
| i actually agree for opus... but sonnet 4.6 is like magic
| ime
| macNchz wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wongarsu wrote:
| 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...
| wouldbecouldbe wrote:
| 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.
| PunchyHamster wrote:
| 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.
| karel-3d wrote:
| 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.
| endofreach wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| staticassertion wrote:
| 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".
| Psyonic wrote:
| Also don't miss that he had to do this work on the weekend...
| hperrin wrote:
| 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.
| ipsum2 wrote:
| Everyone is surprised at the $300k/year figure, but that seems on
| the low end. My previous work place spends tens of millions a
| year on GPU continuous integration tests.
| Aurornis wrote:
| The $300K/year figure is surprising because it was for
| something that didn't need to exist (RPC calls).
| mickael-kerjean wrote:
| A principal engineer spending his week end vibe coding some slop
| at a rate of 13k lines of code in 7h to replace a vendor. Is this
| really the new direction we want to set for our industry? For the
| first time ever, I have had a CTO vibe conding something to
| replace my product [1] even though it cost less than a day of his
| salary. The direction we are heading makes me want to quit, all
| points to software now being worthless
|
| [1] https://github.com/mickael-kerjean/filestash
| para_parolu wrote:
| What vendor? My understanding is that they replaced one piece
| of software with similar one that allows them to simplify
| system and save a lot of money. And looks like they are happy
| with quality and have a good test coverage. In AI era not
| everything should be npm dependency or 3rd party. Small things
| are easier to make in house and tailor to one's needs.
| dpark wrote:
| > Is this really the new direction we want to set for our
| industry?
|
| I think the better question is whether it's avoidable. I share
| the concern but is there a real alternative? "Say no to AI!" is
| fine until your competitors decide they don't share your
| concerns. Or at least not enough to stop using it.
| pravetz259 wrote:
| Congrats! This author found a sub-optimal microservice and
| replaced it with inline code. This is the bread and butter work
| of good engineering. This is also part of the reason that
| microservices are dangerous.
|
| The bad engineering part is writing your own replacement for
| something that already exists. As other commenters here have
| noted, there were already two separate implementations of JSONata
| in Go. Why spend $400 to have Claude rewrite something when you
| can just use an already existing, already supported library?
| vovavili wrote:
| If I were in the author's shoes, I would have tried first to
| fork the other Go implementation of this JSON library, then use
| AI to pull it up to the modern standard and make it pass all
| his tests. Still, good job on him - this is what data
| engineering actually looks like.
| hooverd wrote:
| Darn, I'd wished they improved one of the existing Go or Rust
| implementations.
| crazygringo wrote:
| > _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 then do a "cleanish-room" reimplementation in a different
| language (or even same language) using these tests?
|
| Obviously the easy part is getting the LLM's to write lots of
| tests, which is then trivial to iterate until they all pass on
| the original code. The hard parts are how to verify that the
| tests cover all possible code paths and edge cases, and how to
| reliably trigger certain internal code paths.
| jng wrote:
| I've found Claude Code with Opus 4.5+ to be excellent at
| generating test cases that exercise the different features, and
| even push into the edge cases. You sometimes need to nudge it
| into generating more convoluted cases when necessary, but then
| it is just nudging. I now routinely generate more LOCs of test
| cases than actual core code, while I used to only write very
| limited test cases just for the most complex areas amenable to
| automated testing.
|
| I've been successful at using Claude Code this way:
|
| 1. get it to generate code for complex data structures in a
| separate library project
|
| 2. use the code inside a complex existing project (no LLM here)
|
| 3. then find a bug in the project, with some fuzzy clues as to
| causes
|
| 4. tell CC about the bug and ask it to generate intensive test
| cases in the direction of the fuzzy clues
|
| 5. get the test cases to reproduce the bug and then CC to fix
| it by itself
|
| 6. take the new code back to the full project and see the issue
| fixed
|
| All this using C++. I've been a pretty intensive developer for
| ~35 years. I've done this kind of thing by hand a million
| times, not any more. We really live in the future now.
| faangguyindia wrote:
| Imagine how many tests were frauded and fake passed by claude
| on this project
| sublinear wrote:
| These articles remind me so much of those old internet debates
| about "teleportation" and consciousness.
|
| Your physical form is destructively read into data, sent via
| radio signal, and reconstructed on the other end. Is it still
| you? Did you teleport, or did you die in the fancy paper
| shredder/fax machine?
|
| If vibe code is never fully reviewed and edited, then it's not
| "alive" and effectively zombie code?
| zellyn wrote:
| If you can incorporate Quamina or similar logic in there, you
| might be able to save even more... worth looking into, at least
| VladVladikoff wrote:
| This isn't the first time I've read a ridiculous story like this
| on hackernews. It seems to be a symptom of startups who suddenly
| get a cash injection with no clue how to properly manage it. I
| have been slowly scaling a product over the past 12 years, on
| income alone, so I guess I see things differently, but I could
| never allow such a ridiculous spend on something so trivial reach
| even 1% of this level before squashing it.
| jgalt212 wrote:
| These "solutions" place a lot of faith in a "complete" set of
| test cases. I'm not saying don't do this, but I'd feel more
| comfortable doing this plus hand-generating a bunch of property
| tests. And then generating code until all pass. Even better,
| maybe Claude can generate some / most of the property tests by
| reading the standard test suite.
| grogers wrote:
| Well they also shadowed production traffic and fixed some bugs
| that were causing mismatching results. Not saying that stuff
| can't still slip through, but it's a good way to evaluate it
| against real data in a way you can't from just test cases alone
| jgalt212 wrote:
| parallel execution that auto-generates test cases from
| exceptions is very slick. That being said, you still need
| humans in the loop as sometimes the oracle is not THE oracle.
| comrade1234 wrote:
| So they used an ai trained on the original source code to
| "rewrite" the original source code.
| badc0ffee wrote:
| It was trained on the two existing open source Go
| implementations of JSONata.
| cromka wrote:
| If they were paying $500k/year, why haven't they paid _someone_
| to rewrite it? Surely would be cheaper still.
|
| But above everything else, this is a great example of how much
| JavaScript inefficiency _actually_ costs us, as humanity. How
| many companies burn money through like this?
| zer00eyz wrote:
| On top of that there are probably a few more hits for the
| containers, vm and hypervisor, all those pods have monitoring
| etc. All the layers of abstraction are just stacks of turtles
| giving the illusion of being easier but adding complexity and
| cost/overhead.
|
| It is a security product, so unless they want to deal with the
| exfiltration charges on the data it's probably better to keep
| it in AWS. Thats the nasty double edge sword of "cloud", and
| how we're all getting locked in.
|
| All the bits on their own seem to make perfect sense, but it's
| become apparent that the orchestra has been blind folded and
| given noise canceling head phones.
| bitbasher wrote:
| Why not use FFI from Go to something in C/C++ that is faster than
| Go's JSON stuff?
| lwansbrough wrote:
| Huh, I just did basically the same thing. My requirements were
| not due to spending $300k/yr on parsing (lol), but I was amazed
| how far I got just asking the AI for progressively more
| functionality.
|
| My use case is a bit different. I wanted JSONata as the query
| language to query Flatbuffers data (via schema introspection) in
| Rust, due to its terseness and expressiveness, which is a great
| combination for AI generated queries.
| rozzie wrote:
| Some background on one of the other two golang implementations
| mentioned in the comments.
|
| Years ago I hired an Upwork contractor to port v1.5.3 to golang
| as best he could. He did a great job and it served us well,
| however it was far, far from perfect and it couldn't pass most of
| the JS test suite. The worst was that it had several recursion
| bugs that could segfault with bad expressions.
|
| That was the now-deprecated implementation at
|
| https://github.com/blues/jsonata-go
|
| Early in 2025 I used Claude Code and Codex to do a proper,
| compliant port that passes the full set of tests and is safe. It
| was most certainly not a trivial task for AI, as many nuances of
| JSONata syntax derive from its JS roots.
|
| Regardless, it was a great experience and here's the 2.0.6 AI
| port, along with a golang exerciser that lets you flip back and
| forth between the implementations. We did a seamless migration
| and it's been running beautifully in prod in Blues' Notehub for
| quite a while - as a core transformation capability used by
| customers in our JSON message pipeline.
|
| https://github.com/jsonata-go/jsonata
| zozbot234 wrote:
| Why not issue a pull request to the JSONata Github project
| mentioning your implementation in the docs/READMEs? That goes
| for OP's port too of course.
| arpinum wrote:
| I was also involved in writing a clean-slate port of JSONata
| after finding issues in the jsonata-go repo and not wanting to
| run the javascript version in a sandbox. It was relatively easy
| until we stressed it with 20 layers of nested context and 5000
| line expressions and suddenly we had memory explosions not
| present in the JS version.
|
| JSONata is too tied to the language. Looking back, we should
| have slightly altered the spec and written some code mods. we
| didn't have customers bringing their existing JSONata over so
| they wouldn't notice the differences.
| __0x01 wrote:
| > Correctness: 1,778 test cases from the official jsonata-js test
| suite + 2,107 integration tests in the production wrapper.
|
| The AI generated code can still introduce subtle bugs that lead
| to incorrect behaviour.
|
| One example of this is the introduction of functions into the
| codebase (by AI) that have bugs but no corresponding tests.
|
| EDIT: correct quotation characters
| sethammons wrote:
| AI will happily update tests to be wrong or miss the intention
| of the code and test the wrong things.
| fock wrote:
| https://github.com/blues/jsonata-go hmmm
| jdub wrote:
| > 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 such quamina
| (independent successor to aws/event-ruler, and ancestor to
| quamina-rs).
|
| There's going to be a lot of "we were doing something stupid and
| we solved it by doing something stupid with AI [LLM code]" in our
| near future. :-|
| chii wrote:
| But if the ai built solution is slightly less stupid, then it's
| still a win isnt it?
| simultsop wrote:
| 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?
| pullshark91 wrote:
| I don't understand if you're joking or not. I hope you
| are...
| legacynl wrote:
| As far as I see it, AI is the reason they're unnecessarily
| paying 300k/year in the first place. A human engineer was the
| one that identified the problem with this JS dependency, and
| the human told then made AI fix its' original mistake.
|
| That's a win for human engineers, not AI.
| throwa356262 wrote:
| If you start with something really really horrible, chances
| are even an accidental change by an intern can improve it.
| skeeter2020 wrote:
| it can ALWAYS get worse...
| neya wrote:
| _AI company selling AI products claims to have solved a problem
| using AI when it could 've solved it with better code and
| engineering foundations_
| tabs_or_spaces wrote:
| The headline seems to be flashy indeed, but ai didn't really
| solve this imo.
|
| They just seemed to fix their technology choices and got the
| benefits.
|
| There's existing golang versions of jsonata, so this could have
| been achieved with those libraries too in theory. There's nothing
| written about why the existing libraries aren't good enough and
| why a new one needed to be written. Usually you need to do some
| due diligence in this area, but no mentions of it in this post
|
| In order to measure the real efficiency, gnata should've been
| benchmarked against the existing golang libraries. For all we
| know, the ai implementation is much slower.
|
| The benchmarks in the blog are also weird. The measurement is
| done within the app, but you're meant to measure the calls within
| the library itself (e.g calling the js version in its isolated
| benchmark vs go version in its isolated benchmark). So you don't
| actually know what the actual performance of the ai written
| version is?
|
| The only benefit, again, is that they fixed their existing bad
| technology choice, and based on what is observed, with a lesser
| bad technology choice. Then it's layered with clickbait marketing
| titles for others to read.
|
| I'll probably need to expect more of these types of posts in the
| future.
| leonidasv wrote:
| > There's existing golang versions of jsonata, so this could
| have been achieved with those libraries too in theory
|
| The only one I found (jsonata-go) is a port of JSONata 1.x,
| while the gnata library they've published is compatible with
| the 2.x syntax. Guess that's why.
| heavyset_go wrote:
| Looking at the releases, it looks like JSONata's 2.1.0
| release from July 2025 added the `?:` and `??` syntax, and
| there hasn't been an update to the syntax since January
| 2020's 1.8.0 release that added `%`
| teaearlgraycold wrote:
| Anyone who ships a k8s cluster to make a JS library available
| over RPC needs to have a long hard look in the mirror. Should
| have bundled node, quickjs, anything into the go nodes for the
| first pass. k8s truly is a cancer for many teams.
| themafia wrote:
| > then pointed AI at it and had it implement code until every
| test passed.
|
| You used to have two problems. Now you have three.
| err4nt wrote:
| The moment the amount of savings surpassed the annual salary of a
| good programmer you know you made the wrong investment.
| leonidasv wrote:
| Congrats to the team. Unfortunately many comments here are
| missing the big picture by attacking the previous architectural
| decisions with no context about why they were taken. It's always
| easy to say so in retrospect.
|
| Also, I have to comment on the many commenters that spent time
| researching existing Go implementations just to question
| everything, because "AI bad". I don't know how much enterprise
| experience the average HN commenter these days have, but it's not
| usually easy to simply swap a library in a production system like
| that, especially when the replacement lib is outdated and
| unmaintened (which is the case here). I remember a couple of
| times I was tasked with migrating a core library in a production
| system only to see everything fall apart in unexpected ways the
| moment it touched real data. Anyway, the case here seems to be
| even simpler: the existing Go libs, apart from being unmaintened
| and obscure, don't support current feature of the JSONata 2.x,
| which gnata does. Period.
|
| The article missed anticipating such critics and explaining this
| in more detail, so that's my feedback to the authors. But
| congrats anyway, this is one of the best use cases for current AI
| coding agents.
| mads_quist wrote:
| I mean, great, but which CTO gave greenlight to such a weird
| architectural choice. Sorry for the rant!
| politelemon wrote:
| > No longer just vibe coding
|
| It is, by definition.
| nirb89 wrote:
| 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, a
| significant subset of our customers are quite large (think
| Fortune 500 and up). For the engine, that means a few things:
|
| - It was designed to be dynamic by nature, so that both out-of-
| the-box and user-defined expressions evaluate seamlessly.
|
| - Schemas vary wildly, of which there are thousands, since they
| are received from external sources. Often with little
| documentation.
|
| - A matching expression needs to be alerted on immediately, as
| these are critical to business safety (no use triggering an alert
| on a breached account a day later).
|
| - Endpoints change and break on a near-weekly basis, so being
| able to update expressions on the fly is integral to the process,
| and should not require changes by the dev team.
|
| Now to answer some questions:
|
| - Why JSONata: others have mentioned it here, but it is a
| fantastic and expressive framework with a very detailed spec. It
| fits naturally into a system that is primarily NOT maintained by
| engineers, but instead by analysts and end-users that often have
| little coding expertise.
|
| - Why not a pre-existing library: believe me, we tried that
| first. None actually match the reference spec reliably. We tried
| multiple Go, Rust and even Java implementations. They all broke
| on multiple existing expressions, and were not reliably
| maintained.
|
| - Why JSON at all (and not a normalized pipeline): we have one!
| Our main flow is much more of a classic ELT, with strongly-
| defined schemas and distributed processing engines (i.e. Spark).
| It ingests quite a lot more traffic than gnata does, and is
| obviously more efficient at scale. However, we have different
| processes for separate use-cases, as I suspect most of the
| organizations you work at do as well.
|
| - Why Go and not Java/JS/Rust: well, because that's our backend.
| The rule engine is not JUST for evaluating JSONata expressions.
| There are a lot of layers involving many aspects of the system,
| one of which is gnata. A matching event must pass all these
| layers before it even gets to the evaluation part. Unless we
| rewrote our backend out in JS, no other language would have
| really mitigated the problem.
|
| Finally, regarding the $300k/year cost (which many here seem to
| be horrified by) - it seems I wasn't clear enough in the blog.
| 200 pods was not the entire fleet, and it was not statically set.
| It was a single cluster at peak time. We have multiple clusters,
| each with their own traffic patterns and auto-scaling
| configurations. The total cost was $25k/month when summed as a
| whole.
|
| Being slightly defensive here, but that really is not that
| dramatic a number when you take into account the business
| requirements to get such a flexible system up and running (with
| low latency). And yes, it was a cost sink we were aware of, but
| as others have mentioned - business ROI is just as important as
| pure dollar cost. It is a core feature that our customers rely on
| heavily, and changing its base infrastructure was neither trivial
| nor cost-effective in human-hours. AI completely changed that,
| and so I took it as a challenge to see how far it could go. gnata
| was the result.
| pu_pe wrote:
| I appreciated the writeup and your clarification.
|
| I wonder whether this was your first attempt to solve this
| issue with LLMs, and this was the time you finally felt they
| were good enough for the job. Did you try doing this switch
| earlier on, for example last year when Claude Code was
| released?
| nirb89 wrote:
| Honestly, I was very adverse to agentic code up until Opus
| came out. The hallucinations and false confidence it had in
| objectively wrong answers just broke more things than it
| fixed.
|
| However after it came out it suddenly behaved closely to what
| they marketed it as being. So it was my first real end-to-end
| project relying on AI at the front seat. Though design wise
| it is nowhere near perfect, I was holding it's hand the
| entire way throughout.
| haspok wrote:
| To me, the odd part is when you compare the performance of RPC
| vs inline code. You present it as if you found something new
| and foundational, only possible thanks to AI, when in fact, it
| has nothing to do with AI, and the results should be no
| surprise to anyone.
|
| Your original architecture was a kludge to start with, it was a
| self-inflicted wound. This is probably the craziest part:
|
| > We'd tried a few things over the years - optimizing
| expressions, output caching, and even embedding V8 directly
| into Go (to avoid the network hop).
|
| I know hindsight is 20/20 - but still, you made the wrong
| decision at the start, and then you kept digging the hole
| deeper and deeper. Hopefully a good lesson for everyone working
| with microservices.
|
| To end on a more positive note, I think this (porting code to
| other languages/platforms) is one use-case where AI code
| generation really shines, and will be of immense value in the
| future. Great reporting, just let's not confuse code generation
| with architectural decisions.
| nirb89 wrote:
| Oh, I don't disagree. The original vision and what the
| product ended up doing are light years apart. Likely, had we
| known what it would evolve into, we would have decided on a
| different solution (perhaps not JSONata at all, for example).
|
| Having said that, My opinion still is that the previous
| solution had valid business merit. Though inefficient, the
| fact that it was infinitely scalable and the only limit was
| pure dollar cost is pretty valuable. It enables business
| stakeholders / managers to objectively quantify the value of
| the feature (for X dollars we get Y business, scaling
| linearly). I've worked in many systems where this was not at
| all the case, and there was a hard-limit at some point where
| the feature simply shut down.
| otterley wrote:
| > Finally, regarding the $300k/year cost (which many here seem
| to be horrified by) - it seems I wasn't clear enough in the
| blog. 200 pods was not the entire fleet, and it was not
| statically set. It was a single cluster at peak time. We have
| multiple clusters, each with their own traffic patterns and
| auto-scaling configurations. The total cost was $25k/month when
| summed as a whole.
|
| So, then, what do you estimate the actual savings of the
| transition to be, taking into account only the component in
| question and its actual resource needs? (i.e. not simply
| projecting based on a linear multiple of peak utilization).
|
| I'm going to be a little harsh here, and please forgive me:
| intellectual dishonesty, especially when the hard numbers are
| easily determinable, is something I've denied engineers'
| promotions for. It's genuinely impressive that you've saved the
| company money, but $500k/year based on peak projections is a
| very different number than, say, $100k/year in actual resources
| saved over the full course of it.
| nirb89 wrote:
| 200 pods was peak allocation on a specific cluster, not total
| sustained cost for all of prod. The savings are taken by
| quite literally looking at the last month's bill on the
| cloud, compared to the new one after all optimizations
| applied and resources were aligned.
| NetOpWibby wrote:
| 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 gonna
| be the domain when I launch the marketing site.
| adityaathalye wrote:
| If "AI" is the poor man's (unhygienic) macro system, then a lot
| of such token software builders are going to viscerally know what
| it is to plumb the darketst depths of the "Lisp Curse".
| techpression wrote:
| As others have said, the title is bollocks. For any mismanaged
| infrastructure you can make these crazy claims. If they did it
| today it would be "saved $100/year".
|
| The thing is, if it took them a day with AI it would've been _at
| most_ a week without it. So why did they wait? Someone is not
| being responsible with the company funds.
| camgunz wrote:
| Wait could I have written a JSONata parser and sold it to reco.ai
| for $499k/yr?
| nbevans wrote:
| The most baffling thing here is that they allowed a very very
| simple JSON expression language to become a 500k/year cost burden
| on their business
|
| My god. But I am happy that they finally realised their error and
| put it right.
| gloosx wrote:
| If the first commit was two weeks ago, how did it ended up saving
| 500k a year already? Did they mean expected to save?
| monegator wrote:
| they probably got paid 500k for sponsored content
| varjag wrote:
| You'll never get an impressive resume with an attitude like
| that.
| hgo wrote:
| > I shared the numbers internally and someone asked about the
| ROI. Production cost for jsonata-js in the previous month was
| about $25K - now it was 0. That conversation ended up being
| pretty short.
|
| I'm obviously projecting from my own experience, but it echoes so
| clearly how power can be wielded without actual insight and an
| almost arrogantly: "OK, all very nice, but the ROI...?"
|
| The article seems to come from a company with stellar engineering
| so maybe doesn't apply to this case. But, the tone I imagine from
| that comment still stands out. To me more, precisely because of
| the mature engineering.
|
| Of course ROI is important and a company exists to build it. I'm
| extrapolating from something tiny and thinking of the Boeing
| culture shift: https://news.ycombinator.com/item?id=25677848
|
| In short, why can't good engineering just be good engineering
| fostered with trust and then profits?
| hgo wrote:
| In my mind, this "observation" (if I can call it that) may
| explain or at least relate to what other commenters bring:
|
| > 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.
|
| https://news.ycombinator.com/item?id=47537229
| sarchertech wrote:
| I've predicted the future and I've figured out where vibe coding
| is going to go based on this article.
|
| 1. People are going to come in and vibe code a replacement for
| some shitty component in a morning. They aren't going to take
| time to verify and understand the code.
|
| 2. The new code will fix most of the problems with the original
| component, but it will have a whole new set of issues.
|
| 3. People will use AI to fix the bugs, but they won't take the
| time to understand the fixes or the regression tests that they
| tell AI to add.
|
| 4. The new system will get so complicated that it's hard for even
| AI to work on it. The "test suite" will be so full of tests that
| are redundant, and nonsensical that the run time will be too high
| to meaningfully guide AI. And even in the cases where AI does use
| it, many of the tests are just reimplementing the code under test
| in the test (Claude does this about 25% of the time based on what
| I've seen if you don't catch it).
|
| 5. Goto 1
|
| This is the same cycle I've seen in 90% of companies I've worked
| at, it will just be on a faster cadence.
|
| And that is how we'll get to a place where we output 100x lines
| of code, and spend 2x developers salaries on tokens, with little
| meaningful impact on the outside world.
| spiderfarmer wrote:
| > The new system will get so complicated that it's hard for
| even AI to work on it.
|
| I used AI to refactor several of my own "move fast and break
| things" projects and it worked absolutely GREAT. So if that's
| what you're concerned about, you're not seeing where the puck
| is going.
| sarchertech wrote:
| Did you take the time to review the code?
| spiderfarmer wrote:
| 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.
| sarchertech wrote:
| If you're taking the time to review the code, none of the
| the above applies to you.
| Yokohiii wrote:
| Bad decision making. Lack of code ownership. Absence of
| confidence.
|
| Is what made this exaggerated cost even possible.
|
| Or: the peter principle.
| lmaoeven wrote:
| $500k for JSON files LOL OK
| hirako2000 wrote:
| These examples of rewrite are fallacy.
|
| See Next.js, over a decade of iterative development. Countless
| vulnerabilities discovered internally, and externally, which got
| patches with tribal knowledge acquired by core contributors,
| security reviewers.
|
| Now Joe shows off he rewrote it with Vite at its core, for just
| 1,100 dollars worth of token. Performance improvement and no
| licensing liability.
|
| Outcome: more money for Nvidia, and even more money into the
| pockets of your next hackers.
| tantalor wrote:
| They say "embedding V8 directly into Go (to avoid the network
| hop)" was only an "incremental improvement"
|
| I'm very curious why this didn't help more. That was my first
| thought. Maybe they didn't get the result they wanted immediately
| so gave up before evaluating this fully?
| garganzol wrote:
| JS runtimes are fatty, so embedding one instantly adds at least
| 30-50 Mb of RAM usage. Imagine that you do this for just for a
| specific function (JSON processing) and your total RAM budget
| for a whole pod is around 256 Mb.
|
| No doubt, this approach would work reasonably well for machines
| with plenty of RAM, but I can see why it can be a bottleneck
| when scaled to N instances. RAM is expensive, and when you
| multiply those 50 extra megabytes by N, your total costs
| quickly climb up.
| swills wrote:
| I'm going to be the contrarian here. I have looked at the code. I
| suspect quite a few nil deref panics in their future.
| vitriol83 wrote:
| this seems to be the way. make great technical improvement in a
| way that's nothing to do with AI. the only way to make executives
| happy is to then tenuously link it to AI usage.
| stronglikedan wrote:
| Is JSONata to JSON what Xpath is to XML?
| vips7L wrote:
| The future of open source will be to never publish tests because
| of things like this.
| tonymet wrote:
| the real lesson is that Jsonata should have been written in C so
| anyone could link to it and keep the parser resident in memory,
| to avoid $300k vCPU costs spent on marshalling & RPC
|
| Think of the gigawatts wasted on this nonsense.
| forrestthewoods wrote:
| My opinion of the median webdev is... impolite at best.
|
| This article does not do much to improve their standing.
| vitalikpie wrote:
| 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 crucial
| pieces (there are navigation links but not navigation stack).
|
| I'm trying to be not picky. I want AI to do my job. But it's so
| far away.
|
| Am I alone and everyone rewriting Linux in Rust over a weekend?
| hperrin wrote:
| I rereleased this as public domain, since it's all AI generated,
| so it is public domain:
|
| https://github.com/hperrin/gnata
| tzury wrote:
| One day a kid came home breathing heavily, to his father's
| surprise face he tells, daddy daddy, I saved a dollar fifty!
|
| How did you do it? ask the father
|
| Instead of taking the bus, I ran after it all the way home.
|
| If you were smarter, you could have save us $22 by running after
| a taxi!
|
| This old joke came to mind while reading this post.
|
| A tech company spends hundreds of thousands of dollars per year,
| "for years", on a piece of software that could have been replaced
| by a month of coding top? (prior to LLM and all), you sit and
| write and save the money.
|
| If I was an investor in this company I would have hire a team to
| look through their entire stack. See, if this JSON thingy alone
| is half a million a year, their entire cloud is at least $35MM
| annually.
|
| Perhaps this is not even a bad business idea. One can offer
| companies to provide drop-in replacement for their costly "micro
| services that no one dares to touch" and share the cost savings.
| convexly wrote:
| This problem existed for years, so at some point decided it
| wasn't worth fixing and that decision just stuck. I wonder how
| many companies have multiple of these types of problems that they
| aren't addressing.
___________________________________________________________________
(page generated 2026-03-27 23:01 UTC)