When to salvage, refactor or rebuild an AI-generated product

The prototype did its job. Built in a few weeks with Cursor, Claude or Lovable, it won the pilot, the investor meeting or the signed contract. Now paying users depend on a codebase nobody has read end to end, and every second deploy breaks something.

At this point the general argument about AI-generated code quality stops being useful. The decision in front of you concerns one specific codebase and whether it can carry the weight now sitting on it. There are three honest routes: salvage, refactor or rebuild. Each is right under different conditions, and each fails in a predictable way when picked for the wrong reasons.

Audit before you choose

The route should be chosen from evidence, and the evidence takes roughly a week to gather. Five checks reveal most of it.

Test coverage. Near zero means every change is a guess. Whatever route you pick starts with tests around current behaviour, so the real question is how much of that behaviour is worth pinning down.

Secrets. Search the client bundle for API keys, database URLs and admin tokens. Coding agents put credentials wherever they make the demo work, which is often the browser.

Migrations. Ask how the database schema changes when the product does. If the answer is "we edit it by hand", or silence, the data layer cannot evolve safely. The data is the one part of the system you cannot regenerate.

Shape. One 10,000-line file mixing routing, business logic and SQL is a different problem from fifty scruffy but separated modules. The first resists change everywhere at once; the second can be fixed a piece at a time.

Security. Assume vulnerabilities until an audit says otherwise. Veracode tested more than 100 models for its 2025 GenAI code security report and found that 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities, with cross-site scripting defences failing in 86% of relevant samples. Security performance stayed flat regardless of model size, so code generated by a newer model earns no benefit of the doubt.

Salvage: harden the worst parts in place

Salvage is right when the audit comes back scruffy rather than rotten. The code is readable. Authentication runs through a real library rather than a hand-rolled session check. The data sits in one Postgres database with a schema a stranger could follow. The problems form a finite list, not a fog.

The work is hardening: move secrets server-side, patch the flows that touch money and auth, add error tracking, write tests for the paths that would hurt most, and document how deployment actually works. Weeks, not months, and the product keeps running throughout.

The risk is the ceiling. Salvage keeps the structure you have, so it buys time rather than headroom. The predictable failure is salvaging, relaxing, and re-entering the same crisis six months later with three times the users. Treat salvage as the first step of a plan, not the whole plan.

Refactor: keep the product, replace the subsystems

Refactor is right when users like the product and the data model is roughly correct, but change has become unpredictable. Auth is bolted on. Components reach into each other. Deployment works because one person remembers the steps.

The method is progressive replacement. Pin current behaviour with tests first, then swap one subsystem at a time: authentication, then data access, then deployment, then the worst of the interface. The product ships features throughout, more slowly, and every replaced subsystem lowers the cost of the next change.

Budget months, and expect the work to absorb a large share of whatever engineering capacity you have. The characteristic risk is the half-finished refactor: two auth systems and two data layers are worse than either endpoint alone. A refactor needs a definition of done and a date, or it becomes a permanent tax.

Rebuild: new codebase, migrated users

Rebuild is right when the prototype validated the product but the code cannot carry it. Three signals make the case on their own. The framework fights the product: a collaborative real-time tool generated on a static-first stack, or an offline-first app welded to serverless functions. There is no migrations story and the schema is already wrong, so the most important asset, the data, is trapped. Or the security model has to be designed rather than patched, because authorisation lives in the client and the server trusts whatever arrives.

Rebuild is the most expensive route and the slowest to show progress, and it adds a migration project on top: data, users, integrations. What survives is the thing that mattered. The prototype becomes the spec. Keep it running as the reference implementation, and hold the first release to what the prototype does today. Feature parity is the finish line; improvement comes after.

The old warning about rewrites

Joel Spolsky called the ground-up rewrite "the single worst strategic mistake that any software company can make", pointing at Netscape, which spent three years rewriting its browser while its market share evaporated. His reasoning: old code has been used, tested and debugged, and those ugly functions encode years of fixes for edge cases someone spent weeks diagnosing. A rewrite throws that knowledge away.

The warning was written in 2000 about mature products, and there it still holds. It transfers poorly to a prototype generated in three weeks, because the argument rests on knowledge accumulated in the code, and a three-week-old codebase has accumulated three weeks. The hard-won knowledge lives in the founder's head and in how users behave inside the product, and both survive a rebuild intact. What Netscape lost by rewriting, a young prototype barely has.

Two cautions keep the warning relevant. Rewrites still drift: Herb Caudill's review of six rewrite stories argues there are more than two options, and points at Basecamp, which shipped each rewrite as a new product alongside the old one instead of forcing users across. And patching forever is not free either: in Fastly's July 2025 survey of 791 professional developers, 28% said they fix or edit AI-generated code often enough to offset most of the time it saved. The cost of keeping fragile generated code alive is real. It just arrives monthly instead of upfront.

Making the call

Default to refactor. It keeps revenue flowing, spreads the cost, and forces the habits the codebase should have had from the start. Drop to salvage when a hard deadline sits within weeks, or when the audit finds nothing worse than scruff. Step up to rebuild when two or more of the rebuild signals are present, and accept the honest price: slower now, faster every month after.

Whichever route you take, protect the data first. Code can be regenerated in an afternoon; eighteen months of user records cannot. That asymmetry, more than anything about code quality, is what changed the day the prototype picked up real users.