Book-Reader-Assist/library/Spec Driven Development/Chapter-02-Why-SDD-is-essential-in-the-age-of-AI/Chapter-02-chapter-notes.md

Spec Driven Development — Chapter 02: 0 - Why SDD is essential in the age of AI

• Date Created: 2026-10-01
• Status: Complete
• Reading Span: PDF pages 13–19

---

1. Pre-Reading Briefing

• Core Question: When AI can produce code quickly, which decisions and checks still depend on the person building the software?
• Key Points to Watch For:
  • Notice how Ködel defines the problem he calls “vibe-coding” and the alternative he proposes.
  • Identify the distinct human responsibilities he says remain when AI writes code.
  • Examine his “70% and 30%” framing: what does it illustrate, and is it presented as measured data?
  • Track what he claims a written specification changes about prompting, evaluation, and maintenance.
  • Watch how he positions this approach relative to older software methods.
• Context & Thread from Prior Chapters: The author introduction established Ködel's experience and interest in maintaining systems. Now test the method's own reasoning rather than relying on the author's résumé. Keep the Context Engineering question in view: what information must be available for a useful AI result?

---

2. Reading Review & Reflections

• Prompt Questions:
  1. In your words, what does Ködel mean by “vibe-coding,” and what does he propose doing before asking AI to write code?
  2. What three responsibilities does Ködel say remain with the person building the software? Give one concrete example of where one of them would matter.
  3. What is his “70% and 30%” framing meant to show? How convincing is the support he gives for it?
• User Key Takeaways:
  1. “prompting an agent to build something with no direction. figure out what you want before you ask ai to code it”
  2. “judge,decide,answer , SOmeone has to judge what the COmputer Produced there are edge cases that need to be looked at”
  3. “AI is good at 70% of the task. the 30% is where the value is , its what AI misses and you shuold be abel to tell if it has”
• Scaffolding & Feedback: The reader correctly identified vague direction as the problem, and named the three responsibilities: judge, decide, and answer. The edge-case example fits Ködel's warning that plausible code can miss behavior that matters. The next step is to make the intended behavior explicit in a specification, including rules and what counts as correct, so there is a basis for judging output. “Decide” includes product trade-offs before implementation; “answer” means taking responsibility for the deployed result. The reader captured the point of the 70/30 framing, but the chapter offers those percentages as an illustration, not measured task shares. Its examples make the risk plausible; they do not establish an exact rate or prove that SDD improves outcomes across projects.

---

3. Chapter Synthesis

• Core Thesis: As AI makes code generation fast, Ködel argues that a clear specification becomes more valuable because people must decide what to build, judge the result, and remain accountable for it.
• Key Concepts / Mental Models:
  • Vibe-coding: Giving AI loose requests and accepting plausible output without a clear target; it can hide missing behavior and force repeated prompting.
  • Specification as a reference: A written statement of the problem, rules, and success criteria before code; use it to guide work and evaluate the result.
  • Judge, decide, answer: Check behavior against intent, choose product trade-offs, and own the outcome when software runs in the real world.
  • The “70% and 30%” framing: A heuristic about routine generated work versus project-specific judgment; treat the numbers as illustrative, not empirical.
• Notable Arguments & Evidence: Ködel uses hypothetical examples involving permission flaws, offline behavior, scale, and missed product-specific statuses. He argues that unclear prompts increase rework and a growing chat history can obscure the intended target. The chapter provides reasoning and examples, but no measured comparison establishing the 70/30 split or SDD's general effectiveness.
• Updates to Prior Understanding: Extends Chapter 1's maintenance concern into a proposed practice: record intended behavior before generating code. It connects to Context Engineering by treating the information supplied to an AI as part of the quality of its output.
• Weekly Action Item: Before building one small feature this week, write a five-line mini-spec: problem, intended user outcome, one rule, one edge case, and a check that would show it works.