Spec-driven development:
- https://opengsd.net/
- https://openspec.dev/
- https://docs.bmad-method.org/
- https://github.github.com/spec-kit/
- others
Conceptually
- we assume that at any given moment we know exactly what we want in our heads
- a complete specification is the code itself
- therefore, all specifications are incomplete
- incompleteness comes in 2 types: positive incompleteness and negative incompleteness
- positive incompleteness: not specified, but implemented the way we have it in our heads
- negative incompleteness: not specified, and implemented differently from what we have in our heads
- frameworks somehow fight negative incompleteness
- positive incompleteness can only be fought by deleting the spec (after implementation)
Practical conclusions
- code is primary
- at the same time, it’s important to document why a particular decision was made (ADRs, for example)
- specs are better deleted after implementation, otherwise they will eventually drift out of sync with the code