Refactor in place wins when the architecture has the right shape but the wrong execution. Most AI-generated codebases look like this: the chosen framework is sensible, the data model approximately matches the domain, the file layout is recognisable — but the implementation has duplicated logic in three slightly different shapes, stringly-typed interfaces between layers, side effects leaking into pure functions, and tests that are coupled to implementation details rather than behaviour. None of that requires a new codebase. It requires focused refactor work.

Refactor wins when the business cannot freeze feature delivery for the months a rewrite needs. A working-but-fragile codebase shipping at half-speed still ships. A rewrite ships nothing until it reaches parity with what the previous codebase already does, and "parity" is a moving target if features keep being added in the meantime.

Refactor wins on cost. The audit puts a defensible upper bound on the work; sprint-level milestones make slippage visible early; if the plan changes, you absorb that change against work you have already gained, not work you would still have to do from scratch.

And refactor wins on edge cases. Every bug fix in the original repository encoded knowledge — a regulation, a customer requirement, a corner of the data — that nobody currently remembers but the code still respects. A rewrite throws that corpus away and rediscovers it via production incidents over the following year.

Rewrite is the right call in a narrow set of cases. The cleanest signal: a single load-bearing wrong decision is doing all the damage, and replacing it in place would require rewriting most of the calling code anyway. The wrong database choice for the workload. The wrong rendering model for the user pattern. The wrong language for the team you can hire. In those cases, the cost of replacing the one thing approximates the cost of starting over — and starting over removes some of the dead weight that built up around the wrong call.

Rewrite is on the table when the codebase is small. Under roughly twenty thousand lines of code, where most of the bulk is AI-generated boilerplate rather than earned domain logic, the math for a rewrite is less catastrophic. Above that line, every extra thousand lines makes the rewrite economics worse.

Rewrite is feasible when the user-facing behaviour is well documented separately — in specs, mocks, screenshots, customer support tickets — so the rediscovery cost is bounded. Without that documentation, the rewrite team will recreate everything from the existing code anyway, slower.

And rewrite is feasible when you have six or more months of business runway you can afford to spend with no shipped features. That is a real cost; teams routinely underestimate it. If your runway does not include it, you do not have the option you think you have.

The pattern that beats both pure refactor and pure rewrite: identify the one or two load-bearing wrong decisions, replace those specific modules in place (behind feature flags), and refactor the rest of the codebase around them. The repository never restarts. The business keeps shipping. Risk is bounded by sprint-level milestones. Cost is bounded by the audit estimate.

This is what a Bitnoise vibe-code-rescue engagement looks like in practice. The audit identifies the twenty percent of the codebase doing eighty percent of the damage; that twenty percent gets surgically replaced in production behind flags; the rest of the codebase gets refactored where it touches the new modules. Feature delivery continues on a hardened path that we set up in the first week of the engagement.

The version that does not work: declaring "we're rewriting the whole thing" without an audit, without the senior staffing the rewrite needs, and without a feature freeze the business agreed to. That is the failure mode that the Spolsky essay warned about in 2000 and that mid-stage companies are still walking into in 2026.