The Rewrite Is Cheap Now. Being Right Isn't.

For twenty-five years, "never rewrite from scratch" has been the closest thing software engineering has to a commandment. The canonical argument rested on a cost structure everyone took for granted: rewriting means re-reading, re-understanding, and re-typing years of accumulated code, and while you do that, the old system keeps moving and your competitors keep shipping. The rewrite was forbidden because it was slow.

Coding agents just deleted the slow part. An agent can translate a hundred-thousand-line codebase from one language or framework to another in days, not quarters. Teams that ran the numbers on mainframe modernization watched average program costs drop from $9.1 million in 2024 to $7.2 million in 2025, largely on the back of AI-assisted conversion, and consultancies now report 40–50% acceleration on modernization timelines. So the commandment is dead, right? If the expensive part of the rewrite got cheap, the rewrite is back on the menu.

Here is the problem: the typing was never the expensive part. It was just the visible part. The organizations that failed at big migrations rarely failed because the code was hard to convert. They failed on everything around the code — undocumented behavior, data migration, integration cutover, and the operational muscle memory that nobody thought to write down. Agents made the rewrite cheap to start. They did much less for what made rewrites dangerous to finish.

What Actually Got Cheap: Translation

Be precise about the thing agents genuinely changed, because it's real and it's large. Something like 80% of a typical legacy codebase is mechanical: CRUD plumbing, data mapping, serialization, glue between layers. This is exactly the material agents translate reliably — the syntax-level transformation from COBOL to Java, from AngularJS to React, from a deprecated internal framework to whatever replaced it.

That translation used to be the schedule. A rewrite was a multi-year project largely because humans had to read old code, reconstruct intent, and retype it — and reading code is the hardest, slowest part of programming. When an agent does the reading and retyping, the schedule collapses. Microsoft's engineering teams describe agent pipelines that inventory a COBOL estate, extract candidate business rules, and emit translated services in a loop that runs while the humans sleep.

But look at what practitioners report on the other side of that loop: automated COBOL-to-Java conversion still needs 40–60% manual remediation before it's production-ready, and the output is often "technically Java" that preserves COBOL's procedural structure — the same program wearing a different syntax. The agent gave you a translation, not a redesign. Translation preserves everything, including the parts you were rewriting to escape.

That distinction is the whole article, so it's worth restating: agents collapsed the cost of producing a new codebase that behaves like the old one. They did not collapse the cost of knowing what "behaves like the old one" actually means.

What Was Never Cheap: The Behavior Nobody Wrote Down

Hyrum's Law says that with enough users, every observable behavior of your system will be depended on by somebody — not the documented contract, the observable behavior. The bug that a downstream team built a workaround for, and the workaround now requires the bug. The undocumented sort order in an API response. The report that arrives at 6:02 a.m. because a batch job has always finished by then, and a spreadsheet three departments away breaks if it doesn't.

None of this lives in the code in a form an agent can faithfully carry across. The agent translates what the code says. Your users depend on what the system does, under production data, at production scale, in the presence of every other system it touches. The gap between those two is where rewrites have always died, and it is exactly as wide as it was before agents:

• Data migration. The schema is in the code; the data quality isn't. Two decades of half-completed backfills, sentinel values that mean something ("999999" is not a quantity), and rows that violate constraints the new system enforces. Every migration estimate that ever slipped, slipped here.
• Transaction and performance behavior. Legacy systems, especially mainframes, encode non-functional guarantees — batch throughput, I/O ordering, strict SLAs — that are properties of the platform, not the program. A faithful line-by-line translation can be functionally identical and operationally wrong.
• The integration web. Every consumer of your system is a Hyrum's Law liability. Internal callers you can find; external partners, scheduled file drops, and screen-scraping scripts you often can't — until cutover night.
• Operational muscle memory. The on-call knowledge of which alarm is noise, which failure self-heals, and which requires waking someone in finance. The old system's runbook is in people's heads, and the new system voids it.

