AI and technical debt: Faster code, faster debt?

One speed changed, the other didn’t

In Technical debt as a team phenomenon (in Norwegian) I wrote that debt rarely comes from one bad decision. It grows through many small compromises that were never aligned. That mechanism hasn’t changed with AI; what has changed is the speed. Where a team used to produce debt at human pace, it can now produce it at machine pace.

AI often writes strikingly good code. But debt was never about code quality alone – it was about understanding, and understanding still runs at human pace.

Volume as the new debt driver

The classic debt ledger looked like this: the team took a shortcut, knew about it, and planned (or forgot) to pay it back.

The new ledger can look different:

• no one took a deliberate shortcut
• the code isn’t bad
• but no one fully understands it

A developer generates a module in an afternoon. It works. It gets merged. Three months later something needs changing, and the team spends two days figuring out what the module actually does. That’s debt. Not because anything was necessarily done wrong, but because the speed of production exceeded the speed of understanding.

So the word has to cover more than it used to. Debt is no longer just what you know you owe, but also everything you’ve merged without owning.

Code no one owns

The most dangerous symptom of classic debt was the TODO comment without context: the trace of a thought no one remembers. The new variant can be worse because it’s invisible. Call it code no one owns.

It looks finished. It has no TODO. It doesn’t resemble debt. It is even well liked: a study presented at MSR 2026 compared pull requests from agents and from people, and the agents’ code reused less of what already existed and was more redundant – while reviewers were more positive about it than about their colleagues’. The surface hides the bill.

But ask “why is it done this way?”, and no one can answer – not the author, who had it generated, not the reviewer, who approved something that looked right, and not the AI, which doesn’t remember the conversation.

Knowledge debt has always been easy to underestimate. With AI it can accumulate faster, every time a team merges code it doesn’t fully understand.

The debt has already been measured

The numbers already exist. GitClear has tracked 623 million code changes from 2023 to 2026 so far, and the three signals that warn of debt all point the same way. Duplicated code blocks – five or more identical lines in a row – are up 81 percent since 2023. The share of changes that touch code untouched for over a year has fallen from 1.7 to 0.46 percent; GitClear’s own phrase is that the neglected sections calcify until something breaks. And constructs that mask errors instead of handling them are up 47 percent. The 2026 figures are provisional. The direction has been the same every year in the window.

Developers see it themselves. In Sonar’s January 2026 survey of 1,100 developers, 93 percent see positive effects of AI on their technical debt, such as better documentation and test coverage, and 88 percent also see negative ones – above all code that looks correct but isn’t reliable (53 percent), and code that is unnecessary or duplicated (40 percent). The same developers report that AI now accounts for 42 percent of the code they commit. DORA summed up 2025 in one sentence: AI improves throughput, but often at the cost of stability if the foundation isn’t solid.

None of these numbers says AI writes bad code. They say it writes more of it, that less of it gets cleaned up, and that what sits untouched sits longer. That is the ledger above, measured.

What hasn’t changed

The toolbox, though, is the same. Many of the practices that work against classic debt also work against AI-accelerated debt, because the underlying cause is still human:

• TDRs document the why, which is precisely what generated code lacks
• The boy scout rule works just as well on generated code as on handwritten code
• PR templates can make understanding explicit: “Explain the choices you approved”
• Retrospectives catch the patterns before they become culture

You just have to do it more often than before, and more deliberately. GitClear’s own advice after 623 million changes is concrete: set aside time for refactoring and maintaining old code, put a tripwire on duplicated blocks, look for code that masks errors as a separate item in review, and measure structure, not only volume. The debt wheel spins faster, so repayment has to move into day-to-day work too – not as heroic cleanup sprints, but as rhythm.

Deliberate debt is still allowed

This is not an argument against speed. As before, debt can be strategically right. An MVP for investors. An integration with an API still in flux. AI can make some deliberate shortcuts cheaper or faster, and that’s good.

The line runs where it always ran: between debt the team controls, and debt that controls the team. Awareness requires someone to stop and ask: “Do we know what we just merged?” That question cannot be delegated entirely to automation.

The tech lead’s math

As a tech lead you have to help the team – and the decision-makers – see the new arithmetic. The pace of production may have risen sharply, but has the pace of understanding kept up? If not, the gap grows every single sprint, and that gap is the debt.

So make it visible: in demos, in dashboards, in concrete examples. “This module took four hours to build and two days to change” is arithmetic everyone understands.

The interest rate has risen

AI hasn’t changed what technical debt is, only how quickly it can accumulate. Debt has always been culture, not code.

Debt is still inevitable. How fast it grows is decided by what the team chooses to understand before the next merge.