How to Fix a Vibe-Coded App Without a Full Rewrite

A vibe-coded app is built by prompting: you describe what you want to Lovable, Bolt, Cursor, or ChatGPT, accept the output, and iterate until the screen looks right. Andrej Karpathy coined the term in February 2025 and described the method plainly: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He also called it fine for "throwaway weekend projects." By November, Collins had named vibe coding its Word of the Year for 2025, and a quarter of the startups in Y Combinator's Winter 2025 batch had already reported codebases that were 95% AI-generated.

So there are now thousands of apps that demo beautifully and hold customer data, and their owners are quietly worried. A developer looked at the code and winced. An auditor asked questions nobody could answer. Someone quoted a ground-up rebuild and a number with five digits.

Here is the position we take after reading a lot of these codebases: a vibe-coded app is not a lost cause. It is unaudited code. Unaudited code has a known fix path. Audit first, then stabilize, then repair by severity. The reflexive big-bang rewrite is almost never the right call, and the quote for it is usually written before anyone knows what is actually broken.

What "vibe-coded" actually means, and why the demo lies

Karpathy's original post included the line "I 'Accept All' always, I don't read the diffs anymore." That was the joke. It stops being funny when the repository holds other people's data.

Vibe coding produces code nobody read. The model writes plausible code fast, and plausibility is the trap: the output looks like software, runs like software in the cases you tested, and fails in the cases you didn't. Your demo exercises the happy path, the one path you built on purpose. Production exercises everything else at once: concurrent users, expired tokens, malformed input, a payment provider that times out mid-transaction.

In codebases built this way, the same failure classes show up over and over:

• Hallucinated dependencies. The model imports a package that does not exist, or exists but does something different than the name suggests. It installs fine on a Tuesday.
• Plausible-looking auth. A login screen that checks a password, then hands every user the same access. The page looks like security. There isn't any.
• Missing error states. The payment webhook fails and the app records nothing anywhere. You find out from an angry customer three weeks later.
• Secrets in plain text. API keys committed straight into the repository, which now lives in three backups and a hosting provider's logs.
• Unhandled concurrency. Two users book the same time slot because nothing checks twice. It worked perfectly with one user. You tested with one user.

The compounding matters too. Each bug gets "fixed" by describing the symptom in another prompt, which generates more unread code around the old unread code. After a few months of this, nobody on earth knows what the app does in its edge cases, including the model that wrote it. That is not a skill problem. It is the method working exactly as designed.

None of this is hypothetical at scale. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across Java, Python, C#, and JavaScript; 45% of the generated samples failed security tests with OWASP Top 10 vulnerabilities. Newer, bigger models wrote more functional code and no more secure code. The security curve stayed flat while the capability curve climbed. CodeRabbit's December 2025 analysis of 470 open-source pull requests found AI co-authored code carried roughly 1.7 times more major issues than human-written code, with security vulnerabilities 2.74 times higher. And in May 2025, researchers found 170 of 1,645 apps built on the Lovable platform left personal information accessible to anyone who went looking. (Exposed records get expensive fast; we broke down what an AI mistake actually costs your business in a separate piece.)

There is a slower failure too, the one you feel before you can name it. GitClear analyzed 211 million lines of code change from 2020 to 2024 and found duplicated code volume up roughly four times, while refactoring fell from 25% of changed lines in 2021 to under 10% by 2024. In practice, every feature request takes longer than the last one, because the same logic now lives in five places and a fix has to find all of them.

That is the honest state of a vibe-coded app. Notice what is not on the list: unusable. The demo worked. The data model is probably fine. The fix path is real, and it starts before anyone writes a line of new code.

Step 1: Audit before you touch anything

You cannot price a fix you have not scoped, and you cannot scope a codebase nobody has read. An audit answers three questions: what exists, what is it missing, and what breaks first under real use.

The inventory part is mechanical. Every screen and endpoint, where the data lives, which third parties the app talks to, which accounts can touch production, where the code is deployed, and whether anyone can reproduce that deployment on a clean machine. Most owners discover at least one surprise here, usually a forgotten integration or a production database with no backup.

Then the findings get ranked by severity, and the ranking is the whole point:

• Anything that leaks data or lets a stranger in gets fixed immediately.
• Anything that corrupts data or dies under load gets fixed next.
• Anything ugly, duplicated, or slow but functionally correct gets left alone for now.

