Is vibe coding bad? The honest answer.

Short answer: no, vibe coding isn’t bad. Building software faster is a good thing. Building software with AI is a good thing. Lowering the bar so people who couldn’t ship anything before can now ship a working app is, by any reasonable measure, good.

The problem isn’t vibe coding. The problem is what people ship when they vibe code, and that they have no way to know what they shipped.

What “vibe coding” actually is

You sit in Cursor, or Lovable, or Bolt, or v0, or Replit. You describe what you want. The AI writes the code. You click through, see it works, and ship it. You may have never read the code it wrote. You almost certainly didn’t read all of it.

That’s vibe coding. It’s not lazy — it’s the actual workflow more and more people use, and it’s how a huge amount of real software is going to get built from now on.

The thing nobody warns you about

When you write code yourself, you make mistakes you understand. When an AI writes code for you, it makes mistakes that are weirdly consistent — patterns it picked up from training data, defaults it falls back to, shortcuts it takes when the prompt was ambiguous.

We’ve looked at a lot of AI-built apps in production. The same five things turn up again and again:

1. Supabase keys in the frontend bundle. The AI puts them in process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY and calls it a day. The anon key is fine — but it also tends to put your service role key right next to it, or hard-code the project URL with the wrong key. Anyone with devtools can read what shipped.

2. Row-Level Security never turned on. Supabase creates tables without RLS by default. The AI knows this, but it usually doesn’t enable RLS unless you ask. If your app uses Supabase from the browser and you never enabled RLS, your entire database is public. We’ve watched people pull every row of customers from the browser console.

3. OpenAI keys hard-coded in JS. The AI was told “call OpenAI from the frontend” and did exactly that. Your key shipped to every visitor. The first time someone notices, your bill goes from $20 to $20,000.

4. Admin pages with no auth. The AI built /admin/users because you asked it to. It didn’t add a login check because you didn’t ask for one explicitly. The page responds to anyone with the URL.

5. .env files committed to git, deployed to production, or both. Hosting providers usually catch this. Sometimes they don’t.

None of these are exotic. They’re the kind of thing a senior engineer would catch in five minutes of review. The point of vibe coding is that there isn’t five minutes of review.

”But this happens with human code too”

It does. People have been leaking AWS keys on GitHub since 2014. The difference is the volume. When AI tools let one person ship ten apps a month instead of one app a year, the rate of mistakes goes up by the same factor.

Two specific things make it worse:

• The person shipping often can’t read the code. If you don’t know what auth.uid() = id means, you can’t tell whether the Supabase policy the AI wrote is actually doing what you asked.
• The AI’s confidence is independent of correctness. When Claude or GPT says “I’ve enabled RLS on this table,” it sounds true. Sometimes it is. Sometimes it generated a policy that lets everyone read everything. The output looks the same either way.

The result: more apps shipping, more mistakes per app, and the person who shipped is the least equipped to spot them.

So is vibe coding bad?

It’s not. But shipping a vibe-coded app without checking what’s actually live is. The whole point of the speed-up is that you ship fast — there’s no built-in “wait, what did I just deploy?” moment. You have to add that moment back in deliberately.

There are a few ways to add it:

• Read the code (defeats the point, but works).
• Ask another AI to review what the first AI wrote (helps, but also susceptible to the confidence problem above).
• Use a tool that looks at your live app from the outside, the way an attacker would, and tells you what’s exposed.

That last one is what Patchable does, and it’s why we built it. We scan what your AI actually shipped — not what the AI thinks it shipped — and write each fix as a prompt you can paste back into Cursor, Claude Code, Bolt or Copilot. The scan is free. You only pay if there’s something to fix.

If you’ve shipped an AI-built app and you haven’t checked what’s exposed, you don’t know if it’s exposed. Run a scan — free.

Vibe coding isn’t the problem. Shipping blind is.