video youtu.be Watch ↗

Spec-Driven Development: AI-Assisted Coding Explained (IBM Technology)

TL;DR

A ~9-minute IBM Technology glassboard explainer that defines spec-driven development (SDD) by contrasting it with vibe coding. Vibe coding starts from an initial natural-language prompt to a coding agent, which generates code from what it infers you want; you eyeball the result, edit the prompt, and loop until it looks right — fast and great for prototyping, but nondeterministic (the same underspecified request has "30 different ways" to be implemented, so "a hundred tries" yield a different result each time) and it skips the software development lifecycle (SDLC) entirely. SDD re-imports that lifecycle: you prompt the behavior and constraints you want, not an implementation; the spec is treated "like a contract" that generates requirements, which — once you approve them — become a design document with per-feature to-dos, which — once you approve that — the agent implements as code and tests. The load-bearing move is inverting the artifact order: where traditional dev goes code→docs and TDD goes test→code, SDD goes spec→design→implement→code ("TDD and BDD on steroids"), making the spec the primary artifact that drives all downstream work — implementation, tests, documentation, verification. The payoff the video sells is less ambiguity for the coding agent and auditability: because nothing is implemented until the spec is approved, "we know when the implementation starts why it got to this conclusion." This is an introductory, whiteboard-level treatment — it corroborates the vault's existing Spec-Driven Development concept from a fresh, mainstream source and names its foil, but adds no new mechanism for the hard part (keeping spec, tests, and code in sync as they drift).

Concepts introduced

Vibe Coding — new page. The prompt→generate→inspect→edit-prompt loop with a coding agent and no durable spec; SDD's foil. Fast and good for prototyping, nondeterministic and unauditable for anything you must maintain.
Spec-Driven Development — corroborated, not duplicated. A third independent, mainstream source restating the core: prompt behavior/constraints not implementation; make the spec the primary artifact that drives implementation, tests, and docs.

Held, not dropped

Themes the video touches that don't warrant their own page yet (spin out on demand):

The SDLC / software delivery lifecycle (plan→design→implement→test→QA→deploy→maintain) — used here only as the classic frame that vibe coding skips and SDD re-imports. Generic prior-art background, not an LLMOps-specific concept; held rather than paged.
The staged approval workflow (requirements → design doc with to-dos → implement, with a human approve/edit gate before each stage) — this is the Kiro-style spec workflow. Already covered by Agent Supervision (human gate) and Spec-Driven Development's "audited, ask-first build contract"; recorded there as a corroborating source rather than a new node.
Provenance / auditability of implementation decisions ("we know why it got to this conclusion") — a motive for SDD, folded into the concept's claims below rather than paged.

Key claims

The hard part of building has shifted from writing/reviewing code to conveying intent to an LLM effectively — and doing that is spec-driven development. observation → the video's framing thesis for Spec-Driven Development; a claim about where the skill now lives, stated as the source's assertion.
Vibe coding is the prompt→generate→inspect→edit-prompt loop: you start from an initial NL prompt, the agent generates code from what it infers, and you iterate until it looks right — no durable spec. observation → definitional, for Vibe Coding.
An underspecified request is underdetermined — many valid implementations exist, so the output is nondeterministic ("30 different ways," "100 tries → a different result each time") and the chosen decision goes unrecorded. principle → the durable reason a spec helps: ambiguity in, variance out. Motivates both Vibe Coding's weakness and Spec-Driven Development's fix.
Vibe coding is best for prototyping, testing, and quick edits on the fly; iterating by re-prompting can cost more than writing the code yourself. best practice — context: throwaway/exploratory work where reproducibility and auditability don't matter; the low-ceremony end of Agentic Simplicity. Don't reach for it where you must maintain or audit the result.
SDD inverts the artifact order — traditional dev is code→docs, TDD is test→code, SDD is spec→design→implement→code — making the spec the primary artifact that drives implementation, tests, docs, and verification. best practice — context: AI-assisted builds where reducing agent ambiguity is worth the up-front planning; a second-independent-source restatement of Spec-Driven Development's "spec as source of truth" and Eval-Driven Development's measure-don't-vibe. ("TDD and BDD on steroids.")
Prompt the behavior and constraints you want, not a specific implementation; the spec is used "like a contract" to generate requirements. best practice — context: the whole SDD bet; contingent on the agent being able to turn a behavioral contract into a faithful implementation.
Gate each stage on human approval before any code exists — requirements, then a design doc with per-feature to-dos, then implementation — so you can approve or edit before committing. best practice — context: builds where a wrong silent decision is costly; the Agent Supervision human-gate folded into the plan step. IBM Technology is a third independent source converging on this staged-approval shape (cf. Buildable, Plumb in Spec-Driven Development).
SDD gives the coding agent less ambiguity and makes its decisions auditable — because nothing is implemented until the spec is approved, you know why the implementation turned out as it did. observation → the video's headline benefit claim for Spec-Driven Development.

