SCOPE: A Staged Code Review Model for Agentic Development

This is still a draft and the 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.

Before agentic programming, the dominant code review operating model centered on peers inspecting code changes. The goal was to make sure the code author had implemented the change correctly and taken the right approach, but also to support knowledge sharing and learning and provide a point of accountability and handover. The main inspection artifact was the code, often reduced to only the diff, meaning the changed parts, even though screenshots or live deployments already helped reviewers understand the change. The key characteristic was that code written by one developer was reviewed and improved by peers. This practice made sense because, for many changes, writing code took longer than reviewing it. Human reviewers could keep pace with the rate at which changes were produced and obtain enough context to assess the code. Also, as other developers would potentially add, remove or change code themselves, they needed intimate familiarity with the coding concepts used, which also made the time investment valuable for knowledge sharing. With agentic programming, however, both basic assumptions may no longer be true.

Why the Traditional Code Review Model Is Under Strain

Agentic code generation and agentic code review fundamentally change how quickly code can be produced, the role of code in software development, and how its quality must be established. Generating code is becoming faster than we can realistically read and review it. Yet, AI does not automatically increase the capacity of human developers to understand, review, and assess these rapidly produced artifacts.

As a result, many teams face growing tension within the traditional code review operating model. Emerging evidence suggests that AI adoption can increase reviewer workload through higher change throughput and larger change sets. As teams give agents more substantial tasks and greater autonomy, some changes will naturally become even larger.

In these faster development cycles, a peer who was not directly involved in creating the change may become less well positioned to act as the primary reviewer of every implementation detail. This is particularly true when that person is presented with a large and complex change only after it has already been produced. Reconstructing the decisions, assumptions, and iterations behind the change can require significant cognitive effort. This can lead either to superficial approval or to long review cycles, especially for large changes.

Some teams try to enforce small pull requests so that detailed peer review of every code change remains manageable. Yet, as code production becomes faster, the growing volume of small changes can still introduce substantial waiting time, context switching, and coordination overhead. This can reduce some of the speed gained through GenAI-assisted development, and impact the flow-state.

At the same time, GenAI does more than deliver speed improvements; it changes the role of code in programming, and how developers engage with code. As agents take over more of the implementation work and become increasingly capable, especially in low-level implementation tasks, the knowledge developers need begins to shift towards higher-level architectural and design understanding.

These developments do not reduce the need for human understanding, accountability and oversight. GenAI cannot upload a mental model to a developer, and apart from the possibility to introduce defects, it can also produce implementations based on flawed assumptions, introduce architectural or design drift, . Agents can enable developers to produce more work, potentially with higher quality and in less time, but it has also never been easier to produce plausible-looking, low-quality output. Distinguishing between the two can require significant effort, particularly when problems are buried inside a large change.

Code review therefore remains important, not because human reviewers can guarantee correctness or find every defect, but because teams still need to understand changes, challenge important decisions and tests, notice obvious problems, share knowledge, and maintain collective ownership of the system. However, its operating model needs to evolve as development becomes more agentic.

Introducing SCOPE: a multi-stage review model for agentic software development

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

The model is deliberately evolutionary. It reflects the changing roles of developers, peers, automation, and code within the review process. SCOPE aims to bring emerging practices together and add structure where teams are currently struggling. In particular, it clarifies who is responsible for reviewing agent-generated work, what information should be carried into peer review, and how review depth should change with risk, complexity, and uncertainty. In this way, SCOPE gives teams a shared language and process that allow them to benefit from the potential speed and quality improvements of agentic development while addressing the bottlenecks and risks introduced by these capabilities.

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

The central shift in SCOPE is that the steering developer becomes the first detailed human reviewer of the implementation, while peers provide an independent perspective, learn about the change, and challenge it at a review depth proportionate to the required oversight. The required oversight depends on the risk and complexity of the change, together with the strength of the assurance established before peer review. 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 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 return the change to Developer Review for improvement.

Proportional escalation is informed by change risk, which is established by the team before coding begins, and assurance strength from each stage. It determines not only how deeply the code is inspected, but also how large the change may become, when another developer or specialist should enter the loop, which artifacts require review, and whether the change can proceed at all.

Through this staged oversight and proportional escalation, SCOPE aims to preserve the advantages of agentic development while maintaining meaningful human collaboration, accountability, quality assessment, system understanding, and knowledge sharing.

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.

I see Agent Review as an additional, advanced automation layer alongside established checks such as linting, static analysis, and tests. As this is an automation layer owned by the steering developer, peer involvement is not required by default during this stage. 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. 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.

