Comprehension debt is the gap between how much code exists in your system and how much of it anyone still present genuinely understands. Not how much is documented, not how much passes its tests: how much a person on your current roster could explain, modify under pressure, and defend in an incident review at 2am.
Every codebase has some. A team that has been stable for a decade carries very little. A codebase where the founding engineers left, the AI assistants write most new change, and reviews approve in ninety seconds carries a lot, and carries it invisibly, because nothing on a standard dashboard measures it. Velocity looks fine. DORA metrics look fine. The code ships. The understanding quietly walks out the door or was never in anyone's head to begin with.
Technical debt is a property of the code: the shortcuts, the outdated patterns, the module everyone is afraid of. You can pay it down by rewriting.
Comprehension debt is a property of the relationship between the code and the people currently responsible for it. The code can be excellent and the debt can still be total. The cleanest module in your system, written by someone who left in 2023 and touched by nobody since, is fully paid up on technical debt and fully in arrears on comprehension. Rewriting it does not settle the debt; it only reassigns it, and if the rewrite is machine-generated it may not even do that.
That distinction matters because the two debts respond to different treatments and fail in different ways. Technical debt fails slowly and announces itself in friction. Comprehension debt fails suddenly: the outage nobody can diagnose, the security patch nobody dares apply, the acquisition diligence question nobody in the room can answer.
Three curves crossed. AI assistants write a growing share of new code, and hard evidence of that share shows up in co-author trailers and bot accounts in public git history. Review depth is thinning at the same time, because generated code arrives in volumes no reviewer reads line by line. And ordinary attrition has not slowed down to compensate: the humans who steered the generated code move on at the same rate they always did.
Each of those alone was survivable. Together they mean code enters the system understood by at most one person, reviewed by approximately nobody, and orphaned on a normal hiring cycle. The result is code that works, shipped by people who could not tell you why.
You cannot see comprehension debt by reading the code, and asking people produces polite overestimates. But it leaves tracks in the one record every repository keeps honestly: git metadata.
Work attributable to authors who no longer commit. Modules whose every line belongs to people past their last activity date. Change that carries machine co-authorship trailers. Heavy churn in files whose remaining human bench is one person deep. None of these requires reading a line of source; all of them are computable from history you already have.
That is what the Grasp Score measures: a single number for how much of a repository's recent work is held by someone still active, with the evidence published and the method open. You can run it on any public repository in about a minute, or see it across well-known projects on the Scoreboard.
Measurement first, because the instinct-based version of this conversation goes nowhere in a leadership meeting. Then the boring, effective things: review depth on generated change, deliberate knowledge transfer before departures instead of after, ownership maps that get checked against activity instead of against a wiki page from 2024, and a bias toward having the person who steered a piece of generated code write down what they asked for and why.
The debt is not a reason to stop using AI assistance. It is a reason to stop assuming that shipped means understood.
Related reading: The State of Comprehension Debt 2026, the 22-repository benchmark; the full methodology; live scores for well-known repositories.