- 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 1: Who holds the knowledge
Transcript
1. Who holds the knowledge
The knowledge an enterprise application depends on falls into four kinds: functional, design, architecture and code. The product owner holds the functional knowledge: the personas, the outcomes, the scenarios, and the proposals that were rejected. The UX designer holds the design knowledge: the components, the interaction patterns and how each screen handles its states. The architect holds the architecture knowledge: the service boundaries, the databases that are the source of truth, and the integration contracts. The engineering team holds the code knowledge: the live functions, the retry policies, the active feature flags and the unused utilities. The product owner writes functional knowledge into prose specifications, the UX designer writes design knowledge into Figma handoffs, and the architect writes architecture knowledge into an architecture wiki. Much of the code knowledge stays in people's heads, each developer holding a narrow slice of the codebase. No single person and no document holds all four kinds of knowledge. The four roles are the custodians of the application's knowledge.
On the site: The Shared Problem · What the Custodians Know That the Code Does Not Show · The Landscape Today
Choose a path
The full video in six parts and an appendix, one part at a time.