In Lesson 1, you learned that SDD exists because vibe coding fails at scale. The question becomes: what do you do instead?
The answer is a structured workflow that treats Claude not as a solo coder who figures everything out through conversation, but as a development team you orchestrate. You provide direction. Multiple agents investigate. A comprehensive specification emerges. Implementation follows the spec, not the other way around.
This lesson introduces the four-phase workflow that makes SDD work. By the end, you'll understand why this sequence matters and how it prevents the mid-implementation pivots that derail vibe coding projects.
Before diving into the phases, note that Phase 1 research and all subsequent phases operate within the governance boundaries established by your project constitution (Lesson 3). The constitution defines how you build; the phases define what you do.
Here's the complete workflow at a glance:
Each phase has a clear deliverable. Each transition is a checkpoint where you can review, adjust, or stop. Unlike vibe coding—where you're constantly course-correcting during implementation—SDD front-loads the thinking so implementation becomes execution of a well-understood plan.
Deliverable: Written summaries of findings from multiple investigation threads
What happens: You ask Claude to investigate your problem from multiple angles. Instead of a single conversation exploring everything sequentially, Claude spawns multiple independent subagents. Each subagent investigates a specific aspect:
Why parallel matters: Each subagent operates with fresh context. They don't pollute each other's thinking. Research that would take hours sequentially becomes minutes in parallel. Different agents may discover conflicting approaches—that's valuable information for your specification.
Deliverable: A comprehensive markdown document (spec.md)
What happens: Research findings converge into a written specification. This isn't a to-do list or rough notes. It's a complete description of:
Why written matters: The specification becomes your source of truth. When Claude's session ends, the conversation disappears. When you start a new session tomorrow, your spec.md persists. Every decision captured in the spec survives session restarts.
Deliverable: An updated specification with ambiguities resolved
What happens: Before implementation, Claude interviews you using AskUserQuestion patterns. The goal is to surface every design decision that would otherwise become a mid-implementation pivot:
Why interview matters: Every ambiguity found now saves correction time during implementation. The spec becomes more precise. You maintain architectural control instead of discovering surprises in generated code.
Deliverable: Working code committed in atomic chunks
What happens: With a refined specification, Claude extracts tasks and delegates each to a fresh subagent. Each subagent:
The main agent orchestrates, tracking progress and handling blockers. If a task fails, only that subagent's context is affected—the overall project state is preserved in git commits.
Why delegation matters: Context isolation prevents accumulated errors. Atomic commits enable rollback. The spec serves as the contract that keeps every subagent aligned.
The sequence isn't arbitrary. Each phase depends on what comes before:
What happens if you skip phases:
Traditional AI coding blurs planning and execution. You prompt, see code, adjust, prompt again—planning and execution interleaved in a single conversation.
SDD separates them completely:
Review at phase gates, not during coding. After research, you review findings. After specification, you review the plan. After refinement, you confirm decisions. During implementation, Claude executes the agreed plan—you don't need to approve every file edit because the spec already captured your intent.
When you start a new Claude Code session, your conversation history is gone. But your specification remains:
Tomorrow's Claude can read today's spec and understand:
The specification captures accumulated decisions. Without it, every new session starts from scratch—you're explaining the same context repeatedly instead of building on documented decisions.
Consider what happens when you invest one hour in each approach:
One hour of vibe coding:
One hour of SDD:
The one-hour outcomes look different. Vibe coding produces code faster initially. SDD produces more durable artifacts. For a quick script, vibe coding wins. For a system you'll maintain for months, SDD's documentation pays dividends.
Objective: Practice thinking in phases before you need to execute.
Think of a real task you need to accomplish with Claude Code—something you'd normally tackle through conversation. Map it to the four phases:
Phase 1 (Research): What would you want subagents to investigate?
Phase 2 (Specification): What sections would your spec need?
Phase 3 (Refinement): What questions might surface ambiguities?
Phase 4 (Implementation): How would you break this into tasks?
You don't need to execute this yet—Lessons 5-8 cover each phase in detail. The goal is to start thinking in phases rather than jumping straight to implementation.
Running Example: Throughout this chapter, you'll write "Personal AI Employees in 2026"—a research report for CTOs. This lesson maps that task to the four phases.
Prompt 1: Phase Mapping
What you're learning: Even a writing task benefits from SDD thinking. The research phase discovers what CTOs actually care about (not what you assume). The spec commits to structure before you write 2000 words in the wrong direction.
Prompt 2: Skip-Phase Analysis
What you're learning: Your knowledge is partial. Research might reveal: CTOs care about security compliance (you forgot), Cursor has enterprise features you didn't know, ROI calculations need specific metrics. Skipping research means writing for yourself, not your audience.
Prompt 3: Artifact Comparison
What you're learning: Vibe coding produces a draft that might not fit your audience. SDD produces: research.md (what CTOs need), report-spec.md (structure decisions), and sections written to spec. The artifacts persist; the conversation doesn't.