Kent Beck's Post

Kent Beck · article · 2026-10-08 source ↗ Reader 🖥️

Agile & XP Spec-Driven Development Test-Driven Development

The common framing of Spec-Driven Development — write the complete specification, then implement — rests on a false assumption that implementation teaches you nothing that should change the spec, whereas TDD's tight test/code/fail/pass loop is structured around the opposite assumption: that you will learn continuously and must feed that learning back immediately.

theoretical · argumentative — A short LinkedIn post (67 words plus a two-panel diagram) that surfaces and rejects a single hidden assumption behind Spec-Driven Development, contrasting it visually with TDD's interleaved loop.

Structure

Part	Role
Characterization of Spec-Driven Development's typical framing (write the whole spec first, implementation is separate)	setup — states the position being critiqued
Naming the hidden assumption explicitly ('you aren't going to learn anything during implementation that would change the specification') and calling it bizarre	critique — surfaces an implicit premise and rejects it
Appeal to a recurring folk belief ('if only we could get the specification "right"')	evidence — names the pattern as a repeated, well-meaning but mistaken belief he's heard many times
Two-panel diagram contrasting SDD's loop (test, test, test, code, fail, code, fail, code, pass) with TDD's loop (test, code, (fail), pass, test, code, (fail), pass)	evidence — visual argument

Key terms

Spec-Driven Development Spec-Driven Development
As Beck characterizes it here: a workflow where the complete specification is written before any implementation begins, on the assumption that implementation will not generate information that should feed back into the spec.

Propositions

explicitThe common description of Spec-Driven Development assumes that implementation produces no learning that should change the specification.conf: high
supportsWhen AI Writes the Code, Specifications Need an Exit Strategy · p7 — Beck's one-line critique (SDD wrongly assumes no learning during implementation) converges with this article's more developed claim that discovery continues throughout implementation and a specification should remain part of an ongoing loop rather than fixed before work begins.
supportsWhen AI Writes the Code, Specifications Need an Exit Strategy · p6 — Both identify exhaustive upfront specification as the specific failure mode — Beck calls the underlying assumption 'bizarre'; the article independently documents that this 'waterfall' pattern recurs and raises review burden rather than lowering it.
explicitThis no-learning-during-implementation assumption is false and should strike a practitioner as bizarre.conf: high
explicitThe belief that getting the specification 'right' up front would make everything else easy is a widespread, recurring folk theory among well-meaning practitioners, not a one-off claim.conf: high
implicitTDD's test/code/fail/pass loop is structurally designed to interleave learning and specification continuously (each red-green cycle updates the 'spec' — the tests — as understanding grows), in contrast to SDD's batch sequence of writing many tests/specs before any code.conf: medium

Arguments

Spec-Driven Development, as commonly described, rests on a mistaken premise and should be viewed with suspicion. strength: medium

Explicit premises:

SDD-as-described requires writing the whole spec before implementation.
Writing the whole spec first only makes sense if implementation won't surface spec-changing information.

Implicit premises:

In real software work, implementation routinely surfaces information that should change the specification (a premise Beck treats as self-evident and doesn't argue for in this short post).
TDD's interleaved loop is the structurally correct response to that fact, making it an implicit positive counter-example to SDD.

Inferences:

If implementation reliably generates spec-changing information, then any process that finalizes the spec before implementation is structurally unable to incorporate that information without rework or waste.

Questions addressed

✅ Does the standard description of Spec-Driven Development hold up under its own assumptions?
No — it depends on an assumption (no learning during implementation) that Beck considers obviously false.

Gaps

incompleteBeck asserts that implementation teaches you things that should change the spec, and treats this as self-evidently true without any example, data, or anecdote in this post — unusual for his style elsewhere, where personal anecdotes typically carry the argumentative weight. The post also doesn't address the version of Spec-Driven Development that the corpus has already documented as explicitly built around iterative discovery (extract-when-ai-writes-the-code-specifications-need-an-exit-strategy's 'change brief' as part of an ongoing loop) — so it's unclear whether Beck is critiquing SDD as such or only a naive/batch variant of it that more careful SDD proponents have already moved past.
Read next: extract-when-ai-writes-the-code-specifications-need-an-exit-strategy#p6 and #p7 make almost exactly Beck's point with evidence and detail (exhaustive upfront spec recurs and is 'engineering-useless'; discovery continues throughout implementation and the spec should remain part of an ongoing loop) — worth reading together to see whether Beck's one-liner and that article's longer argument are the same claim or whether Beck is attacking a strawman the more sophisticated SDD literature has already addressed.