Shipping software faster sounds like a straightforward goal: write code more quickly, complete more tasks, and merge more pull requests. But as development accelerates, another problem often appears. The volume of code waiting for review grows, and the process intended to protect quality can become the very thing slowing delivery down.

This creates an important question for engineering teams: does every code change need the same level of human review?

The answer may be no. As AI-assisted development and automated verification increase the amount of code teams can produce, traditional review practices deserve another look. The goal should not be to remove human judgment. It should be to use that judgment where it has the greatest impact.

A team can become significantly more productive without making its entire development process faster. That distinction matters.

I see this pattern more and more. One public example: at Imprint, the average engineer was merging four times as many pull requests as two years earlier, and some teams had increased their output tenfold.

More output does not have to mean more defects. In that same period, the company also reported falling incident counts overall. Those were company-wide trends with many causes, not the result of any review change, but they show that shipping more and staying reliable can go together.

However, code review became a growing constraint. The median time required to review a pull request increased from approximately 33 minutes to 77 minutes over the same two-year period. As more changes entered the pipeline, reviewers had more work competing for their attention.

This is a common operational problem: improving one stage of a process can expose the limitations of another. Developers may be able to generate and submit changes faster, but those improvements do not automatically increase the capacity of the people responsible for reviewing them.

The result is a growing queue. Engineers spend more time waiting for approval, reviewers face more interruptions, and the organization risks turning a productivity improvement into a new bottleneck.

Tip: When delivery volume increases, examine the entire development pipeline rather than celebrating faster coding alone. Track how long changes spend waiting for review, testing, approval, and deployment to identify where work is actually getting stuck.

Code review has traditionally been treated as one process with several responsibilities. But separating those responsibilities reveals why a single human approval step may not be the most effective way to handle every risk.

First, reviews support knowledge sharing. Less experienced engineers learn from experienced colleagues by seeing how they approach design decisions, identify problems, and maintain code quality. This is an important part of engineering development, but reviewing every individual pull request may become impractical when the number of changes increases dramatically. Teams may get more value from reviewing groups of related changes and discussing recurring patterns.

Second, reviews help prevent errors. Human reviewers can catch mistakes, but they are not necessarily the strongest or most consistent defense against every defect. Continuous integration and continuous delivery (CI/CD), automated tests, and verification tools can catch many problems systematically. These mechanisms can run against every qualifying change instead of depending entirely on whether a busy reviewer notices an issue.

Third, reviews can help prevent malicious behavior. However, even a careful reviewer may miss a deliberately concealed security problem, particularly when the change appears technically competent. Fixed rules for sensitive files, anti-abuse controls, auditing, and inspection of audit logs can provide additional protection. Security should not depend on a reviewer simply reading every line and hoping to recognize suspicious intent.

Fourth, some organizations have compliance requirements that specifically demand independent human approval for certain changes. These obligations cannot simply be ignored because automation has improved. They need to be identified and preserved unless the documented controls are formally changed.

The important distinction is that these four responsibilities require different safeguards. Knowledge sharing benefits from discussion and mentorship. Error prevention benefits from repeatable verification. Security needs dedicated controls and auditing. Compliance may still require documented human approval.

Treating all four as reasons to manually inspect every pull request can create unnecessary work without guaranteeing better protection.

Tip: Identify the actual purpose behind each review requirement. If a process exists for security, compliance, learning, or defect prevention, establish the most effective safeguard for that specific responsibility instead of assuming one approval step can accomplish everything.

One practical way to reduce review pressure is to classify changes according to their risk and complexity.

The approach I recommend is an earned fast lane: a narrow path for contained pull requests that qualify for faster approval. Developers do not decide for themselves whether a change is small; automated checks determine eligibility.

Here is the kind of rule set I would start from (example only):

These conditions matter because a change involving a familiar service and a limited number of components is not necessarily as risky as a change affecting shared infrastructure or several unrelated systems.

The process also avoids relying solely on labels that developers can manually add or remove. A visible label helps people recognize eligible changes, but the actual eligibility decision comes from a passing GitHub check managed by the build process. This provides a more reliable basis for automation.

The approach does not mean every small pull request is automatically safe. It means that a change must pass defined requirements before it can receive a different review treatment.

That distinction is essential. Faster approval should be earned through evidence of limited scope, author familiarity, and successful automated checks, not simply because someone describes a change as minor.

Tip: Build objective eligibility rules before introducing faster approval. Define limits for code size, affected components, author experience, automated findings, and sensitive areas so that the process does not depend on individual judgment alone.

When review queues become overwhelming, using AI to generate more comments may seem like an obvious solution. An automated reviewer can inspect code quickly, identify possible issues, and provide suggestions without requiring another engineer to read the entire change.

But more feedback does not automatically mean better review.

A problem emerges when AI-generated comments are treated as though they represent a human reviewer's considered judgment. Some comments may identify genuine defects, while others may be incorrect, irrelevant, or based on assumptions that do not apply to the system.

The developer then has to investigate each comment, determine whether it is valid, and potentially make changes or explain why the suggestion is unnecessary. If another AI tool is used to respond to those comments, the process can become a cycle of automated suggestions and automated replies.

The team may appear to be conducting more reviews, but meaningful human involvement and learning can actually decrease.

Some call this meat proxy review: a person becomes a stand-in for an automated review process, spending time managing comments they may not personally endorse or understand.

The result is a review workflow that creates activity without necessarily creating confidence. Developers spend time resolving the output of one AI system through another, while the underlying verification process remains unchanged.

A better approach is to improve the centralized review mechanism and the automated process that checks whether feedback has been addressed. If an AI reviewer repeatedly identifies the same issue, that finding can become a permanent rule, test, or verification step.

