SCOPE: A Staged Code Review Model for Agentic Development

Before agentic programming, the dominant code review model centred on peers inspecting code written by another developer. This model assumes that human review capacity can reasonably keep pace with the changes developers produce, and that detailed engagement with those changes provides knowledge developers will later need to maintain the system.

Agentic programming puts both assumptions under pressure. Recent evidence shows that AI-assisted development can increase software-delivery throughput, while large-scale engineering telemetry also points to larger changes and increasing review demands as AI adoption grows.

A peer who encounters a complex change only after it has been produced may no longer be best positioned to reconstruct every decision and act as the first detailed human reviewer. Knowing all the implementation details might also no longer be necessary for developers, who themselves instruct agents to add, change, and remove code.

This does not make human review less important. Developers still need to understand changes, challenge important decisions, share knowledge, and maintain collective ownership. However, the operating model must evolve. SCOPE is intended to provide that evolution.

For a more detailed discussion, see: Why the Traditional Code Review Model Is Under Strain.

Introducing SCOPE: A Multi-Stage Review Model for Agentic Development

Based on these developments and my experience working with teams on code review over many years, I propose SCOPE, a new code oversight model for agentic development. SCOPE stands for Staged Code Oversight with Proportional Escalation.

SCOPE is a candidate model is under active research and development. If you read it and would like to provide feedback, I would appreciate hearing from you. Please email me at michaela @ michaelagreiler.com or use this link.

The central shift in SCOPE is that the developer who directs the agent, subsequently referred to as the steering developer, officially takes over a central part of the code review and verification work, while peers are brought in to provide an independent perspective, learn about the change, and challenge it at a depth proportionate to the required level of oversight.

It treats code review as a proportionate, multi-stage practice and distributes review across three stages:

• Agent Review
• Developer Review
• Peer Review

The first stage in SCOPE is Agent Review. Here, GenAI-based reviewers complement automated tests, static analysis, and other established checks by repeatedly examining the implementation and identifying potential problems.

The next stage is Developer Review. During this stage, the steering developer reviews the code changes produced by the agents. The main goal is to ensure that the steering developer has an accurate and sufficiently detailed understanding of the change to assess it and accept responsibility for the implementation.

The final step is Peer Review. Here, one or more peers review the work, build a sufficient understanding of the change, bring an independent perspective, challenge important assumptions and tests, and contribute to the team’s shared judgment about whether the change is ready.

SCOPE consists of three stages, but is also iterative in nature. Agent Review and Developer Review may repeat several times, while Peer Review may also return the change to Developer Review for improvement.

Proportional escalation is the heart of SCOPE and determines the intensity and depth of the oversight. The stages themselves remain stable, but how they are carried out adapts to the change’s understanding needs, risk, and the assurance already established. These factors influence how deeply the code should be inspected, how large the Agent-Dev Loop may become, whether another developer or specialist should be involved, which artifacts require review, and whether the change can proceed in its current form.

The following sections explain each stage and the escalation process in more detail.

Stage 1: Agent Review

The first review stage begins during code generation. Here, GenAI can be used to review code automatically and quickly within seconds or minutes, far exceeding the speed of human review. This can happen before a human looks at the code. Code is the primary artifact during Agent Review, alongside specifications, documentation, tests, architectural guidance, and other instructions that provide the context against which the agent assesses the implementation.

Agent Review builds on a common automation baseline of established checks such as linting, static analysis, and tests, but forms a separate layer of review on top of it. This baseline should be defined and owned by the team, applied consistently, and should automatically preserve what ran, under which conditions, and with which outcomes. The steering developer and peers may add change-specific agent reviews, analysis, or tests that enhance the mandatory baseline. The automation can run either locally or in a pipeline, yet it is important that the outcomes and steps taken are preferably automatically documented for transparency and accountability for the broader team.

While the baseline automation is defined by the team, the handling of the outcome does not require peer involvement, but should instead be handled as much as possible by the steering developer. Right now, two common review patterns are fully autonomous reviews, in which agents review and immediately revise the code, and semi-autonomous agent reviews, in which the agent reviews the code while the steering developer also assesses the agent review findings and determines how the findings should be addressed based on their experience.

