Technical debt is now also paid in tokens

In the previous article, which opened this space for reflection, I pointed to a side effect: if context starts to cost money in a visible way, clarity stops being only a technical virtue. It becomes a way to save money.

For years, we got used to talking about technical debt as if it were an internal nuisance: something that slows teams down, complicates delivery, and turns small tasks into expeditions through old layers of the system. It cost onboarding time, strange bugs, Slack debates, fear of touching legacy modules, slow tests, tense releases, and that familiar feeling that a one-hour task needs three days of archaeology.

It was never free, but it always seemed like it could be postponed indefinitely.

The difference is that part of that cost is now starting to appear somewhere else. With AI agents, technical debt is not only paid in human time, delays, fatigue, or operational risk. It can also be paid in measurable compute consumption.

If people already struggled to understand or modify these systems, it is unsettling to see that these machines struggle with the same thing.

Context also sends an invoice

Agents do not arrive in a neutral repository. They arrive in an environment made of documentation, conventions, tools, names, abstractions, and accumulated decisions. If that environment is clear, they need fewer passes. If it is confusing, they need more context, more reading, more attempts, and more corrections.

Before agents, a poorly organized module mainly cost human time. With agents, it can also cost tokens. Outdated documentation does not just confuse a person: it pushes the model down false paths.

Disorder becomes a recurring compute expense. Humans can at least compensate with memory or intuition. Agents trip over the same problems again and again, across all their interactions, increasing the cost each time.

This changes some incentives. For years, many good practices were defended with arguments about maintainability, quality, or professionalism. Those arguments were right, but they often lost to urgency. Good documentation, modularity, clean APIs, useful tests, and better error messages mattered, but they did not always feel urgent.

Part of the problem was accounting. Technical debt had a cost, but rarely a direct metric. It showed up as a task taking longer than expected, an estimate falling apart, someone being blocked for two days, or a deployment requiring more coordination than it reasonably should. It was a real invoice, spread across too many line items.

When context costs money, clarity starts to have a direct financial return.

Good engineering reduces consumption

A repository with clear boundaries lets you give the agent less context. An understandable architecture reduces exploration. Good engineering stops being merely an internal or romantic virtue and also becomes a way to optimize inference costs.

This may be one of the most positive consequences of the changes in agent pricing models. They do not make good practices obsolete; they may make them more important. What used to be justified as professional discipline can now also be justified as economic efficiency.

Efficiency does not fall on a flat surface

This may open a gap inside organizations themselves. Teams with healthy repositories will get better results at lower cost. Teams with critical, old, and confusing systems will pay more for each attempt. AI does not distribute efficiency evenly. It builds on the prior quality of the system.

That is why metrics matter. It will not be enough to look at total token consumption. We will need to observe which repositories are more expensive for agents, which types of tasks consume more, which tools return more noise, which modules require more attempts, and which parts of the system cause loops. Those signals can become a new kind of technical debt map.

Until now, we knew certain areas of the code were painful because people avoided them. Soon, perhaps, we will also know they are expensive because agents spend too much trying to understand them.

The question will not only be where we have technical debt, but where we are paying interest in tokens.

Design for human and machine readers

Let us leave behind that brief period when it seemed chaos did not matter because the agent would figure it out one or two million tokens later. Let us recover the useful goal of building software that is understandable, useful, and maintainable for people, but also for machines.

Designing for that coexistence will once again be part of engineering.