The One-Shot Myth: What Vibe Coding Actually Looks Like

There's a post on r/vibecoding or r/ClaudeCode every week. Someone ships a full dashboard in an afternoon. A complete SaaS in a weekend. An entire app in one prompt.

And then there's everyone else, spending weeks debugging features that half-work, watching Claude say "Done" while the bug is still there, wondering what they're doing wrong.

Here's the honest answer: they're not lying, but they're not telling the whole truth either.

---

What "one-shot" actually means

When someone says they one-shotted a dashboard, one of three things is true:

1. It was simpler than it looked. A CRUD UI with hardcoded data, no auth, no error states, no real backend. It looks like a product. It isn't.

2. They're showing the highlight reel. The four hours of debugging before that screenshot didn't make the post. The broken mobile layout didn't either. The "one-shot" was session 7 of a project that started two weeks ago.

3. They're optimizing for engagement. "I spent three weeks debugging this" doesn't go viral. "I shipped an app in 6 hours" does.

None of this is unique to AI coding. It's how all technical content works. But it creates a false benchmark that makes everyone else feel like they're failing when they're not.

---

What real projects actually look like

Here's what the honest posts on r/ClaudeCode say, the ones buried in the comments, not the headlines:

"I've been working on a ticketing platform for 2.5 weeks. It's 80% complete, and I'm at the point where I'm just using it like I would any other app and debugging as I go."

"Still debugging Claude Code's creations after weeks, frontend not connected to the backend, broken animations, etc. Some battles I win, some not."

"The last 10% is like 95% of the work."

This is what it looks like. Not because people are bad at vibe coding, but because that's what software is. It was true before AI, and it's still true with it.

The AI accelerates the first 80%. It doesn't change what the last 20% costs.

---

The actual pattern behind who ships

The people who consistently finish projects aren't the ones who found a better prompt. They have a different mental model of what the tool is for.

They treat AI as an executor, not an architect.

Every gap you leave in your spec, your context, or your review gets filled by the AI's defaults. Those defaults are trained on generic code, not your project, not your users, not your constraints. The people who ship are the ones who've accepted that they are still the product manager, the architect, and the code reviewer. The AI is just very fast at writing what they define.

They go slow at the start.

One comment from r/ClaudeCode that gets upvoted every time it appears:

"Slow is fast. Claude can burst through a PRD, claim done, and you're left with slop. It's better to go slow, particularly at the beginning when establishing patterns. You're building brick by brick, not jello by jello."

The builders who move fastest in week four are the ones who moved deliberately in week one. They established naming conventions, file structure, component patterns, and testing habits before building features. Everything built on top inherits those patterns.

They build vertical slices.

A "vertical slice" means building one complete feature end-to-end, frontend, backend, and test together, before moving to the next. No "build the entire frontend first, wire it later." No "we'll add tests after shipping."

This is why the most common failure mode is disconnected layers. Someone builds a complete UI, then tries to connect it to an API that was built separately, and discovers the data shapes don't match, the auth logic doesn't align, and half the state management assumptions were wrong. Vertical slices prevent this.

They review every diff.

Not skim. Review. Every changed line, against the spec, before it's committed. If something changed that wasn't in the task scope, that's a flag. If a new dependency appeared without a clear reason, that's a flag.

The AI generates code at a rate that makes review feel like a bottleneck. It isn't, it's the entire job. Everything else is just typing.

---

The 80/20 of vibe coding pain

Most debugging weeks are caused by the same four things:

1. No AGENTS.md. Every new session, the AI fills in what it doesn't know with defaults. Defaults accumulate. You spend more time correcting drift than building.

2. Tasks that are too big. "Add auth" sent to an AI produces a diff you can't review. You accept it, it ships, it breaks something three sessions later, and you don't know where it started.

3. The AI said "Done," and you believed it. The AI has no way to verify its own output in your environment. It only knows what it predicted. It can predict wrong and still sound confident. "Done" means "I think this is correct." It does not mean "I ran it and checked."

4. Frontend and backend built in parallel, connected never. Two systems built independently, with different assumptions baked in. The connection step is not wiring, it's reconciliation.

All four of these have the same fix: stay in the loop. The AI goes faster when you slow it down.

---

What to do when you're stuck in debugging week three

First: you're not behind. This is normal.

Second: run an architecture health check. After several weeks of AI-assisted building, the codebase has almost certainly accumulated structural debt that the AI introduced quietly. Files that got too long. State that's in the wrong place. Logic that exists in two places. Naming that diverged. Run an audit before adding anything new, fixing the foundation is faster than debugging on top of it.

Third: use the debug persistent bug prompt instead of re-describing the problem and hoping this time is different. The pattern that keeps failing is asking the AI to fix what it already tried. Force it to reproduce and isolate before it touches anything.

Fourth: if the frontend and backend aren't connected, use the connect frontend to backend prompt. Don't let the AI rewrite either side, only wire them. The rewrite is where the new bugs come from.

---

The real expectation

A real, shippable app with auth, a real backend, real error handling, and real edge cases takes weeks. With AI, it takes fewer weeks than it did before. That's the actual value.

The one-shot dashboard is a demo. A demo is not a product.

If you're three weeks in and still debugging, you're building a real thing. That's not failure. That's just what it costs.

The workflow exists to make those three weeks productive instead of chaotic. That's all it is.