Agent-based code review is already operating at substantial scale. GitHub reports more than 60 million Copilot code reviews, with Copilot now involved in more than one in five reviews on GitHub, and reports actionable feedback in 71% of its Copilot reviews. At the same time, emerging research shows that the usefulness and reliability of LLM-based review remain highly dependent on the task, context, and review setup, including harness and safeguards.¹ Right now, industry focuses extensively on finding ways to make the harness and safeguards more reliable. For example, this can involve directing agents to make failures, uncertainty, and unresolved findings visible to the steering developer rather than allowing the agent to present an unqualified success. Using separate agents or models for implementation and review may also provide a more independent perspective, although the effectiveness of such configurations is still emerging.

A stronger harness improves the coverage, repeatability, and traceability of automated checks. It can help humans focus their attention, but it cannot by itself establish that the implementation is correct or even that the right implementation was produced. This creates an epistemic problem. The implementation, tests, summaries, and agent reviews may all appear coherent while relying on the same incomplete specification, incorrect assumption, or missing context. Agent-specific problems can also arise. For example, agents may circumvent constraints or misunderstand what the developer instructed them to do. Agent Review should therefore be seen as an AI-based review layer that can strengthen assurance, but cannot provide accountability or take responsibility for the change. Oversight and human judgement must come from the two later stages: Developer Review and Peer Review.

Stage 2: Developer Review

In the next stage, Developer Review, the developer who instructed and steered the agent reviews and verifies the code. Unlike in Agent Review, the review is now performed directly by the steering developer rather than by an agent. The developer then either provides feedback to the agent so that it can revise the code or makes the necessary changes themselves.

The Iterative Nature of Agent Review and Developer Review

There may be several rounds in which the agent produces or changes code based on the developer’s input and the developer inspects the result during Developer Review and provides further feedback (optionally running additional Agent Review rounds). I call this back-and-forth between the agent and developer the Agent-Dev Loop. In many development workflows that use agents, this loop will emerge naturally and may become the primary mode of interaction with an agent. First, the developer gives the agent a prompt. They then read, review, and assess its work. Much of the inspection, testing, and iteration that follows the initial prompt can be understood as part of change assessment and code review.

SCOPE makes this review work explicit and establishes a clear responsibility boundary. The steering developer must read, review, and inspect enough of the code to have an accurate mental model, determine whether the agent implemented what was intended, identify decisions the agent made without explicit direction, and assess or correct those decisions. In the end, the steering developer must accept the agent’s work as their own.

The Role of Code During Developer Review

Some argue that, with sufficiently strong models and good safeguards in place, the steering developer may no longer need to inspect the implementation. To me, this is like Schrödinger’s cat: the code may be written as expected, but without looking, you do not know.

However, the level of detail with which the developer needs to inspect the code depends on the understanding need of the change and the risk profile. The developer may not need to examine every line with equal intensity, but they must inspect enough of the changed code and tests to confirm that the agent solved the problem as intended, detect any mismatch between the intended and actual implementation, and accept responsibility for the result. Developer Review is also about maintaining a reliable mental model of the system and its implementation. The focus and questions of this code review may also differ from those of traditional code review, shifting towards the known failure modes of agents or the reliability of automation safeguards like tests. But more on this in another post.

Ultimately, the code is where the story we tell ourselves, or that agents tell us, must face reality.

The developer can and should also use agent summaries, session logs, explanations, and the outcomes of manual or automated testing, but these cannot replace inspection of the implementation. This is especially true for high-risk changes and implementations involving complex concepts, such as synchronisation in multi-user scenarios or non-trivial algorithms.

The Steering Developer’s Review: Strengths and Weaknesses

Empirical research on code review shows that code comprehension is fundamental to how reviewers evaluate changes: reviewers first build context and construct a mental model against which they assess the actual implementation. In a fast-paced agentic development environment, the steering developer may therefore be particularly well positioned to perform the first detailed human review because they have followed the work and should already have substantial context about the intended change.

However, while the steering developer has the best context, they also have the worst independence. The steering developer and the agent might not only share the same assumptions, but also the same misunderstanding of the task. The developer might also lack the relevant expertise or review the implementation only superficially.

