Sam Hatoum's Post
Sam Hatoum · article · 2026-04-20 source ↗ Reader 🖥️
Spec-driven development with AI is not waterfall because waterfall's fatal flaw was slow feedback, not specifications themselves, and AI collapses the feedback loop from months to minutes — making specs more essential, not less.
practical · argumentative — A short LinkedIn post rebutting two common objections to spec-driven development with AI. Primarily argumentative — identifies the objections, diagnoses their shared error, and makes a case for spec-first workflows under new AI-driven feedback dynamics.
Structure
| Part | Role |
|---|---|
| Two common objections stated | Sets up the straw-man positions the post will dismantle |
| Diagnosis: waterfall's real problem was feedback speed | Reframes the debate — the problem was never specs, it was the cost-of-being-wrong accumulation over long cycles |
| AI inverts the math | Shows that AI implementation collapses the spec-to-verification loop to minutes, removing the condition that made waterfall brittle |
| Historical precedent: TDD/BDD were spec-first | Anchors the argument in accepted practice — spec-first is not controversial when the loop is tight |
| Thought experiment: instant coding | Extrapolates to the limit case — if implementation cost is zero, 100% of effort is design/spec work |
| Small batches still matter — the constraint has moved | Qualifies the argument — the discipline of small increments remains, but the bottleneck shifts from implementation speed to verification capacity |
| Closing: the cost of not writing specs | Flips the question — the alternative to specs is trusting an amnesiac AI with all decisions |
Key terms
- spec-driven development Spec-Driven Development
A workflow where human-authored specifications are the primary artifact, and AI handles implementation and test verification against those specs in a rapid feedback loop - feedback speed / feedback loop Feedback Loops
The elapsed time between expressing intent (writing a spec) and learning whether the resulting implementation is correct - amnesiac AI Spec-Driven Development
An AI system that does not retain decisions, context, or rationale across sessions — so without specs, accumulated design intent is lost
Propositions
- explicitWaterfall's fundamental problem was slow feedback, not the use of specifications.conf: high
- explicitBig upfront design fails for the same reason as waterfall: the loop between intention and reality is too long to allow timely correction.conf: high
- explicit⚡ disputed & corroboratedSpec-driven development with AI collapses the feedback loop from months to minutes.conf: highsupports ←Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p4 — Both describe agentic tooling collapsing the spec-to-discovery feedback loop from months/weeks to minutes.contradicts ←It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p2 — Hatoum claims the fast spec-to-implementation loop is the win; Pocock claims that same loop produces progressively worse code each iteration due to software entropy.
- explicitTDD, BDD, and acceptance criteria are spec-first practices that are accepted as agile because their feedback loops are tight.conf: high
- explicitdevelopedIf implementation became truly instant, 100% of human effort would go to specification/design.conf: mediumextendsPresentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p6 — Generalizes the empirical 10:1 spec-to-code effort ratio to its limiting case: with instant implementation, 100% of human effort goes to specification and design.extends ←Spec-Driven Production Grade Development In The Age Of Vibe Coding · p3 — Boonstra's 'code is disposable once the spec is rock-solid' is the present-tense, practice-level version of Hatoum's limiting-case thought experiment that if implementation became truly instant, all human effort would go to specification.
- explicitcorroboratedThe constraint on batch size has moved from implementation speed to verification capacity — how much spec you can meaningfully verify, review, and correct in one cycle.conf: highsupports ←Article: When Spec-Driven Development Pays Off · p1 — Hatoum asserts the constraint moved from implementation speed to verification capacity; this proposition states the same shift in different vocabulary (writing to verification).refines ←Article: When Spec-Driven Development Pays Off · p2 — Hatoum names 'verification capacity' as the new constraint in the abstract; this study operationalizes and measures it directly, and the measurement narrows what that capacity actually consists of — attribution/accountability capacity, not raw bug-finding capacity, since recall itself did not move.extends ←A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale · p9 — Both claim the binding constraint has shifted from generation/implementation speed to verification capacity -- Hatoum's post makes the claim for AI-assisted coding; this document applies the identical structural claim to AI-assisted technical documentation.
- explicitWithout explicit specs, you are trusting an AI that cannot retain decisions across sessions to hold your entire design intent.conf: high
- implicitWhether a development practice is 'waterfall' or 'agile' is determined by feedback-loop speed, not by whether specifications exist.conf: high
- implicitestablishedSpecs serve as durable external memory for design intent — a function that becomes more critical when the implementer (AI) has no persistent memory.conf: highsupports ←Spec-Driven Production Grade Development In The Age Of Vibe Coding · p4 — Boonstra's 'spec as Architectural North Star preventing context fragmentation' is the practical restatement of Hatoum's claim that specs function as durable external memory for design intent precisely because the implementer (the agent) has no persistent memory of its own.extends ←Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p6 — Agrees specs serve as durable external memory for design intent, and extends the claim by pairing spec-anchored SDD with TDD and fitness functions so behavior and structural conformance are persisted alongside intent, not just intent alone.supports ←A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale · p4 — Both treat specs as durable external memory/ground truth that constrains an AI implementer/drafter lacking persistent memory of design intent.
- implicitcontestedAI implementation quality is good enough that the spec-implement-verify cycle can run in minutes without human coding intervention.conf: mediumcontradicts ←[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p5 — Pocock insists the code is the developer's battleground and specs-to-code does not work, directly denying Hatoum's claim that the spec-implement-verify cycle can run without human coding intervention.
Arguments
Spec-driven development with AI is not waterfall.
Explicit premises:
- Waterfall's problem was feedback speed, not specifications (P1)
- AI collapses the feedback loop to minutes (P3)
- TDD/BDD were spec-first yet accepted as agile because of tight feedback (P4)
Implicit premises:
- The defining characteristic of waterfall is slow feedback, not the presence of upfront design artifacts (P8)
- AI implementation is reliable enough that the rapid loop actually works (P10)
Inferences:
- I
- f
- w
- a
- t
- e
- r
- f
- a
- l
- l
- =
- s
- l
- o
- w
- f
- e
- e
- d
- b
- a
- c
- k
- ,
- a
- n
- d
- A
- I
- e
- l
- i
- m
- i
- n
- a
- t
- e
- s
- s
- l
- o
- w
- f
- e
- e
- d
- b
- a
- c
- k
- f
- r
- o
- m
- s
- p
- e
- c
- -
- d
- r
- i
- v
- e
- n
- w
- o
- r
- k
- ,
- t
- h
- e
- n
- s
- p
- e
- c
- -
- d
- r
- i
- v
- e
- n
- d
- e
- v
- e
- l
- o
- p
- m
- e
- n
- t
- w
- i
- t
- h
- A
- I
- ≠
- w
- a
- t
- e
- r
- f
- a
- l
- l
- .
- T
- h
- e
- T
- D
- D
- /
- B
- D
- D
- a
- n
- a
- l
- o
- g
- y
- r
- e
- i
- n
- f
- o
- r
- c
- e
- s
- t
- h
- i
- s
- b
- y
- s
- h
- o
- w
- i
- n
- g
- a
- c
- c
- e
- p
- t
- e
- d
- s
- p
- e
- c
- -
- f
- i
- r
- s
- t
- p
- r
- a
- c
- t
- i
- c
- e
- s
- t
- h
- a
- t
- n
- o
- o
- n
- e
- c
- a
- l
- l
- s
- w
- a
- t
- e
- r
- f
- a
- l
- l
- .
Writing specs is not optional — it is more necessary than ever when working with AI.
Explicit premises:
- The alternative to specs is trusting an amnesiac AI with all design decisions (P7)
- If implementation were instant, 100% of effort would be design/spec work (P5)
Implicit premises:
- Specs serve as durable external memory for design intent (P9)
- AI cannot currently maintain persistent memory of design rationale across sessions
Inferences:
- A
- s
- A
- I
- t
- a
- k
- e
- s
- o
- v
- e
- r
- i
- m
- p
- l
- e
- m
- e
- n
- t
- a
- t
- i
- o
- n
- ,
- t
- h
- e
- s
- p
- e
- c
- b
- e
- c
- o
- m
- e
- s
- t
- h
- e
- s
- o
- l
- e
- c
- a
- r
- r
- i
- e
- r
- o
- f
- d
- e
- s
- i
- g
- n
- i
- n
- t
- e
- n
- t
- .
- W
- i
- t
- h
- o
- u
- t
- i
- t
- ,
- d
- e
- c
- i
- s
- i
- o
- n
- s
- a
- r
- e
- l
- o
- s
- t
- b
- e
- t
- w
- e
- e
- n
- s
- e
- s
- s
- i
- o
- n
- s
- .
- T
- h
- e
- r
- e
- f
- o
- r
- e
- s
- p
- e
- c
- s
- b
- e
- c
- o
- m
- e
- m
- o
- r
- e
- —
- n
- o
- t
- l
- e
- s
- s
- —
- i
- m
- p
- o
- r
- t
- a
- n
- t
- .
Small-batch discipline remains important even with AI, but for a different reason.
Explicit premises:
- Piling a hundred behaviors into one spec loses signal (P6)
- The constraint has moved from implementation speed to verification capacity
Implicit premises:
- Human cognitive capacity for reviewing and verifying correctness is limited
- The value of a feedback loop depends on the human's ability to evaluate the output
Inferences:
- E
- v
- e
- n
- t
- h
- o
- u
- g
- h
- A
- I
- c
- a
- n
- i
- m
- p
- l
- e
- m
- e
- n
- t
- l
- a
- r
- g
- e
- s
- p
- e
- c
- s
- q
- u
- i
- c
- k
- l
- y
- ,
- t
- h
- e
- h
- u
- m
- a
- n
- b
- o
- t
- t
- l
- e
- n
- e
- c
- k
- i
- n
- r
- e
- v
- i
- e
- w
- a
- n
- d
- v
- e
- r
- i
- f
- i
- c
- a
- t
- i
- o
- n
- m
- e
- a
- n
- s
- s
- m
- a
- l
- l
- b
- a
- t
- c
- h
- e
- s
- a
- r
- e
- s
- t
- i
- l
- l
- r
- e
- q
- u
- i
- r
- e
- d
- f
- o
- r
- e
- f
- f
- e
- c
- t
- i
- v
- e
- f
- e
- e
- d
- b
- a
- c
- k
- .
Narratives
→ Reductio ad absurdum to show that as implementation cost approaches zero, spec work is all that remains — and calling that 'waterfall' would be absurd.
Questions addressed
- ⭕ Is spec-driven development with AI just a return to waterfall?
- ⭕ Does big upfront design work when AI does the implementation?
- ⭕ Why should developers write specs when AI can just generate code?
Gaps
- incompleteThe post assumes AI implementation is reliable enough to close the loop in minutes but provides no evidence for this. Real-world AI coding involves debugging, hallucination, and rework cycles that could lengthen feedback well beyond minutes.closed byArticle: When Spec-Driven Development Pays Off — Hatoum's post assumes AI implementation is reliable enough to close the spec-implement-verify loop in minutes but offers no evidence; this article's generation-side data bears on that assumption in the negative direction for hard tasks — a staged spec-then-generate approach reached only 45% pass on a 20-invariant banking task even for the winning arm, with the other arms lower still, though gains were much larger and near-ceiling on single-function tasks. It qualifies rather than confirms Hatoum's optimism, and does not directly measure debugging/rework cycle counts.
- incompleteNo discussion of what a 'spec' actually looks like in this workflow — the granularity, formalism, and format of specs are left entirely unspecified. The practical difficulty of writing good specs is not addressed.closed byArticle: When Spec-Driven Development Pays Off — Hatoum's piece leaves the granularity, formalism, and format of a 'spec' entirely unspecified; this article supplies a concrete three-layer format (specification, HLD, LLD) with a worked banking example and a twenty-invariant baseline, directly filling that gap for one domain — though it is offered as one worked example, not a universal template.
- incompleteThe 'amnesiac AI' framing assumes no progress on persistent AI memory (RAG, project context, long-term memory). If AI memory improves, the strongest argument for specs (external memory) weakens — though the argument from verifiability would remain.
- illogicalThe thought experiment ('if coding became instant') proves too much — it assumes zero implementation cost, but actual AI implementation is not zero-cost. The gap between 'minutes' and 'instant' may matter more than the post acknowledges.
Related documents
- Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices
- Addy Osmani's Post
- Agentic AI and Code Reviews
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- Harness engineering for coding agent users
- The AI-Native SDLC playbook
- Why AI Coding Agents Still Need Clear Specs
- Fragments: February 18
- Patterns for Reducing Friction in AI-Assisted Development
- How to Build a Superteam That Keeps Getting Better