- 10When are specifications not enough?
- 11Where is the state of the work kept?
- 12Who prepares a change before coding starts?
- 13What does impact analysis tell you, and when does it run?
- 14How do coding agents use the graph?
- 15How is each change checked, and how does the graph stay current?
- 16Who decides which work agents do?
- 17How do managers see what people and agents are doing?
- 18What happens across many products?
- 19What about existing systems and technical debt?
- 20What changes for the team?
- 21What results have teams seen?
Home / Follow the story / Scene 10: When are specifications not enough?
Transcript
10. When are specifications not enough?
AI coding tools are fast for one developer working on small, contained tasks. A small application that its team can hold in mind works well with a written specification for each change, which the coding agent builds from and the reviewer checks against. Specifications start to fall short as the application grows complex: a large existing system, a legacy code base, or work that crosses team boundaries. Each specification describes one change, and knows little about the rest of the application. Specifications drift from the code under deadline pressure. A specification carries the product owner's functional knowledge, and little of the design, architecture and code knowledge the change depends on. Writing specifications becomes the slowest step in the process. The knowledge graph sits alongside the specifications and supplies the design, architecture and code knowledge they lack. Each specification still describes the change, and the knowledge graph describes the application the change lands in.
On the site: The Four Zones · When This Zone Stops Working · From SDD to SE
Choose a path
The full video in six parts and an appendix, one part at a time.