Nine days from an empty repository to a signed term sheet. The founder built the first version in Lovable, patched the gaps in Cursor, and demoed a working product to four investors who had all seen the same slide deck from somebody else that month. The lead partner said yes. Six weeks later, their technical diligence team asked for read access to the repository.
Here’s what nobody says out loud in that moment: the founder has no idea what’s in there. Not the folder structure, not the dependency tree, not where the payment provider key is stored. Veracode’s longitudinal study, now covering more than 150 models, reported in spring 2026 that AI produces syntactically correct code over 95% of the time, while only around 55% of it survives a security review. The code looks finished because, syntactically, it’s finished. That’s the trap.
The standard advice at this point is to rewrite. Bin it, hire real engineers, start again properly. That advice is usually wrong, and it’s almost always given by someone who bills for rewrites. Rewriting is the most expensive way to solve a problem you haven’t diagnosed yet.
Cleaning up vibe-coded software is a triage discipline rather than a demolition project. This guide covers what the cleanup involves, the ten checks that decide whether your prototype is salvageable, what the work costs in 2026, and a scoring method that tells you which modules to keep and which to throw away. Most teams find the honest answer sits in the middle: hardening for the majority of the codebase, and rebuilding it properly as an MVP only for the parts that can’t be saved.
Vibe Coding Cleanup, Defined: The Work Your Prototype Skipped
Vibe coding cleanup is the engineering work that converts a prototype optimised for demo speed into software that survives real users, real load, real attackers and real auditors. It covers secrets, authorisation, the data layer, input validation, error handling, observability and test provenance. It isn’t a rewrite, and it isn’t a code review.
The distinction matters because founders keep buying the wrong thing: a review when they needed repairs, or a rebuild when they needed a weekend. A code review produces a document. A rewrite produces a new codebase and a four-month gap in your roadmap. Cleanup produces the same product, still running, with the parts that would have failed replaced by parts that won’t. You keep your users, your data and your momentum.
Think about what the generator was actually asked to do. When you prompt Cursor, Lovable, Replit Agent, Bolt or v0, you describe an outcome a user can see: a signup flow, a dashboard, a checkout. The model delivers exactly that. Nobody prompted it for rate limiting, for a migration strategy, for row-level authorisation, for structured logs, for a rollback path. Those things are invisible from the browser, so they were never in the specification.
This is the honest way to think about how to make a vibe coded app production ready: you’re not fixing bad code. You’re supplying the requirements nobody wrote down. One team we audited had a working referral system and no record anywhere of who had referred whom, because nobody thought to ask for the table. The prototype did its job, which was proving the idea deserved money. Cleanup is the second job.
95% Syntax, 55% Security: Why AI-Generated Code Is Not Production Ready
AI-generated code is not production ready by default because language models optimise for plausible output, and plausible code compiles. Syntax correctness now exceeds 95% across leading models while the security pass rate sits at roughly 55%, which means the failure is silent. Your prototype runs perfectly and is still unsafe.
The Veracode Spring 2026 GenAI Code Security Report, which has now evaluated more than 150 models, found the security pass rate virtually identical to where it stood two years earlier. Java code passed 29% of the time. Cross-site scripting defences passed 15% of the time. Meanwhile syntax quality climbed steadily. The models got better at writing code and no better at writing safe code, which is precisely the combination that fools a non-technical founder.
Consider what that looks like in a real repository. The signup form works, and the password reset token never expires. The admin dashboard loads, and the check deciding who is an admin runs in the browser where any user can edit it. The search box returns results, and it builds its query by string interpolation on a URL parameter. Every one of those pages passes a demo. Three of them are in the OWASP Top 10.
The prototype is not unfinished. It is finished against the wrong specification. Switching tools changes nothing here. Claude Code, Windsurf and GitHub Copilot are all working from the brief you gave them, and no amount of prompting your way to a better answer closes a gap the conversation never contained.
Hardening a vibe-coded codebase therefore starts with an inventory rather than an opinion. You need to know what’s broken before anyone argues about what to do with it.
Find the Vibe Coding Security Risks Before Diligence Does
The audit that finds your vibe coding security risks takes three to five days and follows the same sequence an investor’s diligence engineer follows: secrets, authorisation, injection surfaces, data integrity, dependencies, error handling, observability, test provenance, deployment and accessibility. Run it yourself first. Finding ten issues privately costs about £2,000. Finding them in a data room costs a re-priced round.
Almost nobody in this market says the quiet part, so here it is: the reason vibe coding remediation gets funded is rarely a breach. It’s a term sheet. Somebody senior orders a technical review, and suddenly the codebase has to be explainable to a stranger under time pressure. That isn’t a code review. It’s a full architecture review of the codebase, run against the same checklist the other side will use.
One finding surprises founders more than any other. When the same model wrote the code and the tests, the tests assert the buggy behaviour as correct, because the model read the implementation and described it back. On one recent audit, 34 of 51 generated tests passed green against a currency rounding error that had been live for four months. A green pipeline is then certifying the defect rather than catching it. Watch for this before you trust a coverage percentage: a test suite that was generated from the implementation proves only that the implementation hasn’t changed. Test provenance belongs on the checklist for exactly this reason.
The 10 Checks That Decide Go or No Go
Run these ten checks in order before anyone quotes you for remediation:
- Secrets: is any key, token or connection string committed to the repository or hardcoded in client-side code?
- Authorisation: is every permission check enforced on the server, or does any of it run only in the browser?
- Injection surfaces: is any database query or shell command assembled from user input by string concatenation?
- Data integrity: does the schema enforce constraints and relationships, or does the application hope for them?
- Dependency provenance: can you produce a bill of materials and confirm every licence permits commercial use?
- Error handling: does every external call handle timeouts and failures, or does it assume success?
- Observability: if the product broke at 3am, would anything tell you before a customer did?
- Test provenance: were the tests written from the specification by a human, or from the code by a model?
- Deployment: can a second engineer deploy from a clean machine using written instructions alone?
- Accessibility: does the interface work with a keyboard and a screen reader, or is it unlabelled div soup?
Seven or more passes means you’re hardening. Four to six means a scoped rebuild of specific modules. Three or fewer means the diligence conversation is going to be expensive, and you want to be the one who found that out.
Refactoring AI-Generated Code: The Six Repairs Nobody Budgets For
Turning an AI-generated prototype into production software means six repairs in a fixed order: secrets and authorisation first, then the data layer, then input validation, then duplication and coupling, then error handling and observability, then legal exposure. The order is not negotiable. Every later repair is cheaper once the earlier ones are done.
Repair one is credential hygiene: move every key out of the repository into managed secrets, rotate anything that was exposed, and push every authorisation decision to the server. Repair two fixes the schema: real foreign keys, real constraints, real indexes, and a migration path that doesn’t involve someone editing production data by hand. Repair three replaces string-built queries with parameterised ones and validates input at the boundary rather than three functions deep.
Repair four is the one that compounds, and there’s now hard evidence for it. GitClear’s analysis of 623 million code changes found that moved code, their proxy for refactoring, collapsed from 13% of changed lines in 2023 to 3.8% in 2026, while copy-pasted lines rose from 9.4% in 2022 to 15.7% in the first half of 2026 and block duplication climbed 81%. Models don’t refactor. They regenerate. The same payment logic ends up in four files, and a single business rule change becomes a four-file archaeology exercise you didn’t budget for.
Repair five is visibility: structured logging, error tracking and alerting, so failures become facts rather than anecdotes. Repair six is the one almost nobody runs: generate a software bill of materials, confirm every dependency licence permits commercial distribution, and check the interface against basic accessibility requirements. Ask any founder who signed an enterprise contract with an indemnity clause how much they enjoyed discovering a copyleft dependency afterwards.
Picture a two-person team six months past their prototype. Their app has eleven duplicated copies of the same currency-rounding helper, four of which round differently. Nobody wrote them. Nobody chose them. A post-vibe-coding refactor removes ten of the eleven in a single afternoon, and the invoicing bug they had been chasing for three weeks disappears with them.
What It Costs to Fix a Vibe Coded MVP in 2026
Expect four price bands in 2026. A triage and audit runs £1,500 to £2,500 for one week. A scoped cleanup covering secrets, auth, data layer and CI runs £3,000 to £8,000 over three to six weeks. Full production hardening runs £10,000 to £25,000. A complete rewrite runs £25,000 to £60,000.
In dollars, those bands land at roughly $1,900 to $3,200, $3,800 to $10,200, $12,700 to $31,700, and $31,700 to $76,000. The spread inside each band is driven by integration count rather than by codebase size: an app touching one payment provider and one database costs a fraction of one wired into four third-party services with no error handling between them.
Consider the math on delay, because that’s the number founders skip. A three-developer team each losing six hours a week to debugging inherited AI code burns roughly 78 hours a month. At a loaded cost of £36 an hour, that’s about £2,800 a month evaporating into confusion. A £6,000 scoped cleanup pays for itself in just over nine weeks and takes the £45,000 rewrite off the table entirely. Nobody needs a spreadsheet for that. They just need to run it before the diligence email arrives.
One caveat worth stating plainly, because it costs us money to say it. If your product has no users and no revenue, cleanup is premature. Keep validating. That is a £6,000 invoice we would rather not send you yet. The cheapest vibe code cleanup is the one you never needed because the idea didn’t survive contact with customers.
Already know your prototype needs work? You can start a conversation with Empyreal Infotech now, or keep reading to finish the evaluation with the salvage rubric and the proof metrics.
The Salvage Score: Rebuild vs Refactor MVP, Decided Module by Module
The rebuild vs refactor MVP decision should never be taken across a whole codebase. Score each module separately on four dimensions, one to five each, for a total out of twenty. Sixteen to twenty means keep it. Ten to fifteen means refactor in place. Below ten means rewrite that module. The verdict is per module, not per product.
Every competing guide treats your app as one object with one fate, which is why their advice bottoms out at “it depends”. It depends on which part. Your authentication module and your marketing page don’t deserve the same verdict, and pricing them as though they do is how a £4,000 problem becomes a £45,000 quote.
Four Scores, One Verdict Per Module
Score each module from one to five on each dimension:
- Security containment: how little damage does a flaw here do? Payment and authorisation modules score one until proven safe.
- Test truth: are the tests human-written from the specification, and do they assert intended behaviour rather than current behaviour?
- Coupling: can you change this module without editing three others, and does it own its own data?
- Comprehensibility: can a developer who didn’t generate it explain what it does after thirty minutes of reading?
One override applies. Any module scoring a one on security containment goes to the front of the queue regardless of its total, because a well-structured, well-tested, thoroughly comprehensible authorisation bug is still an authorisation bug.
Watch what this does to a real quote. An eleven-module app is scored, and nine modules land above ten while the billing service and the admin permissions layer score six. The honest recommendation is to rewrite two modules for about £4,000 and refactor the other nine for £9,000, rather than rebuild eleven for £45,000. The founder keeps their users, their data and four months of runway. That’s the difference between a vibe-coded app rescue and a demolition invoice.
Green Tests Are Not Proof. Measure the AI Prototype to Production Move
Six numbers prove the AI prototype to production move worked: critical security findings, human-authored test coverage on money paths, mean time to fix a defect, p95 response time under realistic load, change failure rate, and how long a new developer takes to ship their first merged pull request. Measure all six before the work starts. A number without a baseline proves nothing.
Start by killing the green-pipeline illusion: a passing suite is evidence only if a person wrote it. If the tests were generated from the code, delete them and write the critical paths again from the specification. This feels like going backwards and is the single highest-value hour in the whole engagement. Stack Overflow’s 2025 developer survey found that 45.2% of developers name debugging AI-generated code as one of their biggest frustrations with AI tools, only 3.1% highly trust AI output, and the most-cited frustration of all, selected by 66%, is “almost right, but not quite”. That phrase is the most accurate definition of a vibe-coded prototype anyone has published.
Six Numbers, Measured Before and After
Put these on one page, capture the before column on day one, and review them at handover:
- Critical and high security findings: the count from a static analysis run. Target is zero criticals, no exceptions.
- Human-authored coverage on money paths: percentage of payment, auth and data-write flows covered by tests a person wrote.
- Mean time to fix: hours from a defect being reported to a fix reaching production.
- p95 response time under load: measured against realistic concurrency, not a single request on a developer laptop.
- Change failure rate: the share of deployments that cause an incident or require a rollback.
- Time to first merged pull request: how long a new developer needs to ship something, which is the only honest measure of comprehension.
Agree the stopping rule while everyone is still calm. If a module fails the same check twice across two remediation passes, stop refactoring it and rewrite it. Teams routinely spend more defending an early estimate than the rewrite would have cost. A module you have already fixed twice is telling you something.
How Empyreal Infotech Clears Vibe Coding Technical Debt, and When We Refuse
At Empyreal Infotech, vibe coding technical debt gets cleared in phases rather than in one sprint. Week one is triage: the ten checks, a Salvage Score per module, and a written verdict with a price against each option. Nothing is touched until the founder has seen the arithmetic and chosen.
Weeks two to four handle secrets, authorisation and the data layer, because every other repair is cheaper once those are stable. The test suite is then rebuilt from the specification rather than the implementation, which routinely turns a reassuring 80% coverage figure into an honest 30% one. Observability goes in last, so the product reports its own failures instead of waiting for a customer to do it. Handover includes the step most teams skip: documented architecture, a recorded walkthrough, and a working session with your engineers so a human can genuinely own the code afterwards.
The Two Projects We Turn Down
We refuse two kinds of work, and it’s worth being specific about both. The first is the pre-traction prototype: no users, no revenue, no evidence anyone wants it. Cleanup there is a tax on an unvalidated guess, and the right answer is to keep testing the idea cheaply. The second is the codebase where every module scores below ten. At that point remediation costs more than a clean build and delivers less, so we say so and quote the rebuild instead.
A partner who never talks you out of the expensive option is selling rather than advising. If you want a straight read on which of the four bands your product actually sits in, you can talk to our team about your codebase and get the Salvage Score before you commit budget anywhere.
What Founders Ask Before Paying for a Cleanup
What is vibe coding cleanup?
Vibe coding cleanup is the engineering work that turns an AI-generated prototype into production software: securing secrets, moving authorisation to the server, fixing the data layer, validating input, adding error handling and observability, and replacing model-written tests with human-written ones. It’s a targeted repair sequence rather than a rewrite, and it typically takes three to fourteen weeks.
How much does vibe coding cleanup cost?
A triage audit costs £1,500 to £2,500. A scoped cleanup of secrets, auth, data layer and CI runs £3,000 to £8,000. Full production hardening runs £10,000 to £25,000, and a complete rewrite runs £25,000 to £60,000. Integration count drives the price more than codebase size does, so an app wired into four third-party services costs materially more than one touching a single database.
Is AI-generated code safe for production?
Not without review. Veracode’s 2026 testing across more than 150 models found roughly 55% of generated code passes a security review while over 95% of it is syntactically correct, so the failures are invisible until someone looks. AI-generated code is safe for production after secrets, authorisation and injection surfaces have been audited and fixed by a person, and not before.
Should you rebuild or refactor an MVP built with vibe coding?
Decide per module, never across the whole product. Score each module out of twenty on security containment, test truth, coupling and comprehensibility. Sixteen to twenty means keep it, ten to fifteen means refactor it, and below ten means rewrite that module. Most codebases land in a mix, which is why a blanket rebuild quote is usually three to four times more expensive than necessary.
How do you scale a vibe coded MVP after funding?
Treat the scale event and the audit event as the same event, because your investor already does. Run the ten-check audit before diligence requests repository access, fix secrets and authorisation first, then rebuild the test suite so the pipeline reports truth. Teams that harden before hiring avoid onboarding three engineers onto a codebase nobody can explain.
Make the Vibe Coding Cleanup Call Before Someone Makes It for You
Back to the founder with read access requested and nine days of history in the repository. Vibe coding cleanup isn’t an admission that the prototype was a mistake. The prototype worked. It bought a term sheet in nine days, which no traditional build would have managed, and the cleanup is simply the invoice for that speed arriving on schedule.
Everything above is usable this week: the ten checks, the six repairs, the four price bands, the Salvage Score and the six numbers that prove the work landed. None of it requires a vendor. It requires three hours with your own repository and somebody honest about what they find in it.
If you’d rather not learn which of the ten checks you fail during a diligence call, book a free 30-minute review with Empyreal Infotech. No pitch deck. No pressure. Just a direct read on whether your prototype needs hardening, surgery, or nothing at all yet.
Score the modules. Fix the criticals. Keep what earns its place.