Discovery of this buried behavior — not code conversion — is the highest-value phase of any migration, and the one most programs treat as a formality. Agents can help here too, but as archaeologists, not typists: mining logs for undocumented callers, generating characterization tests that pin down current behavior before anyone changes it. That work didn't get 10x cheaper. It got maybe marginally cheaper, and it was always the long pole.

The New Failure Mode: Serial Half-Finished Rewrites

When rewrites were expensive to start, the expense was a filter. You needed executive sponsorship, a funded team, and a multi-quarter commitment before the first line was written. The filter blocked plenty of good rewrites — but it also blocked frivolous ones.

Agents removed the filter. A senior engineer with an agent fleet can produce a plausible-looking v2 of an internal system in a week, unprompted, as a side project. The demo works. The demo always works. What the demo doesn't carry is the last 20% — the parity proof, the data cutover, the seventeen integrations — and that 20% costs what it always cost.

The strangler-fig migration data has an instructive number in it: projects that extracted less than 5% of monolith functionality in their first 90 days showed a 92% failure rate, and failed migrations left a median sunk cost of $2.1 million. Early momentum was always the predictor, and stalling was always the killer. Now imagine that dynamic when starting is nearly free: organizations accumulate not one stalled rewrite but several — a graveyard of 80%-complete replacements, each modern enough to attract new feature work, none complete enough to let the old system die.

That end state is strictly worse than never rewriting. You now maintain the legacy system plus N partial successors, and every bug fix has to be considered in each of them. The old advice was "never rewrite"; the failure mode was one expensive rewrite. The new failure mode is five cheap ones, none finished. Cheap starts demand a discipline that expensive starts enforced automatically: don't begin a rewrite you haven't scoped a cutover for — a date, a parity criterion, and a plan for turning the old thing off.

The Calculus That Actually Shifted

None of this means the never-rewrite commandment survives intact. It means the deciding variable changed. The question is no longer "can we afford to retype this system?" — you can — but "how much undocumented behavior does this system carry, and how cheaply can we verify parity?" That reframing sorts legacy systems into two piles.

The cheap-rewrite era genuinely unlocks systems where behavior is verifiable and blast radius is contained:

• You own all the clients. Internal tools, admin panels, back-office workflows. When every consumer is in your repo, Hyrum's Law liability is enumerable. This is why the build-versus-buy line is moving in exactly this segment — one 2026 industry survey found 35% of organizations had replaced at least one major SaaS product with an internally built tool in the past year, and 78% planned to build more.
• An executable spec exists. A real test suite, or better, replayable production traffic. If you can pipe last month's requests through both systems and diff the outputs, parity stops being a research project and becomes a batch job.
• The data model is stable and small. Rewriting the service is one thing; migrating the data is the thing.
• It was "retain" only because of cost. Every system that languished untouched because modernization quotes came in at seven figures with a coin-flip failure rate deserves re-evaluation. The quote genuinely changed.

And it leaves the same systems dangerous that were always dangerous: wide surface area, external consumers you can't enumerate, decades of accreted behavior, data whose migration is itself the risk. For those, the strangler-fig approach — replace incrementally behind a routing layer, validate each slice against live traffic before cutting over — is still the only pattern with a defensible track record, agents or no agents. Agents make each strangler slice faster to build; they don't remove the need to slice.

Budget for the Archaeology, Not the Typing

The practical takeaway is an inversion of where rewrite budgets go. The pre-agent budget was mostly construction with a thin verification tail. The post-agent budget should be mostly verification — characterization tests before translation, traffic replay and output diffing during, staged cutover with instant rollback after — wrapped around a construction phase that has become almost incidental.

Run the checklist before green-lighting any rewrite in 2026: Can you enumerate every consumer? Can you replay real traffic against both systems? Is the data migration scoped as its own project with its own owner? Is there a named cutover date and a criterion for turning the old system off? If the answer to those is yes, the rewrite that was irresponsible in 2020 may be straightforwardly correct today — and sitting on a decaying system out of inherited dogma is the actual mistake.

If the answers are no, the agent hasn't changed your situation. It has only made it cheaper to discover that the typing was never your problem.