Most software shipped this year by non-engineers wasn't really written by the person who shipped it. They typed what they wanted into Cursor, Claude Code, Lovable, v0, Bolt.new, Replit Agent, or Windsurf. The AI wrote the code. They iterated until it worked. That workflow has a name now: vibe coding. It's everywhere.
The result is a weird new category of software. It runs. It looks production-ready. And it breaks the second you push it past a demo. You can't scale it. You can't host it yourself. The next developer who picks it up gets stuck reading 2,000-line files with hallucinated imports. This guide walks through what's going on, when it's worth rescuing, and what to actually do about it.
What vibe coding actually is
Vibe coding is programming through natural language. You describe what you want, the AI writes the code, you keep going. The developer's job shifts from typing every line to specifying intent, reviewing the output, and nudging the AI back on track when it drifts. The name comes from the fact that you're steering by feel rather than by understanding every line of what the AI produced.
Different tools sit at different points on this spectrum. Cursor and Claude Code work alongside a developer in a familiar IDE. Lovable and Bolt.new generate whole full-stack apps from a few prompts. v0.dev outputs React components. Replit Agent and Windsurf build apps inside their own runtimes. The common thread: the human writes less code than ever, and the AI writes more.
Why vibe-coded apps break
AI tools optimize for code that runs. They don't optimize for maintainability or security, and they have no concept of what happens at scale. Code that worked perfectly for a demo tends to fall over on the first real load test, the first security review, or the first time another developer tries to read it. We've audited a couple dozen vibe-coded projects this year. The patterns repeat with striking consistency:
- Exposed secrets. 73% of audited projects have at least one API key, OAuth secret, or database credential exposed in client-side code or committed to git history.
- Zero automated tests. 84% of vibe-coded projects ship without a single test. Every change risks a regression.
- Architecture that doesn't scale. 91% of projects need refactoring before they can support more than 1,000 concurrent users.
- Massive files. AI tools generate code, but rarely refactor it. We routinely find 2,000-line components and 3,000-line API handlers.
- Hallucinated APIs. AI calls functions that don't exist, imports packages that aren't installed, and writes regexes that don't work, and you don't notice until production.
- Permissive auth. Supabase RLS rules with `USING (true)`, missing auth checks on sensitive endpoints, anon roles with insert permission on user data tables.
The eight signs your AI-built app needs rescue
If three or more of these apply, you should consider a rescue:
- You can't deploy to your own infrastructure. The app only runs in Lovable, Replit, or Bolt's runtime. You don't actually own your software.
- A security audit found problems. Exposed keys, permissive RLS, missing auth, vulnerable dependencies. Each one is a potential incident.
- The app slows past 100-1,000 users. The database queries weren't designed for scale. The state management doesn't share well. Caching doesn't exist.
- You need a feature the AI can't reliably generate. Complex business logic, custom integrations, performance-critical paths, AI struggles past a certain complexity threshold.
- A new developer can't understand the code. Onboarding takes weeks instead of days. The cost of every new hire scales linearly with codebase confusion.
- Every AI change breaks an old feature. Without tests, the AI can't tell what it's about to break. Velocity slows to a crawl.
- You're locked into a platform you want to leave. Lovable's template, Replit's runtime, v0's component patterns, they all create lock-in.
- You need production-grade Stripe, auth, observability. Template payments and basic auth aren't enough for real customers.
Refactor, rebuild, or continue?
The decision usually comes down to whether the business logic is salvageable, how bad the architecture actually is, and what budget you have to work with. In our code audits, the breakdown looks roughly like this:
- Continue with guardrails (15% of cases). The app is fine. Add CI/CD, lint rules, basic tests, and tighter AI rules to prevent regression.
- Refactor (70% of cases). Business logic and data model are sound, but code organization, security, and infrastructure need work. A 4-8 week sprint typically resolves it.
- Rebuild (15% of cases). The architecture is fundamentally wrong, or the cost of refactor exceeds 70% of a from-scratch rewrite. The right move is to preserve what works (UI, data, business rules) and re-implement the technical foundation properly.
What rescue actually costs
Code audits start at €600 and deliver in three to five days. You get a code quality audit, secret scan, dependency check, security review, and an honest recommendation on what to do next. Stabilization sprints (fixing critical security issues, exposed keys, show-stopper bugs) typically run €3,500-€5,000 for two weeks. Full refactoring or migration to a production stack runs €9,000-€30,000 over four to eight weeks, depending on scope.
The most expensive part of a rescue isn't writing new code. It's understanding what the AI already wrote. A senior developer has to read through every file, figure out what works, what doesn't, and what's safe to refactor without breaking. That's why a fixed-price audit is almost always the right first step: it tells you what you're dealing with before you commit to a budget.
Can you prevent the debt in the first place?
Yes. Treat the AI like a junior dev whose work has to be reviewed. Turn strict TypeScript on. Write tests before you refactor. Wire up CI/CD with lint, typecheck, and test gates from day one. Don't commit secrets. Use a .cursorrules or .clauderules file so the AI follows your project's conventions instead of inventing new ones every prompt.
Most of the rescue work we do could have been avoided with those guardrails in place from the start. But if you're reading this because you already shipped a vibe-coded MVP and want to know what to do next, the answer is straightforward: get a code audit. Five business days, fixed price, real verdict.
If you want a second opinion on whether your vibe-coded app is ready for production, send us the repo. See our Vibe Code Rescue service for the full picture, or jump to the security audit if that's the immediate concern.