Description
Somewhere in most AI business cases there is an unstated assumption: that the speed will eventually pay for the mess. Circle back later, once the tooling has bought us the room. It is a comfortable belief and it is the wrong way round. Debt is not what acceleration fixes. It is what acceleration is spent on.
Two findings sit under that. The first is that the speed is less certain than it feels. In a randomised trial, experienced developers working in mature repositories they already knew took longer with assistance while believing they had been faster, and the belief survived the measurement. Decisions about hiring, capacity and delivery dates are being made on a gain that has not been demonstrated in the environments where most enterprise code actually lives.
The second is what happens to the code. As assistance spread, duplicated blocks rose and the share of changes that were consolidation rather than addition fell. That is the maintenance work which keeps debt from compounding, and it is the first thing dropped under delivery pressure. Ordinary debt accumulates and can be budgeted for. This compounds: every component that avoids restructuring creates one more dependency making the next restructuring harder, and it does so at generation speed.
Which turns a technical argument into a financial one. Debt that is not quantified cannot appear in a business case, and a business case without it is optimistic by construction: the remediation still happens, it just arrives later, as delay and change requests nobody named as debt. So what this dimension scores is not whether your engineers know the system has problems. They do. It is whether the number has been put on the table where the money is decided, and whether it is allowed to change the answer.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nothing measures what the estate owes. There is no inventory, no cost and no agreed definition of what counts, so the debt exists only as a shared feeling that some parts of the system are horrible to work in. It shapes every estimate and appears in no plan.
The tellAsk what your technical debt costs you in a year. If the answer is a story about a system rather than a quantity, and no two people tell the same story, you are here.
- 2
Tacit
Individual teams know their own debt and some keep a list of it, negotiated into the plan whenever there is room. It is real work done by people who care, and it is invisible one level up: nothing aggregates across teams, and nothing survives a quarter when the roadmap is under pressure.
The tellAsk two teams for their debt list. If both have one and nobody above them has ever seen either, the practice belongs to the teams rather than to the organisation.
- 3
Visible but inert
The debt is measured and reported. There is a register, a quality-gate score or a remediation backlog, and the figure gets quoted in planning. No decision depends on it: the acceleration programme is approved with the number in an appendix, and remediation is what gets cut when the date moves.
The tellFind where your debt figure is reported, then find a decision that changed because of it. If the number has never moved a date, a budget or a scope, it is reporting rather than governance.
- 4
Acted on
Debt is quantified in money and the number is a term in the investment case rather than a footnote to it. A programme that would accelerate on top of an unremediated system either carries the remediation budget or does not get approved, and the argument is had with a figure on the table.
The tellFind the last acceleration or AI programme your organisation approved. It carries an explicit remediation line, and something in the approval refused to proceed without one, rather than a reviewer who happened to ask that day.
- 5
Durable
The measurement holds and the remediation is continuous. The figure is recomputed on a cadence rather than produced for a business case, new debt is taken deliberately and carries a date, and paying it down is a standing part of how work is funded instead of a campaign somebody has to win each year.
The tellLook at how the debt figure has moved over two years, and who owns it. If it is recomputed on a cadence, and remediation was funded in a year when no transformation programme was running, the practice is durable without anyone campaigning for it.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025)
Ran a randomised controlled trial with experienced developers in the mature repositories they already knew, and found they took longer with AI assistance while believing they had been faster. The perception moved before the productivity did.
GitClear, AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones (2025)
Analysed a large body of changed lines as AI assistance spread, and found duplicated blocks rising while the share of refactored lines fell. Refactoring is the maintenance that stops debt compounding, and it is what gave way.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Technical debt →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.