Chapter 22 — Vibe Coding, Spec-Driven, and ADLC

The mistake is not vibe coding. It is failing to notice when the artefact stopped being a prototype.

22.1 What it actually is

Andrej Karpathy coined vibe coding in February 2025. The research literature that followed is more interesting than the discourse that followed, and it is worth starting there.

Pimenova, Fakhoury, Bird, Storey, and Endres — with Fakhoury and Bird at Microsoft Research — analysed over 190,000 words from semi-structured interviews, Reddit threads, and LinkedIn posts, producing a grounded theory of the practice [B]. Their characterisation:

A natural-language programming paradigm centred on iterative co-design with an AI assistant, emphasising flow and experimentation over strict upfront specification.

Three findings from that study matter for this chapter, and none of them is what the dismissive version predicts.

It is a distinct interaction paradigm, not lazy engineering. The theory they build treats vibe coding as supporting the co-creation of software by humans and AI agents — a mode of working, with its own structure, rather than an absence of one.

Flow is central and psychological. The paper's title names it, and the study captures the flow experiences of developers while "vibing". This is not incidental colour. Section 22.9 argues it is a design constraint on any lifecycle that hopes to be adopted.

Practitioners personify the assistant. Many describe the LLM as a partner or pair programmer. That framing does real work — it explains why the practice feels like collaboration rather than tool use, and it is worth noticing that Chapter 5 established the partner has no memory, no stake, and no accountability. The felt relationship and the actual one differ, which is Chapter 18's territory.

So: a real paradigm, with real psychological content, that people adopt deliberately. Any treatment that opens by calling it undisciplined has already misdescribed its subject.

22.2 The precise formulation

The formulation this book's research notes proposed is that vibe coding is A2 with the harness switched off. That is close and not quite right, and the correction matters.

Chapter 13 defined A2 — Delegated: the agent completes a scoped task and the human reviews the resulting diff. Vibe coding has the delegation. What it lacks is not the harness exactly — it is the acceptance criterion as an artefact.

Vibe coding is A2 with the acceptance criterion held in the human's head rather than written down. The human still verifies. They verify by looking, running it, and judging — live, in the moment, against a standard that exists only in their mind at that moment.

This is more precise and it is more useful, because it immediately yields the condition under which the mode is correct rather than merely popular.

The acceptance criterion lives in one person's live judgment. So the mode works exactly when that judgment is an adequate acceptance test — and fails, predictably, when it is not.

Notice what Figure 22.1 does not say. It does not say the code is worse. It says the verification is bounded by one person's attention at one moment, and lists the four ways that bound is exceeded.

22.3 The security evidence

The fourth condition — silent failure — has the strongest evidence behind it, and it is recent.

Deng and colleagues built VibeApps, a corpus of 10,517 open-source vibe-coded applications, randomly sampled 200 deployed applications, and identified 1,471 vulnerabilities across them [B]. That is roughly seven per application, in software that was deployed.

Three recurring classes:

And now the part that should interest a reader of this book. The authors attribute these to systematic limitations of AI agents across the vibe-coding lifecycle, and name three root causes:

Memory loss. Chapter 5's third failed assumption — the author has no interrogable intent — and Chapter 7's finding that no repository in a 2,853-repository study used the persistent memory feature available to it [A].

Locally optimised objectives. Chapter 4's cost gradient, precisely: the agent optimises within the scope it was given, and the cheapest correct action is the locally-scoped one. That chapter derived duplication from this mechanism; here it produces placeholder logic, which is the same locality applied to completeness.

Insufficient security knowledge. Chapter 11's argument that belief-based controls fail — you cannot instruct your way to security, and an agent's security knowledge is a belief-shaped asset.

Three root causes, arrived at independently by security researchers analysing 10,517 applications, and each is a mechanism this book derived from different evidence in different chapters. That convergence is worth more than any single figure in it.

Their conclusion is the one to carry forward: advances in model capability and improved prompting reduce the incidence of these vulnerabilities but do not eliminate the underlying risks. This is Chapter 9's distinction restated — some deficits are capability deficits that training closes, and some are structural, and no model improvement closes a structural one.

