Every software and QA engineer knows how AI is helping us get a good chunk of our work done and how fast it can ship code out the door. Most developers that I know are leaning more heavily on tools like Claude Code, Codex, and GitHub Copilot to write new code, including myself. Even if you're not using these tools as much as others, it's a global trend. According to GitHub's COO Kyle Daigle, GitHub's platform processed 1 billion commits in 2025 but is currently on pace to receive at least 14 billion code commits in 2026, although it looks like it’ll easily surpass that number.
The massive number of code commits isn't the only thing that's going up. A lot of these commits are done for organizations where it's expected to have the work reviewed by members of a team before they're put to use in a production environment. On GitHub, requests for code reviews come in the form of pull requests, and those have also been growing at an exponential pace. The number of pull requests driven by AI agents on the platform has gone from 4 million in September 2025 to over 17 million less than six months later. That’s over four times the number of PRs being opened by AI tools in a given month.
Unless you're working on a solo project (or a team that doesn't do code reviews or pull requests, for whatever crazy reason), this means we're all getting slammed by this flood of work being pushed onto our plates. I don't know how it's been for most engineers reading this, but I admittedly have been struggling at times to handle the sheer volume of PRs getting assigned to me. In the past, I estimate I would spend less than ten hours in a given week doing code reviews. Now, on some projects, I've spent an entire workday only on reviews.
The struggle isn't only due to the sharp increase of pull requests coming my way. I don't mind spending the time doing a thorough code review to share knowledge, learn, and help both myself and my colleagues. But the problem I'm noticing is that the quality of the work for most of these pull requests has decreased significantly, making the review process much more difficult since it requires more mental energy to figure out what's going on.
Why Code Review Is Becoming a Bottleneck
My assessment of my progressively growing concern is twofold. First, most organizations have increased the expectations of work for developers and testers. Because of LLMs and AI tooling, the belief is that we should be churning out more code in less time, providing less and less time to do the work correctly from the start. AI-generated code helps us get moving and can get things done surprisingly well, but in my experience it still falls short of what I'd consider high-quality code, especially for the long-term health of a codebase. Anyone who's worked for months on mostly AI-generated codebases knows the tangled mess it leaves behind.
The other issue I see is that most teams and individuals are not equipped to handle the amount of work that's coming our way. There are not enough hours in a day to go through our tasks plus reviewing other people's code, especially when it's all coming from AI. The context switching and cognitive load required to address multiple PRs a day is just not feasible at the current pace. I'm sure I'm not the only one who feels completely drained at the end of the day because of this.
It all leads to developers and testers handling the situation in a common pattern that I've seen pop up a few times in the past couple of months. As more PRs come in, code review becomes the primary bottleneck in the development process. Since the team can't process each of them quickly enough, the review process eventually suffers when they spend less time on each review, to the point where it gets a “Looks good to me” signoff with barely a glance at the changes. We've all seen large pull requests receive approval just minutes after they're open.
I've also seen a rise in the adoption of AI code reviews in many organizations. In my experience, these tools are useful as a first pass to catch obvious issues, like linting errors, typos, and even some security issues. However, they often raise a lot of noise in the form of nitpicks and incorrect assumptions that waste a ton of engineering time. Unfortunately, many teams are using AI code reviews as the only review without bringing in a human contributor, so the code quality ends up suffering as a result.
The Instant-Reject List: A Faster Way to Review PRs
With engineers getting slammed by dozens of low-quality and poorly documented pull requests, I propose that development teams should get together and adopt an “Instant-Reject” list for pull requests. This list should contain agreed-upon scenarios where a pull request can be rejected (with comments for improving it) without needing to spend a lot of time going deep with the review. There are a few reasons why this helps make the code review process easier in our current AI-driven workplaces.
First, some teams don’t have enough psychological safety embedded in the team, where individuals don’t feel secure enough to publicly ask questions or express their opinions, fearing being judged or looking dumb. This problem is especially prevalent with less-experienced developers and testers, who don’t want to cause issues with the team by rejecting a PR. If there’s a list showing reasons for rejecting a code review, everyone can feel like they have the permission to do so without repercussions.
Moreover, preparing beforehand will let teams have a clearly defined scope on what’s acceptable and what isn’t when asking someone to take time to review their work. This step saves time by reminding engineers what they need to do before submitting a pull request so they don’t waste other people’s time. It also allows the reviewer to quickly point out things that need to be fixed without having to justify their response.
5 Rules for Your Instant-Reject List
Most teams will already have unwritten rules in place to reject a pull request, with the more common and clear reasons being failed CI runs, lack of automated tests, and commits with sensitive data or security holes. However, every team operates under different circumstances that require them to make up their list of “instant-reject” rules for pull request reviews.
Below are five rules that I recommend most teams adopt, since they cover the areas that typically slow down engineers from their daily work. Not every rule on the list works the same way. Some are immediate calls that anyone can make without further discussion. But a couple might require some conversation before deciding, and while they’re not instant decisions, they still belong here to help the team agree that they're fair grounds for sending a PR back.
1) Massive code changes
Many of us have gotten requests to review a PR that contains thousands of lines of code added or removed. Every so often it’s because of the addition or removal of third-party dependencies (I see you, node_modules/ directory). But with LLM tools making code generation as easy as a prompt, it’s becoming a more common occurrence for developers to spin up an agent in the background and have it return minutes or sometimes hours later with dozens of commits and a gargantuan code diff. And despite the developer not fully understanding the changes, they submit the pull request and let others deal with it.
Several studies have found that smaller pull requests help developers and testers find more issues during code reviews in less time. For example, a SmartBear study found that reviewing changes between 200 and 400 lines of code uncovered 70-90% of defects. It’s an older study, but the results are the same in 2026, in my experience. The fewer changes to look for, the easier it is to find problems. No one should expect to find all defects in any code review, but if you’ve ever had to scan a 2,000-line diff in a pull request, you know how impossible it is to do a thorough review unless you spend a whole day on it.
Instead of wasting time trying to review these massive PRs, or worse yet, just rubber-stamping the request with an LGTM comment when you didn’t check everything, it’s better to reject it and ask for the pull request to be split into smaller chunks. GitHub recently added stacked PRs, which let you break larger chunks of work into a chain of smaller and dependent segments. It's a helpful option if you’re on the platform, but it shouldn’t replace the rule. Developers still have to decide to split the work in the first place, and the team still has to expect it. Having the team understand this rule from the beginning will keep developers and their AI tooling in check before throwing too many changes over the proverbial fence.
2) Mixing different concerns
Huge pull requests require a significant time commitment from reviewers because of the scope contained in thousands of lines or changes. But these PRs usually also introduce multiple functionality changes within a single unit of change. For instance, I’ve received a single pull request that contained a new feature, fixes for smaller bugs, and the refactoring of a module completely unrelated to the other commits. It takes time to properly review each of these individually, and it compounds when there’s multiple changes stacked one on top of the other.
Pull requests with many changes are also poor software development practice, since it’s easier to lose track of changes in version control and leads to potential confusion when someone is trying to figure out why that code is there in the first place. Also, it makes it nearly impossible to roll back any changes if one of the many things touched in that PR has a bug. This problem is not exclusive to large PRs, either. I’ve seen pull requests with fewer than 10 lines of code changes, but they touch entirely different areas of the codebase. Even though the code is simple to review, the same versioning and rollback issues still apply to these tiny commits.
Most modern applications are complex enough that what seems like an insignificant change in one area can modify the behavior of another. When mixing too many changes in a single place, you risk missing potential issues during review and make it more of a pain when they have to be reverted. These changes should be rejected with the request of splitting them up into separate, smaller PRs or stacked PRs for long-term maintainability.
3) Lack of a clear description
I might be in the minority, but I believe that the description in a pull request is far more important than the code changes. The code diff shows you what changed between branches, but it can’t explain why that change is being made. Without this information, the engineer is just creating unnecessary friction with the rest of the team because it’s leaving everyone to guess why the work was done. Assumptions are made that might be incorrect, leading to long back-and-forth discussions that could have been prevented if the requester had taken a few minutes to add a clear description of the work done.
There’s also the issue of having too much in the PR description. I’m guilty of this, as I tend to write too much in an attempt to clarify my thoughts and make sure it’s clear to others while working asynchronously. However, it’s usually not a problem if someone is doing the writing. The issue nowadays is that LLMs are opening pull requests containing a ton of unnecessary or even incorrect context in the description.
Platforms like GitHub and GitLab give teams the ability to create templates that the developers can fill out with the relevant details of their pull request, so there’s no reason not to have a clear description for all pull requests. LLM tools do a decent job of reading these templates and filling in the blanks. If a PR description doesn’t contain information like why this code was written, links to tickets, what testing was done, potential gotchas, and other details that will make the reviewer’s task quicker, it should be rejected until provided.
4) Slowing down the development workflow
One good thing that AI tooling has brought to software development is that most software developers are including automated tests for the code they write (possibly for the first time in history). LLMs are excellent at writing test cases for new functionality. However, like most of the output that’s generated by these services, AI tends to go a bit overboard by writing too many test cases that are often unoptimized. Most engineers see new test cases and think, “Awesome, we have more test coverage!” but fail to see that those test cases are making everything slow down over time.
One project I worked on recently merged a commit that caused the automated test suite to go from 2 minutes of total run time to 5 minutes due to a change in the test data cleanup phase, and no one noticed for days. These types of slowdowns are easier to manage, but a bigger problem is when the test run times slowly creep up over time. These are a lot more difficult to notice as we get accustomed to the slower times until we’re further down the road, kind of like the “boiling frog” fable. A slow test suite usually means a slower feedback loop, affecting team velocity and the ability to ship quickly.
Not all test slowdowns are bad. Sometimes it’s a necessity, such as adding end-to-end tests for more complete coverage. In many cases it’s a judgment call the reviewer must take, according to the circumstance. However, engineers must be more observant about the potential slowdowns they introduce in the codebase. It’s not enough to see that there are new tests and that they pass. Teams should reject PRs if they slow the workflow down unnecessarily, asking for improvements to the workflow that are cheaper to handle now than discovering them much later.
5) The author can't explain the code
In any codebase that’s in production, the author of a pull request should be able to explain the changes made, why they chose their approach, and any potential ramifications that the team should look out for. You would think that this part goes without saying, but you’d be surprised at how often engineers are submitting code nowadays without fully grasping what’s happening, deferring this task to other engineers who are likely to understand it less.
This step is especially important when dealing with AI-generated code. It’s not to say that code coming from Claude or Cursor is a bad thing, and most developers should be using these tools to better use their time during the workday. However, the owner of that pull request should take accountability for the work that’s being submitted, whether they typed every byte themselves or passed the task along to a coding agent.
Admittedly, making sure PR owners understand what they’re submitting can add to the burden of code review since it’ll need some back-and-forth conversation. Sometimes it’s a judgment call, like when the addition of tests slows down the development workflow. But the purpose of this process is that code that isn’t understood inevitably creates a maintenance burden for every engineer, current and future, who works on the project. The potential risk usually isn’t worth it and should lead to a PR rejection until there’s a decent understanding of what’s going to get merged.
Reject More, Review Better
There’s a lot of added pressure on software developers and testers, thanks to AI and other workflow improvements leading to more code and more pull requests being pushed daily. With the ability to deliver code more frequently, we’re also getting flooded with requests for checking that work. A lot of code that would have likely been flagged before is now slipping through to production because we’re overloaded, and it feels awkward or rude to reject someone’s request to merge.
An “Instant Reject” list helps teams save time and mental energy by letting anyone bounce PRs without feeling like they’re creating problems. This article offers my top rules, but each team should come up with a list that fits their situation better. Beyond the obvious reasons like failing tests, the common themes on rejecting PRs are due to poor scoping, a lack of clarity, having a negative impact on the team’s workflow, and not fully grasping what’s going in.
This kind of list might sound like gatekeeping, but a shared, agreed-upon standard ahead of time is what keeps rejection from being personal in the first place. The whole purpose is to remove as much friction and keep quality as high as possible when there’s more work coming our way than we can handle.
