Comprehension Debt Is an On-Call Problem for Agent Code

Your agent’s 600-line PR passed CI and got an LGTM in four minutes. The first person who has to understand it is whoever gets paged when it breaks. That is the worst possible first reader. In Anthropic’s randomized trial of 52 mostly junior engineers learning a new library, the AI group averaged 50% on the quiz against 67% for hand coders. The largest gap was on debugging questions (Anthropic: AI assistance and coding skills¹). Comprehension debt usually gets framed as personal discipline. It works better as an on-call policy set before merge: one owner on the rotation, a split between what must be understood and what can stay regenerable, and two checkpoints that prove the understanding exists.

Comprehension Debt Comes Due at the Page

Author’s judgment. No source says comprehension debt is an on-call problem. The framing is my inference from four sourced premises: AI assistance opens its widest comprehension gap on debugging, knowledge gaps surface only during incidents, AI-generated code is reaching production before teams comprehend it, and supervising an agent takes the very skills that atrophy with heavy agent use.

The bill for code nobody understands arrives at the page, not at review. Whoever holds the pager pays it, whether or not they saw the change. Here is the shape of it in an illustrative composite, not a real incident:

payments: rewrite webhook retry and idempotency handling

author:   agent session, prompted by an engineer on the growth team
files:    internal/payments/webhook/handler.go
          internal/payments/webhook/retry.go
          internal/payments/webhook/parse.go
          internal/payments/webhook/handler_test.go
diff:     +612 -88
checks:   build ok | unit ok (214) | integration ok
review:   1 approval, "LGTM", 4 minutes after request
merged:   Friday 16:40

The following Tuesday the payment provider slows down and a timeout fires inside ProcessChargeEvent. The provider re-sends the webhook while the first attempt is still writing, and the new retry path applies the same charge twice. The engineer on payments on-call never saw #4812. They open handler.go to 600 lines nobody on the team can explain, including the growth engineer who prompted it. The 2am question is not whether the diff was correct but which of those lines decides whether a webhook counts as already applied.

Google’s SRE book describes this failure mode without any AI in it:

Being out of touch with production for long periods of time can lead to confidence issues, both in terms of overconfidence and underconfidence, while knowledge gaps are discovered only when an incident occurs.

Agent-written code manufactures exactly those gaps. The paper behind the Anthropic study reports an overall effect of Cohen’s d = 0.738 and labels its debugging breakdown exploratory and not pre-registered. Its authors warn that “humans may not possess the necessary skills to validate and debug AI-written code” (Shen and Tamkin: How AI Impacts Skill Formation³). Anthropic’s internal survey of 132 engineers and researchers calls this the paradox of supervision: “supervising Claude requires the very coding skills that may atrophy from AI overuse” (Anthropic: How AI is transforming work⁴). The incident-linked data is thinner and comes from a debugging vendor. An Undo-sponsored survey of 300 senior engineering leaders reports that 35% of AI-generated code reaches production before teams fully comprehend it. Of those respondents, 93% said an AI hallucination had led to a misdiagnosed root cause (LeadDev: AI code causes production outages⁵).

One population caveat, stated once: every controlled comprehension study cited here used novices or students. The only professional-population signal is Lee et al.’s CHI 2025 survey of 319 knowledge workers. It found that “higher confidence in GenAI is associated with less critical thinking” (Lee et al.: GenAI and critical thinking⁶), and that measures self-reported critical thinking, not code comprehension. Read the numbers as a direction, not an effect size for your team.

Practitioners already land on accountability. The Ask HN thread on shipping AI-written code you don’t understand drew 621 points and more than 760 comments (Hacker News: Ask HN⁷). One reply compresses the premise: “at the end you’re the owner/accountable so you need to justify your and your agent choices” (xinu2020 on Hacker News⁸). Without a named person and a check behind it, accountability is a slogan.

The policy question is therefore: who on the rotation can debug this change, and how will you know before the pager tells you?

Approvals and Green Tests Measure Neither

An approval click and a passing suite both record that the work finished. Neither records that a person can explain it, and the studies show the two come apart under AI assistance.

The Bad column is what most teams’ tooling counts as done. The tests cover only the inputs someone thought to write. Neither half shows that anyone could answer a question about the retry path the tests never asked.