Why this corroborates the existing graph

This is an introductory, mainstream-source explainer, so its value is corroboration, not new mechanism. The vault's Spec-Driven Development concept already holds the deep material — Drew Breunig's no-code whenwords, Plumb's drift-management, Buildable's audited ask-first contract, the plan-first "front-load 90% of attention" convergence. This IBM Technology video adds a third independent voice on the load-bearing claim (make the spec the primary artifact; prompt behavior not implementation; gate stages on approval before code) from outside the practitioner/creator niche — which is exactly the "N sources now agree" signal that raises confidence without duplicating the concept.

Its one genuinely novel contribution to this vault is naming and drawing the foil, Vibe Coding, as a first-class concept — previously only mentioned in passing in Agentic Simplicity and other distillates. The video does not engage SDD's hard part (the ongoing sync as spec/tests/code drift); it is an on-ramp, not an advance. Attributed as the source's framing throughout — the "the hard part has shifted" and "the primary artifact" claims are the video's assertions, offered to the reader, not adjudicated here.

Illustrated walkthrough

Format: IBM Technology "glassboard" — a presenter drawing labeled boxes and arrows on a dark transparent board while narrating. The board is drawn cumulatively; the moments below are the anchors.

t=00:18 — the thesis. Title "Spec Driven Dev." beside a browser window glyph (</>) and a little equation "🧍 + 🤖 = </>" (human + agent = code). Framing claim: what changed is that the hard part of building shifted from writing/reviewing code to effectively conveying what you want to an LLM — and doing that well is SDD.
t=00:36–02:00 — vibe coding, drawn as a loop. Start at the AI coding agent → write an initial prompt ("I want an app that does X in Java/Python") → model generates boilerplate from what it thinks you want → "not quite" → edit the prompt → back-and-forth until you hit a "desired state." Narrated caveat: you can't tell why the model made the decisions it did, and repeated runs diverge — "a hundred different tries… a different result every time."
t=03:14 — vibe coding skips the SDLC. A left-to-right pipeline of boxes — planning/design (PRD) → implement → test → QA → Deployment → Maintenance — labeled SDLC. The point: traditional software engineering runs this lifecycle; vibe coding jumps straight to generated code and skips it.
t=04:20 — "SPEC CODING" flow. Prompt Spec → Requirements → {design doc / implement / tests} with curved feedback arrows looping back (the approve-or-edit gates). Narration: the spec is used "like a contract" to create requirements; the requirements are the "main hierarchy" from which code, tests, docs, and verification all flow.
t=06:16 — the artifact-order inversion. Right side lists three lineages: TRAD → CODE → DOCS; TDD → TEST → CODE; SDD → spec → design → implement → code. Left side shows SDD's approval flow: …EDIT → design → ◆happy? → Implement / EDIT. SDD "turns it on its head" — spec first, code last; framed as "TDD and BDD on steroids."
t=08:22 — the concrete spec. A worked example under "SPEC CODING": Feature: User Auth with bullets - Endpoint: /login POST, - Accepts: {user, pass}, - Fails: 400 if missing user, - Tests: valid credentials → 200. The narrated contrast: the vibe version was just "give me a /login page," leaving 30 implementations open; the spec version pins the endpoint, inputs, failure code, and a test case first — so "we know why the implementation got to this conclusion."
close — the one-liner. The spec "becomes the primary artifact that drives all this downstream work like implementation and test and much more" — less ambiguity for coding agents.