That’s why in SCOPE, we use the advantages of developer review at a stage where context matters most, followed by mandatory Peer Review, which complements the review with independence.

Stage 3: Peer Review

In the final stage, the change is handed over to one or more peers. This resembles traditional team code review, but in SCOPE its focus has changed. Because the steering developer has already performed the first detailed implementation review during the Agent-Dev Loop, the team should not simply repeat the same work.

The main responsibilities of Peer Review are to provide independent challenge and create and maintain a shared understanding of the system. For the independent challenge, the peers focus on understanding and assessing architectural and cross-system impact, reviewing important decisions, and inspecting critical areas, instead of detecting minor problems in implementation details.

Code is one of several review artifacts, and the required depth of code inspection depends on the need for understanding as well as risk. Changes with low risk and modest understanding needs may primarily require a review of the rationale, supporting evidence, and system impact, while high-risk changes or changes with substantial understanding needs may require inspection of critical implementation paths or a comprehensive code review.

Peer Review also ensures that knowledge created during the Agent-Dev Loop does not remain with the steering developer alone. At least one other team member should gain sufficient understanding of the change to challenge it, maintain it, and support continued collective ownership of the system.

The form of Peer Review can vary depending on the change. It may take place asynchronously, but synchronous walkthroughs, review meetings, or focused inspections of high-risk areas may be more appropriate when knowledge transfer, discussion, or collective judgment is needed.

Peer reviewers can and should take advantage of agentic capabilities. They can spin up their own review agent with different prompts, or even better, use agents to help them build a mental model of the change or challenge the underlying assumption. As with all agentic usage, this should be done responsible, and the peers must take action to ensure they do not blindly accept an agent’s version of the truth, but rather use those tools to enhance their own capabilities of understanding and judgement.

To assess the change, the team can use all relevant information available, such as the code, tests, specifications, acceptance criteria, architectural information, harness evidence, and relevant operational context. The importance of each source of evidence depends on the understanding needs, risk and assurance already established for the change.

Proportional Escalation: Understanding Need, Risk, and Established Assurance

Proportional escalation is the central point in SCOPE where human judgment is brought together and turned into an explicit, revisitable decision about how a change should be reviewed. It determines how large the change may become for peer review, whether one or more developers should participate in producing it, who should review it, what expertise and independence are required, and how deeply the change should be examined. This is the scope in SCOPE.

Proportional escalation starts with two properties of the change: understanding need and change risk. Together, they establish how much oversight the change requires. As work progresses, the team also considers the assurance already established through automation and human review. Established Assurance does not change the inherent risk or understanding need of the change, but it influences what additional verification and review are still needed.

Understanding Need concerns the need for developers and peers to understand, discuss, and align on the change. It may be high when a change introduces a new concept or abstraction, affects several parts of the system, crosses ownership boundaries, establishes a precedent, or changes assumptions that other developers rely on. Understanding need also depends on which knowledge is required by the team to maintain and evolve the system.

Based on my work with development teams, interviews, and emerging industry evidence, I see these knowledge needs shifting as agentic development becomes more common. For some changes, peers may increasingly need to understand the rationale, design decisions, architecture, and system implications rather than every implementation detail. This does not apply uniformly. For complex algorithms, unfamiliar mechanisms, or changes whose correctness depends on implementation details, substantial code inspection may still be necessary.

If development moves faster than teams can maintain a reliable mental model of the system, they can accumulate cognitive debt. SCOPE’s emphasis on understanding need and the Oversight Record is partly intended to prevent teams from losing track of what they built, why they built it, and how it works.

Established assurance describes how much justified confidence has already been created through the verification and review performed so far. Automation contributes to this assurance only to the extent that the team has reason to trust the checks and evidence it produces. Relevant tests, static analysis, reproducible checks, and sufficiently independent agent reviews may strengthen assurance, while missing context, weak specifications, substantial unguided agent involvement, or poorly understood automation may limit it.

During the Agent-Dev Loop, the steering developer adds further assurance through their own inspection, verification, testing, and judgment. By the time Peer Review begins, peers can therefore consider both what oversight the change requires and what assurance has already been established.