Balepur et al. measured this directly in a lab study of students using a coding agent. Adding initial task accuracy to their comprehension model “barely improves adjusted R2 (0.40→0.42), so comprehension is distinct from task completion” (Balepur et al.: (Im)Paired Programming⁹). How participants reviewed mattered more than whether the task passed. Auto-accepters scored 0.615 on comprehension (n=6) against 0.777 for those who reviewed each file (n=7), and the authors treat all of it as exploratory. Qiao et al. found the same split with 15 CS graduate students in an unfamiliar brownfield codebase. On the first task, Copilot users passed 7.2 tests on average against 4.2 without it, with no corresponding gain in comprehension (p=0.59). The authors suggest that “task success does not reliably demonstrate comprehension” (Qiao et al.: Faster but Not Wiser¹⁰).

Approvals also degrade on their own. Anthropic’s containment team writes about tool-permission prompts, not code review, but the mechanism transfers. Their telemetry showed users approving roughly 93% of permission prompts, with attention to each one falling as approvals piled up (Anthropic Engineering: How we contain Claude¹¹). An agent that opens five PRs a day is a permission-prompt stream with a merge button attached. Shrivastava states the consequence plainly: “An approval with no comments on a four-hundred-line agent-written change is not evidence of understanding” (Shrivastava: Comprehension debt¹²).

Correctness is a separate question with its own checks, covered in how to evaluate AI coding agent output. A diff can be fully correct and still have no one behind it.

Split the Change Into Theory and Regenerable Code

Author’s judgment. The four-item list below is my synthesis. Its parts come from Naur’s theory of programs, Bacchelli and Bird’s survey of what reviewers need to learn, Google SRE’s playbook guidance, and Storey’s intent debt; no source names these four items as the set a human must hold.

Not every line of a 600-line diff deserves a human’s working memory, and pretending it does is how teams end up with the four-minute LGTM. The useful split runs between what you could not safely regenerate and what you could. Before merge, have the owner write down items 1 through 4 and mark the rest regenerable:

Naur argued in 1985 that a program’s real substance is the theory its programmers hold. Holding it means being able to “explain why each part of the program is what it is” and to respond “constructively to any demand for a modification of the program”. He was blunt about whether that theory survives on paper:

program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible.

Majors draws the same line from the regeneration side, and her test for understanding is regeneration itself: “The fact that we cannot regenerate our code in the same way is a sign that we do not understand it” (Charity Majors: AI demands more engineering discipline¹⁴). Items 1 through 4 are the part of #4812 you cannot regenerate safely. A regenerated retry loop that quietly drops the at-most-once invariant is a double charge, not a refactor. The split also follows the code’s natural seams. In Parnas’s preferred decomposition, each module is “characterized by its knowledge of a design decision which it hides from all others” (Parnas: On the Criteria for Decomposing Systems¹⁵, quoted via The Morning Paper¹⁶). The interface is the durable contract, and the body behind it is bounded, verifiable work an agent can redo.

Each item has a precedent. In Bacchelli and Bird’s survey, 798 of 873 programmers (91%) said reviewing unfamiliar files takes time because they need to “learn enough about the files being modified to understand their purpose, invariants, APIs, etc.” (Bacchelli and Bird: Modern Code Review¹⁷). The debug path comes from SRE practice. Google reports that recording best practices ahead of time in a playbook produces roughly a 3x improvement in MTTR over winging it (Google SRE: Introduction¹⁸). Its workbook warns that “Details in playbooks go out of date at the same rate as production environment changes” (Google SRE Workbook: On-Call¹⁹). That warning is why #4812’s debug path belongs in the PR that changes the handler, not in a wiki page nobody revisits. Storey calls the missing rationale intent debt: “the absence or erosion of explicit rationale, goals, and constraints” (Storey: Technical, Cognitive and Intent Debt²⁰).

Regenerable does not mean free. Böckeler tested spec-driven tools where “only the spec is edited by the human, the human never touches the code”. She saw non-determinism when she generated code multiple times from the same spec (Böckeler: Understanding Spec-Driven Development²¹). Regenerable means replaceable behind a contract a human holds, with the tests and the invariant checking every replacement. It does not mean the agent will write the same retry.go twice.

Dependencies You Don’t Understand Either

