The vibe-coding trap: why your Lovable app breaks in week two

The pattern is now familiar enough to have its own name. A founder spins up v0, Lovable, Bolt or Replit Agent on a Friday afternoon. By Saturday they have a working app. By the second weekend the app has thirty paying users. By the third weekend a single payment bug has them paralysed, because the codebase is fourteen files of AI-generated spaghetti and nobody can read it.

Vibe-coding is real, the wins are real, and the cliff is also real. This essay is about the cliff: why it happens, what the cleanup looks like, and the founders who are about to make a small fortune fixing it.

Why vibe-coded codebases collapse

Three failure modes recur, in roughly this order:

1. The code is not wrong, but inconsistent

A vibe-coded repo is a transcript of a conversation. Each session the LLM was in a slightly different mood: different naming conventions, different state-management pattern, different way of handling errors. The file you wrote on day one uses useState with local effects. The file you wrote on day five uses a context provider. The file from day eleven mixes both.

Each file works in isolation. Together they form a codebase where adding any new feature means re-reading the conventions, because there are no conventions.

2. Tests are absent or theatrical

Most vibe-coding tools ship tests when prompted. Inspect them and you usually find tests that assert tautologies (expect(2+2).toBe(4)) or that simply mock the function under test. They pass. They prove nothing.

3. Security holes are quietly shipped

Three patterns we have seen often: hard-coded API keys committed to git, Supabase RLS policies that allow anonymous reads on user tables, and CORS configured as * across the entire API surface. A junior developer would catch any of these on a first read. The vibe-coding tool will not, because it solves the user's stated problem ("make payment work") and the security context is implicit.

The "week-two cliff" in numbers

Three founders we spoke with described the same arc:

• Days 1-3: euphoria. Working app, fast iteration, real users.
• Days 4-10: confidence. New features ship. Codebase doubles in size.
• Days 11-18: first real bug. The fix touches three files. The fix breaks four other things.
• Days 19-30: paralysis. Founder hires a contractor. Contractor quits after one session, citing "AI slop."

Pattern: the curve falls off the cliff the moment a customer-affecting bug needs a fix that touches more than two files.

The cleanup pattern that works

The right move is not to start over. The right move is to run a structured cleanup pass before the cliff, ideally between days 5 and 10. We have seen four steps reliably stabilise a vibe-coded codebase enough to be ownable by a single human:

Step 1: freeze conventions

Pick one state-management pattern, one error-handling pattern, one folder layout. Write a one-page CONVENTIONS.md. From now on, the AI tool gets that file as system context on every prompt.

Step 2: write tests for the three workflows that matter

Not coverage tests. Three real workflows: sign-up, the core paid feature, billing. Use Playwright if it is a web app. These three tests are the canary. When they fail, you stop and fix.

Step 3: run a security pass

Three checks before anything else. Search the repo for the strings sk-, SUPABASE_SERVICE, STRIPE_SECRET. Check that no env var ending in _SECRET is referenced in any file under public/ or client/. Read your Supabase RLS policies aloud, table by table. This takes thirty minutes and catches almost everything.

Step 4: delete dead code aggressively

Vibe-coded repos accumulate dead components, unused routes and unreachable utility functions at twice the rate of human-written codebases. Delete anything not reachable from the home route or the paid feature. If you regret deleting it later, you can prompt it back in five minutes.

The cleanup market is real

We catalogued this opportunity in the directory as AI13. The wedge is not "another AI codebase tool." The wedge is a refactor agent that takes a Lovable or v0 repo as input, identifies the three failure modes above, and ships a clean PR an engineer can review.

The buyer is real. The pain is acute. The leading agentic coding tools (Cursor, Claude Code) are great at making code, not at retroactively cleaning what already exists. A dedicated cleanup product has room to win.