Technical debt is a real loan, not a metaphor — and the interest is eating a third of your build budget

There is a sentence that costs businesses more than almost any other in software: "we will clean it up later." It sounds harmless — a reasonable trade to ship now and tidy afterward. But "later" is a loan, and like every loan it carries interest. The shortcut you take this month to hit a date is not free; it is principal you now owe, and you start paying the interest the very next time someone has to work around it. The trap is that the loan never appears on an invoice, so most operators never see it — until the day a feature that used to take a week somehow takes a month and nobody can say why.

The scale of that interest is not a hunch. Stripe's landmark study of developers found that engineers spend roughly a third of their time — over 17 hours a week — not building anything new but wrestling with maintenance and bad code, a misallocation Stripe valued at close to 300 billion dollars of lost output a year [1]. On the books it is just as heavy: CIOs put technical debt at 20 to 40 percent of the entire value of their technology estate [2], organisations now spend an average of around 30 percent of their IT budget servicing it [3], and Deloitte's latest leadership study pegs it at 21 to 40 percent of IT spending [4]. This is not an edge case for badly run shops. It is the median.

And in 2026 the interest rate is climbing, pushed up by the exact tool meant to speed everyone up. GitClear's analysis of 211 million changed lines of code found that in 2024, for the first time ever, copy-pasted code surpassed refactored code, while the share of lines being properly reworked collapsed from 25 percent in 2021 to under 10 percent [5]. AI assistants ship code that works, passes tests, and reads fine — and quietly duplicates instead of reusing. This piece is about treating debt as the financial decision it actually is: when to take the loan on purpose, when to refuse it, and why "we will clean it up later" is the second most expensive sentence in software, right after "we will figure out the scope as we go."

Start with what technical debt actually is, because the metaphor gets misused. The programmer Ward Cunningham coined it to describe something specific and not inherently bad: shipping code you know is not quite right, on purpose, to learn from real use faster — provided you go back and refactor as your understanding firms up. Debt taken deliberately and repaid on a schedule is a legitimate tool, the same way a business loan to seize an opportunity is. The problem is the other kind: accidental debt you did not know you were taking, and deliberate debt you promised to repay and never did. The first is a financing decision. The second is just a balance compounding in the dark.

Now the interest, in the currency you actually pay it in — your team's hours. Stripe's Developer Coefficient survey of over 1,000 developers and 1,000 executives found engineers spend more than 17 hours a week, around a third of their time, on maintenance issues like debugging and reworking bad code rather than building new things; scaled globally, Stripe put that misallocation at nearly 300 billion dollars of lost GDP a year ^[1]. That is the running interest payment. It comes out of payroll every single week whether or not anyone ever names it as a line item, which is exactly why it is so easy to ignore until the bill is enormous.

On the balance sheet it is just as large. McKinsey's survey of CIOs found they estimate technical debt at 20 to 40 percent of the value of their entire technology estate, and that 10 to 20 percent of the budget earmarked for new products quietly gets diverted to resolving debt instead — with 60 percent of those CIOs reporting the problem had grown over the prior three years ^[2]. Protiviti's global technology executive survey puts the share of the IT budget spent on tech debt at around 30 percent ^[3], and Deloitte's leadership study lands in the same band at 21 to 40 percent of IT spending ^[4]. Three independent surveys, one consistent answer: roughly a quarter to two-fifths of what you spend on technology is servicing the past, not building the future.

Here is why ignoring it is not a linear bet but a compounding one. A single shortcut, in isolation, is cheap — that is what makes it tempting. But every shortcut makes the next change a little harder: the workaround has to be worked around, the duplicated logic has to be updated in five places instead of one, the part nobody understands becomes the part nobody dares touch. The codebase entangles, and the cost of the next feature climbs — slowly at first, then steeply. Eventually a team hits a velocity wall, the point where shipping anything at all risks breaking something else, and the only options left on the table are a freeze or a full rewrite. The damage was never the original shortcut. It was the interest compounding silently for two years while everyone celebrated how fast the early version shipped.

And 2026 has a specific accelerant: AI-generated code. GitClear analysed 211 million changed lines and found that 2024 was the first year on record where copy-pasted ("cloned") code exceeded refactored ("moved") code, while refactoring as a share of changes fell from 25 percent in 2021 to under 10 percent, and cloned code rose from 8.3 to 12.3 percent ^[5]. AI assistants are extraordinary at producing code that works, passes the tests, and reads cleanly — but they lack architectural judgment, and left ungoverned they duplicate rather than reuse. The result is a genuine short-term velocity boost bought with long-term debt you cannot see in the demo. The fix is not to ban the tools; it is to keep a human owner who refactors what they generate, and an architecture the AI fills in rather than invents.

So what does an operator who cannot read the code actually do? You cannot see the debt, but you can see its symptoms, and they are unmistakable once you name them: features that used to take a week now take a month, every change seems to break two other things, and the team starts using the word "rewrite." The response is not heroics, it is policy. Fund refactoring as a fixed line in every build cycle rather than the thing that always loses to the next feature. Insist that shortcuts taken on purpose come with a written plan to repay them. And — the part that decides everything — build on an architecture you own, so that paying the debt down is a choice you can make on your own timeline, not a line item you wait for a vendor to prioritise on theirs.