The general phenomenon underneath is worth naming, because it is what makes the fourth condition of Figure 22.1 bite: silent failure — code that compiles perfectly and executes flawed logic. It is exactly what judgment-by-looking cannot catch, because there is nothing to look at. (The construction-safety study often cited for this framing remains 🔴 unverified in this book's ledger and is not relied upon here; the VibeApps evidence carries the point on its own.)

22.4 Spec-driven development, placed

The alternative discipline takes the opposite approach: write the specification first, make it precise enough to be checkable, and let generation proceed against it.

Farrag's specification-driven governance ladder, introduced in Chapter 12 §12.11, gives the escalation: post-hoc review → natural-language specification → executable contract → constitutional governance [B]. Chapter 8's held-out acceptance set is a point on that ladder. Chapter 12 made Intent a phase with an artefact rather than an assumed precondition, which is spec-driven thinking absorbed into the lifecycle.

So this book already contains a substantial amount of spec-driven development. What it has not done, until now, is answer the question of when specification should be the primary investment rather than one guide among several — and Chapter 3 left that question open in a form that threatens the book's argument.

22.5 Chapter 3's open question

Chapter 3 plotted the realism gradient and then raised an objection to its own reading:

Is the gradient a gradient of task realism or of specification completeness? Every high-scoring study supplied a clear specification; METR's real tasks did not. If it is the latter, the remedy is specification discipline rather than harness scope, and Chapter 22 has to take that possibility seriously.

Take it seriously. In that dataset the two variables are almost perfectly confounded: toy tasks arrive fully specified, real tasks arrive under-specified. So the gradient is consistent with both readings.

There is one datum that partially separates them, and it favours the specification hypothesis more than I expected.

The Google trial put 96 engineers on a realistic enterprise task — build a logging service on Google's internal infrastructure, editing 10 files and 474 lines — that was nonetheless clearly specified. Result: 21% faster, though losing statistical significance under controls [A]. METR's tasks were realistic and under-specified: 19% longer [A].

Realistic-and-specified came out positive. Realistic-and-unspecified came out negative. The confounds are real — Google engineers on Google infrastructure versus open-source maintainers with five years in their own repositories, and a 96-minute task versus multi-hour ones — so this is suggestive rather than decisive. But it is enough that the specification hypothesis cannot be waved away.

Here is the resolution, and it dissolves the opposition rather than picking a winner.

Chapter 8 established the Ashby constraint: a regulator can only govern variety it has a model of, an unconstrained generator has unbounded variety, so variety reduction is forced. What that chapter did not say is that there are two places to reduce it.

So the answer to Chapter 3's open question: it is both, and they are not rivals. Under-specification and structural illegibility are the same failure — too much variety reaching the generator — differing only in where you would intervene.

And the choice between interventions is economic, not philosophical. A team doing a hundred similar changes a month should build the harness, because the fixed cost amortises. A team doing three novel high-stakes changes a quarter should specify, because there is no volume to amortise against. Most organisations need both, in a ratio set by their task distribution rather than by their methodology preference.

This also explains a persistent disagreement in the field. Spec-driven advocates and harness advocates are usually both right, about different task distributions, and neither says which distribution they are describing.

22.6 Three modes

Now place them on the two-dimensional space Chapter 12 §12.11 established, where the axes are specification strength and agent authority:

22.7 Mode confusion, and the heuristic

The failure named in Chapter 21 as Prompt-and-Pray is not vibe coding. It is vibe coding's operating point applied where Figure 22.1's conditions have been violated — the upper-left region of Figure 22.3.

And the crucial property, which Chapter 23 develops: nobody moves there deliberately. The artefact moves. A weekend prototype acquires a user. A script someone wrote to check something acquires a maintainer. A demo acquires a credential. The mode was correct when chosen and became incorrect without any decision being made.

The selection heuristic, which is the practical output of this chapter:

Note that none of the three inputs is a judgement about quality. That is deliberate. Quality assessment is exactly the faculty Chapter 18 showed is decoupled from performance and Chapter 19 showed is degrading. The heuristic uses inputs you can know without trusting your own assessment of the artefact.

22.8 What ADLC must preserve

A lifecycle that eliminates vibe coding would be a mistake, and not only on grounds of fairness. Three arguments, in ascending order of strength.

Flow is real and it is in the research. Pimenova et al. name it in their title and capture it in their theory [B]. Chapter 17 §17.6 listed craft satisfaction as the cost of the author-to-director shift, and noted it was the only cost on that table with no measurement attached. Whatever the size of the effect, a discipline that treats enjoyment of the work as free to spend is making an assumption it has not tested.

A process that kills flow will be routed around. This is the same argument Chapter 21 made about anti-patterns: the remedy for a rational behaviour is never exhortation. If your lifecycle makes the good path miserable and the bad path pleasant, people take the bad path, rationally, and your controls become something to evade. Flow preservation is therefore an engineering constraint on the lifecycle, not a concession to sentiment.

And exploratory building is the practice Chapter 19 said protects judgment. This is the strongest argument and it is not obvious. Chapter 19 §19.7 reported the ordering effect: forming your own answer before delegating preserved recall and prefrontal activation, while the reverse ordering produced shallow encoding [B]. Vibe coding — building something exploratory, yourself, with a partner, against a standard in your own head — is attempt-first at the scale of a whole artefact.

Which means the prototype phase is not merely commercially useful. In an environment where Chapter 19 showed the work is becoming verification, and verification is the faculty whose feedback signal is decoupled, the exploratory mode may be where competence is still being built. An organisation that eliminates it in the name of rigour would be removing one of the few remaining places where engineers form their own answers before seeing someone else's.

That is a hypothesis rather than a finding, and I flag it as such. But it inverts the usual framing entirely: vibe coding is not the indulgence that a serious lifecycle tolerates. It may be a load-bearing part of how the people in that lifecycle stay able to run it.