The Review Bottleneck Is the Product

The most useful signal about whether a company is getting value from coding agents is not how many agents it has deployed. It is what happens to a pull request after an agent opens it.

In the teams that are struggling, every agent-authored pull request lands in the same queue as every human-authored one. The queue grows, because agents produce changes faster than humans produce changes, and the review process was sized for the rate at which humans produce them. The team responds by asking people to review more, or by hiring reviewers, or by quietly letting low-risk changes sit until someone merges them out of fatigue. None of those are strategies. They are symptoms.

The teams that are succeeding did something different. They changed what review is for.

Review was doing two jobs

A code review has always carried two responsibilities that nobody separated because they usually arrived together.

The first is comprehension. A reviewer reads a change to understand it, to catch a mistake, to suggest a better shape. This work is genuinely valuable and genuinely hard, and it does not get easier when the change was written by an agent. If anything it gets harder, because the agent will not explain its reasoning unless asked.

The second is authorization. Somewhere in the process, a person with the standing to say so decides that this change may merge. That decision is about authority and accountability, not about the code. It answers a question the diff cannot: who is answerable for this, under which policy, and on what evidence.

Comprehension and authorization look identical when a human writes the code, because the human who understands the change is usually the human who can authorize it. Agents break that coincidence. An agent can produce a change nobody on the team has read closely, and the authorization question arrives before the comprehension work is done.

When you make everyone review everything, you are asking each reviewer to do both jobs for every change. Comprehension does not scale by adding reviewers, because understanding is the expensive part. Authorization does scale, if you can separate it from comprehension and decide what it actually requires.

What authorization actually requires

Strip away the code review ritual and an authorization decision rests on a small number of facts. Who or what produced this change. Which human is accountable for it. What evidence says it is safe to proceed. Which policy governs it. What happened to similar changes after they shipped.

None of those are questions about whether the code is elegant. They are questions about accountability, evidence, and policy, and they can be answered without reading the diff.

That is the observation the teams getting value from agents have acted on. They kept comprehension for the changes that need it, and they moved authorization to something that evaluates evidence against policy and returns a decision. The reviewer who reads a change is now doing so because the change warrants reading, not because the process requires a signature.

The objection worth taking seriously

The obvious objection is that this is just a rubber stamp with better branding. If a system approves changes without a human reading them, have we not automated away the accountability that made review meaningful?

It is a fair objection, and it fails on a specific point. The alternative to a deterministic authorization decision is not careful human judgment. It is a human reviewer under time pressure, approving a change they did not fully read, because the queue is long and the change looks fine. That reviewer is making an authorization decision on weak evidence and calling it comprehension. The accountability was already thin; the ritual was hiding it.

A system that evaluates evidence against policy and records its reasoning is not less accountable than that. It is more accountable, because the decision is reproducible and the reason is written down. A reviewer who approves a change after skimming it leaves no record of why. A policy evaluation leaves a reason code, the evidence it considered, and a signature.

The honest version of the objection is narrower: a policy can be wrong, and a wrong policy applied consistently is worse than a wrong judgment applied inconsistently, because it is wrong at scale. That is true, and it is why the useful systems make the policy explicit, version it, and let the customer change it. A policy you can read and edit is a different object from a model's judgment, which you can neither read nor pin.

What changes when authorization is separate

Once authorization is its own step, several things become possible that were not before.

You can start in a mode where the system reports what it would have decided and nothing blocks. That is how a team builds confidence in the policy before it has consequences, and it is the opposite of the usual rollout, where you discover the policy was wrong at the moment it blocks a release.

You can tell a developer why their change was blocked, specifically, in the pull request where they are already working. Not a dashboard they have to visit, not a report someone has to compile. The reason code and the missing evidence, next to the diff.

You can answer the auditor's question with a record instead of a person. When a decision is signed and the signature can be checked without access to the system that made it, an auditor verifies the record rather than interviewing whoever approved the change.

And you can widen the scope of what gets authorized without widening the scope of what gets read. The changes that are genuinely novel still get human comprehension. The ones that are routine get a policy evaluation, and the human attention goes where it earns something.

The uncomfortable part

Separating authorization from comprehension requires admitting that most code review was not comprehension. It was a signature on a change nobody had time to read properly. Teams resist this because the ritual feels like diligence, and replacing it with a policy evaluation feels like lowering a standard.

But the standard was never the ritual. The standard is that a change merges only when someone with the authority to allow it has reason to believe it is safe. A policy evaluation can meet that standard and show its work. A tired reviewer at the end of a long queue often cannot, and rarely does.

The teams getting value from coding agents are not reviewing faster. They are deciding what review is for, and giving the authorization half of it to something that can be trusted with it.