- 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 / Act 1: The shared problem
Loading the video
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
2. One feature in one sprint
Consider one developer in a conventional Scrum sprint, working with an AI coding agent on a feature that lets users choose how often they receive saved-search alerts. The coding agent writes code in seconds: in one example, twenty minutes of typing becomes ninety seconds of reading and editing. Before the agent can write the right code, the developer needs four kinds of knowledge, and each kind comes from a person. For the functional knowledge, the developer has the product owner's one-paragraph user story, and three questions about it. For the design knowledge, the design system offers four controls, and the UX designer takes thirty seconds to name the right one. For the architecture knowledge, the architecture wiki has not been updated in nine months, so the developer asks the architect where the new data should live. For the code knowledge, the developer messages two colleagues, one of whom is away until Monday. Each message costs the person asking about thirty minutes, and each answer takes ten to fifteen minutes to write. The answers come back partial, and one contradicts the wiki. Code review catches one issue, integration testing catches another, and the third surfaces in production six weeks later. The coding agent saved minutes of typing, and the feature still waited on people. Each of these exchanges happens between two people, and none of them is recorded. The time and information lost in exchanges like these is what the methodology calls the Manual Translation Tax.
On the site: The Manual SDLC Problem This Zone Addresses · What This Looks Like on a Sprint · The Landscape Today
3. The Manual Translation Tax
The Manual Translation Tax is the recurring cost of knowledge and context lost at each handoff across roles, artifacts and tools, as documents, messages and memory become decisions and code. Every translation takes time, and every translation loses some information. A coding agent makes writing code faster, and leaves the tax where it is. The team's time goes into paying the tax, so faster code generation does not make the team faster. The tax has three components, and all three appear even on disciplined teams with good tools. The first component is ambiguity: the same words mean different things to different people. A product owner writes "let users save their search so they can return to it later". The frontend developer stores the search in the browser, the backend developer stores it in the database, and the QA engineer tests for a confirmation message. The difference surfaces in code review, and two weeks of work are partly redone. The second component is non-persistence: knowledge that was never written down is lost when the person who holds it leaves. When a senior engineer leaves, the team spends months rediscovering what she knew, usually when something breaks. A coding agent loses its knowledge the same way, because every new session starts with no memory of the last one. The third component is non-traceability: nothing records which parts of the code depend on a feature the user sees. When the alert frequency on saved searches changed from daily to weekly, some customers received both emails, because a worker in another repository still sent the daily ones. Nothing linked the alert frequency feature to that worker, and finding the cause took two days. The usual response to the tax is to write more documentation. On one platform team, roughly 40% of the architecture pages sampled were materially out of date by the end of the year. More documentation adds more text to translate, and the new text goes out of date in the same way. Removing the tax requires changing how the knowledge is recorded.
On the site: The Manual Translation Tax: The Cost, Named · How It Shows Up in a Sprint · The Three Components of the Tax
4. Why AI coding agents make mistakes
A coding agent working on the same feature faces the same gaps. The agent sees the codebase, the ticket and the wiki, and the wiki is often stale. The agent cannot see the direct messages, does not know which custodian to ask, and cannot ask anyway. Everything the four custodians know is invisible to the agent. In one example, an agent called a function the team had removed three sprints earlier, because the spec said the function existed. Coding agents do well on small, contained tasks, and make mistakes on the complexity of enterprise applications. On one codebase of more than two million lines, the team's AI coding tools produced isolated prototypes and no overall gain in productivity. On another team, an agent working from an out-of-date wiki needed so much back-and-forth that the change took longer than it would have taken by hand. Bigger context windows do not solve the problem, because more unstructured text gives the agent nothing it can check its work against. Building new applications, changing existing ones and modernizing legacy systems all face this gap, at different levels of complexity. The agent needs what the four custodians know written down in a structured form, which it can search for exactly the part each task needs.
On the site: The Shared Problem · Why AI Coding Agents Stall on This · The Manual Translation Tax: The Cost, Named
Choose a path
The full video in six parts and an appendix, one part at a time.