Most rewrites serve the engineer, not the business - Anatoliy Babushka
Most rewrites serve the engineer, not the business
June 30, 2026 · 5 min read
For a few weeks one summer I woke at 4am to rewrite code my employer<br>had already paid someone to write. It ran in production every day, and<br>it was built on CakePHP. I barely knew CakePHP, so every file looked<br>wrong to me. I knew Laravel, and I loved working in it. So on my own<br>time, unasked, I ported the thing piece by piece, swapping in Illuminate<br>packages until the old framework was gone.
We merged it. We started the next project in Laravel too. And I never<br>once made the case for why it was worth doing, because it wasn't, at<br>least not to the business. The application did the same job for the<br>same users at the same speed as before. The rewrite improved exactly<br>one thing: how the code felt to me.
That is the pattern worth naming. Most rewrites answer to the engineer -<br>what they want to learn, what offends their taste, what looks good in an<br>interview - and not to the company paying the salary.
Working code is a ledger of bugs someone already fixed
The strongest case against a rewrite is not the effort. It is memory.<br>Code that has run in production for years is a written record of every<br>bug someone hit and quietly fixed. The odd conditional, the retry with<br>the suspicious timeout: most of it is scar tissue, and each scar marks an<br>incident you never saw. Joel Spolsky made this point in 2000, calling the<br>full rewrite<br>the single worst strategic mistake<br>a software company can make.
Throw the code away and you throw away the fixes. Then you meet the same<br>bugs again, in production, in front of the same users.
I have worked on a Perl system that was already more than ten years<br>old, and a homegrown PHP CMS of about the same age. Neither looked<br>anything like what I would write today. Both just ran. The companies<br>never reinvested in them, and that was the right call. The code had<br>paid for itself long ago, and every quiet year it kept serving traffic<br>was pure return.
Unfamiliar is not the same as broken
Here is the tell I missed in my own story. I was sure the CakePHP code<br>was wrong, but I had never actually learned CakePHP. Unfamiliar is not<br>the same as broken. When you don't know a tool well, everything built<br>with it looks like a mistake, because you can't yet see the reasons<br>behind the choices. That feeling of "this is all wrong" is often just<br>the sound of you not understanding it yet.
Start from the opposite assumption: the people before you were not<br>fools. They made choices that fit the use case and the constraints they<br>had at the time. The code is shaped the way it is for a reason, even<br>when that reason is no longer visible to you.
When touching it is the right call
None of this means freeze everything. That is the lazy reading of "if<br>it ain't broke," and it is how you end up running an end-of-life runtime<br>in 2026 with no security patches. Some debt really does come due. The<br>honest forcing functions look something like this - not a complete<br>list, just the ones I keep running into:
The runtime or a key dependency is end-of-life, with open CVEs and no upgrade path.
One person understands the system, and they just gave notice.
Every new feature costs three times what it should because of the design, and you can show the trend.
The business needs a capability the current code was never shaped to grow into.
That last one is where I am right now. I am rewriting a service, with<br>an AI coding agent doing much of the typing, because we need it to do<br>something it was never built for. The code works. The business outgrew<br>it. That is a reason with a number behind it.
The test that sorts a real rewrite from a vanity one is that simple: can<br>you put a figure on the pain? A CVE, a velocity tax, a hire you can't<br>make, a launch you'll miss. If no number shows up, what you have is a<br>preference about style.
AI makes a rewrite cheap to type and just as hard to get right
AI shifts this math, though not the way most people claim. The new<br>argument is that rewrites are cheap again: the model can port a whole<br>module in an afternoon, so why not let it. But typing was never the<br>expensive part of a rewrite. Rediscovery was.
An agent generates the replacement in minutes. It does not know why the<br>old code carried that strange timeout, because the reason lives in a<br>Slack thread from 2021 and a postmortem nobody linked from the source. So<br>it produces something clean and plausible, with the scar tissue stripped out.<br>You ship it, and you meet the old bugs again, this time without the<br>context the first author had when they fixed them. Fast generation of<br>code that has forgotten its own fixes is not a discount.
The clean version will not stay loved either. The reason today's code<br>reads like a pile of someone else's mistakes is that it survived contact<br>with reality. The AI-written replacement earns the same fate. In two<br>years an engineer opens it, can't see why it is shaped that...