The Rewrite-It-From-Scratch Trap — And Why Security Debt Makes It Worse

What Willison actually said

Responding to a Lobste.rs discussion about abandoning a legacy codebase deemed irrecoverably drowning in technical debt, developer Simon Willison laid out why the 'burn it down and start over' move so rarely works in practice. The old system stays a moving target because it's still running the core business, so it keeps changing. The team assigned to write it doesn't lose momentum on day one — but everyone building the replacement knows their current work is temporary, which saps the incentive to do it carefully. The usual outcome, per Willison, is two production systems instead of one.

Shore up the old system with as much automated testing as possible and then see if targeted refactors can get it to the desired shape.

— Simon Willison

Why this matters for security teams specifically

Security debt is a special case of the same problem, and arguably a worse one. When a legacy application accumulates enough known weaknesses — unpatched dependencies, unreviewed auth logic, sprawling permission checks nobody fully understands — 'rewrite it securely from scratch' is a proposal that feels responsible. It rarely is. While the replacement is being built, the original system keeps its existing exposure, and now there's a second, half-finished codebase to secure as well, often with looser review discipline because 'it's not live yet.' The attack surface goes up, not down, for the entire migration window.

There's also a knowledge-loss problem specific to security work. Legacy systems tend to encode institutional memory about past incidents — a validation check added after a real bypass, a rate limit tuned after a real abuse pattern. A rewrite team working from the current spec, not the incident history, can easily reintroduce a vulnerability the original system already learned to guard against.

The AI-assisted rewrite temptation

None of this is new advice, but it's worth restating as AI coding agents make it cheaper to *start* a rewrite. Generating a large volume of new code quickly doesn't remove the structural risk Willison describes — it just compresses the timeline for producing a second system that needs its own security review, threat model, and test coverage before it can safely replace the first. Speed of code generation is not the same as speed of safe migration; if anything, fast-generated code without matching review rigor reproduces the trap at higher velocity.

What to do instead

• Threat-model the current system before deciding to replace it — know exactly what risk you're trying to retire, not just that the code is old.
• Build automated regression and security test coverage around the existing system first, so refactors can be validated rather than trusted on faith.
• Prefer targeted, incremental refactors and staged migrations over a single big-bang cutover — see Will Larson's case that migrations, not rewrites, are the scalable fix for technical debt.
• If a parallel system is unavoidable, treat the transition window itself as a defined risk period with its own monitoring and access controls, not an implementation detail.

FAQ