Understanding a bottleneck doesn’t solve it, even when it comes to reviews. It isn’t action. At the same time, most engineers can’t unilaterally change their team’s review process. You don’t always get to choose the tools, force faster reviews, or have the skills to navigate politics alongside architecture. Here’s what you can actually do based on your role and constraints.
Start By Measuring Link to heading
Before changing anything, figure out where you actually are. If you don’t have means to grab metrics, track four things for two weeks (in a spreadsheet or on a notepad or wherever).
- Queue depth at end of day as in how many PRs are sitting there waiting for review. Zero to five is manageable, fifteen-plus means you’re saturated.
- Time to first review as median hours from PR creation to first human comment. Under 24 hours is Google’s standard, over 48 means people are blocked.
- PR size as median lines of code per PR. Under 300 LOC is the cognitive sweet spot, over 500 hits overload.
- Context switches as how many times per day you stop coding to review something. Two or three scheduled blocks work, ten-plus is interrupt-driven chaos.
These four numbers tell you whether your bottleneck is assignment (high queue with slow first review), size (large PRs getting shallow comments), capacity (queue stays saturated even when individual reviews move fast), or workflow (constant switching with end-of-day escalations).
Avoid worrying about dashboards or tools. Just count manually for two weeks if you have to. The data helps build credibility, shows the actual constraint, and proves whether any changes you made helped or hurt.
What You Can Actually Change Link to heading
If You’re Junior or Mid-Level Link to heading
You have almost no organizational power but you do have full control over your own work. Use that to your advantage
Start with ready-to-resume plans which essentially asks you to write down one or two line of what you were doing and what’s next before context switching. Here’s an example I used two day ago, “checking error paths in reports.java:145-203, verify exception propagation next.” Research shows this takes few minutes to seconds, and eliminates 24% of the attention residue tax.
Keep your PRs under 300 lines. The cognitive cliff at 450 LOC/hour is biological—87% of reviews past that threshold miss defects. An 800-line feature splits into database schema (200 LOC), service layer (250 LOC), API endpoints (200 LOC), tests (150 LOC). Each piece gets better review faster than the monolith would.
Tag specific reviewers instead of assigning to the team. Meta’s data showed 11.6% faster reviews with individual assignment. You’re not being pushy—you’re preventing the bystander effect.
When reviewing AI code, I’ve found checking for specific patterns works better than treating them as the same human-written code. Missing input validation shows up constantly. It’s the most common flaw across models. Edge cases AI consistently skips like null, empty arrays, boundary conditions. Cross-file duplication, which jumped 48% in AI-generated code. Hardcoded credentials that slip through because the model learned from public repos where that pattern appears thousands of times. Raising these doesn’t require authority. “Spotted potential SQL injection here, should this be parameterized?” is factual observation, not political maneuvering.
Track your own numbers during those two weeks. When your data shows “my PRs average 4h to first review with individual assignment vs 18h assigned to team,” you’ve got credibility to suggest broader changes.
If your team uses AI review tools and you think a suggestion is wrong, say so. “[Tool] flagged this as a security issue, but it’s a false positive because [context]. Keeping for [reason].” The 73.8% acceptance rate also means 26% of bot suggestions are wrong. Questioning them is appropriate and it’s also data for a senior to investigate or escalate. If the tool has local config you can tune, submitting a follow-up PR to refine the rules works even better—you’re improving the filter for everyone.
If You’re Senior Link to heading
You have credibility to propose experiments and shape team process.
Run time-boxed experiments. “Let’s try individual assignment for backend PRs for two weeks, track time-to-first-review, see if it helps.” Anything that’s small in scope, has clear metrics, and is reversible should be game. If it works, expand. If it doesn’t, you learned something with low disruption in a sprint or two.
When PRs pile up, make the constraint explicit rather than asking people to “review faster.” I’ve found showing the math works better than appeals to work harder. “We’re averaging 15 PRs per day with 4 reviewers at 200 LOC/hour capacity. That’s 750 LOC per day per reviewer at cognitive limits. We need to reduce number of lines or increase the time being spent on PRs.” The math makes the bottleneck legible without blaming anyone.
If you’re catching the same AI-generated flaws repeatedly, propose automating them. The CI division of labor assumed human-written code. AI’s defect profile is different (fewer syntax errors and more SQL injection patterns, missing input validation, cross-file duplication). Track what you catch manually for two weeks, then propose automating the high-frequency patterns. “We flagged missing input validation in 12 of 15 AI PRs last sprint—should we add that as a check before merging?”
If You’re Staff+ or Managing Engineers Link to heading
You have the opportunity to redesign the process, not just work within it.
Run the full diagnostic of available metrics across team dimensions but also across time, percentiles, and other segments to look for systemic patterns. Avoid any implications of individual performance issues. I’ve seen these diagnostics reveal that the bottleneck isn’t where people assumed, sometimes it’s not review speed at all, but PRs sitting unassigned for days.
The ROI conversation with leadership isn’t “developers are slow”, it’s showing the capacity constraint has measurable cost like blocked engineering hours, defects escaping to production, and throughput loss. The exact numbers and methodology matter less than making the bottleneck legible to people who can allocate resources. Also, make the division of labor explicit. The implicit version where CI checks syntax and humans check design is outdated for AI code. Instead emphasize quarterly updates as defect patterns shift and tools evolve.
If you’re doing a full rollout of process changes, sequence it over many weeks. Week one and two are baseline measurements. Week three and four you enforcing some of easier change to build trust. Week five and six you add more intrusive changes such as scheduled review blocks like 10am and 3pm if queue depth is still high, adjusting based on what the data actually shows.
What Works and What Doesn’t Link to heading
Success looks like queue depth trending down, P75 review time under SLA, P75 PR size under 300 LOC with quality maintained or better. Red flags are queue growing despite changes, reviewers reporting burnout, quality declining, or changes getting reversed due to pushback.
After two to four weeks, expect to see queue depth trending down. After two to three months, PR size median and quality metrics improve while review stops being the top complaint in retros. After six months, the queue should stay stable despite PR volume growth and reviewers report sustainable workload rather than burnout.
Telling everyone to “review faster” won’t work because you can’t review 600 line PRs at the same rate as 200 line ones without missing defects. Hiring your way out fails if PR volume grows faster than hiring, and it usually does. AI tools don’t solve it either if you misconfigure them as mandatory gates instead of pre-filters. Adopting everything all at once creates change fatigue and you won’t know what actually worked.
If the queue keeps growing despite changes, or reviewers are burning out, or quality is declining, stop adding practices. Diagnose the actual constraint—arrival rate, service rate, PR size, or response expectations. The solution changes based on which constraint is binding.
It’s Architecture, Not Effort Link to heading
The review bottleneck isn’t about working harder. The solutions aren’t revolutionary either. What’s new is AI making the bottleneck impossible to ignore. You can’t run fast enough to outrun it through brute force. Instead, you start with metrics, then take incremental steps. Also, the bottleneck isn’t inevitable, it’s architectural; which means it can be redesigned.
What you do next depends on your role and your constraints. You don’t need permission to track your own metrics, or push for change within your area of influence. Start there. Build credibility. Then propose experiments. I’m curious whether the teams that fix this early do it because they measured first, or because someone with enough credibility made the constraint legible.