The Agent Writes Faster Than Anyone Can Read: Review Capacity Is the New Limit

If an agent now writes most of your code, the limit on how much software you ship is no longer typing speed. It is how many lines a human can read carefully in a day, and that number did not move. The practical response is not another tool: it is a hard ceiling on change size, a written rule about who approves what, and repository settings that enforce both without a conversation. DORA's 2025 research found that 90% of technology professionals use AI at work and that higher AI adoption correlates with more throughput and more delivery instability at the same time. That combination is what a review queue overflowing looks like from the outside.

What the research says, and what it does not

DORA's analysis of its 2025 State of AI-assisted Software Development report (opened July 25, 2026) sets out the tension directly: "higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability." Alongside that, over 80% of respondents believe AI has increased their productivity, while 30% of developers report little to no trust in the code AI generates. The qualitative material draws on 1,110 open-ended responses collected in Q3 2025 from a global professional sample.

One practitioner quote in that analysis states the mechanism better than any metric: "Reviewing [another's] code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed." DORA names small batch work as "a critical countermeasure to the risks of AI-assisted development."

Be careful about what this evidence supports. Instability correlating with adoption is not the same finding as "AI-generated code contains more bugs per line", and DORA does not claim the latter. A simpler reading fits the data: more change reaching production per week, in larger units, reviewed by the same people at the same reading speed. You would expect exactly this pattern from any process that accelerated authorship alone. Several widely shared figures about pull request size and review time come from vendor summaries we could not open at source, so they are absent here.

The queue arithmetic

This calculation is ours, and it is uncomfortable because it is so simple. Suppose one reviewer on your team has 90 minutes a day of genuine review attention, meaning reading with enough care to catch a wrong assumption rather than skimming for style. At a realistic careful-reading rate of about 200 lines an hour for unfamiliar logic, that is roughly 300 reviewed lines a day, 1,500 a week.

Now change one input. An agent-assisted developer produces 2,000 lines of proposed change a week instead of 600. Generation tripled; review capacity is fixed. The queue grows by 500 lines a week, every week. Three outcomes are available, and every team picks one whether or not they discuss it: the backlog grows until releases stall, reviews get shallower until approval means nothing, or the size of what gets proposed comes down. Only the third is a decision rather than a symptom.

The same arithmetic explains something teams find puzzling: adding a second reviewer buys less than expected, because review is not fully parallel. Two reviewers on the same 800-line change duplicate the reading and split the accountability. Two reviewers on eight 100-line changes genuinely double throughput. Batch size, not headcount, is the lever.

A size ceiling with a documented basis

Google publishes its internal guidance on this, and it predates the current argument by years, which makes it a useful neutral reference. From its engineering practices documentation (opened July 25, 2026): "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large." The document adds that file spread matters as much as line count, since a 200 line change in one file may be fine while the same 200 lines across 50 files "would usually be too large", and that a good change is "one self-contained change" that "makes a minimal change that addresses just one thing".

Two documented exceptions apply and both come up constantly with agents: deleting an entire file, and changes produced by an automated refactoring tool. A 3,000 line mechanical rename is not a 3,000 line review. A 3,000 line feature written by an agent in one pass absolutely is, and it should be split. Google lists four ways to split: stack changes sequentially, split by file group, split horizontally across stack layers, or split vertically by feature.

Turn that into a rule you can state in one sentence and enforce without arguing: changes over about 400 lines of hand-authored or agent-authored logic get split before review, and mechanical changes get labelled as such in the title so the reviewer knows to read the pattern rather than the lines. The number is yours to set. Having a number at all is the part that matters, because without one the default ceiling is whatever the agent produced in its last run.

The settings that make the rule stick

Written conventions decay. Repository rules do not. GitHub's ruleset documentation (opened July 25, 2026) lists the options that matter here, configurable by a repository admin or a custom role with the edit repository rules permission:

• Require a pull request before merging, with a required approvals count you set between 0 and 10. One is enough for most small teams; the value is the gate, not the number.
• Dismiss stale pull request approvals when new commits are pushed. This is the single most valuable switch in an agent-assisted workflow, where "just one more fix" after approval is a routine event and the approval silently keeps applying to code nobody read.
• Require approval of the most recent reviewable push, and require approval from someone other than the last person to push. Together these close the self-approval path.
• Require review from code owners, backed by a CODEOWNERS file. This is how you make sure the payments module is never reviewed by whoever was free.
• Require all comments on the pull request to be resolved before it can be merged. Cheap, and it stops the unanswered question in a thread from becoming a shipped assumption.
• Require status checks to pass, with the strict option requiring branches to be up to date before merging.
• Require linear history, forcing squash or rebase merges, which keeps the history readable enough that a rollback is a decision rather than an investigation.

Fifteen minutes of configuration. It converts a norm that erodes under deadline pressure into a mechanism that does not.

If you are the only reviewer

Most readers here run a one-person operation, where "require an approval" means requiring your own, which is theatre. A version that works solo:

1. Separate authoring from reviewing in time. Never review agent output in the same session that produced it. Merge tomorrow morning. The gap restores enough distance to read it as someone else's code, which is the entire mechanism you are missing.
2. Keep the size ceiling anyway. It exists for your reading capacity, not for a colleague's.
3. Turn on the automated gates you would otherwise delegate: required status checks, linear history, blocked force pushes, and the tightest linter and type checker your language offers. A machine reviewer that never gets tired is worth more to a solo maintainer than to a team.
4. Read the diff, not the summary. An agent's description of its own change is a claim about the change. The diff is the change. This is the same reason to check what your tooling actually sends and stores, which we covered in the piece on where your code goes.

A rule to keep

When code generation gets cheaper, the scarce resource becomes understanding, and understanding is bought in units of attention that no subscription increases. So spend the cheap thing to protect the expensive one: let the agent write the change three times if that produces three small reviewable pieces instead of one large opaque one. The same instinct sits behind choosing boring technology, where the point was never that new tools are bad but that a small team's comprehension budget is finite and should be spent on the product. Ship the change your reviewer, even if that is only you tomorrow morning, can actually hold in their head.