An AI-generated prototype fails in production for reasons that have nothing to do with the AI and everything to do with what the prompts never covered: authorization, data integrity, concurrency, secrets, error states, and cost. The code usually works. The system usually does not. Those are different problems, and only one of them is visible in a demo.
This is the triage process we run when a founder arrives with a working prototype, real users, and a growing sense that something is wrong. It covers the eight failure modes, the audit that finds them, the order to fix them in, and what the work costs. It is not an argument against AI coding tools. We use them daily. It is an argument about what has to happen between "it works on my laptop" and "it holds up with 500 paying customers."
Why this is suddenly everyone's problem
AI now writes an estimated 41% to 46% of new production code at the enterprise average. Research across more than 8 million pull requests found technical debt rises 30% to 41% after teams adopt AI coding tools without a review process. Meanwhile 84% of developers use AI tools, but trust in the accuracy of the output fell from 40% to 29% year over year.
Read those together and the picture is clear. The volume of generated code went up sharply. The review discipline did not. The gap between "looks finished" and "is production-ready" is where the entire category of rescue work now lives.
The eight failure modes, in the order they bite
1. Authorization was never modelled
The most common and most dangerous. Generated code checks whether you are logged in, and almost never checks whether this user may touch this record. The classic symptom: changing an ID in the URL returns another customer's data. This is the first thing we test and it fails more often than not.
2. Secrets are in the client bundle
API keys, service-role database keys, and third-party tokens shipped to the browser because the prototype had no backend. Anyone can open devtools and read them. Rotating the keys is the easy part. Finding every place they were used is not.
3. No data integrity constraints
Tables without foreign keys, unique constraints, or NOT NULL. It runs fine on ten records. At ten thousand you have duplicate users, orphaned rows, and reports that disagree with each other, and no reliable way to work out which version is true.
4. Race conditions under concurrency
Read-then-write with no transaction or lock. Two people click at once and you double-charge, double-book, or lose one of the writes. Invisible in testing because one person tests at a time.
5. Error states do not exist
Happy path only. The payment provider times out, the upload fails, the model returns nothing, and the interface just sits there. Users assume it worked. Support finds out four days later.
6. Cost has no ceiling
Unbounded queries, no caching, unlimited model calls per user. A prototype costs $30 a month and a modest launch turns it into $4,000 with no per-tenant cap to stop it.
7. No migration path
Schema changes were made by hand or by regenerating tables. There is no migration history, so there is no safe way to change the database without risking data, and no way to roll back.
8. Nobody can change it safely
Duplicated logic across files, no tests, no consistent structure, because each feature was generated in a separate session with no memory of the last one. Every change risks breaking something unrelated. This is the one that quietly ends products.
The 10-point production audit
Run this yourself before hiring anyone. Each item is a yes or no, and the score tells you which path below applies.
| # | Check | How to test it in 10 minutes |
|---|---|---|
| 1 | Row-level authorization | Log in as user A, change a record ID in the URL to user B's. Do you see their data? |
| 2 | Secret exposure | Open devtools, search the JS bundle for "key", "secret", "sk_", "service_role" |
| 3 | Database constraints | Inspect the schema. Any foreign keys? Any unique indexes? |
| 4 | Transactions | Does any multi-step write run inside a transaction? |
| 5 | Input validation server-side | Send a malformed request with curl, bypassing the form. Does it get accepted? |
| 6 | Error handling | Disconnect the network mid-action. Does the UI tell the truth? |
| 7 | Migration history | Is there a migrations folder with ordered, reversible files? |
| 8 | Automated tests | Any test that would fail if you broke checkout? |
| 9 | Backups, verified | Not "backups are on". Has a restore been performed? |
| 10 | Cost ceilings | Is there any per-user or per-tenant limit on expensive operations? |
8 to 10 yes: you have a real application, hire for features. 4 to 7: hardening engagement, roughly 3 to 6 weeks. 0 to 3 with paying users: stop shipping features today and fix items 1, 2, and 9 this week.
Rescue, refactor, or rebuild
The decision is not sentimental and it is not about code quality. It is about whether the data model is salvageable.
| Path | When it applies | Typical cost | Timeline |
|---|---|---|---|
| Harden | Data model is sound, gaps are in security, errors, and ops | $12k–$35k | 3 to 6 weeks |
| Refactor | Data model is mostly right, structure blocks change | $30k–$80k | 6 to 12 weeks |
| Rebuild core, keep UI | Data model is wrong, interface is validated | $50k–$120k | 10 to 16 weeks |
| Full rebuild | Wrong model, wrong product, no traction | $60k–$180k | 12 to 24 weeks |
The honest version most agencies will not tell you: a full rebuild is rarely the right answer when you have paying users. It throws away validated product decisions to solve an engineering problem. We push clients toward hardening or a core rebuild behind the existing interface far more often than toward starting over. If a vendor's first recommendation is always a rebuild, notice that it is also their largest invoice.
The fix order that keeps you shipping
Sequence matters more than speed. This order fixes what can hurt you first, without a feature freeze.
- Week 1, stop the bleeding. Rotate exposed secrets, move them server-side, add row-level authorization, verify a real backup restore. Nothing else ships until this does.
- Week 2, make the data trustworthy. Add constraints, deduplicate existing records, introduce a migration system, wrap multi-step writes in transactions.
- Week 3, make failure visible. Server-side validation, real error states, structured logging, error tracking. You cannot fix what you cannot see.
- Week 4, put a floor under it. Tests around the three flows that generate revenue. Not full coverage. The three that must never break.
- Week 5, bound the cost. Query limits, caching, per-tenant caps on expensive operations, spend alerts.
- Week 6, make it changeable. Consolidate duplicated logic, document the architecture, set up CI so the next change is routine.
- Then resume features. Now every new one lands on something that holds.
How to keep AI tools without recreating the problem
The tools are not the issue. Unreviewed output at volume is. Four rules that let a team keep the speed and lose the debt:
- Generated code gets reviewed like contractor code. By a human who will be on call for it.
- Never generate the security layer. Auth, authorization, payments, and secrets handling get written and reviewed deliberately.
- Schema changes go through migrations, always. No exceptions, no matter how small.
- Tests are written before the generated feature, not after. They are the specification the generator is aiming at.
This is the same discipline we apply on our own builds. Car Block went from zero to live on both app stores in three months with an AI VIN scanner producing a listing in 30 seconds and full escrow-protected payments. Fast and production-grade are compatible. What makes them compatible is that the constraints, the transactions, and the permission model were designed, not generated.
Frequently asked questions
Can a vibe-coded app be made production-ready?
Usually yes. In most cases the fix is a 3 to 6 week hardening engagement covering authorization, secrets, data constraints, error handling, and cost limits, at roughly $12,000 to $35,000. A full rebuild is only warranted when the underlying data model is wrong, which is a minority of cases.
How do I know if my AI-generated app is safe to launch?
Run the 10-point audit above. The three that decide it are row-level authorization, secrets exposure, and a verified backup restore. If any of those three fail and you have real users, you have an incident waiting rather than a roadmap item.
How much does it cost to fix an AI-generated codebase?
$12,000 to $35,000 for hardening, $30,000 to $80,000 for a structural refactor, and $50,000 to $120,000 to rebuild the backend while keeping the validated interface. The variable that decides which bracket you are in is whether the database schema is salvageable.
Should I rebuild from scratch instead?
Rarely, if you have paying users. A rebuild discards validated product decisions to solve an engineering problem, and it usually takes two to four times longer than the estimate. Rebuild the core behind the existing interface instead. Full rebuilds make sense when the product itself is being changed, not just the code.
Why does AI-generated code fail in production specifically?
Because prompts describe features, and production failures come from everything a feature description omits: who is allowed to do this, what happens when two people do it at once, what happens when the third party is down, and what it costs at a thousand times the volume. Models generate what was asked for. Nobody asks for concurrency control.
Do I need to stop using AI coding tools?
No. Technical debt rises 30% to 41% after adopting these tools without a review process. The review process is the variable, not the tools. Teams that review generated code, hand-write the security layer, and gate schema changes behind migrations keep the speed without the debt.
Key takeaways
- AI-generated prototypes fail on authorization, secrets, data integrity, concurrency, error states, and cost. Not on syntax.
- Run the 10-point audit before hiring anyone. It takes an afternoon and tells you which of four paths you are on.
- Hardening costs $12k to $35k. Full rebuilds cost 5x that and are usually the wrong call when you have users.
- Fix in order: secrets and authorization, then data integrity, then observability, then tests, then cost, then structure.
- Keep the AI tools. Add the review discipline. The debt comes from the missing process, not the generator.
If you are not sure which category you are in
Most people arriving at this point already suspect the answer and want someone to confirm it without a sales pitch attached. Send us read access to the repo and we will run the 10-point audit and send back a written findings list: what is critical, what is important, what is cosmetic, and which of the four paths we would recommend with a cost range. If the answer is "this is fine, hire for features instead," we will say that, because telling you otherwise costs us the next three referrals. Related reading: the contract clauses that decide who pays when a build goes wrong, web application security for business owners, and our custom software development service.