This is also where an automated scanner printout stops being enough. Scanners are good at patterns: a dependency version with a known flaw, a plaintext secret, a missing security header. They are blind to logic. A scanner cannot tell you that the "admin" role is granted to every new signup, because that code is clean, plausible, and wrong only in what it does. Ranking severity takes a human reading the code against what the app claims to do, which is exactly what our AI Code Audit delivers: a ranked findings list in plain language, sized so you can decide what gets fixed and in what order.

The audit also buys you an honest answer to the rewrite question. When someone quotes a ground-up rebuild after a two-hour glance at the code, they are usually telling you they would rather write new code than read old code. Reading is cheaper.

Step 2: Stabilize before you change anything

Every fix is a change, and every change to an unstable system is a gamble. Stabilization makes the app safe to work on. Four things, none of them glamorous:

• Backups, verified by restore. A backup nobody has restored is a hope, not a backup. Restore one into a scratch environment and click around. Then schedule that test to happen again on its own.
• Monitoring that reaches a human. Errors should surface somewhere a person sees them the same day. If your current setup is "a customer emails us," the app is effectively unmonitored.
• A real deployment pipeline. One command, reproducible, with a rollback. If the only way to ship is a laptop pushing straight to production, every repair becomes a bet on nothing going wrong mid-deploy.
• Environment parity. Staging should mirror production closely enough that "it worked in staging" means something: same runtime versions, same config shape, same database engine. Differences between environments are where fixed bugs go to resurrect themselves.

Is this overkill for a small app? It is about a week of work, and it converts every later fix from a leap into a step. Guardrails under change matter more now than ever: in July 2025, Replit's AI agent deleted a startup's production database despite explicit instructions to make no changes. Tools and agents that act on your system need a floor under them. So do humans.

Step 3: Repair by severity

Now the fixes ship, in the order the audit established. Not everything at once. The first two repairs usually matter most: the thing that leaks data, and the thing that takes the app down. Those get closed first, verified, and deployed while the app stays live.

Targeted patches beat vanity refactors every time. Renaming variables does not protect a customer record. Collapsing duplicated payment logic into one path does make the next fix cheaper, so refactor where the audit showed duplication actively hiding bugs, and nowhere else. New code is untested code, and the smaller each change, the faster you learn whether it worked.

The habit that holds everything together: every fix ends with a test that would have caught the original mistake. When the auth fix ships, a test proves a non-admin cannot reach the admin screen. When the concurrency fix ships, a test books the same slot twice and expects one booking. Without that, the next AI-assisted change quietly reintroduces the bug you just paid to remove.

One boundary keeps repairs cheap: scope discipline. The audit list is the work list. Mid-repair ideas ("while we're in there, can we also...") go on a backlog, not into the change set. Every scope jump multiplies what a rollback has to undo.

Keep the app live throughout. Small changes, verified deploys, and a rollback path that has actually been exercised at least once. Users never notice a well-run repair. They remember an outage.

When a rewrite actually is the right call

Rarely. But not never, and you deserve the honest criteria:

• The data model cannot hold the business. A scheduling product built on a shopping-cart schema will fight every feature forever. No amount of patching fixes a foundation that is the wrong shape.
• Nobody can run it. No repository access, no deployable artifact, the whole thing welded inside a platform account that exports a static snapshot. If the app cannot be changed, only replaced, that is a different project.
• The audit says most of it has to go. When the ranked findings show a majority of components need replacement anyway, a staged rebuild costs less than serial repair. That conclusion comes out of the audit, with numbers attached, not out of a sales call.

Even then, a rewrite does not mean big-bang. You rebuild in stages around the parts that work, keep the app serving customers the whole time, and migrate data in parallel with verification at every step. Engineers call this the strangler pattern: the new system grows around the old one until the old one has nothing left to do. The ground-up rewrite that discards working code and pauses the business for six months is the option you almost never need.

What this costs

An AI Code Audit starts at $2,500 and scales with codebase size. The audit fee credits toward the fix work if you have us do the repairs, so the findings effectively cost you nothing but the decision. You get the inventory, the severity-ranked findings in plain language, and a straight answer on whether your app needs patches, a staged rebuild, or nothing urgent at all.

If the app demos well and you don't know what is underneath it, the cheapest next move is finding out. The Veracode and CodeRabbit numbers above describe what unaudited code carries on average, and averages are made of individual apps. Get the audit, close the two findings that matter, and keep shipping.