Sixty-one billion workdays is a number that means nothing
Global technical debt estimates size a market. They cannot justify a single decision in your organisation, and a budget request built on one gets funded once and cancelled twice.
CAST puts global technical debt at something like 61 billion workdays. It is a striking figure and it will appear on a slide in your organisation within the next year, probably in a request for a remediation budget.
I want to argue against using it that way, and I should be clear that I am arguing against a number I think is broadly honest. The problem is not accuracy. The problem is that a global stock figure cannot support any decision a platform team actually has to make, and building a case on one produces a programme that gets approved in Q1 and quietly killed in Q3 because it can never show a return.
My position: debt only becomes a real quantity when it has a price attached to a specific area of your codebase and a specific rate of change against it. Everything else is atmosphere.
What the number is for
Aggregate estimates do one job well. They establish that a category exists and is large enough that vendors, analysts and boards should take it seriously. Gartner expects a remediation market for auditing and refactoring AI-generated debt, and the CAST figure is the kind of evidence that makes that expectation credible.
That is genuinely useful, and it is the entire job. What the number cannot tell you is whether to refactor the payments module, whether last quarter’s agent output made your position worse, or whether the two engineers you are about to assign to cleanup would create more value doing something else. It contains no information about your organisation, because it was never about your organisation.
The failure mode is specific and I have watched it repeatedly. A leader cites a global figure, gets a remediation budget, and the programme has no way to demonstrate impact, because nobody defined what the local quantity was before work started. Twelve months later the only measurable outcome is that a lot of files changed.
Nobody pays principal
The debt metaphor is better than its usual application. Borrow the rest of it.
A stock figure is a principal estimate: the total notional cost of bringing everything to some standard. No organisation ever pays that, and no organisation should want to. What you pay, continuously and involuntarily, is interest: the extra cost imposed on each piece of work that has to pass through the affected code.
Interest is measurable, local, and denominated in the currency your finance function already understands. Principal is a hypothetical number about a state you will never reach.
A principal estimate
- Total notional remediation cost
- Same whether the code is touched daily or never
- Never actually paid by anyone
- Cannot be reduced measurably in a quarter
- Justifies a programme, not a decision
An interest measurement
- Extra cost per change in a specific area
- Zero where nothing changes, regardless of quality
- Paid every sprint, by identifiable people
- Moves visibly when the area improves
- Ranks work against other work
Measuring interest without buying anything
You can get a usable version of this from data you already hold, in about a week, without instrumenting anything new.
Pick a unit of area that matters in your codebase: a service, a module, a directory that maps to an owning team. For each one, over the last two quarters, pull three things.
Cost per change. Elapsed time from first commit to merge on changes touching that area, as a distribution rather than a mean. The tail is the interesting part.
Rework rate. How often a change to that area is followed by another change to the same area within a short window. This is the closest cheap proxy for “the first attempt did not hold”.
Failure contribution. Share of incidents in the period whose remediating change touched that area.
Then put those against change frequency, because frequency is what converts a rate into an amount.
High frequency, high cost per change
You are paying interest continuously and at scale. This is the only quadrant that reliably justifies dedicated remediation spend, and it is usually two or three areas, not twenty.
High frequency, low cost per change
Healthy. Whatever the code looks like, it is not costing you. Resist the aesthetic urge to improve it.
Low frequency, high cost per change
Quarantine rather than repay. Strengthen the boundary, document the entry points, and accept that each rare change is expensive. Rewriting it returns almost nothing.
Low frequency, low cost per change
Invisible to your economics. It may be objectively terrible code. Leave it alone.
Where agent output changes the arithmetic
This is the part that makes the local measurement urgent rather than merely tidy.
With around 41 percent of production code AI-generated by early 2026, the volume flowing into every area has gone up, and it has not gone up evenly. The interest rate in a given module can now change materially within a quarter, which was rarely true before.
The characteristic new cost is not bad code, it is unread code: work that functions, that nobody on the team has ever comprehended, sitting in a path that changes often. That shows up in cost per change and rework rate before it shows up in any static quality score, which is another reason to measure the local economics rather than buy an assessment of the principal.
Where this breaks down
Cost per change is contaminated. Elapsed time to merge reflects reviewer availability, holidays, deadline pressure and whether the author was on three other things. Attributing it to code quality is a leap. The mitigation is to compare areas within the same team over the same period, which controls for most of it, and to treat the number as a ranking signal rather than a measurement.
Some debt is genuinely catastrophic and low frequency. A rarely touched authentication path with no tests is not something to leave in a quadrant labelled quarantine. Risk-weighted areas need a separate assessment that has nothing to do with change economics, and my framework will underweight them every time. This is the strongest objection here.
Interest measurement is backward looking. It tells you what an area cost when the work you happened to do went through it. It says nothing about the area your roadmap is about to route six months of work through. Cross-reference against planned work or you will optimise for last year.
Global numbers do real work in a boardroom. I have argued they cannot support a decision, and I will concede they can open a conversation. Getting a board to accept that the category is real is a legitimate use of a large external figure. Just do not let the same slide carry the budget request.
And a platform desk arguing for measurement before spending is exactly what you would expect. Discount for that. The falsifiable version of my claim: ask any organisation currently running a remediation programme what their cost per change in the target area was before it started. If they cannot answer, the programme has no way to end successfully.
The takeaway
Sixty-one billion workdays tells you a market exists. It tells you nothing about where your money should go, and a case built on it cannot demonstrate a return, which is why those programmes get cancelled.
Measure interest, not principal. Cost per change, rework rate and failure contribution, per area, weighted by how often that area changes. Then act on the top two, quarantine the expensive-but-static, and deliberately ignore the rest.
If you take one thing into next week: rank your top ten areas by change frequency, then look at which of them have the worst rework rate. That short list is your actual debt, and it will not resemble the one your engineers would have written from memory.