The Review Bottleneck
How AI-generated code is breaking the pull request model
The pull request queue is where engineering velocity goes to die. For decades, the bottleneck in software development was the act of writing code. It was a slow, deliberate process of thought and syntax. Now, that has changed. AI agents can generate functional, syntactically correct code in seconds. This creates a new, more dangerous problem: a flood of pull requests that no human team can possibly review. The senior engineers, who used to spend their time solving hard problems, are now drowning in a sea of automated changes. They are stuck in a cycle of endless verification, trying to spot the one subtle error in a hundred lines of AI-generated logic that will eventually crash the production environment.
The Failure of Manual Review
The traditional model of peer review assumes a manageable volume of changes. It relies on the idea that a human can look at a diff, understand the intent, and spot the risk. But when the volume of code increases by an order of magnitude, the quality of human review collapses. Engineers begin to skim. They approve changes because they lack the time to do anything else. This is how technical debt accumulates at an accelerated rate. We are building faster than we can think, creating a gap between our ability to ship and our ability to understand what we have actually shipped.
The bottleneck is no longer the act of writing; it is the act of verifying.
The solution is not to review everything more carefully. That is a mathematical impossibility. The solution is to stop treating all code as equal. We need to move toward a model of automated risk scoring. By categorising changes based on their potential impact, we can decide which ones require a human eye and which ones can be handled by an agent. This requires a shift in how we define trust in a software system. Trust should not be a blanket assumption; it should be a calculated metric based on the specific properties of a change.
The Six Dimensions of Risk
To automate the review process, you must first define what constitutes risk. A robust system does not just look for bugs; it looks for systemic impact. A sophisticated agent can score a pull request across several specific dimensions to determine its safety. This allows for a tiered approach to merging, where low-risk changes move through the pipeline automatically, and high-risk changes are escalated to human experts.
- Blast Radius: How much of the system does this change touch?
- Reversibility: How difficult is it to undo this change if it fails?
- Data Security: Does this modification touch sensitive user information?
- Ops Impact: Will this change affect system stability or latency?
- Verification Gap: How much testing is required to prove this works?
- Change Surface: How many files and lines of code are being altered?
This approach turns the review process into an audit rather than a manual inspection. As long as the process is queryable and follows a clear risk policy, it can remain compliant with standards like SOC 2. The goal is to clear the backlog by automating the mundane, leaving the humans to focus on the architectural decisions that actually matter.
Automate the low-risk verification to protect the high-value engineering time.