Against the AI debt panic
A remediation market is being sold before most buyers have measured the problem. The panic buys the wrong thing: an audit produces a report, and a report is not the deliverable you need. The fix is a rate control you already own.
I want to argue against a position I mostly hold, because the version of it now being sold is going to cost people a lot of money for very little.
The position is that AI-generated code is accumulating debt at a rate no organisation can absorb. Gartner expects a remediation market to emerge: specialist tools and consultants to audit and refactor it. CAST has put global technical debt at something like 61 billion workdays. Put those together and you get a story with a clear shape and an obvious purchase at the end of it.
My position: the underlying problem is real, the panic is being manufactured slightly ahead of the evidence, and the thing the panic sells you is the thing least likely to help. Before you buy an audit, notice that the number describing the disaster mostly predates agents entirely, and that the intervention with the best return is a throttle you already own and have chosen not to use.
I have a commercial interest here. We sell software in the control layer. Discount what follows accordingly, and note that the recommendation at the end costs nothing and involves buying nothing.
The big number is not about AI
CAST’s 61 billion workdays is a measurement of accumulated technical debt worldwide. Nearly all of it was written by people, over decades, under deadlines, in languages and frameworks that have since moved on. It is a real and useful figure and it is not evidence about agents.
When that number appears next to a claim about AI-generated debt, it is doing rhetorical work rather than analytical work: establishing scale, transferring alarm from a well-measured problem to a poorly-measured one. Notice when it happens, because the transfer is where the argument stops being about your codebase.
The honest position on generated-code debt is that we do not yet have good longitudinal measurements of it. Teams that look at defect rates on the generated portion of their codebase mostly do not find a dramatic quality gap. That is not the same as saying there is no problem. It means the problem is somewhere other than where the panic is pointing.
What the panic sells
- An audit of the existing codebase
- A report ranking findings by severity
- A refactoring engagement scoped from the report
- Priced against the volume already accumulated
- Leaves the inflow untouched
What changes the trajectory
- A limit on what merges unread
- Ownership attached at merge, not retrospectively
- Cutting the generated code you never needed
- Priced against next quarter's inflow
- Costs no new licence
Why an audit is the wrong purchase
Suppose you buy one and it works perfectly. You receive a thorough report identifying every place your codebase has drifted, duplicated, or accumulated risk.
Ask what changed. You now know things you did not know. Nobody on your team understands the code any better than they did before, because understanding is not transferable through a document. The code is unchanged. And next quarter another tranche arrives at the same rate, because nothing in the pipeline was altered.
That is the structural problem with remediation as a category. It treats debt as a stock to be drawn down, and the thing generating it is a flow. Draw down the stock without touching the flow and you have bought a temporary improvement at a permanent price.
There is a sharper version of this for the specific harm people are actually worried about. If the problem is that code arrives faster than anyone reads it, then the deliverable you need is comprehension, and comprehension cannot be delivered by a third party. A consultant who reads your codebase has understanding of your codebase. You have a report about it. Those are different assets and only one of them helps at 3am.
The intervention nobody wants
The effective control is admission. Limit what enters the codebase without somebody understanding it.
That is unpopular because it looks like slowing down, and it is the reason this article is not going to be widely agreed with. But look at what the numbers describe. LinearB’s 2026 benchmarks put pull requests merged with zero review up about 31 percent, alongside review duration up over 400 percent on agentic changes. That is a system where the inflow already exceeds the absorption rate and the excess is going in unread.
You cannot raise absorption much. Review capacity is bounded by people with context, and adding reviewers does not scale it the way adding writers scales production. So the only variable left is the inflow, and choosing not to control it is a choice to accumulate.
Concretely: a cap on how much unreviewed change can merge per week, enforced rather than aspirational. An owner named at merge for every change above a size threshold, because unowned code is the actual failure mode. And a serious bias towards not generating code you do not need, which is the cheapest debt reduction available and gets almost no attention, because “we decided not to build that” does not appear on any dashboard.
What would change my mind
I want to be specific about the evidence that would move me, because “the panic is overblown” is an easy thing to say and a hard thing to be held to.
If defect rates on the generated fraction of a large codebase turned out to be meaningfully worse than the human-written fraction, controlling for age and area, the quality story would be right and the audit market would be justified. That measurement is doable and I have not seen it published convincingly in either direction.
If incident post-mortems started consistently naming generated code as the root cause rather than as the location, that would be a signal. Location is not causation and most of what I have seen conflates them.
And if the remediation tools turn out to deliver understanding rather than reports, by producing something that makes a team faster at reasoning about their own system, then my objection to the category disappears. That would be a genuinely valuable product. It is not what is currently being sold.
Where this breaks down
Complacency is the expensive error here, not overspending. If the debt is real and compounding, then arguing against urgency is exactly what a team wants to hear and exactly what will hurt them in three years. I am arguing against a specific purchase, not against concern, but that distinction gets lost the moment somebody quotes this in a budget meeting, and I should say so plainly.
“Cap the inflow” is throughput-hostile and your business may not accept it. The strongest objection. I am recommending a control that visibly reduces delivered volume in exchange for a benefit that shows up years later and cannot be attributed. That trade loses most arguments in most organisations, and I do not have a good answer beyond making the unread fraction visible and letting people choose knowingly.
Audits can be genuinely useful when you have inherited a codebase. Acquisitions, a team that left, a system nobody has looked at in four years. In those cases you are not trying to change a flow, you are trying to understand a stock, and an external assessment is a reasonable purchase. My argument is about ongoing production, not about every situation.
I have a direct commercial interest in the alternative. Control layers are our category. Everything I have written points away from remediation vendors and towards controls at the point of merge, which is convenient for me. The mitigation is that the specific recommendations here can be implemented with what you already have, and if you do that and never speak to us, the argument was still honest.
And “generate less” is easy to write and hard to operationalise. No team has ever succeeded at building less by being told to. It is a real lever and I have offered no mechanism for pulling it, which is a weakness in the practical half of this piece.
The takeaway
The debt is real. The panic is arriving ahead of the measurements, decorated with a number that describes decades of human-written code, and the purchase it recommends acts on the stock while the flow continues.
Before buying an assessment of what you have accumulated, control what accumulates. That intervention is unpopular, requires no vendor, and is the only one that changes the direction of the line.
If you take one thing into next week: work out what fraction of last month’s merged changes had a human who could currently explain them. You do not need a tool to estimate it, and it is the only debt number about your organisation that means anything.