Agentic code review authority should expand only by change class because blast radius and measured outcomes determine whether an agent may flag, block, or approve a pull request.
TL;DR
Engineering teams should assign agent reviewers one of three authority tiers per change class: flag findings, block merges pending human clearance, or approve bounded changes outright. Blast radius routes each class. Measured precision and post-merge failures then determine promotion or demotion. Human approval remains mandatory wherever policy names a person.
A coding agent opens pull requests before standup ends, and the senior engineer on rotation reads a large diff across multiple services with no design thread or prior pull request. No author record preserves the tradeoff, so the other pull requests wait while the reviewer rebuilds context the agent discarded. Agentic code review is pull request review that an agent carries out from context a diff alone does not show. The team defines its authority boundary in advance, which makes that boundary the governing decision.
This guide is for engineering managers deciding how much authority an agent reviewer may hold over code another agent wrote. For each change class, the engineering team chooses one of three settings: post findings and stop, block the merge until a human clears it, or satisfy the approval requirement outright. The team uses blast radius to select the applicable setting. This guide draws the edges of agentic code review against PR bots and SAST scanners, sets out three authority tiers, and describes how a change class moves between them as evidence accumulates. It does not re-argue why an agent cannot check its own work, and it does not rank vendors.
What Agentic Code Review Means
Agentic code review retrieves context beyond the diff and reasons in multiple steps. A team policy then determines what action the reviewer may take on the pull request. A PR bot evaluates documented pull request attributes or dependency metadata within its configured scope. Mergify condition documentation describes boolean expressions over approval counts and labels, along with check status and file paths.
A static application security testing (SAST) scanner evaluates code against fixed rules within a bounded analysis scope. Semgrep's cross-file documentation states that cross-file analysis is not supported on diff-aware pull request scans, although its full scans can use cross-file analysis. AI detection documentation describes that detection as non-deterministic and limited to full scans, unlike its rule evaluation. The category-level definition of AI code review covers pattern-matching reviewers as well as agents; this guide starts where the pull request author is an agent.
Why Code Review Became the Bottleneck
Review became the bottleneck because agents author in parallel while review stays serial and human-bound. A coding agent opens pull requests concurrently, while one reviewer holds one diff's context at a time. Authoring throughput scales, but review throughput does not.
The AIDev researchers presented their dataset at MSR 2026 and cataloged 932,791 agent-authored pull requests across 116,211 repositories through an August 1, 2025 cutoff. LinearB's 2026 benchmark report, published by LinearB as an engineering analytics vendor, draws on 8,109,244 pull requests from 4,813 teams. It puts P75 pickup time for agentic AI pull requests at 17.6 hours against 3.4 hours for unassisted ones, with agentic pull requests also 1.87 times larger at that percentile.
The constraint moved downstream to the engineers with the most context. Google's DORA team, analyzing 1,110 open-ended responses from Google engineers in Q3 2025, names the added reviewer load a "verification tax."
What an Agent Reviewer Adds
An agent reviewer reconstructs intent and traces cross-file impact. When the team makes organization policy available as context, the reviewer can apply that policy in the same analysis. Pattern-matching tools operate within the attributes, code, and rules they receive.
Intent lives in artifacts outside the diff. A reviewer who reads the linked ticket and prior pull requests on the same module, then checks the commit history, can say why a change exists. A scanner rule cannot derive that rationale from a diff alone. Semgrep's AI detection documentation explains that insecure direct object reference detection requires understanding how the specific application handles authorization, which makes generic rules difficult to encode.
Cross-file impact requires a graph. Researchers in the IRIS study evaluated 120 manually validated vulnerabilities requiring cross-file taint paths in real Java projects, and the ICLR 2025 conference accepted the paper. CodeQL detected 22.50% of them, and IRIS with GPT-4 detected 45.83%. Both had high false discovery rates: 90.03% and 84.82%, respectively.
Cosmos, Augment Code's unified cloud agents platform available on all paid plans, builds that same kind of graph through its Context Engine, which maps call graphs and third-party dependencies across repositories containing hundreds of thousands of files. A Cosmos Environment then constrains which of those repositories the Context Engine can reach for any single review.
Higher recall came with more noise, so the policy owner must score an agent's output per change class before granting it authority. Organization policy provides another input. A reviewer who reads a team rule such as "any billing schema change needs a migration plan reviewed by the data platform owner" can apply it.
Agent-authored pull requests arrive carrying two debts. Jason Gorman coined comprehension debt in a September 30, 2025, blog post for code produced faster than a team can understand it. Margaret-Anne Storey formalized intent debt in ACM Queue on June 1, 2026, as the missing record of rationale and of the goals or constraints behind a system. Sonar's 2026 survey of 1,149 professional developers found 38% say reviewing AI-generated code takes more effort than reviewing human-written code.
The Authority Question: Approve, Flag, or Block
Teams assign one of three authority tiers to each change class. A separate reviewing agent enforces maker/checker separation on agent-authored diffs. On Cosmos, that separation runs as two Experts: a Deep Reviewer Expert reviews the pull request, and a Risk Analyzer Expert scores its risk as a separate pass, each bounded by the Cosmos Environment it runs in. The instruments most teams answer to already draw these lines.
SLSA v1.2 Source Track Level 4 says two or more trusted persons must agree to changes on protected branches and defines those persons as humans. The same requirements text says an organization MAY grant a Trusted Robot a perpetual exception, so a bot can merge without two-party review. The approve tier in agentic code review exists only where the organization has written the robot into policy by name.
The repository owner maps each tier to a blast-radius threshold and an evidence bar. At the block tier, the agent typically fails a required check or requests changes so the merge waits for a human to clear or override it. The ordering below runs from least to most authority.
| Tier | Agent action | Merge effect | Change class | Evidence bar before promotion |
|---|---|---|---|---|
| Flag | Posts inline findings and a risk summary | None; a human approves and merges | Default for every class | None; every class starts here |
| Block | Fails a required check or requests changes | Merge waits for a human to clear or override | Changes crossing a service or data boundary | Finding precision on a sampled set holds the team's threshold |
| Approve | Satisfies the approval requirement or fires auto-merge | Change lands without human review | Bounded, deterministic classes with passing checks | Revert and incident rates at or below the human-reviewed baseline |
Uber presented its Last Diff Analyzer at ESEC/FSE 2023, and it shows the approve tier at its narrowest. It auto-approves a revision only when a required human reviewer already approved an earlier revision and the new one preserves that approved behavior. About 15% of analyzed diffs qualify each week.
Blast Radius as a Routing Signal
Blast radius is the set of components or consumers exposed to a change. Teams can use downstream consumer count as one operational proxy and compute it from the dependency graph before assigning a reviewer.
An ACM Queue article defines blast radius through the severity and impact of an issue. For a pull request, the operational version includes code and services reachable from the changed symbols, which is what Bazel's rdeps query returns. A CI job exits non-zero above the team's threshold, and the team sets it as a required check in branch protection.
Riftmap, the vendor of the blast-radius gate it describes, published an engineering blog post that argues for graph traversal over an AI-generated risk score because a score can vary between runs. The engineering team then uses consumer count to route the change to a tier. The routing framework applies these change classes.
- Zero downstream consumers: A test fixture change with green checks is a candidate for approval.
- A dozen-plus consumers on a shared SDK: A serializer change goes to flag, with the owners of those services named as reviewers.
- An auth path or schema migration: The change goes to block until the named owner clears it, whatever its consumer count.
Threshold routing focuses review on concentrated risk. Kamei et al.'s just-in-time defect model in IEEE TSE 2013 found that 20% of the inspection effort identifies 35% of defect-inducing changes.
Where Policy Requires Human Review
A written policy keeps a human in the loop by naming the change class and approver. Habit keeps someone reading every pull request because the team has always worked that way. The written policy carries the same authority SLSA already grants. Source Track Level 4 lets an organization name a Trusted Robot as its own exception to the two-party rule, but only where that organization has written the robot into policy by name. Absent that written exception, the flag tier applies by default, and a human approves and merges every class the policy has not separately promoted to block or approve.
Netflix drew the line for its fleet-wide auto-merge: Sarbanes-Oxley (SOX)- and Payment Card Industry (PCI)-regulated changes can never auto-merge for legal reasons. In an InfoQ-hosted presentation, Netflix described other changes as auto-merging when repository permissions and mergeability qualify, all checks pass, and a confidence rating meets the threshold. Those conditions map onto the same approve-tier bar this guide uses elsewhere: passing checks and a qualifying confidence rating are what a bounded, deterministic change class must clear before authority moves from a person to the pipeline. In a separate initiative further downstream, Netflix removed manual approval gates from a set of service deployments and reported a 77% drop in manual interventions. That is evidence the same kind of boundary can hold after a merge as well as at it.
The FedRAMP monitoring playbook describes routine recurring changes as often entirely automated and calls its two review-and-approval categories "adaptive" and "transformative" changes. Teams need machine-readable policy to enforce that distinction. OPA's CI/CD documentation describes evaluating pull request metadata against Rego policies and returning exit code 1 on violation with the --fail flag, which turns a written rule into a required check. FedRAMP splits along the same distinction this guide draws between tiers: a routine, recurring change can bypass approval entirely; an adaptive or transformative change still needs a named approver.
The decision log makes an autonomous approval reviewable after the fact. A ruleset bypass in exempt mode leaves no record, so the repository owner must keep autonomous approvals on an auditable path. That path is what lets a demotion decision cite evidence rather than assert it. A reverted approve-tier change or an incident traced to one only drops a class in the record if the log shows which approvals were autonomous in the first place. On Cosmos, a Session is that auditable path: it retains the conversation and the work behind a review indefinitely, so the decision log has something durable to point to rather than a summary written after the fact.
How the Boundary Moves as Trust Is Earned
The policy owner expands authority one change class at a time based on measured outcomes and contracts it when those outcomes slip. The review owner decides promotion per class at the end of a fixed sample window, never mid-window.
Meta's RADAR paper, which appeared in PACMSE 2026, puts that ramp in written form. Deterministic codemods get blanket auto-accept, while AI-generated codemods require automated review evaluation. Human-authored diffs pass an eligibility check.
The paper reports 535,000-plus reviewed diffs showing a revert rate one-third and a production incident rate one-fiftieth of non-RADAR diffs. Wickens and Dixon measured a 0.70 crossover in 2007 human-factors experiments on operator reliance on automated aids; below that point, unreliable automation performed worse than none. Teams can borrow that as a starting bar for the block tier.
The team records demotion signals before deployment. A reverted agent-approved pull request drops its class to block. When the team traces a production incident to an agent-approved change, it drops that class to flag. A model or reviewer version change resets the sample count.
Anthropic's Claude Code auto mode escalates to a human after 3 consecutive or 20 total denials, a first-party example of an automatic step down. Augment Code's own code review benchmark, from December 11, 2025, scored a 59% F-score at 65% precision and 55% recall. It is first-party evidence scored against a golden comment set Augment expanded and corrected itself. It also matches the precision-and-recall pair a team computes on its own repositories, per change class, over a sample window fixed before the first promotion.
Setting the Boundary in Practice
Engineering teams should define the agentic code review boundary before the first agent reviewer posts a comment. Every change class needs an authority tier because branch protection governs any class without a written rule.
Run reverse-dependency queries over the last 90 days of merged pull requests. Bucket them by downstream consumer count and whether they touch an owned path. Those buckets become the change classes, and the boundary lives in files the pipeline reads.
- CODEOWNERS: Name a human owner on every path that can never auto-merge, and turn on required code-owner review.
- Required blast-radius check: Fail the CI job above your threshold and mark it a required check in branch protection.
- Policy file: Encode your approve-tier classes as policy the pipeline evaluates, and keep
exemptmode out of the ruleset bypass list so every autonomous merge leaves an audit entry. - Demotion rules: Write the demotion triggers into the same file, so a revert drops the class to block and an incident drops it to flag without a meeting.
Anything outside those four files runs on whoever is on review rotation that day.
Cosmos Triggers can start a Session from an external event such as a schedule or a webhook, and Cosmos Automations connect that event to the Expert responsible for the change class it maps to. The policy file and branch protection above still hold final merge authority no matter what starts the review. Platform selection otherwise sits outside this guide; teams weighing where to run these Cosmos Experts and Environments can compare commercial platform options directly.
What to Do Next
The tradeoff is autonomy against auditable oversight: every class promoted to approve removes a human from a decision. A defensible removal requires a record of what the agent examined and a measured outcome showing it met the team's threshold. Build a one-page table showing each bucket's tier and revert count. Pull the last 90 days of merged agent-authored pull requests, tag each with its downstream consumer count and whether it was reverted, and compute the revert rate per bucket. Grant the approve tier only to buckets where that rate sits at or below the human-reviewed rate for the same period.
Frequently Asked Questions
Related Reading
Written by
Molisha Shah
Molisha is an early GTM and Customer Champion at Augment Code, where she focuses on helping developers understand and adopt modern AI coding practices. She writes about clean code principles, agentic development environments, and how teams are restructuring their workflows around AI agents. She holds a degree in Business and Cognitive Science from UC Berkeley.