A hands-on course

Write the spec.
Then write the code.

Spec-driven development makes the specification the source of truth: the thing you review, the thing your AI agent builds from, and the thing your tests prove. This course teaches you to write specs that are precise enough to build from and short enough to actually read.

$10one-time, lifetime access
9modules
3interactive labs
~90minutes
12question assessment
Module 01 · Foundations

Why specs first

You will be able to
  • Explain what spec-driven development (SDD) is and isn't
  • Recognise the failure modes it prevents
  • Decide when SDD is worth the overhead

Most software goes wrong before a line of code is written. A requirement was ambiguous, an edge case was never discussed, or two people held different pictures of "done". Code then becomes the place where those decisions get made: implicitly, inconsistently, and invisibly.

Spec-driven development moves those decisions earlier and makes them explicit. You write a short, structured specification of what the system must do and how you'll know it does it. Design, tasks, code and tests all derive from that spec and trace back to it.

Code-first ("vibe coding")

  • Intent lives in someone's head or a chat log
  • Edge cases discovered in production
  • Review means reading diffs to guess intent
  • AI agents fill gaps with plausible guesses

Spec-first

  • Intent is written, versioned, reviewable
  • Edge cases argued about when they're cheap
  • Review checks code against stated criteria
  • AI agents get precise, bounded instructions

Why it matters more with AI

A coding agent will build something from any prompt. The less you specify, the more it invents. Spec-driven development turns prompting from a conversation into a contract: the agent is told what to build, what not to build, and which tests must pass.

The core idea: the spec is the primary artifact. Code is one of its outputs. When behaviour needs to change, change the spec first, then regenerate or update the code.

When not to bother

SDD has a cost. Skip the full process for throwaway prototypes, one-line fixes, and spikes whose purpose is to discover requirements. Use it when the work is multi-day, touches several people or systems, will be built largely by an agent, or has consequences if it's wrong.

Module 02 · Foundations

The SDD loop

You will be able to
  • Name the five phases and the artifact each produces
  • Explain the gate between each phase

Every SDD workflow, whether hand-rolled or tool-driven, follows the same shape. Each phase produces a written artifact that is reviewed before the next phase starts. Click a phase to see its details.

01SpecifyWhat & why
02PlanHow, technically
03TasksSmall, ordered steps
04ImplementOne task at a time
05VerifyProve it against the spec
Specifyspec.mdPlanplan.mdTaskstasks.mdImplementcode + testsVerifyACs passspec gap found? stop and update the speclearned something? it goes back into the spec, never only the code
Each phase writes an artifact that is reviewed before the next starts. Dashed lines are the way back: the spec is updated first.
It's a loop, not a waterfall. Implementation often surfaces something the spec missed. When that happens, stop and update the spec (and plan) first. Never let the code quietly become the new source of truth.
Modules 03–09 · Locked

Unlock the full course

You've finished the free preview. The rest of the course is where you learn the craft: writing requirements, acceptance criteria, plans and tasks, working with AI agents, and keeping specs from drifting.

$10one-time · lifetime access · no account needed
  • 7 more modules, including the spec template, EARS patterns and agent prompts
  • 3 interactive labs: spec smell detector, EARS builder, criteria → test generator
  • Spec review checklist and a 12-question final assessment

Secure payment through Stripe. After you pay you'll get a personal access link. Bookmark it to open the course on other devices.