This week's newsletter is sponsored by Unblocked.

Agents can generate code, but getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have an organizational context engine to give agents exactly what they need for the task at hand.

Join a FREE webinar on April 23 to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context engine solves for quality, efficiency, and cost

• Live demo: the same coding task with and without an organizational context engine

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

There is a lot of hype regarding AI and how big a productivity increase it brings. But there’s a lot less talk about the side effects of it.

And the side effect is that teams are drowning in PRs and are not able to review them fast enough. So, it’s important that the code review process evolve as well.

Of course, this really depends on the size of the codebase and the overall complexity of it. The more complex the codebase is, the less productivity increase AI brings.

In today’s article, we’ll go through why PR reviews have become a new bottleneck for engineering teams, and what to do to ensure that they become less.

Let’s start!

Fast PR Reviews Have Always Been a Signal of High-Performing Teams For Me

PR Cycle Time (time from creating the PR to merging it) has always been a metric I liked checking for the teams that I have led over the course of my career.

I am not saying it has been 100% the case, but faster PR Cycle Time has, in many cases, shown to be a case for high-performing teams.

The reason is that the more time we let the PRs stay unreviewed, the more context we need to keep holding in our heads, and the harder it is to move to other things.

Let’s say an engineer creates 1 PR, waits for the review. In the meantime, they start working on another one and later also open a PR. That engineer now has 2 PRs opened and needs to keep the context of both in their head.

And then what if his 2 PRs haven’t been reviewed yet, and they start working on the 3rd one? Then suddenly, the context gets blurred, and especially “why” something has been done the way it has been done gets forgotten. That’s where issues arise, edge cases get forgotten, and bugs get deployed to production.

Now, let’s go through the problematic part of doing code reviews.

The Problem with Code Reviews

For me, personally, I always enjoyed building more and doing code reviews less. And I think the majority of the engineers/engineering leaders would agree with that.

The reason for that is the following.

With building:

• You are solving problems, and you get satisfaction when you solve a certain problem → the code you write or remove results in a change of behavior.

• You are making visible progress, which increases dopamine.

• Finishing a task, closing it, and seeing the change you made directly in production motivates you to keep going and keep building.

Doing code reviews:

• You need to get the full context of the changes and understand them if you want to really review the PR the right way, which takes a lot of mental energy, especially if you review a lot of different PRs. While understanding and getting the context, you may need to ask questions or get additional information from different sources.

• You are directly or indirectly responsible, depending on whether you are an assignee or a reviewer for the PR.

• You are expected to correct or find issues. And giving feedback might be hard, depending on a specific person, especially if a certain discussion results in disagreements between the author and the reviewer.

So, those are the reasons why building is a more enjoyable part of software engineering. However, it’s important to note that the more you grow in your career, the more you need to accept reviewing as an important part of your day-to-day.

That may be reviewing PRs, documentations, specifications, decisions, etc. Especially as a Staff+ Engineer, Architect, or EM+.

This is Also the Reason Why Many Teams Have Issues With PR Cycle Time

Ever since I started working in teams as an engineer and we had mandatory PR reviews + QA engineers testing the PRs, it has always taken some time until the PR got merged.

And especially if the PRs included a bit more change than usual, or the things that we have been building were more complex, part of the legacy codebase, or the changes may have been a bit more ambiguous.

And every engineer has their own things they need to do and focus on, their own problems and initiatives, and doing code reviews is not their primary focus point.

Additionaly, most companies do not look at code reviews as a direct KPI of the performance of a particular engineer. And they shouldn’t as well.

Now, let’s go through an important point about why PR reviews have really become a bottleneck at this time.

Increase in Speed of Writing Code Results in More PRs Created Than Ever

With tools for development becoming better and AI-assisted engineering becoming a standard in our industry, the speed of writing code has increased exponentially. That also automatically means more PRs created.

Especially the 2 main reasons for more PRs created are:

1. Agentic AI PRs

With tools like Devin, OpenClaw, or similar, you can create a dedicated GitHub account for them, and then you assign them work which results in the PR being opened by them directly. The problem with it is that you lack the contextual information of the change, and you need to go over the full code changes when the PR is opened. This results in a lot of mental energy needed.

2. AI-assisted engineering

Using tools like Cursor, Claude Code, or similar, that’s where you use AI to help you generate the code needed in order to finish a certain task. It’s a much more common and preferred approach. In my opinion, it’s the best way to build software these days. You have the full context of the changes, and the PR is opened on your behalf.

Both of these 2 approaches drastically increase the velocity of new PRs created. Now, this sounds great and all, but let’s talk about the problematic part.

With More PRs Created, Code Review has Become a Bottleneck

So, now that we have more PRs created, code reviews have become the real problem in many engineering teams. I’ll be sharing some of the ideas on how to remove the bottleneck and think about code reviews in the latter part of the article.

The recent report from LinearB, called: 2026 Software Engineering Benchmarks Report, supports this. In the report, they checked 8.1M PRs from 4,800 engineering teams across 42 countries.

Especially the data of the difference between Agentic PRs, AI-Assisted PRs, and Unassisted PRs in regards to code review speed, makes a lot of sense.

• Agentic AI PRs have a PR Pickup Time 5.3x longer than Unassisted ones