Early evidence suggests that agent reviewers can scale defect screening and accelerate parts of the review process. However, their effectiveness depends strongly on the task, context, surrounding harness, and safeguards in place.¹ Right now, industry focuses extensively on finding ways to make the harness and safeguards more reliable. For example, by directing agents to make failures, uncertainty, and unresolved findings visible to the steering developer rather than allowing the agent to present an unqualified success. Similarly, having different agents produce and review the work, or even different models, seems to increase the effectiveness of agent reviews.

A stronger harness can increase the confidence that developers and teams place in automated work and help them focus their attention on the parts that require human judgment. However, it does not prove that the implementation is as intended. Current evidence also does not yet show that agents generally outperform human reviewers in review quality, or that harness and safeguards can be completely trusted. Tests may be incomplete, specifications may be wrong, and the generating and reviewing agents may share the same assumptions. 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 automated checking mechanism that cannot provide accountability or take responsibility for the change. Oversight 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. During Developer Review the developer can not prove that the implementation is correct, and that is not the aim. Developer Review means that the developer looks closely enough through the code and the work-outputs of the agents to understand the implementation and accept the agent’s work as their own.

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.

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 complexity 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. 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 reviewers are less effective when they lack knowledge and understanding of a change. In a fast-paced agentic development environment, the steering developer may be the person best positioned to perform the first detailed human review because they have followed the work and should have the strongest mental model of 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 further 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, that complements the review with independence.

Preparing the Review Brief

The steering developer also takes responsibility for making the work understandable and reviewable by the team and for documenting the steps, decisions, and changes made during the Agent–Dev Loop. They do this by creating a Review Brief.

The Review Brief comprises two types of information:

1. Automatically captured context: checks, traces, affected areas, agent findings, and risk signals.
2. Developer explanation: intent, decisions, interpretation, uncertainty, and questions for peers.

The first part is a collection of evidence documenting what happened and which quality controls and safeguards were executed during the Agent–Dev Loop. This should be automatically recorded, and not changed by the developer. Its purpose is to make the work performed during the Agent–Dev Loop transparent.

The second part is the actual human handover and contains a summary of relevant decisions made or revised during the Agent–Dev Loop, along with any remaining uncertainties and unresolved concerns.
It tells peers how the steering developer understands the work and gives them something meaningful to discuss and challenge. It includes areas they consider most critical for review during Peer Review. Automation and AI may assist in creating the Review Brief, but the developer must own its content, verify its claims, and ensure that it reflects their own understanding.

Current tools are beginning to preserve more evidence from agentic development, 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. PR templates can also help developers create this document by providing providing a coherent structure.

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 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, review important decisions, inspect critical areas, instead of detecting minor problems 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. Low-risk or simple changes may primarily require a review of the rationale, supporting evidence, and system impact, while high-risk or complex changes 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 reviewer can and should take advantage of agentic capabilities. They can spun 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 used responsible, and the peers must take actions to ensure they are not blindly accepting an agents 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 Review Brief together with 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, complexity, risk and uncertainty of the change.

Risk, Assurance Strength, and Proportional Escalation

Proportional escalation in SCOPE is shaped by three related but distinct dimensions: change risk, understanding demand, and assurance strength. Change risk describes what could go wrong and how consequential the effects would be. Understanding demand describes how much human attention, explanation, and shared understanding the change requires. Assurance strength describes how much justified confidence the team can place in the review already performed.

Change risk includes both immediate and long-term harm. Immediate risks include incorrect behavior, production incidents, security or privacy failures, data loss, regulatory consequences, a broad blast radius, and changes that are difficult to reverse. Long-term risks include architectural drift, the erosion of system boundaries and assumptions, increasing coupling or complexity, and changes that make the system harder to understand, maintain, or evolve. These effects may not cause an immediate failure, but they can increase future costs and make later defects more likely.

Understanding demand 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 demand is not identical to defect risk. A change may have limited immediate consequences but still require substantial peer involvement because the team needs to develop a shared understanding of it.

Change risk should be established before implementation work begins and assessed as a team effort. This means that risk is already established during planning or design and depends on the assessments of several peers. As far as possible, risk assessment should also draw on mechanical signals, such as the paths touched, including authentication, payments, personally identifiable information, migrations, and infrastructure; code ownership; blast radius; reversibility; changes in test coverage; and whether the change crosses a service boundary. The team’s declared risk level may only raise the level indicated by these signals, never lower it.

Assurance strength describes the quality of the evidence and understanding established during Agent Review and Developer Review. It has two components. The first is the strength and suitability of the team’s automation baseline, including tests, automated checks, review agents, repository guidance, execution constraints, and the team’s experience with their reliability. The second is the change-specific work performed during the Agent–Dev Loop, including how the steering developer inspected, tested, challenged, and understood the implementation, and how clearly the resulting decisions, findings, and uncertainties are communicated.

