Vibe Coding's Bill
Last updated: 2026-08-154 min read
Vibe coding - prompting an AI and shipping largely without line-by-line review - trades verification for speed. The speed is real; so is the deferred bill: two-week churn rising toward 6%, security pass rates stuck near 55% in testing, and follow-up fix cycles per feature. The question is not whether the bill exists but who has budgeted for it.
Contents
From meme to methodology question
Andrej Karpathy coined vibe codingin early 2025 as a half-joking description of his own weekend workflow: say what you want, accept what the model writes, “give in to the vibes”. The name stuck because it captured something real - for prototypes and throwaway tools, skipping review is often rational. The trouble started when the weekend workflow became a production default, and the research caught up with a pointed title: professional developers don’t vibe, they control.
Where the bill arrives
| Cost category | Mechanism | Published anchor |
|---|---|---|
| Rework / churn | Unverified code gets revised or reverted shortly after merge | Two-week churn 3.1% → 5.7% across 211M lines (GitClear 2025) |
| Follow-up fix cycles | Each shipped feature returns as debugging work | ~0.6-2.4 fix cycles per AI-assisted feature (capacity analyses, 2026) |
| Security exposure | Insecure patterns ship unchecked | ~55% security pass rates in testing; >40% insecure choices per Veracode; CVE-2025-48757 as first named incident |
| Duplication debt | Copy-paste outpaces refactoring, inflating every future change | Duplicated blocks up 8x; copied lines overtook refactored lines (GitClear 2025) |
| Cleanup labor | Making vibe-coded systems maintainable becomes its own work item | No quantified anchor in this article's sources - anecdotal reports only, treated as an observation |
The pattern across all five rows: nothing is avoided, everything is deferred. The prototype demo happens today; the churn, the incident, and the cleanup invoice arrive on someone else’s sprint. Which is why the costs so rarely get attributed back to the practice that caused them. What this deferral adds up to per month, with stated assumptions, is worked through in the cost of verification debt.
Put a number on the bill
The recurring half of the bill
The table above names where the bill arrives. This prices the two lines that recur every month rather than once: the rework and the reconstruction. Drag the volume down to a prototype and the block agrees with the counter-position below it.
Estimated cost of verification debt
Example – illustrative arithmetic, not a benchmark€67,000
per year · €5,580 per month
Modelled on about 120 AI-assisted merges a month.
At these inputs the model puts verification debt at €67,000 a year, or €5,580 a month: 74.4 hours of engineering time, 60 of them spent working out what a change was meant to do before it can be judged.
| Cost line | Per month | Hours a month |
|---|---|---|
| Review reconstruction | €4,500 | 60 h |
| Rework on churned code | €1,080 | 14.4 h |
| Incident allowance | none assumed | 0 h |
What the model assumed for you· Assumption set as of 2026-08-15
0.5 hours of review reconstruction per AI-assisted change · 2 % of AI-assisted changes reworked for a defect within 14 days, an illustrative rate to replace with your own · 6 hours to rework one churned change
The honest counter-position
Vibe coding is not simply wrong - it is a bet that fits some stakes. For throwaway scripts, spikes, and demos, review effort genuinely is waste; the code will not live long enough for the debt to mature. The failure is applying prototype economics to production systems, where three things change. Code lives long enough for churn to compound, security surface matters, and other people must understand and modify what shipped - the road to comprehension debt.
The habit also does not stay contained. Sonar’s 96/48 verification gap shows the prototype habit leaking into everyday practice: half of developers do not always check AI code they distrust - vibe coding without the honesty of calling it that.
Keeping the speed, skipping the bill
- Declare the mode. Prototype or production - decide per task, out loud. Most vibe coding damage comes from the mode being implicit.
- For production: a checkable frame, not a bureaucracy. Three lines of written intent before the run, a spec-vs-implementation check after it - minutes, not process theater.
- Measure the bill. Two-week churn and the unverified-merge rate make the deferred costs visible while they are still cheap.
Where Reality Graph fits
Reality Graph keeps the generation speed and removes the blind shipping. Runs happen exactly as fast as before, but each one ends checked against written intent, with validation the model did not author and an evidence report instead of a vibe.
Naming the bill gives you
- A cost frame for the speed conversation
- Published anchors instead of gut feelings
- A legitimate place for vibe coding: prototypes, declared
- Early metrics before the bill compounds
It does not mean
- AI generation is the problem - unverified shipping is
- Every vibe-coded project fails - these are rates and risks
- Prototyping needs process - declared throwaway code is fine
- The exact costs transfer 1:1 to your team - measure locally
If these boundaries fit how your team wants to ship:
FAQ
- Is vibe coding acceptable for professional teams?
- As a prototyping mode, often yes; as a production default, the data says no. Research on professional AI use is titled after its own finding - 'Professional software developers don't vibe, they control': practitioners who ship for a living wrap AI generation in verification. The dividing line is not whether AI writes the code but whether anything checks it before it carries production risk.
- What does vibe coding actually mean?
- The term was coined by Andrej Karpathy in early 2025 for a workflow where you state intent in natural language, let the AI write the code, and largely skip line-by-line review - 'give in to the vibes'. It named an existing practice and made the trade-off discussable: maximum generation speed, minimum verification.
- What does unreviewed AI code cost in rework?
- The clearest published signal is churn: GitClear's analysis of 211 million changed lines shows code revised within two weeks of merge drifting from 3.1% (2020) toward 5.7% as AI adoption grew - and capacity analyses estimate each AI-assisted feature generates roughly 0.6 to 2.4 follow-up fix cycles depending on project type. Skipped verification returns as scheduled work later, with interest.
- How bad is the security side really?
- Consistently mediocre in testing: security pass rates for AI-generated code have hovered around 55% across 2025-2026 test cycles, and Veracode found models making insecure implementation choices in over 40% of cases for most vulnerability categories. Unreviewed, those rates flow straight into production; 2025 also produced the first named large-scale vibe-coding security incident (CVE-2025-48757).
- If vibe coding is so costly, why is it so popular?
- Because the benefit is immediate and the bill is deferred. The prototype works today; the churn, incident, and cleanup costs arrive weeks later, often attributed to other causes. That asymmetry - visible speed, invisible debt - is exactly what verification debt describes, and why teams that measure it react earlier.
- What is the minimum viable alternative to vibe coding?
- Keep the speed, add a checkable frame: a three-line task with boundaries and criteria before the run, a spec-vs-implementation comparison after it, and validation the model did not author. That preserves most of the velocity while converting 'probably fine' into a recorded verdict - vibe coding for prototypes, verified runs for anything that ships.
Keep reading
Sources
- arXiv - Professional software developers don't vibe, they control: AI agent use for coding (2025)
- GitClear - AI Copilot Code Quality: churn 3.1%→5.7%, duplication up 8x across 211M lines (2025)
- Museum of Vibe Coding - security research record: ~55% pass rates, CVE-2025-48757, Veracode >40% insecure choices (2026)
- xgeeks - AI writes code 3x faster, teams spend 2x fixing it: follow-up fix-cycle estimates (2026)
- Sonar - State of Code: the 96/48 verification gap behind the habit (2026)