The code agent that doubles your technical debt

There's a phrase from James Shore that deserves more attention than it usually gets in debates about AI productivity: "You're trading a temporary boost in speed for permanent servitude". It's not rhetoric. It's arithmetic.

On May 11, Simon Willison highlighted on his blog an excerpt from Shore's article You Need AI That Reduces Maintenance Costs, and the logic presented there is as straightforward as it is devastating for any team that has adopted code agents without thinking too carefully.

The math nobody wants to do

Shore's argument starts from a basic premise: the total cost of a software system is not just the cost of writing it, but maintaining it throughout its useful life. When you introduce an agent that makes you three times more productive at generating code, you're also creating three times more surface area that someone else, or you yourself in six months, will need to read, debug, refactor, and update.

If your production rate doubles and the maintenance cost per unit of code stays the same, the result is not neutral: you've doubled your total maintenance burden. If production triples and maintenance costs triple, the result is nine times more debt. The only scenario where the equation works in your favor is one where the agent produces code that is proportionally easier to maintain than what you would have written without it. And in practice, that's not the default behavior.

Why this matters now

In May 2026, with tools like Claude Code maturing rapidly, support for subagents, lifecycle hooks, reusable skills, the temptation to delegate growing volumes of code to agents is completely understandable. Speed metrics are visible and immediate; maintenance costs are deferred and invisible until they're not.

The problem isn't the tool itself. It's the evaluation framework teams apply. If the only success metric is "lines of code generated" or "tickets closed per sprint," the agent will always look like a win. Codebase deterioration takes quarters to become apparent, and by then it's hard to trace causality.

Shore isn't asking you to stop using agents. He's asking you to measure what matters. The question isn't How much code did the agent generate this week? but rather Is the code it generated more or less expensive to maintain than what a developer without assistance would have written?

Who this affects most

This argument hits differently depending on your profile:

• Small teams with long-lived codebases: they're the most exposed. Every architecture decision made by an agent without sufficient domain context is a future problem landing on two or three people's shoulders.
• Startups in rapid growth phase: "move fast now, clean up later" is tempting and sometimes rational, but "later" arrives sooner when your generated code volume has tripled.
• Teams evaluating ROI on AI tools: if the success metric doesn't include projected maintenance cost, the evaluation is incomplete by design.

The projects where an agent might come out ahead in this equation are those where it's given enough context to respect existing conventions, its autonomy is limited to well-defined tasks, and there's real, not ceremonial, human review of the output.

What this says about the industry

That in 2026 we still need someone to write this article says something about how these tools are being sold and adopted. The dominant narrative still revolves around generation speed, and the conversation about structural quality of generated code occupies far less space than it should.

From our vantage point, we've spent months observing that teams getting the best long-term results with Claude Code aren't the ones delegating the most, but those who've invested time in defining what they delegate and how they evaluate the results. Shore's arithmetic isn't pessimistic; it's a reminder that "productivity" without a denominator isn't a useful metric.