Live data from Hacker News

AI changes the economics of software rewrites

thetruthasiseeitnow.com

71–80 of 113 posts

Re: AI changes the economics of software rewrites

#71
We sold a large rewrite to be able to use llms. Our code is such a mess that an llm has trouble implementing new features. (maintainability is still a must, even when vibe coding). So we got a green light to use clean patterns that a llm could extend easily.

Of coarse the requirement of using more Ai came from management.

Re: AI changes the economics of software rewrites

#74

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…

> What's the point of the rewrite if it doesn't fix the underlying issues, though?

Depends on what you mean by underlying issues. If you're in a regulated environment, it may be such a mountain of red tape to change behavior that it's not worth it, even if you know it's not ideal.

But if the underlying issues are tech debt, bad design, and other things invisible to the outside world, that's different.

Re: AI changes the economics of software rewrites

#76
post #56

Earlier quoted context omitted.

Would putting that in black and white in the comments around then controller help?

I feel like there are a lot "you are holding it wrong" arguments flying around. Like, when somebody says that AI wasn't able to accomplish something, people tend to assume it's an User problem. Meanwhile, I have a hard time to believe people don't encounter problems with AI solutions on a regular basis (I do).

mostly the problem with coding is the semantic ambiguation; coders like to reuse similar methods, variable names, copy/paste etc; so large code bases have so much out of context simularities that the LLM, regardless of size, isn't

Re: AI changes the economics of software rewrites

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

Re: AI changes the economics of software rewrites

#78

Earlier quoted context omitted.

It still kind of blows me away that almost any LLM usage for coding isn't viewed as "high risk appetite" Building products that no one really knows the internals of is crazy to me, and the methods people have of trying to mitigate that problem seem half assed at best

Sounds like you might work on a team with some agency to say no to management. We have some and sometimes marketing comes back with some extra revenue from a partner if we build out feature X Y or Z for their new product launch. The contracts are signed so engineering has to do it or we’re blamed for lost revenue. A few of those a year and you eventually end up in a similar situation.

> Sounds like you might work on a team with some agency to say no to management.

If I didn't work on such a team, I would last exactly as long as it took me to find such a team.

Re: AI changes the economics of software rewrites

#79

It also changes the economics of buy vs build.

That's very true. People put up with the many limitations of off the shelf software because it's cheaper, not because it's better. Developing bespoke software solutions is now a lot cheaper than it used to be. So, there are a lot of cases where that now becomes the better option. Doing in days what used to take months, is a bit of a game changer. Like with past cost reductions, people will underestimate the work and…

An efficient business focuses on their core competencies. Increasing the surface area of things to worry about is not what most businesses want to do.

There is no such thing as maintenance-free software, even as the end user.

Re: AI changes the economics of software rewrites

#80
post #3

Does it really change the whys of rewriting? https://www.joelonsoftware.com/2000/04/06/things-you-should-... Maybe the LLM will catch and reproduce all corner cases... maybe not...

I've done two rewrites now with AI. Neither of them particularly large, but still non-trivial; think in the low tens of thousands of lines of code. It's been a bit so I haven't tried it on the very latest models, but I can attest that at least Opus 4.5 does like to sand off the edges and drop use cases without necessarily drawing it to your attention. Based on my other experience with later models I doubt they've changed that much. Partially because in a rewrite, trying to sand off some of the rougher edges is itself a valid move sometimes; if you don't need the crazy complication from 15 years ago maybe you should try dropping it.

In both cases I more-or-less ended up lining up the rewritten code and the original code right next to each other and trying to ensure that I could figure out where every line of code in the original ended up in the rewrite. That's much less of a pain than it sounds since they tend to bunch together. One of the rewrites was much harder because the very reason I wanted the rewrite was that the original was very hard to understand due to a combination of way more indirection than was necessary and the pervasive use of associative maps instead of structures, even though the data was structured. The AIs get confused just as the humans do. I did some work in creating unit tests that drew from a data source that both code bases could test against, since this was an HTTP API there was a relatively clean cut point for both codebases there.

AI makes these rewrites way, way easier than they used to be, but you do need to keep an eye on what they're doing, cross-check the final output by hand or by those shared unit tests, and not just assume you can fire the project off Friday evening and take whatever it made by Monday because that end product is probably missing quite a few of the original features.

Post reply on HN