Make AI-Written Pull Requests Cheap to Review: A Step-by-Step Guide

Not long ago, the slow part of shipping software was typing it. A coding agent has changed that. It can hand you a finished patch before the kettle boils, and then it does it again, and again. What it cannot do is read its own work with a stranger's eyes. So the patches pile up in front of the same few reviewers, and the line that used to form at the keyboard now forms at the pull request.

This note is about shrinking that line. It does not ask you to review less. It asks you to make each pull request cheaper to review: smaller, already checked, accompanied by its evidence, pre-read by a machine, and aimed at the right human. Six steps, each with a finish line and the configuration to back it.

The Queue Is the Cost

01 · Evidence · Faros AI · LinearB · 2025 to 2026

More pull requests arrive, and each one waits longer

Two large datasets describe the same shift. Faros AI looked at telemetry from more than 10,000 developers in mid-2025. Teams with high AI adoption merged 98% more pull requests, and the time spent reviewing them rose 91%. More output did not make review disappear. It made review the place where the extra output stopped.

LinearB's 2026 benchmarks cover more than 8.1 million pull requests from 4,800 teams, and they show what the stall looks like for agent-opened work. At the 75th percentile, an agent-opened pull request waited 17.6 hours before anyone picked it up, against 3.4 hours for one opened without AI. Review itself took 6.4 hours rather than 4.2. The change was bigger, at 408 lines against 157. And within 30 days, 84.4% of non-AI pull requests had been merged, compared with 32.7% of all AI pull requests.

The agent finishes in minutes. The pull request then waits in line for hours.Kintoro Labs, reading the LinearB figures

What Reviewers Can Actually Read

02 · Evidence · Cisco/SmartBear · Google · DORA · Anthropic

Small, and quick, has been the finding for twenty years

None of the remedies below is new. They are what the older research on human reviewers has always said, applied to a faster writer.

• Cisco and SmartBear, 2006. A study of 2,500 reviews recommended keeping a review under 200 lines, never over 400, and finishing it inside an hour. Defect detection falls away once a session passes 60 to 90 minutes.
• Google's guidance. A change of about 100 lines is usually a reasonable size; 1,000 lines is usually too large. Its 2018 study of 9 million reviewed changes found small changes drew first feedback in a median of under an hour, against around five hours for very large ones. Google also sets one business day as the longest a change should wait for review.
• DORA. Google's research programme finds that heavier AI use goes with higher throughput but less stable delivery. Speed in, wobble out, unless something in the middle holds.
• Anthropic's Code Review. An automated reviewer costs on average $15 to $25 per review. It is a research preview for Team and Enterprise plans, and it is not available where Zero Data Retention is in force.

Put the LinearB size figure beside the Cisco and Google ones and the problem is plain. The typical agent-opened pull request, at 408 lines, is already past the point where the research says a reviewer should stop.

The Path of One Pull Request

Here is the route one agent-written pull request should take from task to merge. Each of the six steps below puts a control at one point on this route, so that a person's attention arrives late, and arrives where it matters.

Step 1. Keep Each Change Small Enough to Read in One Sitting

Step 01 · Instruction file

Done when no pull request needs more than one sitting to read

Agents do not feel the cost of a large diff, so they will not hold back unless told to. Put the limit where the agent reads it before every task: the instruction file. The same text works in CLAUDE.md for Claude Code and in AGENTS.md for Codex. Aim for around 100 changed lines, treat 400 as the point at which you split, say how to split, and ask for an explanation when a change truly cannot be divided.

CLAUDE.md / AGENTS.md

The splitting order matters more than it looks. A pure refactor can be skimmed, a behaviour change must be read, and keeping them apart lets the reviewer give each the right kind of attention.

Step 2. Make the Agent Check Its Own Work Before It Hands Over

Step 02 · Stop hook

Done when a red test sends the agent back before a person ever sees it

The cheapest review comment is the one the agent never makes you write. A Stop hook runs a script at the moment the agent says it has finished. If the tests fail, the script exits with code 2, which sends the agent back to fix them. The stop_hook_active flag tells the script it has already pushed the agent back once, so it lets go the second time and the agent cannot loop forever. The script looks at two things: changes not yet committed, and commits not yet on main.

scripts/stop-check.sh

Each tool reads its own settings file. Claude Code takes the hook from .claude/settings.json. Codex takes it from .codex/hooks.json, uses a 300-second timeout, and asks you to trust the hook through /hooks before it will run.

Claude Code · .claude/settings.json

Codex · .codex/hooks.json

Step 3. Send Every Pull Request With Its Evidence

Step 03 · Pull request template

Done when a reviewer never has to ask how it was checked

A pull request that arrives as a diff alone forces the reviewer to reconstruct the story. A template turns that story into five short answers the agent fills in as it opens the request: what changes, why, how it was checked, what it does not do, and how risky it is. The fourth is the most useful. A stated boundary is a thing a reviewer can check.

.github/pull_request_template.md

Step 4. Let Machines Do the Repetitive Review

Step 04 · Review rules

Done when the first pass is posted before a person opens the request

A great deal of review is the same handful of questions asked again on every request. Hand those to an automated reviewer and give it written rules. Claude Code reads them from REVIEW.md; Codex reads a review section in AGENTS.md. Either way the rules cover the same ground: bugs, security problems, missing tests, and a clear instruction to escalate to a person when a change touches migrations, auth or billing paths.

REVIEW.md / the review section of AGENTS.md

An automated first pass is not an approval. It is a pre-read. The person who comes next starts with the obvious problems already named, and spends their attention on the ones a machine cannot judge.

Step 5. Spend Human Review Where the Risk Is

Step 05 · CODEOWNERS and branch rules

Done when risky paths cannot merge without the person who owns them

Not every line deserves the same scrutiny. A CODEOWNERS file names who must look when particular paths change, so the people with the most context are pulled in by the risky edits and left alone by the rest. Branch rules on main then make the routing binding: one approval, review from a code owner, and passing status checks before anything merges.

CODEOWNERS

Branch rules on main

• Require at least one approval.
• Require review from a Code Owner.
• Require status checks to pass before merging.

Step 6. Watch One Number Every Week

Step 06 · Measurement

Done when the gap between agent and human pull requests is on a dashboard

Pick one comparison and keep looking at it: how long agent-written pull requests wait and take to review, against human-written ones in the same repositories. The LinearB gap, 17.6 hours against 3.4, is the shape to avoid. You do not need the gap to close to zero. You need to notice it widening while it is still small enough to fix with a smaller template, a tighter rule or a better owner list.

Do not measure how much the agents wrote. Measure how long it waits.

The Playbook in Six Lines

1. Small. Around 100 lines, split past 400, written into the instruction file.
2. Self-checked. A Stop hook runs the tests and sends the agent back once.
3. Evidenced. A template carries what changed, why, how it was checked, what it does not do, and the risk.
4. Pre-read. Written review rules give every request a machine's first pass.
5. Routed. Code owners and branch rules put people on the risky paths.
6. Watched. One weekly number: the wait and review gap between agent and human pull requests.

Do these in order and each makes the next cheaper. A small request is easier to check, a checked request is easier to evidence, and an evidenced request is easier for both machine and person to read.

The agent writes the pull request. A person decides what merges.