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

AI changes the economics of software rewrites

thetruthasiseeitnow.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: AI changes the economics of software rewrites

#101

Post by james_ross »

fhd2 wrote: post #40
Semaphor wrote: post #29

Earlier quoted context omitted.

I work on a codebase from the early 2000s, a lot of it using webforms, a long abandoned .NET technology. A rewrite preserving all behavior and making no observable changes whatsoever would be amazing. But it’s also tested exactly as well as you’d expect from something like that so I’d rather not let AI go wild.

Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all. And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever. I would argue that LLMs can speed this kind of thing up, but n…

I think everyone is right on this question :) I have certainly worked in places where there were enormous code bases written in dead languages going back to the 1970s and I was part of the collective belief that nothing could be done about it and our job in the 2000s was to put lipstick on the pig by burying it behind a web portal, if you remember that short-lived fad. In that kind of environment I would have _loved_ an exact port to a modern tech stack from which we could begin the very slow and careful evolution. Speaking to people who work there, AI has indeed changed at least their perception of what is possible and they have traction on porting it that was considered impossible for decades. Whether it works for some definition of “works” remains to be seen, but it might be self-fulfilling because the belief that it can be done will mean it is tried more often and some of those tries will probably succeed.

With that said, I’ve also recently done a rewrite in a completely different sense, taking what used to be a web app and rebuilding from the ground up as a desktop app instead. Having the original code base for core concept reference, but rethinking the whole UI more than a decade on was IMHO a much better approach in that case.

Re: AI changes the economics of software rewrites

#103

Post by freejazz »

AndrewThrowaway wrote: post #51
LtWorf wrote: post #47

Earlier quoted context omitted.

"Coding is solved"

Coding, programming and engineering are all a bit different concepts. Coding as in typing in the code might be solved. Engineering? Doubt. What is definitely not solved is knowing what you want and what user wants and what the end result is supposed to be. To write the code you need the specs and to write the specs you need to know what you want. And that can only be answered by years of therapy.

> Coding as in typing in the code might be solved

haha

Re: AI changes the economics of software rewrites

#104

Post by ghost_pepper »

graypegg wrote: post #82
ghost_pepper wrote: post #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.

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.

That's the sign of a good product: when you have to lie that you don't use it.

Re: AI changes the economics of software rewrites

#105

Post by hedgehog »

Semaphor wrote: post #57
trollbridge wrote: post #46

Earlier quoted context omitted.

LLMs/agents are a great way to create a test harness for something like that.

I plan to eventually get there, just need to find the time. It’s a lot of code, and a lot of it is not set up for testability.

To start the transition you can build your own tooling, in this case maybe start with the whole app stack including browser in an emulator, emulator controlled over a socket (write a harness that exposes all the inner debuggers, framebuffer, snapshotting, etc). Then generate a component inventory and likely failures for each, and generate pixel-perfection + internal state checks for each. Then migrate one component out (this may be quite a large project due to all the glue you'll need to make this possible). Then do the rest one at a time.

The big problem with doing it this way is you end up with something structurally the same as what you started with, but potentially more code if you e.g. end up carrying your own reimplementation of Web Forms.

Re: AI changes the economics of software rewrites

#106

Post by Fordec »

matsemann wrote: post #20

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…

A rewrite is like moving house. In the new house, it doesn't have things the way you had everything set up "just right" is the old house. But you now have an extra bedroom and bathroom and no longer have a black mold problem, and most importantly, the opportunity to do things in a new way with hindsight learned from the old house.

The move period has a lot of work ahead to get it back to livable, but also the opportunity to do better than just "livable".

The introduction of AI for rewrites is the equivalent of zero interest loans to housing, reducing the cost of a move. It doesn't mean "keep moving home", it means there is one less factor to worry about if you need to.

Re: AI changes the economics of software rewrites

#107

Post by obelos »

trollbridge wrote: post #46
Semaphor wrote: post #29

Earlier quoted context omitted.

I work on a codebase from the early 2000s, a lot of it using webforms, a long abandoned .NET technology. A rewrite preserving all behavior and making no observable changes whatsoever would be amazing. But it’s also tested exactly as well as you’d expect from something like that so I’d rather not let AI go wild.

LLMs/agents are a great way to create a test harness for something like that.

This was my approach to a large rewrite I'm working on. First create the multiple layers of test suite to map out existing behavior at the unit, API, and integration level (something that should have been done incrementally over the 20 years this software has existed), then predicate the new code on the tests. It's been remarkably effective.

Re: AI changes the economics of software rewrites

#109

Post by matsemann »

metalspot wrote: post #98
matsemann wrote: post #20

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.

Not sure I agree. Having a complete rewrite like you propose is a huge project, and a very scary flip. And I honestly don't see the value in doing it like that. So now you have the same mess as before, just re-written?

Best I've seen it done is to move module by module. So if you want to do "X", you now have to do it in the new system. And the big part of the rewrite of X is figuring out the specs and making it better along the way. Then people also actually want to move.

Re: AI changes the economics of software rewrites

#110

Post by metalspot »

matsemann wrote: post #109
metalspot wrote: post #98

Earlier quoted context omitted.

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.

Not sure I agree. Having a complete rewrite like you propose is a huge project, and a very scary flip. And I honestly don't see the value in doing it like that. So now you have the same mess as before, just re-written? Best I've seen it done is to move module by module. So if you want to do "X", you now have to do it in the new system. And the big part of the rewrite of X is figuring out the specs and making it bette…

Moving module by module is definitely the safer way to do it, but at the module level you do the same thing. You have to have it feature exact so that you can replay test against the same interface and do progressive roll out. The difference with AI is that the module size you can one-shot goes way up compared to traditional human rewrite.

> same mess as before, just re-written

The likely path here is probably rewriting from node.js/ruby/python/etc to go/rust/c#/etc so a feature exact rewrite that passes all tests and can return identical responses for replayed production requests is not the same mess at all. You can do all sorts of refactoring, bug fixing, etc, while maintaining exact feature compatibility. The other major thing is back-filling exhaustive test coverage with AI, which then makes agentic coding much more accurate, because the feedback loop from failing tests provides the context for AI to self correct.

A test suite and code are two complimentary representations of the same logic, so using AI to grind test coverage to really high levels (90-95+) gives you two independent inference paths through a model, then the feedback signal from test failures gives you the mechanism to drive these two distinct generation paths to convergence.

Post reply on HN