Risk-Based Code Review: Who Reviews, and How?

Code review is under pressure. AI tools help us produce more code, while the people reviewing it still have limited time and attention. I explored this tension in my post on review pressure.

At the same time, AI tools have become capable reviewers themselves. In the October 2026 CRBugBench study by Yang and colleagues, the best agent, Claude Opus 5 with Copilot CLI, found 79.6% of the bugs humans had caught before merge. It also found 64.2% of a separate set of bugs discovered after merge, when reviewing the historical changes. Both results count detections within its top five review comments on the open-source benchmark.

These are substantial capabilities. AI can take on a meaningful part of the investigation and defect finding that previously required human attention.

People are still needed. But we should concentrate their involvement where more is at stake: higher-risk changes, decisions that require alignment, and changes people need to understand to maintain and operate the system. A passing automated review cannot establish whether the team agrees with a new access policy or understands a new architectural decision.

The practical question becomes: where does this change need human judgment, and how much?

Escalate oversight as needed

This is the idea behind proportionate escalation in SCOPE, the review model I am developing for agentic software development. We adapt oversight to the risk of a change and its alignment needs: how much shared understanding and coordination it requires.

In practice, we can adjust two things: who reviews the change, and how the review happens.

Who reviews the change?

Four La Linea-style illustrations: an agent reviews alone, the author reviews with an agent, a peer joins, and the team reviews together.

An agent can perform an automated review pass. The author can inspect and verify the work with AI. A peer can bring an independent perspective. And a team review can bring together people who understand different parts of the system.

The useful question is what each person contributes. For a change that expands access to reports, that might mean involving someone who understands the access policy, or a maintainer who knows that another service uses the same authorization logic.

Adding people alone does not make a review better. Give them a clear question to investigate.

How does the review happen?

Three La Linea-style illustrations, from left to right: a person directs a robot’s investigation, a person checks a robot’s findings, and a robot reviews and fixes independently.

We can also change how much direction people provide:

  • AI-autonomous: the agent chooses what to investigate and applies fixes within agreed boundaries.
  • AI-driven: the agent investigates; a person checks its findings and decides what to act on.
  • AI-assisted: a person directs the investigation, uses AI to explore specific questions, and judges the evidence.

For that access-policy change, a reviewer might ask: “Trace every path to these reports. Where is organization membership checked? Show me tests for users who must remain excluded.”

Checking the agent’s findings and directing such an investigation are different activities. If we only assess what the agent flags, we may never investigate what it missed.

These two choices can be combined freely. One person can direct a deep investigation. A team can discuss the results of an automated review.

What people bring to the table

AI can help trace behavior, identify problems, and explore test cases. People bring knowledge of the intended behavior, operational experience, independent challenge, and responsibility for the decision. Review also helps people build the understanding they will need to maintain the system.

Before implementation, agree on what needs checking and who should be involved. Revisit that decision when new uncertainty appears. Record the evidence, the decision, and any remaining concerns in the ticket or pull request.

That is risk-based review in practice: choose human involvement deliberately, and increase it when the consequences or the need for shared understanding demand it.

For a deep-dive into the review model, read SCOPE: Staged Change Oversight with Proportionate Escalation or SCOPE: A Deep-Dive.

Profile picture of Michaela Greiler

Written by Dr. Michaela Greiler who is obsessed with making code reviews your superpower. Learn more about her workshops.