All three dimensions affect the shape and depth of the SCOPE review during Developer Review and Peer Review. Risk and Understanding Demand are the main driver of escalation and sets the minimum required review depth. Escalation affects both the depth of review and how the change proceeds through SCOPE. Strong assurance may make the review more focused and efficient, but it cannot make a high-risk or high understanding demand change subject to low review depth treatment. In contrast, weak assurance always increases escalation and may prevent the change from progressing through Peer Review. The change should then return to Developer Review until understanding, evidence, or support improves.

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 strong assurance, 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 with an initial escalation assessment. One or more peers examine at any changes to the established risk level and understanding demand, assess the assurance strength documented in the Brief, and decide on a proportionate review depth. Based on this assessment, they determine 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.

This decision draws on the full set of available evidence, including the Review Brief, code, tests, specifications, acceptance criteria, architectural information, harness evidence, unresolved concerns, and relevant operational context. The Review Brief supports this assessment, but it is only one source of evidence and does not determine the escalation level on its own.

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, examines relevant evidence, and inspects 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 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.

Failure Modes and Safeguards

SCOPE depends on two judgments that cannot be made perfectly. First, the team must judge whether Developer Review was performed with genuine understanding and sufficient verification. Second, the developer and team must assess the risk of the change and choose a proportionate level of oversight. SCOPE cannot eliminate errors in either judgment, but it makes both explicit and creates clear points at which the work can be challenged, returned, or escalated.

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.

Peer Review should not silently compensate for weak Developer Review. The steering developer must be able to explain and substantiate the important decisions, tests, evidence, risks, and uncertainties. The Review Brief acts as a deliberate gate for detecting weak assurance, but a polished document may still create the appearance of care without demonstrating genuine understanding. Therefore, the information contained in the Review Brief should be falsifiable as much as possible. This means tool runs, checks, and outcomes should be automatically persisted and used. In addition, teams should have clear norms and expectations around trust and accountability.

The Review Brief cannot prove that the change is correct, and its contents may be easy to misrepresent. For this reason, Developer Review must be treated as a serious statement 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 performed and accurately documented the stated checks, decisions, risks, and uncertainties. If this trust is repeatedly or deliberately violated, SCOPE should respond through stronger escalation: requiring smaller and more controlled Agent–Dev Loops, limiting the developer’s use of agentic programming, involving another developer in the Agent-Dev Loop, or refusing to accept the change for Peer Review until sufficient evidence and understanding are demonstrated.

When teams first adopt agentic programming, some developers may need additional support.³ In these cases, another developer should enter the Agent-Dev Loop as a pair reviewer or mentor rather than waiting until the final handoff. This allows the team to strengthen the current change while helping the steering developer develop the understanding and review skills needed for future work.

Incorrect risk assessment

Risk assessment will never be perfect. It may be incomplete, biased, or based on assumptions that later prove incorrect. Developers may overlook consequences, underestimate uncertainty, or classify a change as low risk without sufficient justification.

To strengthen the risk assessment, both the steering developer and the team should participate in it. The risk should be determined during planning or design, before implementation work starts. The assessment should not be based on gut feeling or solely on the developers’ experience. Instead, it should follow a well-established risk framework that is easy to understand and apply. During the review stages, the initial risk level can be adjusted based on new insights. Any adjustment must be documented and justified. Uncertainty should increase escalation rather than be treated as evidence of low risk.

The minimum risk level should be determined using known risk factors that can be analysed automatically. Over time, teams should refine their assessment criteria using review findings, escaped defects, incidents, recurring rework, maintenance difficulties, and signs of architectural drift.

Conclusion

SCOPE is a new code review operating model for agentic development. It responds not only to the increased speed and volume of code production, but also to changes in how developers create, understand, and engage with code. Through staged oversight and proportional escalation, it addresses both the advantages and risks of agentic programming.

The central shift is that the steering developer becomes the main driver of detailed implementation review within the Agent-Dev Loop. This allows developers to work closely with agents, understand the resulting implementation, and benefit from their capabilities without repeatedly stopping for detailed peer review after every iteration. It also avoids handing a large, finished change to a reviewer who has little context and is expected to reconstruct the work from scratch.

Independent Peer Review remains essential, but its focus changes. Peers provide perspectives that the steering developer cannot provide alone. They challenge assumptions, identify blind spots, assess unexpected architectural and cross-system consequences, contribute specialist knowledge, and preserve shared ownership of the system. However, as agents take over more implementation work, peers do not necessarily need the same level of knowledge of every code detail. In SCOPE, the depth of code inspection therefore increases with risk, understanding demand and uncertainty.

SCOPE remains a candidate model, and I’d appreciate your feedback.

Special thanks go to Annie Vella 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 a Review Brief verified and owned by the steering developer. ↩︎
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 5th, 2026