I vibe-coded a working app in 40 minutes and it was glorious. Then I tried to add a second feature, and the whole thing came down like a Jenga tower. If you've shipped anything real with an AI agent, you know this feeling. Vibe coding is incredible for the first 80% and a nightmare for the part that actually matters.
Let me define the term so we're not arguing past each other. Vibe coding is when you describe what you want in plain language, let the agent write it, glance at the result, and keep going on feel — no real review, no architecture, just vibes and momentum. It's fast. It's fun. And it does not scale past the demo. That's the hot take, and I'll defend it.
Why the first hour feels like magic
The early phase of any project has no constraints. There's no existing code to break, no conventions to honor, no users depending on yesterday's behavior. The agent gets a blank canvas and fills it. Of course it's fast. You're not asking it to be careful, you're asking it to generate, and generation is what these models are best at.
This is real value, by the way. For a prototype, a spike, a throwaway proof of concept, vibe coding is the correct tool. Get the idea on screen, see if it's worth building, throw it away. I do this weekly. No notes.
The mistake is thinking the prototype velocity carries forward. It doesn't.
Where it falls apart
The second the codebase has state — existing patterns, real data, a feature someone relies on — the calculus flips. Now every change has to be consistent with what's there. And vibe coding has no mechanism for consistency, because you never looked closely enough to know what "consistent" means.
I've watched an agent, three features deep, invent its third different way to handle API errors. Not because it's dumb. Because nobody told it the other two existed, and on a vibe you don't notice until something breaks in a way that's annoying to trace. The codebase becomes an archaeology dig — six styles, four state-management approaches, two date libraries, and a function called handleStuff that does authentication.
The bugs are the worse part. Vibe-coded bugs hide. The code looks right — the model writes plausible, confident code — so you skim it, it compiles, the happy path works, you move on. The bug surfaces three features later when the edge case finally fires, and now you're debugging code you never actually read. You don't even have the context of having written it.
The review you skipped is the bill you pay
Here's the thing nobody wants to hear: the speed of vibe coding is partly borrowed against the future. You're not skipping the review work. You're deferring it, with interest. Every unreviewed diff is a small loan. The demo ships fast because you took out a lot of loans. The product stalls because the payments come due all at once, usually at the worst time.
This is why teams hit a wall around week three of a vibe-coded project. The first features flew. Now velocity is dropping and nobody's sure why. It's the interest. The codebase has no shape, and shapeless codebases get harder to change, not easier.
What I do instead once it's real
I still use the agent for almost everything. I just stop vibing the moment the thing becomes a product. The shift looks like this:
- I read every diff before it lands. Not skim. Read. If I don't understand it, it doesn't ship.
- I keep a
CLAUDE.mdor equivalent that pins the conventions — how we do errors, how we do state, which libraries are blessed. The agent reads it. Consistency stops being luck. - I make the agent write tests for anything non-trivial, and I run them. A passing test is the difference between "looks right" and "is right."
- I work in small, reviewable chunks. One feature, one clear diff, one review. Not "build the whole dashboard" in a single fevered prompt.
None of this is slow, exactly. It's deliberate. The agent still writes the code. I'm just back in the loop as the person who actually knows what's going on.
The honest framing
Here's a command I run constantly when I take over a vibe-coded mess:
git log --oneline -20 && git diff HEAD~5 --stat
I need to see what changed and how much, because on a vibe nobody was tracking it. The first thing I do to a vibe-coded project is reintroduce accountability — to the diff, to the tests, to the conventions.
Vibe coding isn't bad. It's a phase. It's the brainstorm, not the manuscript. The builders who get burned are the ones who never graduate — who treat the prototype workflow as the production workflow and wonder why their app turned to soup.
Use the vibes to find out what to build. Then put your hands back on the wheel to actually build it. The demo will love you either way. The product only loves you if you read the code.