Stop Reviewing Every Pull Request

At a client, engineering throughput rose as AI-assisted development increased. Time in code review rose with it.

Engineers found themselves reviewing broader changes that touched more files than they expected. Producing the implementation took less time. Reconstructing its context, checking its assumptions, and deciding whether to accept it did not.

That pressure came from engineers working with AI. Autonomous coding agents raise the stakes. They can take issues from a queue, work asynchronously, and return pull requests continuously, with several running in parallel. A contributor that can be copied does not fit behind a review queue that cannot.

That is the constraint AI exposes. When producing code becomes cheap, a uniform human-review queue limits how much useful change the organisation can absorb.

Stop applying the same human inspection to every pull request. Do not stop exercising ownership or judgement. Require an accountable owner, make known standards executable, and route human attention to the decisions and risks that deserve it.

The review pressure is observed. The routing model below is the response I would test next, not a completed multi-repository rollout I can claim as proof. A 2026 longitudinal study of 802 developers and more than 196,000 pull requests (opens in a new tab) shows why it is worth testing. Per-engineer merge throughput roughly doubled at one AI-forward company. Per-reviewer load also roughly doubled, automated review overtook human review, and the gains concentrated in newer code, while coarse merge and revert rates remained roughly steady. It is one unusually favourable company and AI adoption was not randomised, so it shows what can happen, not what every team should expect.

You are reviewing the wrong question

Most organisations still use one control for almost every code change: another engineer must approve it. A copy change, a patch dependency update, a new authentication flow, and a destructive data migration enter roughly the same queue.

But there are two different questions hiding inside code review.

Is this implementation locally sound? Does it compile? Do tests pass? Does it violate a dependency rule? Does it use an approved interface? Did the author include the telemetry required for this kind of change? Does it follow the owning team's established conventions?

Is this the right change to the system? Does this behaviour belong here? Which domain assumptions and business invariants must hold? What happens across service boundaries? Is the operational risk acceptable? Who will maintain the result? Should the organisation accept this obligation at all?

The useful boundary is observable: can correctness be established from the change, repository, tests, and encoded rules, or does it depend on decisions and invariants elsewhere?

A decade before coding agents, research by Alberto Bacchelli and Christian Bird (opens in a new tab) found that defect comments were a minority of modern code-review comments and mostly concerned small, local issues. They argued that automating low-level work could free people to look for deeper problems.

A process that repeatedly asks senior engineers to enforce known rules by hand wastes their judgement. Turn recurring comments into formatters, dependency rules, contract checks, security controls, tests, and policy. Use AI to interpret explicit standards and find omissions where it helps. Do not give it authority merely because it can produce a confident comment.

Do not spend human judgement on questions you could have turned into a rule.

Route review by risk, not authorship

Risk routing starts after one gate: production-affecting code needs a managed repository and an accepted owner. Ownership is agreed before implementation, not transferred by authorship or a pull-request approval. If those foundations are missing, fix them first. AI Won't Fix Your Org Chart explains why.

The owner can pre-authorise a narrow class through repository policy: permitted paths, required checks, contribution conditions, and a credible recovery path. The same policy can admit a human contribution or an agent run because the class was reviewed in advance. The owner remains accountable, the contributor must understand what they submit, and the AI tool owns nothing. For the wider operating model behind agent accountability and measurement, see If You Want ROI From AI Agents, Organise Them Like People.

Then choose the review path using two questions:

1. Is it local or cross-cutting? Can you establish correctness inside the component, or does it depend on contracts, consumers, data, and invariants elsewhere?
2. Is it easy or hard to reverse? Can you disable and correct it quickly, or will it move data, money, permissions, or an external contract?

Two runs of the same model are not two independent opinions. Where policy or regulation requires independent authorisation, a second agent does not satisfy it.

This is a reallocation, not a promise that total review effort always falls. The highest-risk path deliberately spends more senior time before implementation and still verifies the pull request afterwards. It should recover that capacity from routine work. If it does not, the model has moved the queue rather than fixed it.

The minimum tier cannot be a feeling the contributor selects from a dropdown. Use repository paths, dependency and service metadata, API and schema changes, data classification, sensitive-system calls, and change breadth to set an automated floor. Uncertainty raises the tier. Contributors and owners may escalate, but lowering the floor requires a separately reviewed policy change or a logged emergency route.

This extends Ship/Show/Ask (opens in a new tab) rather than replacing it. Teams still need language for changes that can ship, need visibility, or require discussion. The addition is an enforceable minimum route, because contributors and agents cannot price risks they do not know exist.

The important review happens before the code

A pull request is a poor place to discover that the design is wrong.

By that point, the author has committed to an approach. Tests support it. The diff looks finished. Rejecting the direction means throwing work away, so reviewers narrow their comments to changes that fit inside the existing solution.

The intent note should fit on one page. It records the problem, owners, affected systems, invariants, rejected options, risks, rollout, and recovery. Clear work may be challenged asynchronously. Ambiguous work usually benefits from thirty focused minutes with the relevant owners while direction is still cheap to change. AI can trace consumers or test a hypothesis while people challenge the system decision.