The strongest objection comes from the same Ask HN thread. An operations engineer writes that “a huge part of what I ship to production is not code I even understand”, leaning on testing, monitoring, and a staging soak instead. The comment concludes: “This might be why I’m fairly comfortable shipping AI generated code” (linsomniac on Hacker News²²). Nobody reads the kernel, the database, or the HTTP client before shipping on top of them.

That objection is the split, not a counterexample to it. A competent operator of a third-party dependency holds exactly items 1 and 4: what the dependency promises, and where to look when it misbehaves. They can skip its internals because someone upstream holds that theory and answers for it. The webhook handler has no upstream. If the payments rotation does not hold its contract and its debug path, nobody does.

Name the Owner Who Gets Paged

An author-of-record who is not on call does not own #4812; they are a name in git blame. The growth engineer who prompted the change will not be paged when duplicate charges show up on Tuesday. The payments rotation will, so the owner has to be someone on it who can explain and defend the change.

Ownership is one of the few quality levers a manager can set directly. In Bird et al.’s study of Windows Vista and Windows 7, “The number of minor contributors has a strong positive relationship with both pre- and post-release failures”, even after controlling for size, churn, and complexity. The authors call ownership “an aspect of software development that can be controlled and monitored to some degree by management” (Bird et al.: Don’t Touch My Code!²³). That is pre-AI, correlational data about human contributors. An agent session that touches a component once looks like the extreme case of a minor contributor, but that extension is mine, not theirs.

The Linux kernel already writes the defend requirement into policy for tool-generated changes:

You are expected to understand and to be able to defend everything you submit.

The next line is the enforcement: “If you are unable to do so, then do not submit the resulting changes.” At Google, code review was perceived as “ensuring that more than one person would be familiar with each piece of code” (Sadowski et al.: Modern Code Review at Google²⁵), a finding about Google’s review culture, not code review in general. The closest published version of this rule is Storey’s suggestion that teams “may wish to require that at least one human on the team fully understands each AI-generated change before it ships” (Storey: Cognitive debt²⁶). The change here is that the one human must be on the rotation that gets paged. The third and fourth table rows are two of her cognitive-debt signals. One is a low bus factor; the other is loss of transactive memory, where team members lose track of who knows what (Storey: Technical, Cognitive and Intent Debt²⁰).

Owner-hours are review capacity, and they run out. The review capacity math covers how many agent PRs one owner can absorb.

Gate the Merge on an Owner’s Explain-Back

Author’s judgment. No study tests explain-back in software code review. The practice is borrowed from clinical handoffs, and the case for it rests on the comprehension studies above plus that analogy.

The gate is the owner writing the four must-hold items back in their own words, in the PR, before merge. On #4812 it looks like this:

## Comprehension (owner writes this, in their own words)
Owner: Dana, payments on-call (primary next week)

### Contract
The provider re-sends any delivery we don't acknowledge with a 2xx, and it
reuses event.id. ProcessChargeEvent treats event.id as the idempotency key
and returns 200 for an event.id already applied, without re-applying it.

### Invariant
At most one charges_applied row per event.id. Enforced by the unique index
on charges_applied(event_id), not by the retry loop.

### Failure modes
1. Timeout after write, before ack: provider re-sends; the unique index
   rejects the second insert; we return 200.
2. Duplicate delivery in flight: two workers race; the loser hits the
   unique index and logs webhook_duplicate_event.
3. Partial write: charge row lands, processed-event marker does not; the
   retry attempts a re-apply and the unique index stops it.

### Debug path
Trace field: webhook.event_id. Log: webhook_retry_attempt (count > 3 is
abnormal). Kill switch: payments.webhook_retries_enabled=false stops our
internal retries. It does not stop the provider's re-sends.

In the composite, the invariant prompt catches the Tuesday incident before it happens. The agent’s rewrite checked for an existing event.id in application code and then inserted, which races under duplicate delivery. Dana could not honestly fill in the “enforced by” clause until the unique index went in. The tests were green either way; the explain-back was the first artifact that asked the question.

The clinical analogy is real but needs its caveat. Across 10,740 admissions in nine hospitals, the I-PASS handoff program was associated with a 23% drop in the medical-error rate and a 30% drop in preventable adverse events (Starmer et al.: I-PASS handoff program²⁷). Its mnemonic ends in “Synthesis by Receiver”, which “closes the communication loop in the final step to achieve shared understanding” (Ait Aiss et al.: I-PASS nursing handoffs²⁸). Those numbers belong to the whole bundle, not the receiver step alone. The software studies point the same way. Qiao’s high-comprehension participants moved from writing code to viewing it 10.8 times on average against 2.3 for the low group (Qiao et al.: Faster but Not Wiser¹⁰). Writing the answers down forces that kind of engagement.

