AI-generated technical debt deserves its own category
The debt everyone is worried about is not worse code. It is code that works, that nobody has read, in quantities no team can catch up on. That is a different problem with a different fix.
Gartner expects a remediation market to emerge: specialist tools and consultants to audit and refactor the technical debt organisations are accumulating from AI-generated code. When an analyst firm predicts a market before most buyers have measured the problem, it is worth asking what exactly is being sold.
My position: the debt is real, it is a genuinely distinct category, and almost every description of it is wrong about why.
The wrong diagnosis
The common framing is that generated code is lower quality, so more of it means more debt. Straightforward, intuitive, and mostly not what is happening.
Generated code is usually fine. It compiles, it handles the obvious cases, it is consistently formatted, it has tests. Judged as an artifact against the median of what humans commit under deadline, it holds up. If quality were the issue you would see it in defect rates on the generated portion, and teams that measure this mostly do not find a dramatic gap.
The problem is not the code. It is the ratio between how fast it arrives and how fast anyone reads it.
Comprehension debt
Every codebase has always carried a quantity of code that no current employee understands. That number was bounded by turnover: people left, and their understanding left with them, at the speed of resignations. Slow enough that documentation, onboarding and ordinary maintenance could roughly keep pace.
Now the same gap opens without anyone leaving. Code arrives faster than it is read, so the unread fraction grows continuously, and nothing marks the moment it crosses from “we know this system” to “we operate this system.”
Classic technical debt
- Shortcuts taken knowingly
- Someone remembers the tradeoff
- Accrues at the speed of decisions
- Visible as ugly code
- Paid down by refactoring
Comprehension debt
- No shortcut taken, no decision made
- Nobody has a model of it at all
- Accrues at the speed of generation
- Invisible: the code looks fine
- Refactoring makes it worse, not better
That final point deserves weight. The standard response to technical debt is to refactor. Applied to comprehension debt it is actively counterproductive: refactoring code nobody understands, using agents nobody is reviewing closely, generates more unread code on top of the unread code. The remediation market being predicted will sell exactly this, and some of it will make the problem worse while producing a satisfying report.
Where the bill actually arrives
Classic debt bills you during maintenance: the next change in that area takes longer. Predictable, gradual, easy to plan against.
Comprehension debt bills you during an incident. Everything is fine, indefinitely, until something breaks in a subsystem no one has a model of, and then the diagnosis that should take twenty minutes takes three hours because there is no basis on which to prune the search.
This is why it stays invisible on every dashboard. Nothing in your delivery metrics gets worse. Throughput is up. Defect rates hold. The cost is concentrated entirely in the tail, in the worst hour of a quarter, and it never appears as a line item because it looks like an unusually hard incident rather than a systemic condition.
What actually helps
Not refactoring. Three things.
Read deliberately, in proportion to risk. Not everything, which is impossible. The paths where being wrong is expensive, on a schedule, as a named activity with time attached rather than something that happens if a sprint finishes early.
Keep provenance, so the record substitutes for memory. When nobody remembers why a line exists, a chain from that line back to the ticket, the criteria and the approver answers the question that memory used to answer. This is the one place where an agentic pipeline can be strictly better than what preceded it: the human process never produced a complete record, and this one can.
Write down decisions at the moment of deciding. Unnatural, low-reward, and the only thing that reliably prevents the eighteen-month-later version of the problem. Teams that do this have almost always been taught by an expensive incident.
Where this breaks down
I may be underrating quality. My claim that generated code is roughly fine rests on defect rates, which measure the failures you notice. A subtle wrong assumption about ordering or uniqueness that surfaces in eighteen months does not appear in this quarter’s numbers, and that is exactly the failure mode agents are prone to. My evidence is weakest where it matters most.
“Read more” is not a strategy at volume. I have said read deliberately in proportion to risk, and at genuinely high volumes even the risky subset exceeds what a team can absorb. At some point the honest answer is to generate less, and I do not have a better one.
Some codebases genuinely do not need to be understood. A well-bounded service with a strong contract, good tests and a low change rate can be a black box safely. Not everything deserves comprehension, and treating all code as equally worth reading wastes the attention that should go to the parts that matter.
And the remediation market will not be entirely useless. I have been sceptical about it. Some of that tooling, particularly anything that identifies unread and unowned regions rather than promising to refactor them, is genuinely worth buying.
The takeaway
The debt is not that the code is bad. It is that it is unread, in volumes that make catching up impossible, and that the bill arrives during an incident rather than during maintenance.
That makes refactoring the wrong instinct and provenance the right one. You cannot refactor your way to understanding something, and a complete record of what changed, why, and on whose authority does most of the work that memory used to do.
If you take one thing into next week: work out your unread merge rate. Not coverage, not defect density. What fraction of what you shipped this month did no human open.