The speed is real, and so is where it comes from
"Vibe coding", describing a product by intent and letting an AI tool like Cursor or Claude Code write and iterate the implementation, has gone from a niche habit to a dominant build pattern. Reporting on early Y Combinator batches found roughly a quarter of startups had over 95% AI-generated code. One framing of why this works captures it precisely: vibe coding merges design, implementation, and testing into a single fast loop, which is exactly where the speed comes from, and exactly where the risk hides. When all three collapse into one pass, nobody is separately checking the work.
What actually breaks, and it's rarely the obvious thing
The risks that show up in practice aren't "the AI wrote bad code" in some abstract sense, they're specific and recurring: security vulnerabilities that a fast-iteration loop never stopped to check for, inconsistent patterns across a codebase because the AI made different architectural choices in different sessions, data integrity issues from unexamined database writes, and unintended modifications where a change meant to fix one thing quietly altered behavior somewhere else. None of this is a reason to avoid AI-assisted building, it's a reason to know when the loop needs a second pass from someone who can read the whole system, not just the last feature.
The pattern that actually works
The guidance converging across practitioners is consistent and fairly simple: start with small, low-risk projects where a mistake is cheap, make security review a standing practice rather than an afterthought, and bring in specialists for quality control before the product carries real users or real money. That last point is the one most founders skip, because the MVP already works, demos well, and feels done. "Works in a demo" and "survives production load with real user data" are different bars, and the gap between them is usually invisible until it isn't.
What we actually do with a vibe-coded MVP
This is one of the most common calls we get, and it's not a verdict on the work, it's a known stage. We run the same review we'd run on any codebase before a launch: architecture read, security audit, data-handling check, and an honest answer on what needs to be rebuilt versus what's genuinely fine as-is. Often the answer is "80% of this is solid, here's the 20% that will actually break." You don't need to throw away a vibe-coded MVP. You need someone who can tell the difference between the parts that survived contact with real users and the parts that just hadn't been tested yet.