How Code Reviews Evolve: A Multi-Staged Practice

Alternative Title: How Code Review Is Evolving: From Team Practice to Developer-Agent Loops

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, 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

Traditional Code-Review Practice Fail

Based on 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.

I propose a multi-stage approach, consisting of agent review, dev review, and team review.

First, there are AI review rounds in which agents review code that other agents have written. This can happen before a human has even looked at the code. The main artifact the agents examine is the code, but they may also inspect documentation files. 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 layer of automation.

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 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.

Finally, there is the handover to a second human or several other humans. 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.

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. Knowledge sharing and maintaining a mental model of the system are of the utmost importance.

Team-Level Review Is Changing

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.
While I would advise against replacing or omitting the developer-agent review cycle, I think it is wise to change the form of review at the team level depending on the needs. In fact, I think 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.

Can We Stop Code Review Altogether?

Some argue that even the steering developer may no longer need to look at the code. For 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.

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.

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.

Review Stages in the Agentic Coding Era:

Agent review:

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.

Responsibilities: mechanical defects, specification inconsistencies, tests, style, obvious implementation problems.

Developer review:
In the agent-dev review, the steering developer is often the best person to check whether the implementation matches the intended change.

Responsibilities: intended behaviour, implementation decisions, correctness, and the developer’s mental model.

Team review:
For the team review, a second person may be better positioned to challenge the underlying intent, assumptions, architecture, or broader impact.

Responsibilities: independent challenge, critical aspects, architecture, cross-system impact, knowledge distribution, and accountability.

How to Conduct the Reviews

Agent review: Currently, the best practices seem to involve using different models for writing and reviewing code. This is still evolving.

Dev review: 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.

Team review: Here we have three objectives: making 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.

The Role of Code in Code Review

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.

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.

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.

Risks with the Staged Reviews

• Agents: using the same agent, and both agents understanding the natural language in the same way if it was not clearly specified or was ambiguous, as language often is.
• Dev: not doing their work or not having enough expertise to do it well.
• Team: taking over too much of the dev review and being overwhelmed, or trusting too much in the dev review.

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.