Did Simon Willison say rewrites never work?

No — he said full rewrites are rare successes in his experience, not that they're impossible. His argument is about the typical failure pattern (moving target, demotivated maintainers, underestimated scope), not a blanket rule against ever rewriting anything.

What's the alternative to a full rewrite?

Willison and Will Larson both point to the same approach: add automated tests around the legacy system, then run staged, coordinated migrations that move pieces of it toward the desired architecture without taking the whole system offline at once.

Do AI coding agents change this calculus?

They lower the cost of writing new code, not the cost of discovering what the old system actually does — which is usually the real blocker in a rewrite. Agents tend to be more useful applied to characterization tests and incremental refactors than to a from-scratch rebuild.

Vibecoding7 September 20264 min read

Why 'Rewrite It From Scratch' Still Fails — Even With AI Coding Agents

Simon Willison's reply to a Lobste.rs thread on technical debt lays out why full rewrites keep failing — and why AI coding agents don't change the underlying math.

By TRAGenX Desk

The rewrite trap, restated

On September 4, 2026, developer Zach Kehs published "There's No Limit to How Bad Code Can Get", arguing that metaphors like a "sinking ship" give bad codebases a false floor — in practice, a business fails long before its code hits any hypothetical bottom. The post drew a large Lobste.rs discussion, including the familiar suggestion that once debt gets bad enough, the right move is to burn it down and start over.

Simon Willison, replying in that thread, pushed back with a pattern he says he's watched repeat: rewrites announced with confidence rarely finish, and when they do ship, they rarely fully replace what came before.

Why full rewrites fail

The old system stays in production, so it keeps changing — it's still running the business.
The engineers still maintaining it know it's supposedly going away, so they have little incentive to keep it clean.
The new team moves fast early on, then discovers how much undocumented behavior the old system actually covers.
Months or years in, pressure to show something forces a partial launch.
Result: two systems in production — the old, janky one and a new, incomplete one — which is more maintenance burden, not less.

Migrate, don't rewrite

Willison's alternative is to shore up the existing system with as much automated testing as possible, then use targeted refactors to move it toward the desired shape. He points to Will Larson's 2018 essay "Migrations: the sole scalable fix to tech debt" as the sharpest treatment of why staged, coordinated migrations — not rewrites — are what actually retires debt at scale.

The AI-coding wrinkle

This debate predates LLMs, but AI coding agents raise the stakes. An agent can scaffold a plausible-looking rewrite of a service in an afternoon, which makes "let's just start clean" more tempting than ever. What it doesn't do is solve the bottleneck Willison describes: nobody — human or model — understands the old system's undocumented edge cases until something forces the encounter. Pointed at a from-scratch rebuild, fast codegen just gets a team to the two-systems failure state faster. Pointed at reading the legacy code, writing characterization tests against its real behavior, and proposing incremental refactors, it's doing the migration work Larson describes — just faster.

In my experience it's so rare for that to work.
— Simon Willison, on rewriting a system from scratch

FAQ

Frequently asked questions

Did Simon Willison say rewrites never work?: No — he said full rewrites are rare successes in his experience, not that they're impossible. His argument is about the typical failure pattern (moving target, demotivated maintainers, underestimated scope), not a blanket rule against ever rewriting anything.
What's the alternative to a full rewrite?: Willison and Will Larson both point to the same approach: add automated tests around the legacy system, then run staged, coordinated migrations that move pieces of it toward the desired architecture without taking the whole system offline at once.
Do AI coding agents change this calculus?: They lower the cost of writing new code, not the cost of discovering what the old system actually does — which is usually the real blocker in a rewrite. Agents tend to be more useful applied to characterization tests and incremental refactors than to a from-scratch rebuild.

Sources

Comment: There's No Limit to How Bad Code Can Get — Simon Willison
There's No Limit to How Bad Code Can Get — Zach Kehs
Migrations: the sole scalable fix to tech debt — Will Larson, Irrational Exuberance
There's No Limit to How Bad Code Can Get (discussion) — Lobste.rs