This week I had a short exchange in a chat that I keep coming back to. Someone I work with had pointed an AI coding agent at a legacy system with a single goal: get it running locally. The agent got there. My reaction was blunt – rebuild the thing instead. His answer was that he would rather take the Ship of Theseus route and replace it one plank at a time.
I am not sure I was right. And I think the question deserves more than a gut reaction, because AI has changed one side of an old equation and left the other side exactly where it was.
The old argument
In 2000, Joel Spolsky wrote that rewriting a working codebase from scratch is one of the worst strategic mistakes a software company can make. His core point still holds: old code looks messy partly because it contains years of bug fixes and lessons from real use. In his words, "When you throw away code and start from scratch, you are throwing away all that knowledge."
Martin Fowler's Strangler Fig pattern is the constructive answer to the same problem. Instead of a big-bang replacement, you grow the new system around the edges of the old one and move behaviour across piece by piece, until the old system can be switched off. Fowler notes that the simple "replace it all" plan has gone down in flames most of the time, and that working incrementally shows which behaviour actually matters – and delivers value earlier.
What AI actually changes
Writing code has become much cheaper. So has reading it. An agent can get an unfamiliar system to build, trace a request through it, explain a module and draft a replacement in a fraction of the time it used to take. That is precisely what the agent in our chat demonstrated.
So the cost side of "rewrite" has shrunk. That is real, and I think it is why my instinct to rebuild has grown stronger over the past year.
What it doesn't change
The knowledge Spolsky wrote about is not in the syntax. It lives in behaviour:
- the edge case someone fixed after a bad night in production
- the integration that relies on a field being formatted in a particular way
- the scheduled job nobody remembers, until the report it feeds stops arriving
- the data itself, which usually outlives every version of the code
An agent can produce a clean new system in days that is wrong in ways nobody notices for months. In regulated domains such as healthcare, some of that behaviour is not optional: what gets logged, who can see what, and how long it is kept. A rewrite that quietly drops an audit trail is not a modernisation.
The expensive parts of replacing a system – migrating data, cutting over integrations, changing how people work – are barely touched by faster code generation.
Where I land
I still think we should rebuild more often than the textbooks suggest. But only after the old system has told us what it does. So my order of work would be:
- Use the AI for archaeology first. Let it map integrations, data flows, scheduled jobs and configuration – and have a human verify the map.
- Pin today's behaviour with characterisation tests. Tests that describe what the system does now, even where that is wrong. They are the contract any replacement must meet or consciously break.
- Then decide. If the pinned behaviour is small, the integrations few and the data simple, a rewrite verified against those tests can be the faster and cleaner route. If the behaviour is large, data-heavy or tightly integrated, strangle it.
- Make it a decision, not a drift. Write down why you chose one path, agree it with whoever owns the system, and budget for the cutover – not just the code.
The honest counter-argument to my own instinct is this: AI makes each plank of the Ship of Theseus cheaper too. If the incremental route has also become faster, the main reason to take the risk of a big bang gets weaker. That may be the strongest case for my colleague's approach.
What would change my mind
If characterisation tests showed that a system's real behaviour is a small fraction of its code, I would rewrite without much hesitation. If they showed the opposite – that every odd-looking branch is load-bearing – I would strangle it, however tempting a clean start looks.
Either way, the tests come first. Whichever path you choose, they are what lets you say the new thing does what the old thing did.
How do you decide between rewriting and strangling today – and has AI changed your answer?
Sources
- Joel Spolsky, Things You Should Never Do, Part I (2000)
- Martin Fowler, Strangler Fig