• AI-assisted PRs have a PR Pickup Time 2.47x longer than Unassisted ones

The data provides a new finding, which is:

Engineers dread reviewing AI-generated code and often procrastinate when it comes to reviewing such PRs.

So, with more PRs created than ever and with the PR pickup time increasing, PR reviews have become a clear bottleneck.

An Important Note on Codebase Size and Complexity

The more complex a certain codebase is and the more architectural changes you need to make, the less productivity gains you get from AI in general. That has been reported by many of the engineers I talked to. So, usually, the longer the software exists, the smaller the increase in PRs there is.

The biggest increase is in greenfield projects, where you have an opportunity to set up things in a way that LLMs can provide a lot more accurate solutions.

That’s also the reason why frameworks such as Ruby on Rails and Angular have recently gained popularity. It’s because they are very opinionated, and best practices are clearly defined. This results in AI being able to generate much more accurate solutions.

Now, let’s go through my thoughts on how you can approach making PR reviews less of a bottleneck.

This is How you Can Approach Making PR Reviews Less of a Bottleneck

There are a number of different approaches you can take here, and it’s really important to ask yourself: “How can I make the work of reviewers easier?” or “What kind of PR would I like to review?” and do exactly that.

Here are my tips on how to do that:

1. Create test cases of your newly added code

With proper test cases, you automatically improve the confidence in your code, doing exactly what it is supposed to do. This also helps reviewers to have a lot more confidence in your code changes.

This is a great skill you can use to help you generate proper test cases based on the changes that you have made. There are many more skills created by Addy Osmani in this repo that would help you, and I definitely recommend to check it out: Agent Skills.

2. Use AI to review your code even before you open a PR

To make the job of reviewers a lot easier, it’s great if you do a pre-check of your code before opening a PR. Always keep in mind that you want to avoid any unnecessary back-and-forth regarding issues, because that usually takes a lot of your and the reviewer’s time before the PR gets merged.

There are many different AI code reviewing tools available, and you can use them, or you can also use a simple prompt or a skill from Addy’s Agent Skills repo.

3. When you open a PR, I recommend making comments on the parts that may be harder to understand

If you can predict where a certain part of the change may not be that clear to reviewers, make sure to add a comment on the PR in that particular change, even before you assign the PR to reviewers. It will help remove the back-and-forth and get your PRs merged faster.

4. Use an AI code reviewer to automatically review your PRs when you open them

Similar to reviewing PRs before you open a PR, you can use an AI to review your code when the PR is opened. That step is part of the CI, and you can use any of the AI code review tools that already exist, or you can also set up a prompt yourself.

I think that is one of the biggest improvements, and it should be a no-brainer in my opinion, as it makes it so much easier for reviewers to start reviewing when there is already an AI code review check being done, so you don’t start completely from scratch.

This change alone should drastically improve the PR Pickup Time metric. Now, let’s talk about the balance between AI and human reviews.

Balance Between AI Code Reviews and Human Code Reviews

As human code reviews are becoming more and more a bottleneck, I am hearing from many different people that they are relying more on AI code reviews.

For example, I recently talked to Andrew Churchill, CTO, Weave, and he mentioned that they use 4 different AI code review tools.

What they do is: they onboard a new engineer and do really great (human) PR reviews, but after some time, that engineer gets the context of the codebase, and PR reviews are reviewed mostly by AI reviewers.

He mentioned that this provides a lot of productivity gains, and they can move really fast because of it.

Also, Raphaël Hoogvliets, Principal Engineer, Eneco, mentioned that he configured a coding agent with a prompt: “You are a staff engineer. Review this PR. If it meets production standards, approve it. If it doesn’t, request changes with specific reasoning.”

He also based the agent’s skill config on the CV of an actual, really good staff engineer. This has worked well in his case, and he saw a lot of benefits in doing that. He now sees how big a bottleneck human PR reviews are.

I also believe that this is going to be the future of where we are heading as an industry. It’s going to be impossible to keep up with the pace of how fast we can generate code versus how fast we can review code.

Setting up great guardrails and increasing trust in AI code reviews is where you can get enormous productivity gains. Think about decreasing the PR Cycle Time from 2 days to 20 minutes. That kind of productivity improvement can make a huge difference.

A concern regarding AI code reviews I am seeing is for the companies that need to be SOC2 compliant. In order to do that, for every PR review, you need to have at least 1 human engineer confirming (outside of the author) the PR.

And also, an additional concern is with more complex systems. As mentioned above, the more complex your codebase is, the less useful AI is, and the smaller the productivity gains are.

It’s also every company’s individual choice whether to focus more on speed or quality. My take is that for startups, the speed is where they benefit more, while for more established companies, the quality should be the bigger focus.

Of course, every industry is different, and it really depends on what kind of users you are building for.

Last Words

As the speed of generating code increases, it’s important that we also ensure that the code review process evolves as well.

If not, code reviews ultimately slow down everyone and become the bottleneck. That’s also how we won’t be able to get all the productivity benefits that AI brings.

My recommendation is to start simple and make one improvement at a time, like adding AI code reviews when opening a PR.

That alone brings a lot of benefits imo, and is the best way to start.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.