AI is the first tool that can both create technical debt and clear it.

What makes this moment genuinely new is not the speed of writing code. It is that the same capability, pointed one way, manufactures the debt that slows teams down and pointed the other, clears the debt that has always been too tedious to clear. The tool is neutral. The outcome is a choice nobody used to have.

01A definition that matters more now.

Technical debt is Ward Cunningham’s old metaphor for the future cost of a shortcut taken today: ship something quick and imperfect to move now and accept that you will pay to fix it later, with interest.¹ A little is healthy and deliberate, the engineering equivalent of a sensible loan. The trouble is the debt you take on without noticing: the code that works but nobody fully understands, the duplication, the missing tests, the design that no longer fits the problem it grew up around. It charges its interest as drag, so every future change in that area costs more and risks more.

For years this accumulated at human speed, which is to say slowly enough that most teams could mostly ignore it. You could only write so much code in a day, so you could only dig the hole so fast. That speed limit is the thing AI has just removed, which is why a metaphor that felt familiar and manageable suddenly deserves a fresh look.

02Why AI accelerates the debt.

The seductive thing about AI coding tools is exactly the dangerous thing: they remove the friction that used to slow the creation of debt. It has never been easier to produce a large, plausible, working-looking change you do not fully understand. The model writes two hundred lines, it compiles, the tests such as they are pass and in it goes. Multiply that across a team shipping all day and you can accumulate in a week the kind of comprehension gap that used to take a year. The code runs. The problem is that understanding, not code, is what lets you safely change a system later and AI makes it trivially easy to ship the first without the second.

The reviewer is where this breaks down most quietly. Review was always the backstop, the place a human caught what should not go in. But a person who can carefully review three hundred lines in an hour cannot meaningfully review three thousand and AI happily produces the three thousand. So review degrades into approval, the same automation-bias trap that catches anyone asked to rubber-stamp a confident machine. The debt, in the end, is not in the code the AI wrote. It is in the understanding the team quietly agreed to skip.

AI does not write technical debt. It writes code faster than anyone can understand it and the gap is the debt.

03Why AI is also the cure.

Here is the part that genuinely excites me, because the same capability runs in reverse. Everything that ever made technical debt expensive to service was, at bottom, tedious comprehension work and tedious comprehension work is precisely what these models are good at. Point one at a gnarly legacy module and ask it to explain what the code actually does, then watch a map appear in minutes that used to take days. Ask it to write the characterisation tests nobody ever wrote for that untested core and you suddenly have the safety net you needed before you dared refactor. Migrations, renaming, untangling duplication, documenting the undocumented: the chores that always lost to the next feature because they were too dull to fund have become cheap.

This is the first time in my career that the cost of paying down debt has fallen instead of risen. Servicing technical debt was always the thing teams knew they should do and never quite had time for, because the work was real and the reward was invisible. AI changes that economics. It does not make the judgement of what to fix for you, but it removes most of the drudgery that made the judgement academic, which means the refactor you have been deferring for three years is now a week, not a quarter.

04The discipline that decides which.

So the same tool buries you or digs you out and which one you get is not a property of the tool. It is a discipline and the discipline is comprehension. The single rule that decides it is this: never merge what no one on the team understands. Use the AI to reach understanding faster, to explain and test and draft, but keep a human owning the mental model of how the system actually fits together, because that model is the real asset and the code is only its current expression. Hold that line and you get the speed and pay down the debt at the same time. Let the model’s output stand in for your own understanding and you ship faster for one quarter, then grind to a halt in a codebase nobody can safely touch.

That choice is the whole game now. AI has made both the fast wrong path and the fast right one cheaper than they have ever been, which means the gap between teams who choose well and teams who do not is about to get much wider. The reason I am optimistic is that, for the first time, the right path, the one where you genuinely understand and continuously improve your system, is no longer the expensive one. It is right there, as cheap as the shortcut. You only have to decide to take it, on purpose, every day.

QUESTIONS ON THIS PIECE

What readers tend to ask.

01Does AI increase technical debt?

It can, sharply. AI coding tools remove the friction that used to slow the creation of code, which makes it easy to ship large, plausible changes nobody fully understands. Since understanding, not code, is what lets you safely change a system later, the result is a comprehension gap that accumulates far faster than it used to. The debt is not in the AI’s code; it is in the understanding the team skipped.

02Can AI help reduce technical debt?

Yes. This is the more hopeful half. The work that made debt expensive to service, explaining legacy code, writing missing tests, migrations and documentation, is tedious comprehension work, which is exactly what these models are good at. For the first time the cost of paying down debt is falling rather than rising, so the refactoring teams always deferred is becoming affordable.

03What is technical debt?

Technical debt is the future cost of a shortcut taken to move faster now: code that works but is imperfect, undocumented or hard to change. Like financial debt, a deliberate amount is healthy; the dangerous kind is the debt you take on without noticing. It charges interest as drag, making every future change in that area slower and riskier.

04How do you use AI coding tools without creating debt?

Hold one rule: never merge what no one on the team understands. Use AI to reach understanding faster, to explain, test and draft, but keep a human owning the mental model of how the system fits together. The code is only the current expression of that model. Teams that keep comprehension in human hands get the speed and pay down debt at the same time.