The most dangerous sentence in a vibe-coded launch is “but it works.” It does work. The build passes, the demo is clean, the app is live on a real URL. The problem is that working and secure are measured by completely different things — and the gap between them is now well documented.
The data on the gap
This isn’t a hunch any more. Independent research over the past year keeps landing on the same uncomfortable split: AI-generated code runs much more reliably than it’s safe.
- Veracode’s 2025 GenAI Code Security Report found that around 45% of AI-generated code introduced a known security flaw — and in some languages it was far higher. (source)
- A first-quarter 2026 assessment of more than 200 vibe-coded applications found that 91.5% contained at least one real vulnerability. (source)
- Agency audits put it bluntly: roughly 70% of Lovable apps in production ship with row-level security switched off — meaning the database is effectively public. (source)
Read those together and the picture is clear. “It compiles, it passes tests, it deploys” tells you almost nothing about whether real users’ data is safe behind it.
Why “works” and “secure” come apart
Security failures, by their nature, don’t break the happy path. A database with no access rules works perfectly — for you, looking at your own data. A secret in the client bundle doesn’t throw an error; the app runs fine. A /admin route with no server-side check loads instantly for everyone, which is exactly the problem.
The signals you use to judge “done” — green build, green tests, a working demo — are all measuring whether the code does what it’s supposed to. None of them measure what a bad actor can do that it wasn’t supposed to. That second question is the entire game, and nothing in the build flow asks it.
It’s worse with AI-written code specifically, because the model that wrote it shares the blind spots that created the gap. If it didn’t think to lock the database while writing, it has no special reason to flag that it’s open while reviewing.
Closing the gap
You don’t close it with another green checkmark or a smarter prompt to the same model. You close it by having someone read the code asking a different question than the code answers — “what’s the worst a real user could do here?” — and who has seen these exact failure modes before.
That’s a human read. A scanner pattern-matches against generic rules and buries the one finding that matters under a hundred that don’t. A senior engineer holds your actual data model and auth flow in their head and traces who can really reach what. Start with the free self-check to see where you might sit in that 91.5%, then have the code read properly.
That’s the whole idea behind a production-readiness audit: a senior engineer reads your actual code and tells you, in plain English, whether “it works” is hiding an “it’s not safe”. Because the studies agree on one thing — the app running was never the part in doubt.