Strong established assurance can focus later review on the areas where independent judgment is most valuable, but it does not erase high risk or remove an important need for shared understanding. Conversely, weak or uncertain assurance may require additional verification, smaller implementation steps, earlier peer involvement, or deeper inspection.

The Oversight Record

The proportional escalation decision should not exist only as an informal judgment in the minds of individual developers. Instead, it should be a conversation within the team that is explicitly captured. In SCOPE, this conversation is captured in an Oversight Record.

The record starts during planning with a rough assessment of the change’s understanding needs and risk, and the oversight these seem to require. This does not need to be precise or exhaustive. The goal is to surface concerns early and align on whether the change requires, for example, particularly careful verification, specialist input, smaller implementation steps, or deeper peer involvement. Teams should apply established escalation levels and review expectations rather than design a new review process for every change.

As the work progresses, the record becomes more concrete. The steering developer adds information peers need to assess what assurance has already been established and where independent challenge is still valuable: important decisions or deviations, problems or uncertainties that surfaced, additional verification performed, and areas where they want peers to challenge the work. Importantly, the developer should primarily add information that peers cannot easily derive from the implementation itself. The record should reduce comprehension effort, not increase it by adding more information to process. Evidence from the common automation baseline should be captured automatically where possible.

During Peer Review, peers contribute their own judgment. They may confirm or challenge the existing assessment, add concerns or evidence, and update the oversight decision when needed.

The Oversight Record is therefore not documentation for its own sake. It is the trace of an ongoing conversation between the people involved in the change. Teams should capture what materially affects that conversation rather than trying to document every decision.

The Oversight Record does not need to be a separate document. Teams can integrate it into an existing artifact, such as the ticket, pull request description (perhaps through the use of PR templates), or change specification. What matters is that the team defines one consistent location and uses it for all changes, so everyone knows where to find and update the record.

Current tools are beginning to preserve more evidence from agentic development that can help to establish this record, but their summaries do not reliably surface the information most relevant to peer reviewers.² They may sometimes identify the important details well, but at other times emphasize less relevant information or omit issues that require human judgment to recognize.

Developer Review: Escalation within the Agent-Dev Loop

During Developer Review, the main question is not only how much of the code the developer needs to inspect, but also how large a change can become within the Agent-Dev Loop. The boundary is not determined by a fixed number of changed lines, but by whether the steering developer can still maintain a reliable mental model of the implementation and inspect it with sufficient depth for the risk involved.

For low-risk work with modest understanding needs and trustworthy automation, the Agent-Dev Loop may continue for longer before the change is handed over to the team, provided that the change remains coherent and the steering developer maintains a reliable mental model of the implementation. High-risk work, complex changes, unfamiliar code, weak tests, or limited developer understanding require smaller iterations and earlier involvement from others. In those cases, another developer may also join the Agent-Dev Loop directly. This can provide earlier challenge and shared understanding without repeatedly handing partially understood work to the wider team.

The change should remain small enough for the steering developer to confidently inspect and understand the code produced by the agent. Feeling overwhelmed, losing track of important decisions, or no longer being able to explain important implementation details are strong indications that the loop has become too large.

Peer Review: Determining the Escalation Level

Peer Review begins by revisiting the Oversight Record and reconsidering what oversight is still needed. One or more peers therefore examine the change’s risk and understanding needs, together with the assurance already established through automation and Developer Review. Based on this assessment, the reviewer determines where independent review is most valuable, which artifacts to examine, which parts of the code require direct inspection, who should be involved, and whether the review should take place asynchronously or through a synchronous walkthrough.

The peers then perform the review at the selected level. They challenge assumptions, assess unintended architectural and cross-system consequences that arose during the Agent-Dev Loop, examine relevant evidence, and inspect the code and tests to the depth required by the escalation decision.

The escalation level may change during the review. New findings may reveal previously overlooked risks, weak evidence, incorrect assumptions, or implementation areas that require closer inspection. The team may then expand the review or involve additional reviewers or specialists. Conversely, evidence that resolves important uncertainties may allow the team to narrow the remaining review, provided that the minimum depth required by the change risk and understanding need is maintained.

