Spec Driven Development — Chapter 04 Memory: 1 - Fundamentals: where SDD comes from

Stage: Complete
Next Step: None (frozen). Next: Chapter 5 preview (PDF pages 33–42); build its Carried-in Context from this file.
Reading Span: PDF pages 23–32
Source Text: /library/Spec Driven Development/Chapter-04-Fundamentals-where-SDD-comes-from/Chapter-04-source-text.md (the chapter's own words; read instead of the PDF)
Full Record: /library/Spec Driven Development/Chapter-04-Fundamentals-where-SDD-comes-from/Chapter-04-chapter-notes.md (read only if needed)
Last Updated: 2026-10-01

Carried-in Context (from earlier chapters)

Ch1: Ködel offers his experience (ERP, Basel II, mobile, long-run product ownership) as credibility, not proof; reader trusts him, wants to see the method.
Ch2: With fast AI code generation, a specification is the target for judging output; humans judge, decide, answer. The 70/30 framing is illustrative, not measured; no evidence yet that SDD is generally effective.
Ch3: Three connected concerns: SDD = what/why (verifiable target), FOCUS Architecture = where (rules located, dependencies inward), Context Engineering = what the agent sees (selection, cost). Promise: each volume stands alone — cross-references should explain the idea in place (reader agrees). Check this as references appear.

Core Question: How does Ködel place SDD in the history of software methods, and what does he think AI changes about the cost of revising a plan?
Core Thesis: Ködel frames SDD as a way to keep the direction supplied by a specification while revising it through short feedback cycles, arguing AI makes code rewrites cheap enough to support that combination.
Key Concepts: Waterfall and direction; iteration and early feedback; living specification; specify → plan → tasks → implement; rewrite cost versus verification cost.
Notable Arguments / Evidence Limits: Waterfall/agile/Scrum/XP/Kanban history, house blueprint analogy. No project-level measurement shows the claimed drop in total change cost or SDD's superiority; test in practice.
Action Item: For one small change, update a short spec, make the change, run a relevant test, check the result against the spec, and note any gaps.

Pending Questions: None
Reader's Answers (paraphrase): Change is expected and the value is responding quickly; feedback shows what works, what doesn't, and what wasn't accounted for; AI reduces rewrite cost; specify = describe what you want before coding, plan = decide how, tasks = small steps, implement = fulfil them. Follow-up: test the changes and check they fulfil the spec.
Misconceptions / Feedback Given: All correct. Added: spec keeps direction as things change; feedback early enough to adjust; faster rewriting ≠ correctness — still need tests plus a check against intended behavior, including edge cases.
Personal Threads: None

Cross-book: how does this account connect to the maintenance and information-structure themes in FOCUS Architecture and Context Engineering?
Stand-alone check: did the chapter's reference to Context Engineering explain enough in place? (not yet answered)
Evidence for the “AI makes change cheap” claim remains asserted, not measured.