SCOPE: A Staged Change Oversight Model for Agentic Development
SCOPE is a new Review Model developed for the agentic era. The essence of SCOPE is already present in its name, which stands for Staged Change Oversight with Proportionate Escalation.
If that sounds difficult, please bear with me just for a little while.
SCOPE builds upon two main ideas:
First, Staged Change Oversight means that the oversight a change gets does not happen in one place, at one time, or by one actor, but that review happens at multiple stages and by diverse actors. SCOPE can have up to four distinct review stages that can be seen as review building blocks: Initial SCOPE Review, Agent Review, Developer Review, and Independent Review.
The second central idea of SCOPE is Proportionate Escalation. This means that each change can be treated differently based on what the Oversight Needs are for that particular change.
Those two concepts make up the heart of SCOPE. SCOPE has already been partly assessed and refined through an initial empirical evaluation with several software development teams. It’s still under active development, and feedback is very welcome.
But let’s dive into each of the two main concepts a little bit deeper.
Proportionate Escalation
Let’s start with Proportionate Escalation, a core concept of SCOPE. As said, not every change gets the same amount of Oversight. The Oversight Needs of a change are determined by two factors: Involved Risk and Alignment Need.
Risk captures the potential negative consequences if a change goes wrong, while Alignment Need captures how much shared understanding, coordination, or awareness a change requires across the team.
Changes that have a low risk profile and a low alignment need get significantly less oversight than changes with a high risk and/or alignment need. For low-risk and well-understood changes, only a few review stages are needed, for example, Initial SCOPE Review and Agent Review. On the other hand, a change that poses a significant risk or has a high alignment need can undergo more and/or more intensive review stages.
The oversight intensity of a change is determined before the change is implemented, during the Initial SCOPE Review. Here, the team also creates an OSR (Oversight Record), in which the team describes the oversight decisions. Those decisions are revisited and can be altered at every review stage as more or new information about the change becomes available.
Code still plays a role in SCOPE, but is not necessarily the predominant or most important artifact to review, inspect, discuss, and improve anymore. Apart from code, the team might also review the specification, the ticket, the implementation execution plan, and the agent execution; test the system itself; or investigate the system with an LLM. How much code is reviewed depends on the Oversight Needs. If code review helps to reduce risk or alignment needs, reviewers will look at relevant code parts. SCOPE makes this shift because oversight increasingly concerns intent, plans, execution, and system behavior rather than only the final diff.
To learn more about Proportionate Escalation and Oversight Needs, you can read the SCOPE deep-dive. But for now, let’s have a look at the second fundamental concept of SCOPE: Review Stages.
Review Stages in SCOPE
In SCOPE, review happens at different times and for different reasons. Most importantly, compared with traditional code reviews, reviewing starts before code has even been created, in the Initial SCOPE Review. This review is ideally done by a team instead of just one person and uses the artifacts that describe the work that needs to be done. Those could be the ticket, a specification, and/or even the plan that will be executed by an agent.
Apart from shifting review left in the first review stage, SCOPE also differentiates between three different follow-up review stages: Agent Review, Developer Review, and Independent Review. Each one of them has its place, time, and goal. They can be seen as building blocks that we use to fulfill the Oversight Needs of this change.
Agent Review describes an automated review stage in which LLMs are used to challenge and inspect the code in combination with static and deterministic checks. This step can be performed fully automatically, with the agents not only reviewing the code but also automatically reworking it. It can also happen semi-automatically by combining it with either Developer Review or Independent Review. If this is the case, humans take over the judgment of the agent’s feedback and the steering of the change’s rework.
During Developer Review, the developer reviews the code. This can happen completely manually (although those occasions get rarer) or semi-automatically with the help of LLMs. The main difference from Agent Review is that the developer steers the LLM during the inspection. The LLM is used as a tool that helps the developer perform the review, while the developer sets the direction and also performs the judgment. An important part of Developer Review is the emerging Agent–Dev loop. Many developers naturally inspect, question, and correct the code LLMs produce as they steer the LLM during implementation, even though this activity is not always recognized as review. SCOPE treats this as legitimate and important review work, especially in workflows where developers still closely steer the LLM throughout implementation.
Another review stage of SCOPE is called Independent Review. During this review stage, other team members investigate the change. They bring a different perspective and strengthen the review by challenging the change and the previously performed investigations. This step can also happen manually or semi-manually, with LLMs used as tools for the review while the human stays in control. It’s important that, as we recognize the work the developer has already done as a review, Independent Review does not merely perform the same checks again, but really focuses on the value that additional pairs of eyes can bring to the table.
The stages can be seen as building blocks, and several sequences are possible. For example, a change might go through Initial SCOPE Review → Agent Review → Developer Review → Independent Review, or Developer Review might happen before Agent Review.
Importantly, for many teams, several changes will not need to go through all four review stages. In the initial empirical evaluation, teams already identified many changes for which two or three review stages appeared sufficient. How often this applies will likely depend on the industry, risk profile, and company culture.
Conclusion
SCOPE is a response to the current developments with regard to software engineering in an AI era. It not only helps reduce the review burden, but also makes sure scarce human attention is spent on the most impactful and important aspects, through different review stages and proportionate escalation. If you want to know more about SCOPE, you can also read the deep-dive on SCOPE.
SCOPE was not developed from scratch but is deliberately evolutionary, and has already been empirically evaluated. The model covers the natural evolution that AI brings to teams while adding structure and alignment where teams are currently struggling. I’m currently assessing and fine-tuning the review model through studies at different companies. I’m actively seeking feedback, so please reach out to share your view.
