Module 2: Spec-Driven Development
Learning objectives
By the end of this module, you will be able to:
- Distinguish a specification from a wish, using the "can something other than the author check it?" test.
- Write acceptance criteria in the Given/When/Then form and know when a plain example is better.
- Turn a specification into failing tests before any implementation exists, and explain why the order matters more with an assistant than without.
- Run a spec-driven iteration with an agent: spec, tests, generate, verify, repeat.
- Keep a specification alive after the code ships, so it stays the source of truth.
Module content
Chapter 1: Writing executable specs
What makes a specification "executable" - precise enough that a model can act on it and a test can verify it. Acceptance criteria, examples, interfaces, constraints and the anti-patterns that produce vague output.
Chapter 2: From spec to tests to code
The test-first contract. Why tests written before the code are the single most effective guardrail against an assistant, how to get the assistant to write them without letting it also mark its own homework, and what to do when the spec turns out to be wrong.
Quiz
Six questions.
Why this module matters most
If this course had to be one module, it would be this one. Everything an assistant produces is downstream of the description it was given. Engineers who write good specifications get good code from any tool; engineers who do not get plausible code from every tool. Specification is where the leverage is.