Live data from Hacker News

AI changes the economics of software rewrites

thetruthasiseeitnow.com

91–100 of 113 posts

Re: AI changes the economics of software rewrites

#92
In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!" That's kind of the fundamental motivation, and then people couch it in some very plausible sounding technical reasons. (I don't even think people are being dishonest when this happens -- it's easy to look at a codebase and think "this sucks!" because you don't understand the context behind the original decisions.. and writing new code is a lot more fun than maintaining old code) I'm not saying "never rewrite" things, there are valid cases where the original tech stack is no longer relevant or the accumulated tech debt really is too much, but I'm pretty skeptical of most rewrites at this point in my career.

Re: AI changes the economics of software rewrites

#93

Earlier quoted context omitted.

> Garbage It's not just garbage — it's AI slop garbage.

Exactly. You've hit the nail on the head. And quite frankly, your AI slop garbage radar is not just an indicator of good taste — it's the essence of humanity that keeps you above it.

Heh, this one brought a smile - well played.

Re: AI changes the economics of software rewrites

#95
post #84

I don't think it does. (meaningfully change the economics of rewrites) Burning a sea of tokens to arrive at the equivalent functionality and having a small team of people oversee that process is rarely going to be the fix to the organizational problems that surround typical failed/stagnant software projects. Rewrites are rarely about the organization of the symbols and are more often about a change in the fundamental…

I assumed LLMs should be able to rewrite a small amount of code ~5k dense LoC in Ruby to Rust. It could not. I suspect you'll see a wave of transpilers developed to mostly transpile code from one language to another. You can have an LLM generate a 1-2k or so LoC transpiler that can translate 50%+ of code in place from most languages to another. After doing that, it was able to actually get the job done relatively qui…

An LLM can do this easily if you have a good test harness

Re: AI changes the economics of software rewrites

#97

This website has four articles, once daily, three of which being AI crap and doomsaying (the fourth arguably too, it just doesn't say so), all with lines like: > A fast car doesn't win races — a driver does > the gap is not just speed - it's output quality > A rewrite isn't just an opportunity to modernise your technology stack - it's an opportunity [...] Garbage.

The "Written by hand." in the footer hurts my brain. If it is written using real thoughts and ideas formed by themselves, they've fully imbued their brain with that AI stank I guess. It really does FEEL like unedited LLM output. You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.

They prompted the model by hand.

Re: AI changes the economics of software rewrites

#98

What's the point of the rewrite if it doesn't fix the underlying issues, though? A rewrite being a good idea often hinges on the ability to simplify. After a decade or more, it's now apparent what the application should and shouldn't do, so one can build it with those learnings and shed all tech debt from how it grew organically. Aka preserving all behavior is not what I would want from a rewrite. The point would be…

Rewriting while changing features is the worst idea ever, which almost always leads to failure, and is the reason why "don't do rewrites" is a widespread rule.

Whether it is humans or AI, the correct way to do it is always a feature exact rewrite, so you can do comparative testing on both systems, and progressive rollout, and then you start adapting features.

Re: AI changes the economics of software rewrites

#99

In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!" That's kind of the fundamental motivation, and then people couch it in some very plausible sounding technical reasons. (I don't even think people are being dishonest when this happens -- it's easy to look at a codebase and think "this sucks!" because you don'…

Well yeah, for example I'm working on a codebase written mostly in 2003.

The assumptions in the original code are at best tangentially relevant (stuff like "LUTs are cheaper than using ALU" or "CPU power is cheap, GPU power is very expensive").

Despite that, a grand rewrite would have failed massively (even with agents...), replicating millions of lines of code to be functional again just sounds like an absolute nightmare.

So I've been doing "targeted rewrites" instead - not sure, there's maybe a name for it? Basically do it concern by concern, module by module, so even if lots of code was touched, it only affects one logical feature at the same time.

Re: AI changes the economics of software rewrites

#100

Earlier quoted context omitted.

The "Written by hand." in the footer hurts my brain. If it is written using real thoughts and ideas formed by themselves, they've fully imbued their brain with that AI stank I guess. It really does FEEL like unedited LLM output. You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.

you don't need to be an LLM to have LinkedIn brain, but it helps

LinkedIn brain honestly really disturbs me. I didn't believe in souls until I needed a word to describe what people with LinkedIn brain lacked.

Fortunately, then LLMs came along and now if I see a worryingly-soulless LinkedIn-brained post, I can lie to myself and say it was made by a discount LLM.

Post reply on HN