Human involvement remains in the highest path. An independent reviewer verifies that the implementation respects the agreed interfaces, invariants, rollout, and recovery plan. That pre-code decision is what lets an agent implement quickly without asking anybody to trust generated code blindly.

Make the standards executable

A style guide is not enough. Naming and formatting are easy to automate and rarely the consequential part. The valuable context is harder:

• Ownership and contribution rules: who operates each production surface, which changes are accepted, and when another owner must be involved.
• Architecture boundaries: which dependencies are allowed, which APIs are sensitive or expensive, and which interfaces must remain stable.
• Tests and invariants: what must always hold for permissions, state transitions, data handling, contract compatibility, and failure handling.
• Operational controls: which telemetry must exist, how the change is bounded, and how it can be disabled, reverted, rolled back, or rolled forward.

Encode those expectations in concrete places: CODEOWNERS, CONTRIBUTING files, protected branches, service catalogues, dependency rules, API and schema checks, policy-as-code, CI gates, and deployment controls. Repository instructions can give humans and agents the same context. Deterministic controls should enforce the rules that must always hold.

That is real platform work. Many teams do not have trustworthy ownership metadata, dependency maps, or CI rules strong enough to authorise a merge. Do not replace those missing controls with a risk dropdown. Start with repository paths, tests, and one known owner for one narrow class. Add richer signals only when the simpler controls stop being enough.

Automate the recurring checks and consequential invariants for that class. Add rules when the same review comment returns, a dependency changes, a defect escapes, ownership moves, or a control produces too much noise. Owning teams approve changes to their policies.

What this buys when agents work in parallel

The ceiling on agent-assisted delivery is not how fast code can be generated. It is how much change the organisation can accept without increasing rework, incidents, or human review cost.

Risk routing raises that ceiling. Tasks are classified before work starts. Agents implement in isolated environments and return small pull requests. Deterministic checks decide whether a change stays in the autonomous lane, needs focused human judgement, or should never have reached implementation without an intent decision. A merge queue controls integration, while production feedback and escape analysis improve the policy.

The lane still needs limits. One task per pull request. A cap on concurrent changes. Duplicate detection when several agents touch the same area. Size limits that reject sprawling diffs before they consume reviewer attention. Without those controls, parallel generation becomes review debt: the same queue, with a machine feeding it faster.

Do not confuse test-passing with merge-ready. In a 2026 METR review of 296 agent pull requests (opens in a new tab), roughly half of the changes that passed SWE-bench Verified would not have been merged by the maintainers in the study. The agents did not get to iterate on feedback, so this is a warning against reading benchmark scores as production readiness, not a hard capability ceiling. Autonomous throughput is accepted, deployed change with bounded human attention, not pull requests opened.

Where this model fails

Do not open an automated lane when tests are weak, ownership is disputed, production feedback is poor, or nobody can demonstrate a fast recovery. In that environment, the model cannot establish that a change is local and reversible. Human inspection may still be an imperfect control, but removing it would be wishful thinking.

Routing rules can also be gamed or allowed to decay. A change can avoid a protected path while altering a dependency elsewhere. Parallel agents can duplicate work, flood a repository, produce oversized diffs, weaken tests to make them pass, or introduce an unapproved package. Emergency routes can become routine. Teams can classify everything as high risk until the new process recreates the old queue. Sample automated merges, review escapes, and treat repeated uncertainty as evidence that the policy or architecture is not ready.

Removing routine inspection also removes one channel for knowledge transfer. Replace it deliberately with visibility for routine changes, heavier sampling while a lane is new, pairing and intent review on consequential work, and coaching for less-experienced engineers. AI review can help apply explicit context, but it is not an independent guarantee and should not become a substitute for those learning paths.

Start with one repository

Do not announce an AI code-review transformation. Choose one repository with clear ownership, useful tests, production feedback, and a credible recovery path.

Examine enough recent changes to see the pattern. Which comments restated known rules? Where did work wait? Which simple-looking changes crossed a boundary? Establish a baseline for waiting time, active review effort, corrections, incidents, and ownership gaps.

Choose one bounded class that consumes real review time. Internal UI copy and presentation changes may work when impact is limited and controls are strong. Encode the missing checks, then replay the policy against historical changes or run it in shadow mode. Look for false negatives before granting merge authority.

Run the experiment long enough to observe meaningful change volume and failure signals for that repository. Success is less waiting and less active human review for the selected class without a material increase in incident impact, correction cost, or ownership ambiguity. Sample heavily at first, then adjust based on what escapes and what the controls get wrong. The broader measurement principle is the same as for any agent initiative: measure constraint relief, not activity.

When a defect escapes, ask whether the tier was wrong, a useful rule was missing, or the failure was cheap enough to accept. Improve the control proportionately. Do not let one minor escape drag every change back into the same queue.

Use the recovered time on work that needs judgement: challenge risky intent, improve architecture and reliability, coach engineers, and turn repeated review labour into durable controls.

Bounded human attention is what makes an elastic supply of code useful. The organisations that get real throughput from autonomous agents will not be the ones running the most agents. They will be the ones whose owners decided in advance which change classes may enter without a human in the loop.

The future of code review is fewer humans rechecking known rules, more accountable owners deciding what must be true before consequential code exists, and more accepted change delivered safely as a result.