TL;DR. Vibe coding — taking the code the AI writes wholesale, without reading it — is right for code you'll throw away. What's wrong is the "it's small, it's solo, so vibe is fine" indulgence. The axis is not team size but whether the code survives, and the solo developer isn't exempt — they're the most exposed, least able to separate throwaway from survivor, with no team to catch the ones that survive.
The Back Half of the Indulgence
The current consensus is hybrid — spec-driven for large teams and regulated industries, vibe for solos and weekend projects. The front half is right. The back half, I think, is wrong. Spec-first is not a headcount problem; it's a cost-of-reversal problem. The claim isn't "always spec" — it's "vibe only when you're sure you'll throw it away." Even working alone, the you of two months from now is a different person seeing that code for the first time, and "it's small, keep it light" is precisely the on-ramp to that debt.
I sit on the spec-first side. This doesn't contradict the piece arguing to use AI to the maximum — there the call was use AI to the maximum; here it's constrain the method. Not use less AI, but put a spec on it.
Vibe Is Throwaway Code by the Inventor's Own Spec
Put the opposing camp in its strongest form, and "vibe for the small stuff" isn't a late carve-out — it's the inventor's original definition. Andrej Karpathy's original tweet coining vibe coding in February 2025 ends like this: "I 'Accept All' always, I don't read the diffs anymore. … It's not too bad for throwaway weekend projects." Accept All, never read the diffs, "forget that the code even exists" — and the scope nailed down explicitly to throwaway weekend projects. Vibe coding was less a designed methodology than a practice the coiner described for code he intended to throw away — Karpathy later called that tweet "a shower of thoughts throwaway tweet that I just fired off without thinking" — and "vibe for solos and small projects" simply inherits that original scope. The inventor's authority props up the opposing camp.
And there are seats vibe genuinely wins: exploration, MVPs, one-off scripts. Force a spec there and speed dies. The literature concedes this too — "Vibe Coding in Practice" (Dec 2025) frames the core of vibe as a tradeoff between flow and technical debt. Frictionless generation really does accelerate prototypes and MVPs; debt is the price. The hybrid consensus is common sense for a reason.
The Solo Seat Isn't Exempt — It's the Worst
Wedge one — throwaway doesn't get thrown away. In the flow-versus-debt tradeoff, if the code you meant to discard actually gets discarded, the debt is settled. The problem is that it isn't. A "nicely wired MVP" meets real users, real data, real traffic and gets promoted straight to production. A year of vibe code comes due — Salesforce Ben predicted 2026 as "the year of technical debt", naming vibe coding directly. The cost side has hard numbers too. In Stack Overflow's 2025 survey, 45.2% of developers flagged debugging AI-generated code as more time-consuming among their frustrations, and in Veracode's benchmark 45% of AI-written code introduced an OWASP Top 10 vulnerability.
Wedge two, the core — solo isn't exempt; it's the most expensive seat. The indulgence's logic is "small team, small burden," and it's exactly backwards. First, the solo developer is worst at separating throwaway from survivor — with no code review, there's no second pair of eyes to correct the self-assessment of "this is just a prototype." Second, when it survives, maintenance is you — there's no team to absorb the debt. Third, a single production incident severs deep work and wipes the entire mental state you'd built up (days to recover). The "lightness" the indulgence promises is billed most expensively to the solo.
Wedge three — the vendors sell spec. Amazon, selling AI coding harder than anyone, positioned its agentic IDE Kiro as beyond vibe coding and shipped a Requirements→Design→Tasks spec workflow as the core of the product (launched July 2025). What the vendor sells isn't vibe — it's spec. And when an incident reportedly involving agentic AI broke — the FT reported Kiro "deleted and recreated" an environment — Amazon pushed back that it was misconfigured access, not AI, and made peer review mandatory for production access. What the company reached for was not vibe but process.
Reset the axis and it's survival, not scale. Sure you'll throw this away? Vibe. Not sure? Spec. And the solo developer gets that certainty wrong most often.
The Coiner Is Revoking the Indulgence
A year after Karpathy coined vibe coding in February 2025, that year of code came due as 2026's debt (Salesforce Ben, January). And in February 2026 the coiner himself called vibe coding "passé" and moved to agentic engineering — not writing the code directly but orchestrating agents and acting as oversight. From "forget the code exists" to "oversee it." The person who issued the indulgence is withdrawing its premise.
Defer the judgment now with "it's small, so vibe," and the moment that code survives, the cost is billed at compound interest. And the solo developer has no one to split the bill with.
References
Vibe's original definition (opposing camp)
- Karpathy — the original "vibe coding" tweet (Feb 2025)
- Karpathy — the "throwaway tweet" follow-up / shift to agentic engineering
- Vibe Coding in Practice — the flow-vs-technical-debt tradeoff (arXiv, Dec 2025)
The debt side
- Stack Overflow 2025 survey — 45.2% flagged debugging AI code as more time-consuming
- Veracode — 45% of AI code carried an OWASP Top 10 vulnerability (benchmark)
- Salesforce Ben — 2026, the year of technical debt
The vendors selling spec