A five-item dispatch wave came back green. Every item merged, every gate passed, every acceptance criterion checked off. The feature was broken end to end.
No single item owned the seam between two of them. Each build agent had done exactly what its spec said, and the capability that lived between two specs belonged to nobody. Per-item review couldn't catch it — every reviewer was scoped to one item, and the gap was in the space between items. I found it by running an adversarial review workflow against the intent of the whole feature instead of the acceptance criteria of its parts. It came back does-not-meet, with two ship-blocking gaps that a hundred percent of the unit tests were happy to sit on top of.
Nothing at the diff level could have found that. The catch required holding the shape of the feature in mind — what it was supposed to do, end to end, for a user — and asking whether the landed code did that. Decomposition manufactures those gaps. Understanding at the level where the feature actually lives is the only thing that closes them.
That's the argument: you cannot steer an agent to build the right thing if you don't understand the system. What has changed — fast, and it's still changing — is the altitude at which that understanding has to live.
The debt already has a name
I'd been calling this understanding debt in my own notes before I went looking. The idea is well-trodden. Addy Osmani calls it comprehension debt: "the growing gap between the code your team has shipped and the code your team actually understands." Lars Janssen calls the same shape verification debt. SRLabs calls the throughput half of it the verification bottleneck and points out that it's human-limited by construction.
Osmani's framing resonates, because it's the distinction that makes the debt metaphor earn its keep: technical debt lives in the codebase, comprehension debt lives in the people. You can pay down technical debt with a refactor you delegate to an agent overnight. The other kind you pay down inside your own head, on your own clock, and there is nothing to dispatch it to.
Where I part company with the existing accounts is the remedy. The pieces I read converge on understand more of the code — read the diffs, audit the output, maintain your mental model. That advice doesn't survive contact with agent speed. Osmani gets at the arithmetic himself: a junior engineer can now generate code faster than a senior engineer can critically audit it. If the prescription is to close that gap by reading harder, the prescription is already lost.
The altitude keeps climbing
Last year I still had to understand the systems I was building at the level of interfaces, classes, and functions. Not usually the individual line — I wasn't hunting for off-by-ones — but I had to know what a class was for and what a function was supposed to return, because that's where the model's mistakes lived. Correcting the agent meant being able to say: that method has the wrong responsibility, that interface leaks its internals, that logic belongs on the other side of the boundary.
I don't do that anymore. I steer at architecture and business intent. Is this the right decomposition? Does this system boundary belong here? Is that what the user actually needs, or only what the ticket said? The models got good enough to own the level below me, so I moved up a floor.
The altitude has been climbing roughly a level a year. That's the part the debt conversation misses. Understanding didn't become less necessary — it relocated. Reading every line is now the wrong response, because it spends your scarcest resource at an altitude the agent already covers. The right response is to climb to the altitude where your understanding still binds the system, and be rigorous there.
Altitude is not the same as distance. A leader who can't read a system design and say what's wrong with it isn't steering from a high altitude; they've just stopped steering. I wrote about that gap in The Player-Coach Decade — the leaders getting multiplicative returns from these tools are the ones who never let their technical judgment atrophy. The altitude moves. The rigor doesn't get to.
Two different bills
The debt shows up as two costs. Separate them, because they have different fixes.
Understanding debt costs you steering. When an agent goes wrong, you correct it by knowing what right looks like at the level it went wrong. If your understanding sits below the level of the error, you'll fix the symptom and ship the same defect somewhere else. If it sits nowhere at all, you won't notice. That five-item wave is the clean case: everything was correct one level down, and wrong one level up, and the only instrument that could see it was a model of what the feature was supposed to do. This is a comprehension problem, and no amount of process fixes it.
Verification debt costs you throughput. This one is arithmetic, and the numbers are ugly. LinearB's 2026 benchmarks have developers using AI completing 21% more tasks and merging 98% more pull requests — with PR review time up 91%, and AI-generated PRs waiting 4.6x longer before a reviewer even picks them up. Sonar's survey found 96% of developers don't fully trust AI-generated code to be functionally correct, and only 48% always check it before committing. That's a queue, and the queue is made of humans.
Collapsing these two into "review is the bottleneck" is what leads teams to buy another review tool. The steering problem is not a queueing problem, and you cannot throw reviewers at the fact that nobody in the room understands the system.
Human review doesn't scale
Say the harder part out loud, because very few people will yet: human review is not the answer to the throughput bill either. Reviewers don't get faster, and adding more of them has never once closed the gap. If you're willing to move at the speed of human review, you've decided to leave the upside of every model release on the table. In a competitive market that's a choice with a price tag, and the price goes up each time the models improve.
What replaces review is automated evaluation — systems you build to prove to yourself that the software does what it claims. Your understanding of the system is what lets you steer an agent to build that eval. The argument closes on itself.
I built a photo uploader recently with optional privacy settings that strip location metadata before images go out to social media: always-strip, plus strip-by-geofence. That is a bad thing to get wrong. Nobody wants to find out the geofence leaked their home address after the post is public.
I never read that code line by line. I fed the agent real images from different cameras carrying different kinds of embedded location data, exported through different photo management tools — including the IPTC City / State / Country fields that Adobe Lightroom helpfully stuffs into the file where nobody thinks to look. Then I steered it to build integration tests that block promotion if any code path touching location privacy does the wrong thing.
Every judgment in that paragraph is an altitude judgment. Knowing that EXIF isn't the only place a coordinate hides. Knowing that "strip location" has to mean every code path, including the ones the ticket never mentioned. Knowing which failure is unacceptable rather than merely annoying. The agent wrote the tests, and it wrote them well. I could not have told it what to test without understanding the system and the desired behavior at the right altitude.
Critical thinking is the root
Anthropic published a randomized controlled trial in January: 52 junior engineers learning a Python library they hadn't used before. The group with AI access averaged 50% on the follow-up comprehension quiz. The hand-coding group averaged 67%. Roughly two letter grades. Debugging showed the steepest decline — which is precisely the skill you need in order to catch what the agent got wrong.
The finding underneath that headline is the one that matters. The gap tracked how the tool was used. Participants who used the model for delegation scored below 40%. Participants who used it for explanation and conceptual inquiry scored above 65% — the authors concluded that explanatory use "might not hinder, and could potentially aid" performance. Same tool. Same task. The difference was whether a person was thinking while it ran.
That matches my own experience, which is why I trust it. My learning has accelerated since I became a heavy AI user, and so has my thinking — but only because I'm deliberate about it. I treat these tools as a learning instrument that also happens to make me fast. Intent is the whole variable.
That's the mechanism. The debt accrues at the moment you stop having an opinion. Accepting a diff is delegation. Asking the agent why it chose that boundary, and having a view on the answer, is inquiry. Only one of those builds the model in your head that you'll need three weeks later, when the wave comes back green and broken.
What this looks like in practice
Make the agent argue before it builds. I groom complex work through a draft-critic-synthesize workflow rather than a single planning pass. The critics catch things CI structurally cannot — in one case, that a nudge had to be a fresh message rather than an appended one, where getting it wrong would have left a green test suite over a dead feature. The output is a better spec, and the byproduct is that I've been forced to have an opinion about every load-bearing decision before a line exists. Give the planner an adversary.
Interrogate, don't just accept. When an agent hands back a design, ask what it considered and rejected, and why. That answer is where your mental model gets refreshed for free, and it separates the 40% from the 65% in that study. "Looks good" costs you nothing today and quite a lot later.
Put the gates in before the code. Every repo I dispatch into gets its quality scaffold committed first, so the agents can run wild safely — mechanical verification they cannot fake, enforced at commit and at push. Simon Willison's framing is the one to hold onto here: a computer can never be held accountable, so that's your job. Automating the proof doesn't move the accountability anywhere. It stops you paying for it by hand. I've written about the harness as a stack and about investing in the flywheel — this is that argument pointed at comprehension.
Review against intent, not against acceptance criteria. Acceptance criteria are per-item by construction, which means they're blind to the seams between items. Somebody — or something — has to check the feature against what it was supposed to do. That check has to run at feature altitude or it isn't the check.
The part you can't dispatch
Every failure I care about in agentic work is a context failure or an orchestration failure, and both are fixable by building better machinery around a model whose capability was never the problem. Understanding debt sits upstream of both. You can't hand an agent context you don't have; the metadata field you've never heard of is the one that never makes it into the spec. You can't carve a system into clean items if you don't understand it at the altitude the seams live at, which is how five green items add up to a broken feature. And when either failure lands, it arrives as a confident, plausible answer that only your own understanding would flag. Understanding debt generates the failures and disables the detector in the same move.
You can engineer the model's context layer. There's nowhere to dispatch your own.
You can build a factory that catches seam gaps, forces handoffs, and verifies its own claims — I have, and it works. What the factory can't do is hold the model of the system that tells you the factory is building the right thing.
That model only exists in one place, and it decays if you stop feeding it.