If the review reveals that Developer Review was insufficient, Peer Review should pause rather than absorb the missing implementation review. The change should return to Developer Review so that its scope can be reduced, stronger evidence can be established, unresolved concerns can be addressed, or another developer can join the Agent-Dev Loop. The revised change can later return to Peer Review for a new assessment.

Proportional Escalation in Context

SCOPE deliberately does not prescribe either the exact meaning of low, medium, and high understanding need and change risk, or the concrete escalation actions that follow from them. Both depend on the context in which a team operates and should be defined by the team or organization before SCOPE is applied to individual changes.

First, teams should establish how understanding need and change risk are assessed in their environment. This includes what low, medium, and high mean, which signals should inform these judgments, and whether some signals establish a minimum level. Candidate signals include change size, complexity metrics, dependency changes, sensitive files, reversibility, and architectural or ownership boundaries. These signals should support rather than replace human judgment. Established assurance should similarly be assessed against agreed expectations for automation, verification, and review.

Second, teams should define what different levels of oversight mean in practice. SCOPE does not prescribe how many reviewers are required, who must review a change, how large an Agent-Dev Loop may become, or when specialist involvement is mandatory. A healthcare organization may require substantially different escalation measures than a team developing a low-risk consumer service. Existing review roles and practices can also remain in place, allowing SCOPE to fit different development processes rather than requiring teams to redesign them from scratch.

SCOPE provides the structure for deciding when more oversight is needed. The concrete actions used to provide that oversight remain organization- and team-specific.

The goal is not to make these decisions anew for every change. Teams establish and document their assessment criteria and escalation options in advance, so developers and reviewers share an understanding of what to look for, how judgments are made, and what additional oversight means in their context.

SCOPE in Action

To make proportional escalation more concrete, consider a fictional company that operates a podcast hosting and distribution service. The company is neither safety-critical nor highly regulated, but failures can still have very different consequences. A visual defect on an upload page is very different from losing subscriber data or incorrectly processing payments.

Before adopting SCOPE, the team defines what change risk and understanding need mean in its environment. For risk, it considers the potential consequences and reversibility of a failure. Changes involving authentication, payments, subscriber data, migrations, storage infrastructure, or other sensitive parts of the system automatically establish a higher minimum risk level. A localized and easily reversible change with limited user impact may remain low risk.

For understanding need, the team considers how much new knowledge needs to be developed and shared. A familiar change contained within one component may have a low understanding need. Changes that affect several services, introduce a new abstraction, or modify established design decisions may have a medium or high understanding need. A change is considered high when peers need to develop a new mental model of how an important part of the system works, for example because it introduces a new architecture, crosses important system boundaries, or changes assumptions that future development will depend on.

The team also defines its escalation options in advance. Increased risk tends to trigger stronger verification and independent challenge, while increased understanding need tends to trigger earlier collaboration, architectural discussion, walkthroughs, or deeper peer involvement. These are not recalculated from scratch for every change. Developers use the shared criteria to make an initial assessment, record it in the Oversight Record, and revisit it as they learn more.

One escalation option the team uses is to reduce the amount of change that reaches Peer Review at once. Low-risk, well-understood work may be handed over as one coherent PR, while higher-risk or higher-understanding changes may be divided into smaller reviewable steps, with subtasks handed over to Peer Review earlier or more frequently. This is one possible organizational choice, not a requirement of SCOPE.

The following three changes show how the same team might apply these rules in practice.

Failure Modes and Safeguards

SCOPE cannot eliminate failures of human judgment or responsibility. The most important model-specific vulnerabilities are miscalibrated oversight, overestimated assurance, and insufficient Developer Review. SCOPE does not remove these risks, but it makes the relevant judgments and responsibilities explicit and creates clear points at which the work can be challenged, returned, or escalated.

Miscalibrated Oversight

The required level of oversight can be underestimated when the team misjudges either the change risk or its understanding needs. Assessments may be incomplete, biased, or based on assumptions that later prove incorrect. Developers may overlook consequences, underestimate uncertainty, or fail to recognize that a change requires broader shared understanding.

To reduce this risk, understanding need and change risk should be assessed during planning or design using the criteria and escalation framework established by the team. Mechanical signals can help establish minimum levels, while human judgment is needed to interpret them in context. The initial assessment should remain revisable as new risks, dependencies, architectural consequences, or understanding needs emerge during implementation and review.

