Vibe Coding: Fast Until Nobody Can Explain the Code
NOBODY CAN EXPLAIN IT
Hover or focus to flip ↻What vibe coding is, where it genuinely works, and the point where shipping code nobody can explain turns into churn, rework, and a bus factor of zero.
TL;DR: Vibe coding - prompting your way to working software without reading what came back - is a genuinely great way to build things that don't matter, and a genuinely dangerous way to build things that do. The code being bad is not the risk. The risk is that nobody understands it, which converts every future bug into archaeology. What separates superpower from liability is one thing: whether the code outlives the understanding.
What is vibe coding?
Vibe coding is development where the human stops reading the code. You describe what you want, the model produces it, you run it, and if it seems to work you keep going, steering by behavior and vibes rather than by comprehension of the diff. The term went mainstream in 2025, but the practice is just the terminal point of a slider every AI-assisted developer is already on: from "AI completes my line" to "AI writes the function" to "I haven't actually read this file."
Let's be fair before we're brutal, because the fairness is load-bearing: for the right work, this is a superpower. Prototypes, demos, spikes, migration scripts you'll run once, internal tools with three users: code whose job is to answer a question and disappear. Understanding code you're about to delete is waste; vibe coding deletes the waste. The Stack Overflow 2024 survey found 76% of developers using or planning to use AI tools. The practice is not fringe, and pretending it's uniformly reckless is doomerism.
The problem starts at one precise moment: when vibe-coded output crosses into code that has to survive. Merged to main, deployed, depended on, maintained. At that boundary, the trade you made (speed for understanding) comes due, because production code's real cost was never the writing. It's the decade of reading that follows.
The real risk: comprehension debt, not bad code
The lazy critique of vibe coding is "the AI writes bugs." Humans write bugs too. The precise critique is different: vibe coding ships code that works but that no human in the organization understands. Understanding is the asset every future task draws on. Debugging, extending, reviewing, securing: all of it starts with someone who can explain what the code does and why.
Notice what this is: a bus factor of zero. Classic key-person risk means one person understands the payment service - bad, but recoverable, because you can interview the person, pair with them, transfer the knowledge. Vibe-coded production code skips straight past that: the knowledge never existed in anyone's head to begin with. There is no one to interview. The commit author is, functionally, a stranger to their own diff. The same survey above found 44.8% of professional developers rating AI tools "bad" or "very poor" at complex tasks, and complex tasks are exactly where comprehension debt gets called in.
Two more research findings sharpen the picture:
- The speed can be partly imaginary. In METR's randomized trial on mature codebases, experienced developers using AI were 19% slower while believing they were 20% faster. Vibe coding runs on exactly that feeling of speed - the feeling is real, the speedup sometimes isn't. The full story is in the AI productivity paradox.
- The survival stats are already visible at industry scale. GitClear's 623-million-change analysis measured two-week churn up 15%, duplication up 81%, and refactoring line-moves down about 70% across the AI era: code piling up unexplained beside old code instead of replacing it. And Faros AI measured bugs per developer up 54% at high AI adoption. That's what "nobody read it" looks like in aggregate.
How vibe-coded risk shows up in git
No need to interrogate anyone's workflow; the repo testifies:
- Short-window churn. Code rewritten or deleted within two weeks of merging is the signature of shipped-then-understood. Rising churn after AI adoption is the first alarm; AI code churn covers the measurement.
- Slop accumulation. Duplication climbing while refactoring collapses: the artifact-level picture, dissected in AI slop code.
- Review theater. Big generated PRs approved in minutes. A reviewer can't transfer understanding that the author never had; review coverage numbers stay green while the actual safety net is gone.
- Orphaned areas, fast. Directories where the nominal owner can't answer questions about their own recent commits. Classic ownership mapping catches slow knowledge decay; vibe coding creates instant orphans.
Keeping the speed without the amnesia
The fix is not "stop using AI." It's a boundary policy:
- Draw the throwaway line explicitly. Agree what counts as disposable (spikes, prototypes, one-off scripts) and vibe-code it guilt-free. The policy failure isn't vibe coding; it's not knowing which side of the line a change is on.
- Production code requires an explainer. A person who can walk through the diff and defend it. If the author can't, the review either produces that understanding or the code doesn't merge. Small PRs make this achievable; thousand-line generated diffs make it theater.
- Attribute generated work honestly. Trailers and agent accounts, so you can later ask "is churn concentrated in generated code?" with a real denominator; the method is in how much of our code is AI-written.
- Watch survival, not output. Track two-week churn and duplication trend from adoption day. Celebrate code that's still standing in 90 days, not lines generated on Tuesday.
- Backfill understanding where it's already gone. If part of production is already vibe-coded and load-bearing, treat it like an undocumented legacy system you just acquired: tests first to pin behavior, then targeted reading, then a named owner.
Vibe coding is a bet that you won't need to understand the code. For a prototype, that's usually a winning bet. For production, you're betting against the one certainty in software: someone, someday soon, at the worst possible hour, will need to understand exactly that code. Make the bet consciously, per change, with receipts, and the tools stay a superpower instead of becoming the reason your next incident review starts with "well, nobody actually knows how this works."
Frequently asked
Is vibe coding always bad?
No. For prototypes, spikes, internal one-offs, and code you genuinely intend to throw away, generating without deep inspection is a rational trade: speed for understanding you won't need. It becomes a risk exactly when the code outlives the vibe: merged to main, depended on, and maintained by people who never understood it.
How is vibe coding different from AI-assisted development?
Assisted development keeps the human as the author: they read, understand, and can defend every line that ships. Vibe coding delegates understanding itself; the developer directs outcomes and accepts what appears. The output can be identical; the difference is whether anyone in the building can explain the code after it merges.
What's the fastest way to tell if vibe-coded work is hurting us?
Check survival: how much recently shipped code gets rewritten or deleted within two weeks, and whether that's rising. Then check explainability the honest way: in review, ask the author to walk through a non-obvious hunk. If neither the author nor the reviewer can, you've found the risk before the pager does.