Why Every Vibe-Coded App Breaks the Same Way

nero — Thu, 20 Aug 2026 20:40:34 +0000

You know that feeling when a change sails through testing, everything’s green, and it still gets stopped at change advisory board because someone asks the one question testing never checks?

That’s not bureaucracy being difficult. That’s the system catching something functional testing was never built to catch. Vibe coding has the exact same blind spot, and almost nobody’s built the CAB step for it yet.

Passing the Test Isn’t the Same as Passing Review
UAT tells you a change does what it’s supposed to do. It says nothing about what happens when someone pokes at it sideways.

An AI-built app is the same story. It ran. The button worked. None of that is proof it’s safe. It’s proof it works when you, the person who built it, use it exactly as intended.

Nothing in the vibe coding workflow forces that second review. You have to build the CAB step yourself.

The Seven Things That Keep Showing Up
I went looking for patterns across the vibe-coded apps I reviewed while writing my security handbook. Different founders, different ideas, different stacks in the details. Same seven problems, in some combination, every single time.

None of these require you to read a line of code to catch. They require knowing which questions to ask, and where to look for the answer. A dashboard. A browser panel. A log. The same way you’d check a switch config without reading the vendor’s source.

I’ve already gone deep on two of these on this profile, the key exposure and RLS specifically, with the exact fix for each. This piece is the map. That one’s the terrain.

This Isn’t a Hypothetical
Veracode’s 2025 GenAI Code Security Report tested over 100 AI models across 80 coding tasks. AI-generated code introduced a real vulnerability 45% of the time. Worth being straight about what that stat actually is: it’s from curated benchmark tasks, not a direct study of vibe-coded apps in the wild. It’s a strong signal, not a precise match.

The real-world incidents are more concrete. In February 2026, a researcher auditing a Lovable-built app found an inverted authentication check, one that blocked real users while letting anyone else straight in. It exposed records for over 18,000 people.

A separate app, Moltbook, was breached three days after launch. A misconfigured database with no row-level security exposed 1.5 million API tokens and 35,000 email addresses.

You Don’t Need to Learn to Code for This
Here’s the part that surprises people, and it’s worth saying plainly because it cuts against the usual advice. You don’t need to become a developer to catch any of the seven findings above.

Don’t go buy a computer science course. Don’t assume the fix is “learn to read code properly.” That’s the expensive, trendy answer, and it’s not the one that actually closes the gap.

What closes the gap is knowing what to ask your AI tool for, and knowing what “correct” looks like on a screen. If you’ve ever triaged a ticket, reviewed an ACL, or sat through a CAB meeting, you already have the instinct. You just haven’t pointed it at your own app yet.

Seven problems, same shape, every time — which means catching them — -isn’t a mystery. It’s a checklist you run once and reuse forever.

If that clicked, that checklist is the whole spine of the handbook I built around it. Seven core findings, plain-English checks, and a prompt for each one so you’re never stuck reading a diff to feel confident shipping. Worth a look if you want the full system instead of just the map.
Find it here “The Vibe Coders Security Handbook”

The Rule of Thumb
If nobody’s specifically asked “is this safe,” assume the answer is no.

DEV Community: nero

Why Every Vibe-Coded App Breaks the Same Way