When Rewriting Beats Reviewing: How AI Flipped Software's Oldest Rule

Every developer learns the same superstition early: don’t rewrite working code. Yet that rule is starting to crack. As the cost of generating code drops toward zero, engineers are saying something that would have sounded reckless two years ago — that throwing code away and regenerating it can be cheaper than fixing it. The economics of software, unchanged for a generation, are quietly flipping.

Why We Never Threw Code Away

Start with the old logic, because it was sound. The reason rewrites were taboo comes down to one thing: writing code was expensive.

Every line a human typed carried hidden weight. Bug fixes accumulated over months. Edge cases discovered the hard way in production. Throwing that out meant rediscovering all of it from scratch. Joel Spolsky made the canonical argument back in 2000, calling a full rewrite “the single worst strategic mistake a software company can make” — and Netscape’s decision to rewrite its browser, which gave Internet Explorer years of breathing room, became the cautionary tale developers still cite.

So the center of gravity in software moved toward understanding and maintaining what already existed. Reading other people’s code took far longer than writing your own — the often-quoted ratio is something like ten to one. Code review, refactoring, documentation: all of it existed to answer one question. How do you keep an expensive asset running for as long as possible?

AI Rewrote the Cost Structure

Then the inputs changed. AI coding tools didn’t make developers slightly faster — they collapsed the cost of producing code.

A feature that used to eat half a day now falls out of a few prompts in minutes. A CRUD screen, a data-transformation script, a throwaway utility — these materialize almost on demand. Writing code, the act itself, stopped being the bottleneck.

But here’s the catch: the other costs didn’t move. The work of reading code, inferring intent, and hunting for the subtle bug that only shows up on the third Tuesday of the month — the review cost — barely budged. If anything it got worse, because AI is very good at producing code that looks right and is quietly wrong, and it produces a lot of it. Production got cheap. Verification stayed expensive. And once those two costs cross, the old math breaks.

The Inversion: Rewrite Instead of Review

Follow that to its conclusion and you get something genuinely strange. Suppose reviewing and understanding a chunk of code takes an hour, but handing the spec to an AI and regenerating it takes ten minutes. Which do you choose?

The traditional answer was never in doubt: you fix what’s there. But with the cost curve bent, “just throw it out and regenerate” becomes the rational move in specific cases:

• Orphaned code whose author is gone and whose context has evaporated
• Modules with solid tests but a tangled, unpleasant internal structure
• Small components where the spec is crisp but the implementation is grubby

Notice the common thread: the spec and the tests are clear. When you know exactly what the thing is supposed to do, re-issuing that spec to an AI can be cheaper than decoding the existing implementation line by line. Code stops being a durable asset and starts looking like disposable output — closer to a compiler’s intermediate artifact than a treasure.

So What Actually Got Expensive

Don’t take the easy conclusion, though. Cheap rewrites do not mean software got easy. The expense didn’t vanish — it relocated.

When the code itself becomes cheap, the scarce skill becomes defining what to build. Hand an AI a vague spec and it will generate vague code forever. Ship thin tests and you have no way to know whether the regenerated version is correct. The value migrates to the things only a human can nail down: the specification, the test suite, the architectural call about what “correct” even means.

Code review changes character too. It used to mean staring at a single line and asking “is this right?” Now it drifts toward a bigger decision: “do I trust this entire block, or do I throw it out?” The resolution shifts from zoom-in to zoom-out. You’re reviewing whether to keep a chunk, not whether to keep a line.

And none of this is universal. In a payments system or a security module — where decades of tiny, hard-won fixes are dissolved into the code itself, where the context is the asset — a rewrite is still close to professional suicide. The inversion only holds where context is shallow and the spec is clear. Mistake one domain for the other and you’ll learn Netscape’s lesson the expensive way.

What we’re watching isn’t just better tooling. It’s a re-litigation of a foundational question: is software an asset or a consumable? As the cost of writing code converges on zero, a developer’s real job moves away from producing code and toward defining what’s right and judging what to trust. So look at your own codebase. Which parts are now cheaper to regenerate than to read — and which parts must never be touched? Knowing where that line falls may turn out to be the most expensive skill you own.