Book-Reader-Assist/library/Spec Driven Development/Chapter-04-Fundamentals-where-SDD-comes-from/Chapter-04-chapter-notes.md

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

• Date Created: 2026-10-01
• Status: Complete
• Reading Span: PDF pages 23–32

---

1. Pre-Reading Briefing

• 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?
• Key Points to Watch For:
  • Track the problem he attributes to waterfall and how he distinguishes thinking ahead from committing to an unchangeable plan.
  • Identify what iteration and feedback contribute in his account of agile, Scrum, XP, and Kanban.
  • Notice which costs he says AI reduces, and ask what evidence would show that this holds for real projects.
  • Look for the four recurring workflow terms—specify, plan, tasks, implement—and how he differentiates them.
  • Check whether his reference to Context Engineering explains enough here to keep this volume readable on its own.
• Context & Thread from Prior Chapters: Chapter 2 introduced a specification as a target for judging AI-generated work. Chapter 3 placed that target before code organization and selecting information for an AI call. As you read, watch how Ködel connects that target to older approaches and to repeated changes during a project.

---

2. Reading Review & Reflections

• Prompt Questions: The reader responded to the four briefing themes: change and planning; iteration and feedback; AI's effect on cost; and the four workflow stages.
• User Key Takeaways:
  1. “chnage is expected and the value is responding to it quickly”
  2. “It helps to see what works and what doesnt and what hasnt been accounted for”
  3. “the cost of rewriting”
  4. “specify is describing what you want before coding, planning is deciding how it will be built , tasks are the plan broken up into small steps , implement is the fullfilment of the preceding steps”
• Scaffolding & Feedback: The reader correctly identified the chapter's emphasis on responding to change, the role of feedback in exposing missed behavior, the cost of rewriting code, and the four stages of the proposed cycle. A specification still provides direction as the project changes; feedback should arrive early enough to adjust before a mistake spreads. Ködel claims AI makes rewriting code cheaper, but the chapter does not establish that every kind of change becomes cheap or that the overall method is more effective across projects. Follow-up prompt: Suppose AI rewrites a feature quickly after its specification changes. What work would still be needed before you could trust the revised feature?
• Follow-Up Response: “test the changes . also see if it fullfills what you put in the spec”
• Follow-Up Feedback: Correct. The generated change still needs tests and a check against the specification's intended behavior, including relevant edge cases. Faster rewriting does not itself establish correctness.

---

3. Chapter Synthesis

• 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 that AI makes code rewrites cheap enough to support that combination.
• Key Concepts / Mental Models:
  • Waterfall and direction: Define intended behavior before building; the problem Ködel highlights is the cost of changing a large, fixed plan late.
  • Iteration and early feedback: Build and evaluate in small cycles so missed requirements and errors surface while they are easier to correct.
  • Living specification: Keep the written target current as understanding changes, then use it to guide and assess the next implementation.
  • Specify → plan → tasks → implement: State what and what counts as correct; choose an approach; break it into executable steps; build and check the result.
  • Rewrite cost versus verification cost: AI may speed code production, but revised behavior still has to be tested and compared with the specification.
• Notable Arguments & Evidence: Ködel traces lessons from waterfall, agile, Scrum, XP, and Kanban, using the house blueprint analogy and historical examples to argue for direction, adaptation, and early feedback. He claims AI sharply reduces the cost of rewriting code and lets the specification become a reusable project record. The chapter does not provide project-level measurements showing how much total change cost falls or that SDD outperforms alternatives; those claims should be tested in practice.
• Updates to Prior Understanding: Chapter 2 introduced the specification as a target for evaluating AI output. Chapter 4 makes it a document to revise during short cycles, preserving the Chapter 3 distinction between what is intended, where code belongs, and what context reaches the agent.
• Weekly Action Item: For one small change, update the intended behavior in a short spec, make the change, run a relevant test, and check the result against the spec. Note anything the test or spec missed.