Review debt in the AI era cannot be repaid by reading more

General Published:

AI writes faster than anyone can read, and review debt accumulates. The case for repaying it by shrinking the unit, letting machines fail it, and constraining in advance.

Verified on Oct 16, 2026 These tools change quickly. Please also check the latest official documentation. How articles are researched and verified
Contents
  1. Headcount does not catch up
  2. One: shrink the unit you ship
  3. Two: let the machine fail it first
  4. Three: make it not happen
  5. Objections and limits
  6. Summary

Review debt cannot be repaid by reading more. It can only be repaid by shrinking the unit you ship, by letting machines fail what they can, or by making the risky thing impossible in the first place.

The first thing an AI coding tool breaks is the balance between writing and reading. Generation gets several times faster; the rate at which a person reads a diff and judges whether it is right does not. What piles up in that gap is review debt.

Everything below rests on the Claude Code documentation as fetched on 2026-10-16.

KEY POINT

What you will learn

  • Why adding reviewers does not close the gap
  • Three ways to repay the debt, and the mechanism behind each
  • When the argument fails

Headcount does not catch up

Start with the direction parallelism pushes. On agent teams the documentation says: "Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode." Tokens stand in for output volume: raise the parallelism and the pile grows faster than the number of people reviewing it.

Adding reviewers has its own ceiling. You can add readers; you cannot reduce the context each change requires. Readers who don't share that context add variance in judgment, not throughput.

What has to change is not the supply of reading but the demand for it.

One: shrink the unit you ship

Agree on direction before the diff gets large, rather than reading it afterwards. This is why the documentation recommends plan mode: "Claude explores the codebase and proposes an approach for your approval, preventing expensive re-work when the initial direction is wrong."

What the human reads there is an approach, not code. The reading shrinks by an order of magnitude, and so does what you throw away when it's wrong (Claude Code plan mode).

A second move: keep things out of the diff entirely. Exploration produces no code but fills your context. The docs put it plainly — "Delegate the exploration so only the findings come back" and "The subagent reads files in its own context window and reports a summary" (Create subagents in Claude Code).

Two: let the machine fail it first

Before a person reads, let the machine reject what it can — the review-stage version of the previous essay's point that only what can fail is a fixed point.

The tools now ship this idea themselves. The auto mode description reads: "In auto mode, a second model, the classifier, reviews actions instead of you." Instead of you. Part of review has already moved from humans to machines.

Hooks do the same job. In v2.1.295, command and HTTP hooks gained onFailure: "block": a hook that can't start, times out or exits unexpectedly now blocks rather than letting the action through. A broken check no longer waves things past, which is what makes a machine pass trustworthy before the human one (Run lint and format on save with Claude Code hooks).

Where nobody is watching, this layer is the review (Run Claude Code headless in CI).

Three: make it not happen

The third route removes the thing to review: an action that never ran needs no reviewing.

What does the work here is permissions, not requests to the model: "Permission rules are enforced by Claude Code, not by the model," and instructions in your prompt or CLAUDE.md shape "what Claude tries to do" but not "what Claude Code allows."

In practice, convert the comments you keep writing in review into deny or ask rules. "Never touch the production config" and "always stop before a push" are more reliable as one rule each than as a comment every time, and once written they leave the review queue (Design permissions in Claude Code's settings.json).

Objections and limits

Some mistakes no machine catches. Design soundness, a misread domain, a wrong specification — none of these fail a test, a hook or a classifier. The auto mode docs note that "Explicit ask rules still force a prompt", assuming a human stays in the loop by design. Machine review narrows what a person looks at; it does not replace them.

Shrinking each change hides the whole. The smaller the diff, the easier it is to miss that the design is drifting. That is why the first route is "agree the approach before splitting", not "split". Skip the agreement and the debt moves into the design.

You can only constrain known risks. A deny rule names a danger you already thought of. A new category gets caught in review the first time, always. Permission design fixes the output of review, not its input.

Some work doesn't carry this debt. Throwaway prototypes and scripts with no external effect — there, repaying review debt costs more than it returns.

Summary

  • Output scales with parallelism; the context each change needs does not, so more reviewers never catch up
  • Route one: agree the approach before the diff grows — plan mode's documented rationale
  • Route two: let machines fail it. The auto mode classifier reviews "instead of you"
  • Route three: constrain with permissions. An action that never ran is never reviewed
  • The limits: design errors fail nothing, small diffs hide drift, and you can only constrain known risks

FAQ

Can't we just add more reviewers?
Output does not scale with headcount, so you never catch up, and more reviewers means more variance in what gets flagged. What has to shrink is how much each review covers, and how much needs reviewing at all.
Doesn't machine review lower quality?
Machines can only take over what can fail. Design soundness and domain mistakes don't fail anything. Use them to narrow what a human looks at, not to replace the human.
Doesn't shrinking each change hide the overall design?
It does, and that is one of this argument's limits. Which is why the point is agreeing the approach before splitting, not splitting for its own sake.

Primary sources

This article was drafted by AI from official documentation and reviewed by the site operator before publishing. Found a mistake? Let us know via the contact page.