Technical Debt Isn't What You Think It Is — And You're Measuring It Wrong

Ward Cunningham coined the phrase "technical debt" in 1992, and in the 32 years since, it has become one of the most widely cited and least understood concepts in software engineering. Almost every team has a backlog of "tech debt tickets." Almost none of them have a clear model of what the debt is actually costing them or whether the cost is growing or shrinking over time.

The problem starts with the metaphor itself. Financial debt is a fixed liability — you owe a specific amount, the interest is a known rate, and if you make regular payments the principal decreases. Technical debt is none of these things.

The Compound Interest Model

Technical debt is better understood as a compounding drag on the velocity and reliability of every future decision made in its vicinity. A poorly designed authentication module doesn't just cost time to fix — it costs time on every subsequent feature that touches authentication, every security review that has to account for its quirks, every new engineer who has to understand its non-obvious behaviors before they can work effectively near it.

This compounding nature means that the true cost of technical debt grows geometrically with codebase size, team growth, and feature velocity — not linearly. A startup with three engineers can carry significant technical debt and barely feel it. The same codebase with 30 engineers and 10× the feature surface area will feel the same debt as a systemic drag on everything.

The Metrics That Actually Matter

Most teams track technical debt through some version of "hours estimated to fix known issues." This is the wrong unit. It measures the stock of debt, not its rate of compounding. The metrics that actually predict whether technical debt is under control are:

Change failure rate. What percentage of changes to a given area of the codebase require a follow-up fix within 48 hours? High change failure rate in a specific module is a leading indicator that the module has accumulated enough complexity to make reliable changes difficult.

Code churn rate by module. Files that are frequently edited and frequently the source of bugs are where your debt is actively compounding. Files that are edited rarely and reliably are healthy, regardless of their internal complexity. Targeting debt paydown by "ugliness" rather than by churn rate misallocates cleanup effort.

Review time per line changed. If reviewing changes to Module A takes 3× longer per line than reviewing changes to Module B, Module A has a cognitive complexity tax embedded in it. That tax is paid on every future change. It's debt that shows up in engineering time before it shows up in production incidents.

How AI Review Makes Debt Visible

One of the underappreciated benefits of consistent automated code review is that it generates a longitudinal dataset of where issues cluster. After three months of automated review, patterns emerge that are invisible to any individual reviewer: the same file appears repeatedly in issue reports, specific functions generate disproportionate review comments, certain authors' changes to certain modules reliably surface more problems than their changes elsewhere.

These patterns are your debt map. The areas that generate the most review friction are the areas where complexity has compounded beyond what the codebase can absorb cleanly. Addressing these areas first — rather than the areas that feel messy but rarely cause problems — is where debt paydown generates the highest return.

The 20% Investment That Compounds the Other Way

The teams that successfully manage technical debt long-term share a common practice: a standing allocation of 15-20% of engineering capacity to debt reduction, treated as non-negotiable infrastructure investment rather than as optional cleanup that gets cut when sprints fill up.

This sounds obvious. It's almost universally ignored in practice, because product pressure is concrete and immediate while debt compounding is abstract and deferred. The teams that maintain the allocation do so because they have internal metrics that make the compounding visible — change failure rates, review time trends, incident recurrence by module — that convert the abstract debt concept into concrete engineering cost. You can't protect budget for something you can't measure. Measure the right things and the budget case makes itself.