AI changes the economics of software rewrites
thetruthasiseeitnow.com
thetruthasiseeitnow.com
> 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.
You can find a few smoking guns or em a few dashes, whatever. But every sentence is emanating the stank.
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.
"Written with AI. Curated by hand."
Yesterday: https://web.archive.org/web/20260709105821/https://thetrutha...
It's not just garbage — it's AI slop garbage.
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.
Want me to plan an app that detects food made from AI recipes?
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 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.
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 not by an order of magnitude or anything, just a bit. Unless there's 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
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.
If I didn't work on such a team, I would last exactly as long as it took me to find such a team.
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.
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.
Incidentally, Whenever i've done this in the past it's had a pleasant side effect of improving architecture. You end up forcing something akin to "push for's down and pull if's up" because crossing the ffi boundary is not free. It can be quite magical, as in leading to comically unbelievably speed ups when you also take advantage of vector intrinsics.
Of course it won't quite work, but I can definitely see why some people would want that.
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.
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.
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.
> 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.
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.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Maybe the LLM will catch and reproduce all corner cases... maybe not...
Estimates are considerably longer, QA is much harder, integration is full of buckets and rakes, some "senior" devs are afraid to touch stale core code, innovation is stifled, devs are frustrated, hiring is harder, attrition bites. The most frustrating thing is that its very hard to communicate the issues as everyone experiences a fragment of the pain and none of it lines up in a spreadsheet for anyone to appreciate the whole cost. Everything just sucks.
LLMs changing the economy of this sounds great, especially if removes the essential issue with the ground up rewrite, which is the "ground up" part.
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.
With more disciplined engineers we are slowly cleaning it up but it is taking years to realize because management won’t allow work to be stopped on feature development. If we’re lucky, we get two sprints a year to fix things, usually around holidays when half the team is afk anyway so not a huge chunk can be fixed. Then on top of all of that, if you break something when trying to Boy Scout rule improve things, you get chastised and management clamps down more on “scope creep”.
Add in LLMs and now engineering management is convinced that they will solve our problems. Except it can’t really because the project is so spread out and disjointed that it’s impossible to reason about. You’d spend tens of dollars just to have it follow all possible branches of our most critical user flows (and then with hallucinations on top!).
I’m not saying the bots aren’t useful, but they cannot comprehend a disaster zone architecture in anything more than extremely targeted chunks. Without being able to see the entire thing, having it reliably refactor is just not possible without weeks of manual testing or taking a risk and being prepared to rollback on short notice. Writing tests would also take many weeks and if the point is to rearchitect to something sane, a snapshot test is not really going to cut it.
It’s a pickle of a problem for sure… and I’m not sure I will survive at this company long enough to see the end (though I’ve been here years already).
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.
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.
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 understanding of the organization about the problem they've solving. Remember: People change slowly.
People are often too tied to the idea of "rewrite" as a replay of all current capabilities, but should instead be thinking about fundamentally different primitive capabilities of the system. It's not a "redo" if you're changing some of your fundamental assumptions about the problem space.
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 quickly.
I'm working on self-hosting a programming language I've been developing. The transpiler from the original language to the host language is ~12k LoC and translates ~99% the original compiler's ~80k LoC cleanly.
The total self-host looks like it might only take a couple of weeks and <$100... TBD.
Sounds great! Have you tried this? Did you see what went wrong? Otherwise this is just the same nonsense as always.
AI won’t.
If you gave junior dev exact tasks what to do where you will get better results.
Just like with LLM.
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.
haha
I’ve been hearing for quite some time now that I should be using an LLM to plan before the build. This is treating the LLM as the architect, not as a junior being handed small tasks here and there.
I haven’t bought into it, so don’t use it this way, but an army of people online and in the media are pushing the fomo hard and telling people this is how it should be used. If the LLM isn’t doing what we want, it simply means we need to use the LLM even more. That’s the prevailing message from the industry.
> It's not used in production.
Sounds like it’s a tech demo as of now.
For example, the code base contains a physical controller. It’s closed loop in that it can react in realtime to changes. But it’s a slightly untypical implementation because this one can even look into the future through simulations. But Fable does not understand that. Instead, I need to remind it every 30 minutes that this is closed loop. It keeps wrongly claiming that the controller was open loop and then based upon that it will make up constraints that don’t actually exist.
Meanwhile, I have a hard time to believe people don't encounter problems with AI solutions on a regular basis (I do).
I mean it is a tool and you need to understand how the tool works. When there is too little context, where there is so much context so that you are poisoning it, when you are allowing the tool to do patch-on-patch and etc.
In 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.
OP is playing the game. The post literally says "from LinkedIn" so if you look, he has 500+ connections and 1400 followers. That's not nothing. Good for him, all advice points to this new attention economy we live in.
I'm a bit aged out of all this. And I rode the 2010s wave so I can't give any advice in good conscience. I can only say that I see you and there's a whole world of silent majorities out there with no follow count and no broetry with our name on it. (search for that word in this thread, just learned it, it's great!)
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 get it wrong. It helps if you know what you are doing rather than just vibe coding things.
But for rewrites, the sunk cost fallacy becomes a lot cheaper. So, that changes how you deal with stuff that clearly isn't living up to expectations. Unceremoniously replacing what wasn't that expensive to begin with might be the cheaper option relative to fixing it.
There is no such thing as maintenance-free software, even as the end user.
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.
·
·
·
·
[1] https://fenwick.media/rewild/magazine/dead-broets-society-be...
That said it can work surprisingly well with custom frameworks and tools provided that they are predictable and consistent.
For example, I created a platform with custom Web Components. Agents do a great job at using the components by reading the docs. I find it a lot easier and more succinct than React. I think it's because AI isn't as good with high level patterns when there are too many pieces involved and too many sub-patterns to apply, it gets so caught up in the details that it misses the forest for the trees.
My SDK abstracts away a lot of low-level complexity so that agents are able to focus on higher-level architectural patterns. Also, it's very succinct so agents can fit a lot of context/functionality into its context window. It gets faster and better as the codebase grows.
Here's the link if anyone wants to try: https://saasufy.com/
Of coarse the requirement of using more Ai came from management.
Use standard tools, standard frameworks, standing patterns, standard protocols, and so on, and it's incredibly easy to find highly talented members to join your team, running on day one, and enjoy the progress of the industry. It's quite a different tale when you have some massive internal "framework" monstrosity, have weird patterns and standards, and so on, and these are the sorts of places where you usually find some half-baked terrible custom coding language and so on.
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.
Between context collapse and hallucinations, how likely is it that the end result isn't slightly polished slop that misses lots of crucial details?
But this new "you're holding it wrong" series by people whose grasp of the system gets fuzzy somewhere in the v8 headers is a new land speed record for being vacuously correct and still an attractive nuisance for profit.
Yes, the trend towards encoding hard-won domain knowledge as property and fuzz testing and sometimes even proof system was underway before ChatGPT, and yes, the economics of this approach bend sharply under a post terrawright world.
But no, you haven't added anything except tinsel and chaff and some green css on mixpanel.
Just stop with this shit. If you knew shit about AI you'd be too busy printing cash to teach the rest of us about it.
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.
(At least the author sprang for a $20 a month subscription.)
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.