Nowadays, a good AI harness can fairly reliably rewrite a medium complexity piece of software to an appropriate modern tech stack with pretty strong confidence of exactly preserving its behavior. The AI can pick up legacy details and keep them exactly the same as before in ways that a human rewriter would usually not bother with. After rewriting each feature it can then exhaustively smoke test all the happy paths and edge cases and ensure the code behaves exactly the same as before, which is another thing that human rewrites basically never do.
AI changes the economics of software rewrites
11–20 of 113 posts
Re: AI changes the economics of software rewrites
#12Re: AI changes the economics of software rewrites
#13This certainly does. If we think from this angle, it really begs the question of what language/tech stack to use if a company wants to start a new project. On one hand, if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. In certain cases, AI will handle some edge cases which are difficult to come by/replicate under strictest test procedures.…
Eh maybe not.
Stuff that has a lot of deprecated features is honestly burdensome on AI. It keeps rediscovering the deprecated features as the understanding that they are deprecated fall outside of the context window.
What you need is something that either never deprecates syntax, or is <10 years old with minimal changes over that time.
Re: AI changes the economics of software rewrites
#14Does 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...
Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect. Estimates are considerably longer, QA is much harder, integration is full…
I tend to believe that the engineering culture you describe will end up producing similar or, as Joel postulates, an even worse result, just dressed up in a modern stack.
If the technical leadership remains the very same one that enabled such a culture, I don't see them being able to suddenly produce a genuinely better software product only because an LLM is in a picture - especially considering how easy it is to convince an LLM that your idea is the best one.
Re: AI changes the economics of software rewrites
#15The problem is always maintainability. Who's gonna fix new bugs? Who's gonna add new features?
Re: AI changes the economics of software rewrites
#16Does 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...
Joel is right, but he's also wrong. I've been on the other side of a timid engineering culture that commerical rides roughshod over and its this depressing immeasurable decline. The company stagnates and slowly tailspins around an unmaintainable product until a competitor steals their lunch in a way that that further obscures cause and effect. Estimates are considerably longer, QA is much harder, integration is full…
These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.
Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.
We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.
However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.
Re: AI changes the economics of software rewrites
#17In that sense, my homepage (https://www.makonea.com/en-US) doesn't even make it to the HN front page—it's mostly in SHOWDEAD. Does that mean it has less value than this post? I'm feeling a sense of doubt about myself.
Re: AI changes the economics of software rewrites
#18The amount of armchair quarterback commentary in the software business as concerns people waxing eloquent a out difficult things safe atop a perch of the same easy things achieved multiple times has always been obnoxious, offensive to the thermodynamics of the situation as situated by Landauer. But this new "you're holding it wrong" series by people whose grasp of the system gets fuzzy somewhere in the v8 headers is…
Since our owners also own an IT consultant agency, I ran the same process through with one of our regular consultants who is an actual awesome data architect. The output was strikingly similar, well except that I/we didn't need to make the slides. I then had him run over the actual slides, and all we changed was adding a { between some arrows to make the source of the arrows more clear.
We're still going to use real human consultants in the loop because they are readily and freely available, and because this is still new. I doubt we'd want to spend 100 consultant hours on something like this in 5 years though. I mean, we'd still do it for decisions where we'd want someone to blame.
Re: AI changes the economics of software rewrites
#19Somehow this article doesn't even mention the fact that AI makes software rewrites much, much faster than before and with higher confidence of backwards compatibility. Nowadays, a good AI harness can fairly reliably rewrite a medium complexity piece of software to an appropriate modern tech stack with pretty strong confidence of exactly preserving its behavior. The AI can pick up legacy details and keep them exactly…
Re: AI changes the economics of software rewrites
#20A 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 to make decisions on what behavior should be kept and what complexity can be removed. An AI can't do that. It can help with execution if the decisions are made, but they're made by being very intimate with the codebase and floating all cases and then talking with stakeholders.