The pull request is the wrong unit of review

The pull request was invented to solve a specific problem: someone you do not know and cannot talk to wants to contribute to your project, and you need a way to evaluate their change before it touches your code.

For that problem it is excellent. For the problem most teams actually have — a colleague you sit next to made a change to a system you both understand — it is a poor fit that we have collectively stopped noticing.

what it optimizes for#

Asynchrony. Nobody has to be available at the same time. Enormously valuable across time zones, and a real cost when the two people are online simultaneously and could have resolved it in four minutes.

A permanent record. Genuinely useful and undervalued. The PR discussion is frequently the only place a design decision's rationale is written down.

Gatekeeping. The change cannot land without approval. Necessary for untrusted contributors, and a substantial tax when applied uniformly to trusted ones.

what it costs#

Latency. The median PR spends most of its life waiting. Not being reviewed — waiting to be reviewed. That latency is the single largest contributor to cycle time in most organizations, and it is almost entirely queueing rather than work.

Batching. Because review has fixed overhead, people batch changes to amortize it. Bigger PRs are exponentially harder to review well, which produces worse review, which produces more defects. Everyone knows this and everyone does it anyway, because the incentive is structural.

Performative approval. Review quality falls off a cliff past a few hundred lines. Beyond that, "LGTM" means "I skimmed it and I trust you," which is sometimes a fine thing to mean and is not what the approval button claims.

Ownership diffusion. "It was reviewed" becomes a substitute for "someone understood it." Two people who each 60% understand a change do not add up to one person who understands it.

the agent problem#

This is the part that has changed and why the framing needs revisiting now.

If an agent produces five pull requests in an hour and a human can meaningfully review two, you have not increased throughput. You have created a queue with a human at the front of it, and the pressure to approve faster is enormous.

The failure mode is predictable: review quality degrades to a rubber stamp, because the alternative is being the bottleneck that everyone can see. The metrics look great. The defect rate does not, six months later.

We do not have a good answer to this yet. Some things that seem to help:

• Require the agent to explain its reasoning in the PR body, specifically the decisions it made and the alternatives it rejected. Reviewing a decision is faster than reconstructing it from a diff.
• Make tests the primary gate and review the secondary one. If the test suite is strong, review can focus on design rather than correctness.
• Review the interface, not the implementation, for agent-generated code. The interface is where the expensive mistakes live.
• Reject on size. A machine can produce a 2,000-line diff effortlessly. Say no. It is not a favor to accept it.

the alternatives worth trying#

Pair or ensemble programming. Review happens continuously, at the moment of writing, by someone with full context. Zero latency, better knowledge transfer, and no queue. The cost is synchronous time, which is real, and which teams consistently overestimate relative to the cost of PR latency.

Trunk-based with post-commit review. Land it, review it after, revert if wrong. Requires strong tests, a fast revert path, and actual trust. Works extremely well where those exist and is a disaster where they do not.

Tiered review by risk. Not every change needs the same process. A typo fix in a comment and a change to the authentication path are both "a PR" today, and treating them identically is how the process becomes theater.

what I actually recommend#

Keep pull requests. Change three things:

1. Cap the size. A hard limit, enforced by tooling, with an override that requires a written justification. 400 lines is a reasonable line.
2. Set a review SLA and measure it. Not "we should review quickly." A number, on a dashboard, reviewed in the same meeting as uptime.
3. Make small PRs cheap. If opening a PR takes ten minutes of ceremony, people will batch. Automate the ceremony.

The tool is fine. The way it is applied to every change regardless of size, risk, or author is the problem, and that is a policy decision, not a technology one.