An AI coding agent that does not cut maintenance costs is just expensive technical debt

Shore's math is simple and uncomfortable: an AI coding agent must reduce maintenance costs at precisely the rate it increases output. Otherwise the team does not profit from speed; it pays more.

Writing code faster is not enough when the backlog grows as fast as the technical debt

James Shore put it without softening: if a team doubles its change volume thanks to an agent but maintenance costs stay flat, it did not gain 2x productivity. It gained a 2x maintenance backlog. The arithmetic is direct. Twice the output at the same maintenance cost means doubled total cost of ownership. Twice the output with doubled maintenance costs means quadrupled total costs.

For the numbers to break even, the agent must reduce maintenance costs inversely to the rate at which it adds code. Double productivity requires half the maintenance cost. Triple productivity requires a third of the maintenance cost.

For engineering teams this changes the success metric

Tracking pull request counts, story points or hours saved during implementation is not enough. The relevant question is whether the agent produces code that is cheaper to maintain: smaller changes with clear intent, better tests, more readable design, safer refactoring, decisions captured in documentation.

Simon Willison curated this argument on his blog on 11 May 2026. He added no extended analysis of his own. He chose it as strong enough to stand alone. That is a curatorial signal: Shore named a problem that coding agent vendors consistently ignore because their metric is writing speed, not cost of code ownership.

Shore's argument is mathematically correct but silent on nonlinear costs

Shore's argument is mathematically correct but silent on one thing: not all included costs are linearly measurable in advance. Maintenance cost depends on architecture, team agility and who reads the code in the future. An agent that forces the programmer to think more carefully about design can reduce maintenance cost in ways that PR metrics do not capture.

A second caveat: Shore's framework applies cleanly to brownfield code. For greenfield projects where a team actively refactors and tests AI-generated code, the calculation may differ.

An agent that changes review, not just output, will be the proof in practice

Agents that only generate code are high-speed shovels. Evidence that an agent genuinely reduces maintenance cost will appear in tooling: an agent that can explain every change, find side effects across the codebase, maintain the test network and make review cheaper. Until those capabilities are standard in coding agents, Shore is right.

Lilith's verdict

A team with 3x more pull requests that cannot keep up with review is not 3x more productive. It is 3x more indebted. An agent that does not reduce maintenance is just a faster way to dig the hole.