Aller au contenu principal

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.