The Review Operating Model

29.1 The Problem, Stated Numerically #

Telemetry across roughly 22,000 developers found median review time up 500 percent alongside pull requests merged without review up 31.3 percent.¹¹⁹ Those two together are the signature: reviewers are queuing and waiving simultaneously. A study of merged agentic pull requests found 79.1 percent of a manually inspected sample showing no observable reviewer interaction at all.³¹

Uniform review does not survive this. The question is not whether to triage but on what basis.

29.2 Risk-Tier the Change, Not the Author #

Reviewers already do this implicitly, taking a median 3.92 hours on security-relevant agent pull requests against 0.11 hours otherwise.¹⁷¹ Formalize what is already happening.

Tiering is enforced by path and change-shape rules in the platform, not by reviewer judgment at the moment of review. Configuration files belong in R3 and are the most commonly misfiled, because they do not look like code.

29.3 Auto-Merge, Honestly #

Auto-merge is the practice that makes Stage 3 economically different from Stage 2, and it is also where an organization can quietly stop verifying. One published enterprise practice describes it as “auto-merging what’s safe, concentrating review where it matters most,” and that is the entire published record.¹⁰¹

Four preconditions, all required.

Set the sampling rate from your own defect economics, not from a published figure, because there is none. No published study measures human review effectiveness on agent-authored code against a ground-truth defect set, and none measures rubber-stamping rates in agent pull request review. Any auto-merge policy is therefore built on your own measurement or on nothing.

29.4 Collaborate on Hard Changes #

The most actionable review finding in the enterprise literature is not about review at all. When humans committed directly into an agent’s pull request rather than reviewing and returning it, success rose from 55 to 86 percent.¹⁰⁵

That is a large effect and it argues against a pure reviewer posture on complex work. The operating rule: for R2 and R3 changes that fail once, the second attempt is collaborative rather than another review cycle. Reviewing and returning is efficient for mechanical defects and expensive for design ones.

29.5 The Seeded-Defect Probe #

Automation complacency is the same underlying phenomenon as automation bias, with attention allocation at its center rather than two separate failure modes.²¹⁰ A reviewer whose attention has been reallocated by reliable automation does not become a worse reviewer; they become a slower one to notice.

The probe is the only mechanism in this framework that measures whether review is actually happening.

Rotate what reviewers see. Attention settles on the predictable, so a reviewer who always reviews the same work class will detect less within it over time. This is a reasoned application of the complacency literature to review scheduling and it is not measured in a software setting.

29.6 Push the Mechanical Down #

Human review is the most expensive layer and the evidence on what it delivers is less flattering than most organizations assume: a classification of 570 review comments found code improvements at 29 percent and defect finding at only 14 percent, with the remainder understanding, knowledge transfer, and design discussion.¹⁸¹

Meanwhile up to 76 percent of what review catches is in principle detectable by static analysis, against roughly 25 percent that generic tools actually deliver, with the shortfall being project-specific rules no generic tool can express.¹⁸⁰ That gap is the work queue. Every house rule you codify as machine-checkable lint is review capacity returned.

Use human review for design, architecture, intent, and whether the change should exist at all. Those are the things it is measurably good at and the things nothing else does.

29.7 Instrumentation #

• Absorption ratio: review hours required against senior engineering hours available
• Share of changes merged without human review, by tier and by authorship class
• Median and 95th-percentile review duration, and diff size at approval
• Seeded-defect catch rate and median review time on seeded changes
• Auto-merge false-negative rate from post-merge held-out results
• Share of house rules codified as automated checks

29.8 Failure Signatures #

• Approval rate near 100 percent with review times in seconds. Not a control. Instrument both and act on the pair.
• Auto-merge scope creeping. It expands one work class at a time, each individually defensible. Require the four preconditions on every expansion.
• The probe that always passes. Either the seeded defects are too easy or they are recognizable. Rotate their shape.
• Rising review exceptions. Every exception granted to hit a date is a permanent hole unless it carries an expiry.
• Configuration filed as R1. The most common tiering error, and the one every major disclosed vulnerability in agentic tooling went through.

29.9 What This Rests On #

The saturation telemetry, the no-interaction merge finding, the security review-latency differential, the collaboration effect, the review-efficacy classification, the static-analysis ceiling, and the automation-complacency synthesis are measured.^{119,31,171,105,181,180,210} The auto-merge preconditions, the probe design, and the reviewer rotation are this framework’s construction, and the absence of any published measurement of review effectiveness against agent-authored code means every organization is calibrating this on its own data.