The new technical debt: code you did not write

Technical debt always had one property that made it manageable: somebody, at some point, understood the code. The person who took the shortcut knew why they took it. AI-generated code at volume breaks that premise, and that is what makes the new debt different from the old.

The quadrant that explains the difference

Martin Fowler proposed looking at technical debt on two axes: it was taken on deliberately or inadvertently, and prudently or recklessly. That gives four combinations, and the healthy one is deliberate and prudent: "we know this design is limited, we chose to ship now, and we wrote down the cost".

Mass generation by AI tends to produce one specific kind: inadvertent, and worse, at scale. Nobody decided to take on the debt, because nobody built the mental model that would have let them notice they were taking it on.

Comprehension debt

This deserves its own name. The dominant cost is not that the code is wrong, it is that nobody on the team knows why it is the way it is.

Typical symptoms show up a few weeks later:

• A simple bug takes a day because nobody understands the path.
• Refactoring gets avoided because the risk is unknown.
• Review questions turn into "I think the model did it this way because...".

That cost appears in no coverage or complexity metric. It appears in defect resolution time, months later, when whoever could have explained it has already changed teams or companies.

The cruel detail is that comprehension debt grows silently. While the system works, nothing signals the problem, and the discovery happens at the worst possible moment: during an incident, in a hurry.

The lesson ML systems already taught

In 2015, an influential paper from Google showed that machine learning systems carry all the maintenance burden of traditional software plus a set of their own problems, among them excess glue code, pipeline jungles, configuration debt, and the fact that changing anything changes everything.

The analogy with generative AI in development is nearly direct. The code that integrates the model, handles prompts, parses output and deals with failure tends to grow without design, exactly like the glue code described there. And it rarely has an owner.

Where the debt piles up fastest

Three places concentrate the problem:

1. Copied error handling. Generic, repeated catch blocks that swallow the exception and hide the root cause.
2. Duplication instead of abstraction. It is easier to ask again than to discover a function for it already exists. Repository analyses have been reporting rising duplication and falling reuse as assistants spread.
3. Tests that confirm the implementation. A test generated from the code tests what the code does, not what it should do. It always passes, including when the behaviour is wrong.

Controlling it without banning the tool

The goal is not to use less AI, it is to keep the debt in the deliberate quadrant.

Require a mental model at review. One standard question in the PR template solves much of it: "explain in two sentences why this solution works". If the person who opened the PR cannot, the code is not ready to land, regardless of who wrote it.

Measure maintainability, not just coverage. ISO/IEC 25010 decomposes quality into characteristics, and maintainability has sub-characteristics useful for deciding what to track: modularity, reusability, analysability, modifiability and testability. Picking two and measuring them beats debating quality in the abstract.

Write the debt down when it is deliberate. A short comment saying what was simplified and why turns inadvertent debt into prudent debt, which is the kind a team can actually pay back later.

Review the integration layer more strictly. That is where glue code accumulates, and it is the part least likely to have tests.

What this means for your team

Add the explanation question to your pull request template this week. It is the lowest-cost, highest-effect intervention, because it attacks comprehension debt at the source.

Pick two maintainability sub-characteristics and start tracking a trend, even a rough one: duplication and mean time to resolve a defect work well. Compare the quarter before and after adoption.

And treat the layer that integrates the model as real production code, with an owner, tests and review, rather than as a script someone pasted in to make the demo work.