Ward Cunningham’s “technical debt” metaphor turns 33 this year. It was a stroke of practical genius when he introduced it – a way to explain a complex, invisible technical problem to the people who controlled the budget. It worked so well that it spread across the entire industry. Which is roughly when metaphors become dangerous: when we stop noticing they’re metaphors at all.
This is the fourth post in a series on technical debt management. The first three covered what technical debt is, how to identify and quantify it, and how to address it in the development process. I promised posts on culture and business alignment and didn’t deliver them. Rather than pick up where I left off, I want to revisit the underlying frame – because I think the metaphor those posts would have been built on is starting to show its age.
Where the metaphor earned its keep
The financial framing accomplished something real. It moved technical debt out of engineering conversations and into business conversations. “We owe 18 months of rework” lands differently than “the code is messy.” It gave non-technical stakeholders a frame they could reason about, and it implied – correctly – that ignoring debt has compounding consequences.
That was valuable. It still is, as far as it goes.
Where it breaks down
A loan has a defined principal, a known interest rate, a creditor, and a repayment schedule. You can model it. You can budget for it. Technical debt has none of these things in any rigorous sense, which is why every attempt to precisely quantify it runs into the same wall: the numbers feel precise but the uncertainty underneath them is enormous.
The “interest” on technical debt is non-linear. Financial interest accrues smoothly and predictably. Technical debt compounds in unpredictable ways and can spike suddenly – one key developer leaves, one new requirement lands, and a manageable debt load becomes a crisis that wasn’t visible on any dashboard. The metaphor implies a smoothness that doesn’t reflect how technical debt actually behaves.
The debt is also often not a choice. Financial debt is something you take on deliberately. A lot of technical debt accumulates passively – through neglect, through staff turnover, through requirements that evolved faster than the system could follow. Calling it “debt” implies someone made a decision, which can make the conversation about blame rather than remediation.
And crucially, there is no creditor. Financial debt is owed to someone who can enforce repayment. Technical debt is owed to your future team, which makes it very easy to defer indefinitely. I’d argue the metaphor may have made this problem worse – implying a discipline of repayment that organizations rarely achieve in practice because the consequences of non-payment aren’t immediate or legible.
A more honest frame might be organizational entropy. Systems tend toward disorder unless energy is actively applied to maintain order. This doesn’t give you a balance sheet, but it’s accurate about the physics of the situation. You’re not managing a loan. You’re fighting entropy – and the moment you stop, entropy wins.
What AI does to this
The metaphor was built for a world where humans are the primary readers, writers, and maintainers of code. That assumption is being challenged by AI-assisted development – not eliminated, but challenged in ways that matter.
Some of what we’ve been treating as debt (code readability, inline documentation, certain categories of structural messiness) becomes cheaper to carry or cheaper to address when AI can reason about a gnarly codebase as fluently as a clean one. The “just rewrite it” option, which used to be politically radioactive, becomes more viable when the cost of generating clean code from a description of intended behaviour drops significantly. The calculus on some traditional debt categories is shifting.
But AI is also introducing new categories of obligation that the financial debt metaphor doesn’t begin to cover. Undocumented prompts that encode business logic with no version history. Dependencies on specific model versions with no deprecation plan. No systematic way to evaluate whether AI-generated output is actually correct – the equivalent of shipping code with no tests. These don’t look like financial debt. They look like something else, and the field hasn’t developed a mature vocabulary for them yet.
It’s too early to know exactly how this reshapes the technical debt landscape. But it’s not too early to notice that the old framework is being stress-tested at both ends: some traditional forms of debt become less costly, new forms emerge that the old framework can’t describe, and the financial metaphor – already imprecise – becomes increasingly inadequate as the primary mental model.
Where this leaves us
The metaphor did its job. It moved a technical problem into a business conversation, and that mattered. But you can’t manage what you can’t accurately describe, and the financial frame is no longer accurate enough.
Stop optimizing for a clean balance sheet. You’re fighting entropy. Plan accordingly.
This post closes out a series on technical debt started in 2023. The earlier posts – on definitions, quantification, and development process – are still available in the archive.
Monday Morning CTO 
Leave a comment