Vibe coding problems: why your Lovable app breaks in week two

The pattern is familiar enough to have its own name. Picture a founder who 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 opening for builders who fix 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 model made slightly different choices: 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 often 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 worth checking for: 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 may not, because it solves the user's stated problem ("make payment work") and the security context is implicit.

Is vibe coding secure? What the 2026 data says

The best large-scale public measurement we know of is Veracode's. Its Spring 2026 update tested more than 150 models on 80 coding tasks and found that only 55% of generation tasks produced secure code, even though syntax was correct more than 95% of the time. Results varied sharply by weakness: SQL injection defences passed 82% of the time, cross-site scripting only 15% (Veracode, 24 March 2026).

Two caveats. Veracode tested raw model output, not finished apps with human review. And a newer model does not fix this on its own: Veracode reports that the security pass rate has stayed roughly flat across model generations. The practical reading for a founder: assume that a vibe-coded app has at least one security gap until you have checked, and check before real users and real payments arrive.

The "week-two cliff"

A typical arc looks like this (an illustration, not measured data):

• Days 1 to 3: euphoria. Working app, fast iteration, real users.
• Days 4 to 10: confidence. New features ship. Codebase doubles in size.
• Days 11 to 18: first real bug. The fix touches three files. The fix breaks four other things.
• Days 19 to 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.

How to fix a vibe-coded app: the cleanup pattern that works

The right move is usually not to start over. The right move is to run a structured cleanup pass before the cliff, ideally between days 5 and 10. Four steps go a long way towards making a vibe-coded codebase 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 context on every prompt. Most coding agents can read a project instructions file automatically; use it.

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 and its git history 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, for select, insert, update and delete. This takes about thirty minutes and catches the most common holes.

Step 4: delete dead code aggressively

Vibe-coded repos tend to accumulate dead components, unused routes and unreachable utility functions. 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

This is one of the opportunities in our directory of scored startup problems. Two live entries describe it: a vibe-coded app that hits production with no tests and leaks a Stripe key on day two (score 8.7) and a one-bug fix inside a 300-line function nobody wrote by hand (score 9.0). A related entry covers reviewing AI-written code taking longer than writing it. Our original May entry is kept in the archive.

The wedge is not "another AI codebase tool." It is a refactor agent that takes a Lovable or v0 repo as input, finds the three failure modes above, and ships a clean pull request an engineer can review. General coding agents are built mainly to write new code. A product dedicated to cleaning up what already exists has room to stand out. See what tools already exist for each problem, and the gap they leave; if you have built one, list your tool under the problem it solves.

Questions founders ask

Why does my Lovable app keep breaking?

Each prompt session can use different conventions, so after a week the codebase mixes several patterns for state, errors and data access. A fix in one file then breaks assumptions in another. Freezing conventions and adding tests for your three key workflows stops most of the breakage.

Is vibe coding secure?

Not by default. Veracode's Spring 2026 update found that only 55% of AI code-generation tasks produced secure code across more than 150 models, and cross-site scripting defences passed only 15% of the time. Check for committed secrets, open database policies and wildcard CORS before real users arrive.

Should I rewrite a vibe-coded app or clean it up?

Clean it up first. A structured pass (frozen conventions, tests for three workflows, a security check and deleting dead code) usually makes the app ownable without throwing away what already works for users. Rewrite only the parts that fail those tests repeatedly.