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