Specification-Driven Development¶
david-sanchez's successor to prompt engineering. Prompts are ephemeral; specs are durable.
"A well-written specification gives an agent the same information a product manager would give an experienced engineer: the business context, the technical constraints, the user expectations, and the definition of done."
Specification Maturity Curve¶
| Stage | Practice | Agent Effectiveness |
|---|---|---|
| Ad Hoc Prompts | One-off prompts in chat | Inconsistent; depends on individual skill |
| Template Prompts | Reusable templates | Consistent for routine; fragile for complex |
| Structured Specs | Versioned files with acceptance criteria & constraints | Substantially improved; self-validation possible |
| Living Specs | Continuously updated, linked to code/tests, consumed by pipelines | Highest quality; enables pipeline-as-specification |
Double-duty benefit¶
Specs serve as both agent input AND documentation, "reducing the overhead of maintaining separate design documents and user stories."
Why this matters¶
This is the written artifact version of Horthy's qrspi — the Q/S phases produce a spec, not a prompt. Konstanty-adjacent: specs make evals meaningful because "did it meet acceptance criteria" is now a testable question, not vibes.
Connects to¶
- qrspi — the human-process route to the same artifact.
- pipeline-as-verifier — specs become what the pipeline enforces.
- pipeline-as-specification — end state.
- repository-as-interface — specs live in the repo, not chat windows.