Rescue, Harden, or Rewrite: What to Do With Your Vibe-Coded App

Andrej Karpathy coined "vibe coding" in February 2025 to describe a specific, narrow thing: a throwaway weekend project where you stop reading the code and just ride the model's output. He was explicit that it was low-stakes and exploratory, not a way to ship production software. Eighteen months later, 84 percent of developers are doing it anyway, on real products, with real users, and a growing number of them are staring at a codebase they can't fully explain, asking one question: what do I actually do about this?

Rescue, Harden, or Rewrite: The Quick Test

Karpathy's original definition matters because almost nobody uses the term that way anymore. Vibe coding now means shipping a real product, sometimes with paying customers, built primarily by prompting an AI tool and accepting its output without a full line-by-line review. That shift from "weekend toy" to "production system" is where the debt comes from, and 2026's data shows exactly how much has accumulated.

Veracode's Spring 2026 GenAI Code Security Update puts the security pass rate for AI-generated code at 55 percent, flat since mid-2025. Independent testing puts the failure rate for basic security checks, not advanced penetration testing, at 45 percent of AI-generated code. A researcher who audited 50 vibe-coded apps across major platforms in early 2026 found 88 percent had row-level database security entirely disabled. Not misconfigured. Disabled, meaning the database would hand back any record to any query with no enforcement underneath it. Of 1,645 apps publicly listed on one popular AI builder's own showcase, 170 had critical security failures visible from the outside, live products with real users, not unfinished demos.

The trend line is accelerating, not stabilizing. In January 2026, six CVEs were directly attributed to AI-generated code vulnerabilities. By March, that number was 35. Salesforce analysts have started calling 2026 the year of technical debt, specifically because of vibe coding adoption at scale.

None of this means AI coding tools are bad. It means the gap between "generates working code" and "generates code someone reviewed" is exactly where this damage concentrates, and most vibe-coded apps have never closed that gap once.

Every vibe-coded app that lands on a reviewer's desk gets the same first question, before a single line of code changes: is the data model sound, or is the corruption underneath it?

Call it the Foundation Test. If the data model holds, even genuinely messy code sitting on top of it can be patched or systematically rebuilt without losing what's already working. If the data model itself can't be trusted, if migrating it risks real data loss, or the corruption is baked into how records relate to each other, no amount of surface patching survives contact with the next feature. That single distinction is what actually separates the three paths, not the size of the bug list.

Rescue is for a specific, countable list of dangerous holes in an otherwise sound structure: a hardcoded secret that slipped through because the AI's example code included one, an authorization check that works at the route level but not the data level, row-level security that was never turned on. These are patchable in isolation because they're a checklist, not a pattern. Rescue work tends to land around $50,000 on a small app with a clean data model and no breach yet.

Harden is for an app where the data model is sound but the debt is a pattern, not a list: 300-line functions handling five unrelated responsibilities, duplicated logic across a dozen files, no characterization tests documenting what the system actually does versus what a closed ticket claims. This needs a comprehension baseline first, tests written against current behavior before anything changes, then a systematic security and dependency audit across the whole surface, then refactoring the worst offenders. The architecture stays. The discipline around it gets added.

Rewrite is what's left when the Foundation Test fails: the data model can't be migrated without meaningful data loss risk, or the security issues are structural rather than patchable, baked into the core design instead of sitting on top of it. Audit data puts this end of the spectrum around $500,000 and up, typically an app that's been in production 18 months with debt compounding on every iteration since launch.

Running the Foundation Test yourself takes a specific sequence, not a general sense of dread about the codebase.

Start with the database, not the frontend. Check row-level security policies directly, don't trust that a setting was configured just because a tutorial said to enable it. The 88 percent disabled-RLS finding wasn't from apps that tried and failed. It was from apps where the setting was never touched. Then run a dependency audit, most package managers have a built-in command for this, and flag anything with a high or critical severity rating and an available fix. AI-generated dependency files often pull the most recent version at generation time, which is rarely the most recent version by the time anyone's auditing it.

Then, and only then, look at the data model itself. Can every table's relationships be explained in a sentence? Can a record be traced back to the user who owns it without a workaround? If yes, you're looking at a Rescue or a Harden, and the next question is just how much has been built on top of the mess: a specific list of holes closes fast, a pervasive pattern needs the systematic pass. If the answer involves "well, actually," or a migration that risks losing real customer data, that's the disqualifying signal, worth hearing clearly rather than hoping the next sprint fixes it.

One more thing worth checking: whether the vulnerabilities are getting worse over time, not just present. The gap between January's 6 attributed CVEs and March's 35 wasn't from more auditors looking, it was from more AI-generated code reaching production faster than review capacity could keep up. An app that's shipped features on an unreviewed foundation for a year is a different diagnosis than one that shipped six weeks ago, even if the bugs look similar on a scanner's output.

The most expensive mistake in this whole process isn't a security hole. It's accepting a full-rebuild quote before anyone has actually run the Foundation Test.

Call it the rewrite ransom: a "this needs to be rebuilt from scratch" verdict delivered on a first call, before a real audit, often from whoever's hoping to sell the rebuild. It's a sales tactic dressed up as an engineering opinion, and it works because a founder staring at unfamiliar code and a scary security scan is primed to believe the worst about all of it. Most vibe-coded apps are salvageable. A rebuild-everything verdict without component-level math attached to it should be treated as a red flag, not a diagnosis.

The opposite mistake happens too, further into the process: treating a failed Foundation Test as something a few more patches will fix. If the data model itself is the problem, every feature built on top before the rewrite happens is more work that gets thrown away later, not saved. Knowing the answer early, even an expensive one, is cheaper than finding out after another two quarters of shipping on a broken foundation.

This shows up at fundraising too, increasingly in the questions themselves, not just the term sheet. Due diligence guidance now circulating among investors asks founders directly what their monthly AI and cloud costs actually are, whether anyone besides the original builder can explain how the system works, and whether a security review has ever happened at all. One piece of investor advice making the rounds puts it plainly: founders usually understand their own technical limitations better than their investors do, which means an honest answer to a diligence question is worth more than a confident one.

We've written about this exact gap from the due diligence side before: the code that runs fine in a demo while quietly accumulating the debt that only surfaces when someone official goes looking. The Foundation Test is the practical version of that same question, run before a term sheet forces the issue instead of after. It's also the surface-code cousin of the pattern we've described in AI agent pilots: the ones that reach production have a visible layer where a human catches what the model got wrong before it compounds, and an unaudited vibe-coded app is exactly what happens when that layer was never added. The same unreviewed-output pattern shows up again in why AI-built sites keep failing WCAG checks: different symptom, same root cause, a gap between what the model generated and what anyone actually verified.

The Vibe-Coded App Triage Checklist

1. 1.Check row-level security and access policies directly at the database. Don't trust that a setting was configured just because it should have been.
2. 2.Run a dependency audit and flag every high or critical severity issue with an available fix.
3. 3.Trace whether every table's relationships can be explained simply, and whether a record ties back to its owner without a workaround.
4. 4.Count the vulnerabilities: a specific, bounded list points to Rescue; a pattern repeating across the codebase points to Harden.
5. 5.Check whether the data model needs a real migration with data-loss risk. If yes, that's the Rewrite signal, regardless of how the rest of the audit looks.
6. 6.Get a second opinion before accepting a full-rebuild quote from whoever delivered it.

Vibe coding was never a building methodology. It was, by Karpathy's own definition, a way to move fast on something low-stakes. The debt showing up in 2026 isn't a verdict on the tools. It's the bill for using a weekend technique on a production system and skipping the one step, review, that was always supposed to come after.