This turns an individual comment into a system improvement. Instead of asking engineers to catch the same problem repeatedly, the organization builds a mechanism that can prevent or detect it consistently.

Tip: Measure AI-assisted reviews by the quality of the problems they identify and prevent, not by the number of comments generated. A smaller number of reliable findings is more valuable than a long list of suggestions that developers must independently investigate.

When a team reviews changes individually, it can become difficult to recognize patterns across the wider codebase.

One pull request may reveal a confusing interface. Another may expose a missing test. A third may introduce a similar implementation problem in a different service. Each issue can be addressed separately, but the organization may miss the opportunity to solve the underlying cause.

Batch review offers another way to approach this problem.

So I like to review pull requests in batches as well as one by one: look at a group of recent changes together and ask what themes keep coming back. Instead of focusing only on whether each individual change deserves approval, this looks for recurring weaknesses and chances to improve verification.

For example, several changes might reveal that developers repeatedly misunderstand how a particular service handles errors. The immediate response could be to comment on each pull request, but a more effective solution may be to improve documentation, strengthen automated checks, or introduce a shared implementation pattern.

This is where code review can become a source of organizational learning rather than a collection of isolated approvals.

The goal is not to eliminate individual reviews. Some changes still require close attention, particularly when they affect sensitive systems or introduce unfamiliar behavior. However, reviewing clusters of changes can help experienced engineers spend more time identifying systemic issues and less time repeating the same feedback.

Tip: Look for patterns across completed and pending pull requests. When the same mistake appears repeatedly, consider whether the root cause is missing documentation, unclear architecture, weak automated checks, or an incomplete development process.

Another approach to reducing review workload is to move more implementation and verification into a controlled development environment.

Picture a centrally run harness that implements and verifies changes under controlled conditions, with independent evaluation deciding how many reviewers a change needs.

The number of independent reviewers can vary depending on the assessed risk. For a sufficiently safe change, the process may involve one human reviewer alongside the automated system rather than requiring several people to inspect the same work.

This is a different way of thinking about engineering oversight. Instead of automatically assigning the same review requirements to every change, the organization evaluates what kind of independent scrutiny is appropriate.

The important part is the combination of controlled execution and separate evaluation. An AI system writing code should not be the only mechanism deciding whether its own work is correct. Verification needs to provide an independent assessment rather than simply accepting the output of the implementation process.

This also explains why improving the development harness is more important than adding more AI tools without a clear structure. A controlled environment can standardize how changes are implemented, tested, and evaluated. That creates a more consistent foundation for deciding when human attention is essential.

However, automation cannot remove the need for judgment in every situation. Complex business rules, unusual configurations, sensitive financial operations, and security-related changes may require deeper human scrutiny. The more complicated the domain, the harder it can be to prove that automated verification covers every important scenario.

Tip: Keep implementation and verification meaningfully independent. An automated system should not be considered reliable simply because it confirms its own work; use separate checks, tests, and human oversight appropriate to the risk.

Start small and expect the fast lane to be narrow. In the example above, roughly 10% of changes qualified at first, and sensitive areas such as security and money movement could still block fast approval. That is the right starting point.

That figure is important because it shows that the initial goal was not to remove human review across the entire engineering organization. It was to identify a specific category of changes where the existing safeguards could support a faster process.

The bigger challenge is expanding that category without weakening reliability.

As verification mechanisms improve, more changes may become eligible for reduced review requirements. But this will require more than increasing the number of automated checks. Teams must demonstrate that their systems can detect the kinds of failures that matter in their particular products.

A technique that works well for a product with relatively predictable user behavior may not provide enough coverage for software with complicated business rules, different customer configurations, or sensitive workflows. The same testing strategy cannot be assumed to provide equal confidence everywhere.

There is also a cultural challenge. Engineers have been taught that careful manual review is a fundamental part of producing good software. Changing that practice can feel uncomfortable, especially when it appears to challenge standards that have been followed for years.

But engineering practices should serve their purpose, not become permanent simply because they are familiar. If a process creates more delays than protection, it deserves to be reconsidered. At the same time, removing an established safeguard without proving that another mechanism can replace it would be reckless.

The path I trust is gradual: start with a narrow category, define strict eligibility rules, monitor the results, and fix the system whenever something slips through, before you widen the policy.

That is a more sustainable way to introduce change than making a sweeping decision to automate every review at once.

Tip: Treat faster delivery as a system-level responsibility. If an eligible change causes an error, investigate how the automated review, testing, configuration, or development harness failed to detect it. Improve the system so the same problem is less likely to happen again.

The traditional pull request review process was built around a development environment where producing code was relatively slower and human review could serve several purposes at once. AI-assisted development changes that balance.

When engineers can produce substantially more code, the old workflow may no longer scale. Increasing the number of reviewers or asking people to approve changes faster does not necessarily solve the underlying problem.

The more useful question is whether each safeguard is still doing the job it was designed to do.

Human reviews remain valuable for difficult decisions, knowledge sharing, sensitive changes, and areas where automated verification cannot provide enough confidence. But routine error detection can increasingly be supported by automated tests, controlled development environments, and independent evaluation systems.

The strongest engineering organizations will not simply replace people with AI or preserve every existing process unchanged. They will learn which responsibilities benefit from human judgment, which can be handled more consistently through automation, and where the two need to work together.

The real opportunity is not just to merge more pull requests. It is to build a development system where more work can move forward without creating more incidents, more review queues, or more unnecessary interruptions.

That requires continually questioning familiar practices and being willing to improve them when the conditions around engineering work change.

Hit reply and tell me which kind of change you'd trust to merge with a lighter review, and what check you'd need to see first. I read every answer.

Keep going, one small spark at a time.

Erwin