Code Reviews: From team to individual practice
This is still a draft. If you read it and want to give me feedback (I’d appreciate} write me at michaela @ michaelagreiler.com
Before agentic programming, code review was a team practice in which other human developers looked at code written by one author. The goal was to make sure the code author had implemented the change correctly and taken the right approach, but also to share knowledge and learn, and to provide an accountability and handover step, ensuring that insufficiently developed code could not reach production. The main inspection artifact was the code, even though screenshots or live deployments already helped reviewers understand the code change. Code reviews could be conducted in several ways, synchronous, asynchronous, and also the number of involved people changed. Yet, the key-characteristic was that code written by one human was reviewed and improved by other humans. This practice also mainly made sense, because for most changes, writing code took longer than reviewing code. This basic assumption is no longer true.
Why traditional the traditional code review model fails
Agentic code generation, but also agentic code reviews fundamentally change the speed but also the quality with which developers can now generate code. Writing code is now faster, than we can realistically read and review it. Thus AI does not drastically change the capacity of human developers to understand or verify the generated artifacts. Therefore, many teams nowadays face the problem that the old code review operating model does not work anymore. They face more code changes, and lager pull request, and developers are taking on new often more complicated tasks. One major consequence from this is that a peer, that was not directly involved in the code creating, becomes less and less enabled to actually review the code. On the other hand, we have very strong and powerful technological helpers in form of agents, that empower developers to do more work, in less time. Finally, while GenAI is a powerful tool, it cannot overtake human oversight, and accountability. It was never easier than nowadays to create high-quality work, as well as low-quality slop, and the differences are hard to tell from a first glance.
Based on all those developments, data on changes in the Software development life cycle, and my experience working with teams on code reviews for several years, I’d like to propose a new model for reviews that embraces the technological advantages of agentic code reviews but simultaneously mitigates the risks that come with merging without oversight:
SCOPE: a risk-aware, multi-staged review model
SCOPE stands for Staged Code Oversight with Proportional Escalation. It is a risk-aware multi-stage approach, consisting of three steps:
- Agent Review
- Developer Attestation
- Risk-based Team Assurance
The SCOPE model in a Nutshell
Code review in agentic development needs to change in order for us to be able to take advantage of the speed and quality improvements that are possible in an agentic era, but also to enable us to react to the new bottlenecks, problems and significant risks that come along with agentic capabilities. This model aims at allowing us to take advantage of AI, while ensuring that human oversight and understanding stay central in the software development life cycle. It shows code review as a risk-aware, multi-stage practice. Agents perform repeated code-level checks. The steering developer reviews and accepts responsibility for the implementation and produces a human-driven account of the work. And human peers signs off, but the depth and focus of that review depend on risk. The relevancy of code changes based on risk, and experience. Generally, the more left in this cycle we are, the more important role plays code. Detailed implementation review increasingly moves into the developer-agent loop, while assurance and accountability remain collective. For team sign-off code only plays a role on critical paths. Human oversight, accountability and sign-offs are critical elements of this new operating mode.
Let’s look at each of those three steps in more detail.
Stage 1: Agent Review
The first review steps starts already during code generation. Here, GENAi can be used to automatically and fast check code that other agents have written. This can happen even before a human looks at the code. The main artifact of this review step is code, as well as the documentation files, and agent directives that tell the GenAI which issues to look for, or which conventions or patterns to enforce. I see this as an equivalent but more advanced stage of the automated checks we already had before AI, such as linting, style checkers, static analysis, and tests. It is one more powerful layer of automation.
Agentic code review uses the full potential of this new technology and can check the likelihood of a good implementation within seconds to minutes, highly outpacing any human review capacity. Agents can catch many mistakes and problems that won’t be visible to a human due to our limited capacity. Yet they have limitations that can only be mitigated by a human reviewer.
The main responsibilities of agentic code review are mechanical defects, specification inconsistencies, tests, style, obvious implementation problems. There is a lot of literature on how the harness of agents should be put in place, and development teams should take care of following current best practices, but need also to be aware that practices change rapidly. At the time of this writing, many people believe for example, that using different models for writing and reviewing code improves the review outcome.
Stage 2: Developer Attestation
In the next stage, the human who instructed and steered the agent reviews the code and provides feedback. This is now the main code review stage involving a human. It is different from self-review because the developer did not write the code. Code still plays a major role here, but so do the agent’s summary and reasoning, which the developer will likely consume and examine. I see this part as the real shift in code review: from a team practice to an individual practice. It is much like the developer working with a compiler or autocomplete in the IDE. No other human is needed for the first detailed implementation review. There could be several rounds, between agent and developer, where the agent outputs or changes code according to the developers input, and the developer than has to check the generate code. In this loop, agentic code reviews could still happen.
The steering developer should posses a good mental model of the code, and therefore is the best person to check whether the implementation matches the intended change, and whether the agent actually did what the developer wanted.
The main responsibilities of the steering developer are checking the intended behaviour, implementation decisions, correctness, and the developer’s mental model.
If the developer has a good understanding of the intended code change, which is needed for a well-written, detailed specification prompt, the code review should be feasible, so that at least each file can be scanned for potential mismatches. One of the main blind spots of this approach is that if the developer misinterpreted the ticket, the agents will implement this misunderstanding, and the developer will deem it as okay. Another problem is if the developer misses expertise or insights that only other peers posses. For both cases, the next step is critical.
Stage 3: Risk-Based Team Assurance
In the final step, the code is handed-over to peers. This seems similar to the traditional team code review step. But because the first review phase has already happened, the focus of this second review round can and should shift to other aspects.
Code is then only one of several artifacts the reviewer can consider. As the focus of the handover shifts away from making sure low-level implementation details are okay and towards reviewing the solution approach, architectural and design decisions, and the quality of the developer-agent cycle, code becomes much less important. If we embrace agentic programming and the speed-ups that are possible with it, it will often also be infeasible to look at every line of code, so code plays a less important role at this stage.
At team level, the importance of code is risk-dependent. For low-risk changes, reviewers may primarily examine intent, architecture, verification evidence, and the quality of the developer’s handoff. As risk increases, reviewers should inspect the critical implementation paths, and sufficiently high-risk changes may still require a comprehensive code review. The form of team review may change, but independent human sign-off remains part of the model.
The responsibilities during team-review are to make sure the change implements the intended behaviour, fits the system’s quality standards, and reviewing enough of the change artifacts to have a good understanding of the changing system. Checking particularly risky or critical implementation parts. Architecture. Intent. Knowledge acquisition.
Our goals shift away from low-level implementation checks, to seeking knowledge transfer, and mitigation. For the team review, a second person may be better positioned to challenge the underlying intent, assumptions, architecture, or broader impact.
On team-level the responsibilities are independent challenge, checking critical aspects, examining architectural fit, understanding cross-system impact, knowledge distribution, and accountability.
Similar to code review before, the form of review on team level could change depending on the needs. For example, synchronous meetings, which are a form of code review, are often a good fit for team-level reviews. Other techniques for sharing knowledge and ensuring handover and accountability could also include walkthroughs or implementation inspections of certain high-risk or critical system parts.
One problem is that, although tool developers are working hard, we still lack reliable high-level evidence of the work and outcomes produced during the developer-agent loops. This should become the new review artifact at this stage. I see it as the code authors responsibility, thus the responsibility of the steering developer to create such a hand-over document. The developer can use AI to produce it, but it must be human-driven, thus no AI slop and contain the decision points, intend, risk-profile.
The New Human-Driven Handoff Artifact
The artifact handed to the team cannot merely be an AI-generated summary of what the agent claims to have done. It must be created and owned by the steering developer. AI may assist with drafting or extracting information, but the developer must decide what matters, verify every claim, and demonstrate their own understanding.
It should cover:
- the intent of the change;
- important implementation and design decisions;
- architectural implications;
- how the change was verified;
- relevant tests and their limitations;
- identified risks;
- unresolved concerns;
- parts of the implementation that deserve closer review.
This artifact also works as a quality gate: if it does not demonstrate sufficient understanding, care, and verification, the change should be returned to the developer-agent loop rather than forcing the team reviewer to reconstruct the work from the code.
Scaling the loop according to risk and experience
| Risk level | Team assurance |
|---|
| Low | Review the handoff artifact, intent, verification and architectural fit; code inspection optional |
| Medium | Inspect identified hotspots and critical implementation paths |
| High | Detailed code review, potentially multiple reviewers or a synchronous walkthrough |
Risk can play a role for the developer and the team part. On the develop attestation loop, the more experience and the low risk, the larger the code change can be. Rather the larger, the smaller a change should be. The less experienced the smaller a change should be.
On team level, the more risk, or the less experienced the developer, the more detailed inspection. Or, also, when there is a large change coming from a less experienced developer, the change goes back, to be smaller.
The risk factors are: blast radius, security, privacy or regulatory relevance, data migrations, reversibility, complexity, test strength, codebase familiarity and uncertainty.
The steering developer proposes the risk level and identifies review hotspots. The team reviewer independently confirms or challenges that assessment.
The depth of a team-level code review will be determined by several factors, but most importantly by risk. Risk can be influenced by the complexity of the task, the blast radius, security and regulatory relevance, but also by the steering developer’s familiarity and experience with the system or the quality of the tests.
Is the Steering Developer a Good Reviewer?
If we look at the empirical evidence on code reviews, we see that the less knowledge and understanding a developer has about a change, the less effective their review is. I see the developer steering the agent as, on average, the most suitable reviewer of the changes because that person already has a good mental model.
Yet having the steering developer review the code also comes with the trade-off of confirmation bias. This developer created the intent, selected the approach, accepted intermediate decisions, and may share the agent’s assumptions. We have to keep exactly this in mind for the team-level review. If we want a completely fresh pair of eyes, the detailed implementation review has to come from the team. Yet here we face the problem that they probably do not have enough understanding to review meaningfully. In practice, I see that non-meaningful reviews are worse than thorough reviews with confirmation bias. And we can deliberately mitigate confirmation bias in the team-level review.
If we really want to embrace the technological advantage of an agent generating code within seconds, we need someone who already has a good mental model of the code change to be able to review it realistically. It also means that if developers are not experienced enough to review agent-generated code, we have to slow them down by creating smaller changes.
The size of the developer-agent loop should be limited by the developer’s ability to maintain a reliable mental model of the change. Lower-risk changes and strong codebase familiarity may allow larger bundles. Higher risk, unfamiliar systems, or limited review experience require smaller iterations and earlier involvement from another developer.
The Role of Code in Code Review
The importance of code in SCOPE is stage-dependent and risk-dependent:
- central during agent verification;
- central during developer attestation;
- selective during team assurance, increasing again as risk rises.
Code plays one of the most central roles in the agent-to-agent review cycle, in addition to documentation and other agent instructions.
Code still plays a very central role in the developer-agent review. Here, additionally, the developer can use agent summaries to make sense of the code change and also direct their attention to the most critical parts for closer review. Reviewing test code becomes much more critical, and really understanding the strategies we use for our safety net, whether those are appropriate, and whether they can give us confidence is important. Test code was often not reviewed thoroughly in pre-agentic eras, and the risk of this pattern continuing is high.
Code is also important at the team level, but more in highly critical or high-risk areas, or when trust in the dev-agent review is shaken. At the team level, we actually can and should also use other artifacts to help us judge the code change, such as the quality of the specification, acceptance criteria, or tests.
The Dev-Agent Review Cycle
The dev-agent review cycle is now the heart of code review. Here, the developer steering the agent takes a close look at whether what they intended the agents to do was actually done. Often, even with very precise prompts or specifications, there might be decisions we have not foreseen and that the agents made for us. It is exactly at this point that we should make sure all those decisions are made the right way, or correct them. But this dev-agent review is not only a place to check the correctness and validity of the solution, but also to ensure the developer keeps a reliable mental model of the system and its implementation details. Yes, you can observe a lot via black-box testing, but it is not enough. We need to know the details of the implementation, especially for complex concepts such as synchronization in multi-user scenarios or details of algorithms when it comes to complex work. Code is the place where the story we tell ourselves, or that agents tell us, has to face reality. Summaries, reasoning traces, and successful black-box tests cannot fully replace inspecting the implementation. Agent-generated explanations cannot serve as proof that the work is correct.
Dev review is also important because the steering developer should be responsible for understanding, validating, and accepting the changes from the agentic loop. Agent-agent review cannot take over this responsibility, nor can the team.
Small, Iterative Developer-Agent Loops
I am arguing for small, iterative changes within the developer-agent loop. I am not talking about a 400-line review boundary, there is also no empirical evidence for that yet. I am talking about the realities of human understanding.
What “small” means will depend on the complexity of the changes and the experience of the reviewer. The change should be small enough that the steering developer can comfortably review the code. When they feel overwhelmed, it is a good sign that the code change is too large. Yet, after several iterations, the code change produced in the dev-agent loop could get larger than what we “normally” would consider a good sized PR, in pre-agentic times.
Does the Steering Developer need to Look at the Code?
Some argue that the steering developer may no longer need to look at the code. That with a good enough harness, AI can write and review the code, and there is no need for human inspection. To me, this is like Schrödinger’s cat. Yes, the cat could be alive, but you do not know.
The more powerful the agents become, the less important it may be to check every line. But it is still important to inspect the code and the files that changed. A quick review of the changed code artifacts can reveal much more than an agent’s reasoning alone, which, by the way, can also be flawed or incorrect. So perhaps we no longer have to examine every line, especially when we are experienced, but we still need to build a good mental model of the implementation. The less experienced a developer is, the more carefully they should inspect each line and each file. Relevant factors can include domain familiarity, codebase familiarity, task complexity, or review skills.
It does not mean that we don’t need to look at code anymore. It means:
- raw code is no longer necessarily the default or only artifact;
- low-risk changes may receive team sign-off without a code inspection;
- higher-risk changes trigger targeted or detailed code review;
- code stays important on critical paths.
Warning: Low-Quality Developer-Agent Work
One potential problem is that it is not obvious whether code produced in the developer-agent loop is of high quality. LLMs allow us to generate code within seconds, but producing good code still requires effort and expertise. The problem is that code, even code produced with little effort or oversight from the steering developer, looks plausible at first glance.
There are no reliable mechanisms yet for checking its quality without reviewing it. So, if the steering developer is not doing their part, or if they are inexperienced, this can lead to code review exploitation, in which the second human reviewer has to review the code in depth. This also means that verification work that should be placed inside the developer-agent loop is shifted onto a later reviewer. It can also lead to low-quality code reaching production. This is largely a matter of trust and experience.
In the beginning, when moving from traditional code reviews to agent-steered reviews, the team reviewers should make sure each developer is ready. If not, the reviewer should step into the developer-agent loop to provide supervision and help, rather than remaining outside the loop for the handover. This means smaller, more iterative changes and pair-reviewing activities that serve as mentoring and learning opportunities.
(Make a picture in which the second developer steps into the individual practice and the two work as pair reviewers.)
Footnote: Inexperienced developers should use less automation, create smaller changes, and receive more supervision from senior engineers during their learning journey.
Objections
Some might ask: “Isn’t It All Pair Programming?” Is the developer-agent review actually a review, or is it rather a pair programming session? Well, many agentic workflows are fluid and iterative. The developer and agent explore the codebase, revise plans, run tests, discuss failures, and modify the implementation repeatedly. This does look and feel very much like pair programming. Yet there are several moments when the agent produces an implementation and the developer has to switch to review mode. The more we embrace agentic programming, trust agents to do more work autonomously, and step out of this co-creation loop or pair programming, the more our interaction with agents becomes review work.
Conclusion
So, the major changes I see are:
- Who performs the review: increasingly, the developer steering the agents.
- What is reviewed: code, but also higher-level artifacts and evidence.
- Where code review happens: increasingly within an individual developer-agent loop before the work reaches the team.
Agents can generate code within seconds. The quality of this code can vary significantly. Reviewing code is therefore still an important technique, both from a quality and an understanding perspective.
Yet, as we try to embrace the advantages that the new technology brings, developers find themselves faced not only with larger pull requests but also with more pull requests. Trying to preserve the traditional pull-request ritual unchanged will create larger queues, exhausted reviewers, shallow approvals, and growing resentment.
The shift towards an individual code review practice within the developer-agent loop, combined with changes to team-level review practices, allows for faster code generation while still ensuring code quality and supporting knowledge-sharing goals.
