Most teams talk about technical debt as if it lives in the code. It does, partly. The duplicated logic, the function that takes nine arguments, the module that should have been three modules. A linter can find that. A staff engineer can name it on a whiteboard. But the more expensive half of technical debt does not live in the repository. It lives in what the system does at runtime. And that part is much harder to see.

Code debt is what you wrote. Runtime debt is what your system kept doing after you stopped paying attention.

The debt static analysis cannot find

Open any large production system and you will find a second layer of debt that no scanner catches.

A service that fans out to four downstream calls when it really only needs one, because someone added a "temporary" enrichment in 2021. An API that still receives traffic from a single internal client that nobody can identify. A queue with two consumers, where one of them silently fails every message and the other quietly handles it. A config flag that is read on every request and has had the same value for three years.

None of this looks wrong in the code. Each piece, in isolation, is reasonable. The debt is in the behaviour — in what the system actually does versus what it needs to do.

Why it stays invisible

Static views show structure. Runtime debt is about flow, frequency, and dependency.

You can read every line of a service and not know which of its endpoints carry real traffic. You can read every config file and not know which keys are actually consulted. You can read every dependency declaration and not know which libraries are loaded but never executed in any production code path.

Architects sense this. They feel that the system is heavier than it should be. They cannot point at the cause because the cause is not in any one file. It is spread across thousands of small runtime decisions that no one has audited in years.

So the debt accumulates, unmeasured, and the team's confidence in the system slowly drains.

The shift

The fix is not another static audit. It is treating runtime behaviour as a first-class input to engineering decisions.

• Which endpoints have not been called in ninety days.
• Which dependencies show up in the dependency tree but never appear in a real call stack.
• Which async flows fire on every request even though the result is discarded. Which configs are loaded but unread.

This is the kind of debt that production exposes for free, if you are looking. CodeKarma's broader thesis is that this signal — what the system actually does — is the most reliable input architects and leaders have for prioritizing what to clean up next.

You cannot pay down debt you cannot see.

The teams that move fastest in the next decade will not be the ones with the cleanest code. They will be the ones who know which parts of their system are still earning their keep.