# 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.

## This Chapter
- **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.

## Reader State
- **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

## Open Threads
- 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.