Article summary
Pull request (PR) reviews are one of those engineering practices that almost everyone agrees are important, albeit time-consuming. They help teams catch issues, share knowledge and context within a team, and keep code quality from depending entirely on the author of the first version. However, even good processes can get expensive when the shape of the team changes. On my current project team, as the team grew, we were juggling onboarding new developers, keeping PRs moving, and trying to stay on top of planned feature work.
Problem
Initially, we tried to have two reviewers per PR, especially as we onboarded new developers who were less familiar with the architecture and product. As you could imagine, the stress on both sides of the equation started growing. On one side, people were hounding the team for a second review so they could merge their work. On the other side, reviewers were pulled away again and again to look at another PR. On top of that, we started incorporating agentic development more into our process, which was another huge energy and attention expenditure.
With the agentic process, tickets were worked through more quickly, which was great, but it also led to larger PRs. Some of that came from AI-generated scaffolding and documentation, and some of it came from the fact that more work could be completed in one chunk. Either way, reviewers had more context to absorb, and they had to do it while still trying to make progress on their own assigned work.
The issue was not that people hated reviewing PRs. The issue was more about the context switching. Each individual review felt reasonable enough, but cumulatively, the process was splitting everyone’s attention throughout the sprint.
In addition, we found that the duty to review PRs sometimes fell more heavily on one teammate or another. Sometimes, certain reviewers take longer to review. Or, someone is waiting on a second approval. Sometimes you review once, return to your own work, and then get pulled back in for a re-review. All of this led to increased fatigue and frustration on the team.
What We Tried
After identifying as a team that we needed to change our PR review process, we tried a few things to resolve the issue. Logically, we started by requiring only one developer approval to merge a PR instead of two.
However, the team was uncertain about having only one human reviewer per PR, so we experimentally added an AI reviewer as well: Greptile. For context, Greptile is a third-party service that reviews PRs. It assesses the changes made and will flag any issues it finds, as well as leaving a comment summarizing changes with a confidence score. While not perfect, having Greptile as a second reviewer gave the team more confidence when merging PRs. It also gave our team food for thought about possible risks created by the code paths being written.
We also tried splitting review responsibilities. For example, one developer might only review the frontend changes while another reviewed the backend changes. This helped in some cases, especially when PRs crossed multiple areas of the codebase, but it still did not fully solve the issue people were experiencing. At the core of it, the problem was still divided attention and cumulative fatigue from context switching.
So in addition to reducing the number of required human reviewers and adding an AI reviewer, we implemented a PR review schedule. The intention was that each developer would only have one or two days per sprint where their attention was divided by reviews. The other days of the sprint could be mostly heads-down days, without the constant thrash of reviewing and re-reviewing PRs.
The team immediately felt a weight lifted when we implemented these changes. Initially, people even found it kind of fun when it was their PR review day because they could plan for a day of context switching instead of getting pulled away for impromptu reviews every day.
What Worked
What worked best was not just one change. It was the combination of adding an AI reviewer and creating a PR review schedule.
Reducing to one human reviewer helped keep PRs moving. Adding Greptile gave the team more confidence that there was still a second set of eyes, even if those eyes were not human. And the PR review schedule helped reduce team frustration by making the work more predictable.
Instead of everyone being lightly interrupted all the time, reviewers could focus on digging deeply into PRs on their assigned review days. Developers also had more heads-down time for their own assigned work, rather than constantly pausing to review another PR.
The biggest improvement was that people could plan better and communicate more clearly about where their time was going. A review day became a known kind of day. A heads-down day could actually stay heads-down.
How It’s Working Several Sprints Later
Several sprints later, the process is still helping, but there are a few things we have had to learn along the way.
Lesson #1
The first is knowing when to listen to feedback from AI reviewers like Greptile and when to ignore it. PR agents do not always have the product context needed to help a developer prioritize the issues they find. Just because there is a code path to something does not mean it is a high-priority issue to address right now.
Recently, we have tried to assess the risk of the issues Greptile surfaces. If we determine that something is out of scope for the current ticket, we log it in the backlog for later prioritization instead of automatically treating it as blocking feedback.
Lesson #2
Another challenge is keeping up with the team as development speed increases. Agentic development can help work move faster, but that also means more changes to understand and more decisions about what needs human attention.
We have also run into some challenges with the PR review process dragging out over days. If a reviewer leaves feedback at the end of their PR review day, or if the PR author does not get back to addressing feedback until later, then another reviewer may have to pick up a PR that is already mid-review and gain context from scratch.
For some of the larger PRs, this feedback process can stretch across multiple days, which is not ideal. It reintroduces some of the context-switching costs we were trying to reduce in the first place, just in a different shape. We are still working through issues like this.
Lesson #3
There is also a visibility tradeoff. PR reviewing does not just serve the purpose of quality assurance. It also helps share knowledge across the team about how a feature or new slice of the product works under the hood. When you only review the PRs that show up on your review day, you may have less visibility into other domains of the codebase.
Overall, while not a perfect solution, the changes helped us address the part of PR review that was causing the most frustration: not the act of reviewing itself, but the constant interruption of everyone’s focus. By reducing the number of required human reviewers, adding an AI reviewer, and creating a PR review schedule, we made the process feel lighter and more predictable without removing the parts of PR review that still matter.