One of our developers has recently raised a new concern in our shared Slack area since they are under pressure to review a pull request which includes more than 40,000 lines of change.

It isn’t new to have to look at huge diffs, but the increasing use of AI to produce more code more quickly is causing us to encounter such situations more frequently.

I think that the typical size of PRs is growing since developers are becoming more ambitious in the amount of work they include in each development step, as it is easy for coding agents to generate more lines of code.

It remains a hypothesis and not a conclusion. The teams should check whether their PRs are in fact growing in size and also whether they are becoming more difficult to understand, verify, and operate. The number of lines altered by itself does not completely indicate the review burden.

But that is not the only source of tension. We no longer write most of the code by hand and now spend more time reading it and evaluating it than writing it. Therefore, even if the size of PRs had remained the same, we could still be losing effectiveness as reviewers.

If you’re suffering from review fatigue, dealing with huge diffs, or noticing a greater number of unexpected defects, then you have a code review problem.

The real issue isn’t merely that AI generates more code; it is that human review has become a scarce resource even though most teams still distribute it in a rather even manner. We must make a deliberate decision about which changes need human involvement, what sort of involvement they need, and also determine which other kinds of feedback can safely share part of the responsibility.

To review or not review

The more software development takes on an agentic character, the sensible aim should be not to decrease validation but to lessen the extent to which humans have to read each line of the generated code. Loop engineering encourages development teams to create feedback loops which enable the agents to reach acceptable results with ever decreasing need for human supervision.

All the various types of testing, static analysis, type systems, architectural constraints, runtime checks, and observability can shift some of the validation tasks away from the final human inspection. The goal is not to produce code that is never verified by anyone, but rather code for which humans do not need to be the main method of verification.

Since some of the feedback loops depend on non-deterministic methods such as evaluations by using a large language model as a judge, a certain amount of human verification will still be necessary. The reasonable question then becomes how much human inspection a particular change requires, considering the strengths and limitations of the other validation methods nearby.

Teams which have successfully adopted these practices might reasonably think again about how deep human code review should be. Instead of selecting a single classification method, they can assess the changes along a number of different dimensions.

• Complexity: how easy or difficult is the change to understand and reason about?
• Business risk: what would be the impact if the change was wrong?
• Uncertainty: how familiar is the team with the area, the technology, or the method?
• Strength of the feedback loops: how confident can automated systems be in identifying incorrect behavior?
• Review abstraction: should the change be examined on a line-by-line basis, subject to behavioral validation, or require a higher-level architectural review?

A small alteration to a payment feature might warrant more human attention than a much larger one that is automatically generated. In the same way, a major change that is supported by solid deterministic tests would need a different sort of review rather than having proportionally more review.

Regarding long PRs: in certain teams they are the result of a fast software development pace and a wide scope for each development iteration. We could always introduce strict limits on PR size, but that might also lead to higher coordination, integration, and interruption costs.

A team might need to reevaluate not just the way the final PR is reviewed but also when the reviewing takes place if it has good reasons for wanting to make larger changes. Each of the aspects such as intent, specifications, implementation plans, architecture, intermediate results and the final behavior can be looked at at different times and it is not necessary for the final diff to hold the whole of the review workload.

Some ideas to try

First of all, the code review issue must not be left unaddressed; it should provoke a clear team discussion and be subject to continuous oversight. It is not sufficient just to ask developers to do their best without providing them with any guidance or a set strategy.

It is reasonable for stakeholders to expect the productivity gains which coding agents can provide, but it is equally important that the development team remains accountable for the system. No one wants an application to be delivered in record time only for it then to fail in a way that seriously frustrates its users. Likewise, developers should continue to be involved in achieving productivity gains in a controlled manner.

The next piece of advice is to base yourself on evidence. Those teams who are carrying out experiments involving reduced human review should assess both the quality of the final system and the amount of review effort which is being saved.

Escaped defects and the amount of time needed to correct them are a good place to start. Apart from that, rollbacks, reverts, production incidents, and the subsequent fixes can offer further indications. On the other hand, the teams should also note the time it takes to carry out reviews, the latency of the reviews, and how often reviews detect problems that result in significant changes.

The aim of these metrics is not to show that having fewer reviews is always better; rather, it is to determine the situations in which reduced reviewing is safe, the ones in which it leads to unacceptable costs, and the cases where stronger feedback loops are still required.

Conclusion

Since I have always liked working on projects where the health of the codebase and the quality of the system were important, I admit that it is a bit intimidating to work with a codebase in which the various parts have not been checked over by people. The issue then becomes how to make sure that we still have a solid safety net in cases when the situation is serious. Bringing about these changes calls for courage and a readiness to go beyond our comfort zone.

The effects of AI coding agents on everyday project work are still being taken in by the software development industry, and that is exactly the time when we should examine each aspect of the development process, especially code review.

The aim must not be to keep code review as a ritual or to get rid of humans from the process as rapidly as possible; rather it should be to maintain the results that code review was intended to achieve: correctness, shared understanding, maintainability, accountability, and confidence in the system.

Human inspection is likely to be one of the methods employed in order to achieve those results, but it does not have to take the same form or be applied with the same level of scrutiny to each change.