Moltbook launched on January 28. Its founder announced he hadn't written one line of code — the whole thing was vibe coded with an AI assistant. By February 1, Wiz researchers had found 1.5 million exposed API authentication tokens, 35,000 email addresses, and private messages containing plaintext third-party credentials sitting in an open Supabase database. No row-level security. The window from launch to breach: three days.
Three months later, Lovable — a vibe coding platform with 8 million users and a $6.6 billion valuation — spent 76 days with user projects exposed via a broken object-level authorization flaw. Source code, database credentials, AI chat histories. A researcher reported the vulnerability on March 3. Lovable closed the bug report without escalating, then introduced a regression that re-exposed projects from February 3 to April 20 before anyone looked properly.
These are not random failures. They're the predictable result of optimizing the wrong part of the problem.
What Vibe Coding Actually Removed
The premise behind vibe coding is that code generation was the bottleneck. If you can't code, you can't build. Remove that constraint and anyone with a product idea can ship.
The premise is half right. Non-technical founders are hitting real revenue on real timelines. Jon Cheney built Gen-AIPI from scratch in February 2025 with $400 and zero coding experience — a $15,000 customer by Tuesday, $2.5M in year-one revenue. YC's latest batch is reportedly 95% AI-generated code. The generation barrier has been dissolved.
But code generation was never the hard part. The hard part is understanding the system well enough to reason about what it trusts, what it exposes, and how it fails. Writing code is the smallest fraction of that understanding. The Moltbook configuration — Supabase's public anon key is safe to expose if RLS is configured correctly, and AI assistants often skip that step unless explicitly prompted — is invisible to someone who has never built a system with real users at stake. The AI generated coherent, functional-looking code. It just didn't configure the database authorization model. Those are different skills.
When you vibe code an entire application, you own a system you have never fully read. The attack surface is the AI's, not yours.
The Numbers Are Not an Outlier
Research across vibe-coded applications from Q1 2026 found that 91.5% had at least one AI hallucination-related flaw — a misunderstood API contract, an incorrect security assumption, a permission model that looked complete but wasn't. Between 40% and 62% of AI-generated code fails security testing outright.
The Wiz researchers described Moltbook's specific failure as one of the most common vulnerabilities they find in AI-built applications. That's not because AI is uniquely bad at Supabase — it's because security configuration involves a chain of assumptions that require you to understand the threat model. AI models generate code that satisfies the visible requirements. A database that users can read and write to satisfies the visible requirements. Row-level security that limits which rows each user can access is an invisible requirement unless you already know what an attacker would do with unrestricted access.
You have to know the attack to configure against it. That knowledge doesn't come from prompting.
The Bottleneck Flipped
For an experienced developer, vibe coding is a genuine productivity tool. They can review AI-generated code at the speed it's produced. They recognize the Moltbook misconfiguration in 30 seconds — they've seen it before, probably made a version of it themselves, and know exactly where to look. The generation speed is a net gain because the review cost is low.
For a founder without that foundation, vibe coding front-loads the reward and back-loads the cost. Everything looks functional at launch. The Stripe integration works. Users can log in. The feature does what you described. The exposure is invisible until production traffic finds it — or until a security researcher runs a basic scan and finds 1.5 million credentials sitting in an open endpoint.
This is why the failures cluster at launch or shortly after. Development testing validates that the software does what it's supposed to do. It doesn't validate that the software refuses to do things it isn't supposed to do. Those are different tests, and the second kind requires adversarial thinking. It requires asking what an attacker would try, not what a user would try.
The constraint didn't disappear when AI started writing code. It moved. The bottleneck was generating code; now it's understanding what you generated well enough to operate it safely. That second skill is harder to fake, and there is no AI tool that fully substitutes for it.
What This Means for Developers Using AI
None of this is an argument against AI coding tools. Developers who understand their systems and use AI to generate code faster are genuinely more productive — the generation speed is real, and skilled review keeps the quality bar intact.
The argument is about where the leverage actually is, and where the risk is accumulating.
The Anthropic comprehension study from earlier this year puts the mechanism precisely. Developers using AI split into two groups: those who generate and accept, and those who generate and interrogate — asking why the code works, what it trusts, what would break it. The first group finished faster and scored below 40% on comprehension tests. The second group took longer and scored above 65%. Same tools. Radically different outcomes, based entirely on whether they treated AI output as a draft or as a deliverable.
For a developer shipping production software, the interrogation behavior isn't optional. Every security incident in AI-generated code traces back to the same root: someone trusted the output without working through what it was trusting in turn.
The Invisible Time Cost
If you track your development time, you'll notice your in-editor coding time has dropped since you started using AI tools. That's expected — the AI is writing more of the raw code. What most tracking tools don't capture: the review work that has to accompany it.
Auditing AI-generated code for correctness and security doesn't look like coding. It looks like reading diffs, checking documentation, cross-referencing configuration against threat model requirements. It's invisible to editor-based time tracking. It disappears from the metrics while accumulating as actual work.
Moltbook spent effectively zero hours on security review before launch. The Wiz researchers spent an afternoon and found 1.5 million exposed credentials. That asymmetry is the hidden cost of vibe coding at speed — not in the time it takes to write the code, but in the surface area that gets created and left unchecked.
The generation bottleneck is solved. It was the easier one.
The understanding bottleneck — building enough of a mental model of your own system to know where it's fragile, what it exposes, and what an attacker sees when they look at it — is still yours. It has always been yours. No amount of prompting fluency changes that, and pretending otherwise is what turns a three-day launch window into a three-day breach window.