Quiz tools are useful practice for this, and they say so themselves. Sphinx has a reviewer that “never saw your chat” read the diff and ask “what the change does when things go wrong” (Sphinx²⁹). Its README is plain about the limit:

This is practice, not a security gate.

vibecheck goes further and posts a commit status so “the PR cannot merge until the author passes”, but wrong answers can be retried, after which it reveals the answer (vibecheck.dev³¹). Explyt’s proposed quiz gate, the closest published version of this idea, has the author explain the change before accepting the diff, scaled by risk (Explyt: Comprehension debt quiz gate³²). The difference here is who answers and where the answer goes. The person who will be paged writes the explain-back, and it becomes the script the post-merge drill runs against.

Scale the gate by blast radius instead of applying it to every diff. #4812 touches money and gets the full block; a copy change to an email template gets none. The permission tiers for agent changes are the sorting key.

Prove Ownership After Merge With a Drill

Author’s judgment. Wheel of Misfortune exercises and game days are established SRE practice. Running them specifically on agent-written paths, with the agent unavailable, as a test of ownership is my extension.

Explain-back proves the owner understood #4812 on the day it merged. It does not prove she still does three weeks later, after two more agent sessions have touched retry.go. Naur names the moment the gap shows: “The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered” (Peter Naur: Programming as Theory Building¹³). The drill makes that demand on purpose, on a schedule, before production does.

Target:       PR #4812, internal/payments/webhook (agent-written path)
When:         3 weeks after merge, then once a quarter
Players:      primary = Dana (owner); secondary = next payments on-call
Game master:  payments tech lead
Rules:        no agent, no chat assistant; PR #4812 comprehension block allowed

Scenario:     Provider latency spikes. The same webhook arrives twice,
              1.8s apart, while the first attempt is still writing.
              Page: "charge_amount_mismatch: 14 accounts"

Must find:    1. webhook.event_id on the trace for one affected account
              2. whether charges_applied holds one row or two for it
              3. the flag that stops internal retries, and what it does not stop

Scoring:      each item not found unaided = backlog ticket labelled
              comprehension-debt, assigned to the owner, due before next drill

The third item is the one built to fail. payments.webhook_retries_enabled stops our retries but not the provider’s re-sends. An owner who remembers only the flag name will tell incident command the bleeding has stopped when it has not. A half-working kill switch is a footgun, and a drill is the cheapest place to learn that the owner’s theory of it has decayed.

The format is borrowed, not invented. Google’s SRE book describes a game master who “has carefully prepared a scenario that is about to unfold” and picks the primary and secondary on-call. It insists that “Realism is paramount in these interactions”, because learning “should happen before a new SRE reaches that point” of a first real page (Google SRE: Accelerating SREs to On-Call³³). AWS tells teams to “Involve the same teams who would be responsible for handling production scenarios”, which is the owner rule applied to the exercise. Its reliability pillar states the payoff:

When you practice your response procedures in realistic conditions, you can identify and address any gaps or weaknesses before a real event occurs.

Taking the agent away is not anti-AI. At 2am the agent may well help, but its context window holds none of the incident until someone pastes it in. The drill measures what the owner can do when the agent’s explanation is wrong or missing. One Anthropic engineer already runs a personal version: “Every once in a while, even if I know that Claude can nail a problem, I will not ask it to. It helps me keep myself sharp” (Anthropic: How AI is transforming work⁴). The drill is that habit on a team calendar. A quarterly cadence matches Google’s guidance that each engineer be on call “at least once or twice a quarter” (Google SRE: Being On-Call²). Drill the largest blast radius first: the charge path well before the email template.

The Comprehension Policy on One Page

Run the policy as one table per agent-written change. Each row is a checkpoint from the sections above, with the evidence it accepts, what #4812 looks like there, and what skipping it costs.

The PR block, a checker that fails an unowned or unfilled one, and the drill card with its backlog rule are in comprehension-gate³⁵; copy the template, label your agent PRs, and make the check required.