Why big rewrites may stop being incremental

For most of my career, the responsible answer to "should we rewrite this?" has been "no, migrate it gradually". Put a facade in front of the old system, move one route at a time behind it, and retire the old code when nothing calls it any more. Martin Fowler described the pattern in 2004 and named it after the strangler fig, a vine that grows around its host tree until the tree is gone.

The advice was sound because the alternative was worse. A big-bang rewrite asks a team to rebuild everything the old system does, including the behaviour nobody wrote down, while the business waits. Anyone who has been in software long enough has watched one of those fail.

But gradual migration has costs of its own, and after a while you stop seeing them.

What incremental change costs

The first cost is running two systems at once. Every month of that is paid for twice, in infrastructure and in the attention of the people keeping both alive. And the half-migrated state is meant to be temporary, but it often isn't. A migration planned for two quarters can quietly become a permanent part of the architecture, with a routing layer nobody wants to own. Meanwhile every new feature has to be built against the old shape, the new shape, or both.

So gradual migration doesn't remove the risk. It spreads it out over years. We accepted that because of labour: changing a whole system at once needed more people, for longer, than anyone could justify.

That is the part that's changing.

What the large companies have published

Three reports from the last two years point the same way.

Airbnb moved about 3,500 React test files from Enzyme to React Testing Library. The estimate for doing it by hand was about a year and a half; with an LLM pipeline it took roughly six weeks. Each file went through fixed steps, each step had a validation check, and a failed step was retried with the error fed back until it passed. (Airbnb Engineering, InfoQ)

Google published an experience report on using LLMs for its internal code migrations, including moving 32-bit IDs to 64-bit across the Google Ads codebase and replacing old Java libraries. Candidate changes were found through Google's code index, proposed by a model, validated in several stages, and then reviewed by people. (arXiv 2501.06972)

Amazon's chief executive wrote in August 2024 that upgrading an application to Java 17 had dropped from about 50 developer-days to a few hours, that more than half of Amazon's production Java systems had been upgraded in under six months, and that Amazon estimates this saved the equivalent of 4,500 developer-years. (Simon Willison's notes on the post)

These numbers come from the companies themselves, and they describe migrations, not redesigns. What I find interesting is that the work looks the same in all three, and it's a procedure rather than an assistant suggesting code to a developer. Find everything that has to change, transform it in bulk, check every unit against something other than the model's own opinion, and send people only what failed.

The shape the work is taking

Take the company details away and the same sequence is left.

Two parts of it matter more than the rest.

The first is the check. A model that grades its own work will report success, and sometimes the success isn't there. The migrations above worked because each step had a test the model couldn't talk its way past: the test suite runs or it doesn't, the build passes or it doesn't.

The second is running the new system beside the old one before trusting it. You send the same traffic to both, on a copy of the data, compare what comes out, and label every difference: an intended change, a defect, or an ambiguity in the original that nobody had noticed. That last kind is often the most useful thing a rewrite finds.

Why this could make all-at-once normal

If most of the labour moves to agents and most of the checking is mechanical, the trade that made gradual migration the safe choice starts to reverse. A change a team would schedule across a year becomes something that can be planned completely, run, and verified in weeks, with the old system serving users the whole time.

So my guess is that whole-system changes, done as one controlled run instead of a migration that lasts years, will become an ordinary way of working. Big bangs haven't become safe. The procedure around them has become cheap enough to do properly.

What the evidence doesn't show yet

There are limits to all of this, and I'd rather say them plainly.

Every example above is a well-defined, mostly mechanical migration: a test framework, an ID type, a language version. Changing an architecture involves judgement about what the system should become, and nobody has published numbers for that. The figures are also reported by the companies that did the work.

And the whole approach rests on the specification and the checks. Where the definition of "done" is vague, agents fill the gap with something easier, and they can report success while doing it. I've seen that happen, and it's the subject of other notes here.

That's where I think the interesting work is now. Agents can already write a lot of code. The hard part is making "done" precise enough that a whole system can change at once, and the claim can be checked.