Uncertainty should increase oversight rather than be treated as evidence that a change is low risk or easy to understand. Over time, teams should refine their assessment criteria using review findings, escaped defects, incidents, recurring rework, maintenance difficulties, and signs of architectural drift.

Overestimated Assurance

Established assurance can also be overestimated. Tests may pass while verifying the wrong behavior, agent reviewers may share assumptions or missing context with implementation agents, and apparently strong automation may provide less independent evidence than expected. Developer verification can similarly be given more weight than it warrants.

SCOPE therefore treats assurance as justified confidence based on the verification performed, the available evidence, and their known limitations, rather than simply the amount of automation or review activity completed. Automated checks and their outcomes should be persisted where possible, while the steering developer should make important limitations, uncertainties, and additional verification visible in the Oversight Record.

Peer Review provides an additional safeguard because peers independently reassess the assurance already established rather than simply accepting it. Strong-looking evidence should therefore focus peer attention, not replace independent judgment. When the reliability or relevance of the available assurance is uncertain, additional oversight is warranted.

Superficial Developer Review

Developer Review can become a formality rather than a meaningful review. Agent-generated code may look plausible even when the steering developer has not sufficiently understood, inspected, or verified it. The steering developer may misunderstand the task, rely too heavily on the agent, lack the relevant expertise, or deliberately shift verification work onto the team.

This can lead to a phenomenon I call code review exploitation, in which a peer reviewer becomes the first person to seriously inspect, understand, and assess the implementation. Review work that belongs inside the Agent-Dev Loop is then transferred to a later reviewer.

However, no tool trace or Oversight Record can prove that the developer genuinely understood and reviewed the change. Developer Review ultimately remains a matter of professional responsibility and trust between the steering developer and their peers. The developer is not claiming that no defect can remain, but that they have seriously reviewed the work, performed the stated verification, and represented their judgments and uncertainties truthfully.

If this responsibility is repeatedly or deliberately not fulfilled, stronger escalation may be required: smaller and more controlled Agent-Dev Loops, another developer working directly within the loop, additional supervision, or refusing to accept the change for Peer Review until sufficient understanding and verification have been established.

When teams first adopt agentic programming, some developers may also need additional support.³ In these cases, another developer can enter the Agent-Dev Loop as a pair reviewer or mentor rather than waiting until the final handoff.

The Development and Intentions of SCOPE

SCOPE is deliberately evolutionary. Instead of imposing unnatural workflows, it reflects the changing roles of developers, peers, automation, and code within the review process. It aims to bring emerging practices together and provide structure where teams are currently struggling.

The central shift is that the steering developer becomes the main driver of detailed implementation review within the Agent-Dev Loop, while peers provide independent challenge and maintain shared understanding and ownership of the system. This avoids requiring peers to reconstruct every implementation detail from scratch, while preserving the perspectives and accountability that independent review provides.

SCOPE also makes oversight explicit and proportionate. It clarifies who is responsible for reviewing agent-generated work, how relevant information is carried through the review process, and how oversight should adapt to understanding needs, change risk, and the assurance already established.

The model is intended to fit existing development practices rather than replace them. Teams can retain their established roles, workflows, and review mechanisms while defining proportional escalation in a way that fits their own environment.

SCOPE remains a candidate model, and I am actively seeking feedback and discussion to assess its strengths and weaknesses and revise it accordingly.

---

Special thanks go to Annie Vella, Robert Göritzer, Italo Santos, and Leif Singer for providing detailed and constructive feedback on this article.

---

1. What the harness and safeguards should look like is tool-specific. Development teams should follow current best practices while remaining aware that these practices change rapidly. ↩︎
2. For example, GitHub Copilot provides agent session logs and links agent-authored commits to them, while Jules provides activity feeds, code diffs, and final task summaries. These features improve traceability, but they do not replace the shared human assessment and conversation captured in the Oversight Record. ↩︎
3. Inexperienced developers should limit their use of agentic programming, create smaller changes, and receive more supervision from senior engineers within the Agent-Dev Loop during their learning process. ↩︎

Updated on August 12th, 2026