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.
Top comments (3)
The CAB comparison is a good way to explain this to non-security people. The missing step I keep seeing is ownership after the checklist runs. If the AI tool patches RLS or auth, someone still has to know which invariant it was supposed to preserve, or the next generated change can quietly undo it.
The CAB/UAT distinction is the strongest framing here: a green happy-path test proves intended behavior, not what happens when authentication logic is inverted or a database ships without row-level security. The Lovable example exposing 18,000 records and the Moltbook breach leaking 1.5 million API tokens show why "the button worked" is a dangerously narrow release criterion. I'd turn that second review into a release artifact with an owner and evidence for each check, because a reusable checklist only reduces risk when failures block deployment instead of becoming advisory notes.
This is the part people underprice. The first demo is cheap because the loss function is mostly vibes. The bill arrives when the app needs boring invariants, auth edges, audit trails, rollback, and someone willing to own the failure.