Every team I've worked with has a version of the same Slack message. Someone posts a PR link, adds a "👀 when you get a chance", and then... nothing. The PR sits. The author starts the next ticket. Two days later there's a merge conflict, a rebase, and a slightly pointed re-post of the same link.
I run a retrospective tool, which means I sit on top of an unusual dataset: over a million retro cards written by real software teams since 2023. Earlier this month we analyzed all of them and found that code review wasn't the most common complaint (testing won that). But it was the complaint teams voted for most. And buried in the data was one sentence, paraphrased over a thousand different ways: "pull requests sitting too long waiting for review."
So we went deeper on the 11,246 code-review complaints specifically. Here's the finding I can't stop thinking about: review is the only part of the delivery pipeline where complaints are growing. In the era of AI-generated code, I don't think that's a coincidence.
The numbers, quickly
Method first, so you can judge it: aggregate analysis of 87,719 retrospectives run on Kollabe between October 2023 and July 2026. Columns classified as positive or negative by their names ("What Went Well" vs "What Went Wrong"), themes matched with conservative English keywords, no individual card quoted or identifiable. Keyword matching undercounts, so every number here is a floor.
What the 11,246 review complaints show:
- Code review's share of all complaint cards rose from a 3.8% average in 2024 to 4.1% in 2025 to 4.8% in 2026, touching 5% this northern summer. That's roughly 30% growth.
- Testing, the volume champion of complaints, stayed flat between 10% and 12% the entire time. So did deploys, tickets, and meetings. Review is the outlier.
- One in eleven retrospectives now contains a review complaint.
- Review cards attract 0.75 votes per card against a 0.65 baseline, the highest of any major theme. When a review card appears, the room backs it.
Anyone can write a card. Votes cost scarce attention. A theme that's rising in volume and leading in votes is the textbook definition of a growing bottleneck.
What teams actually say about review
The sub-themes rank like you'd expect, until you look at the votes.
Waiting dominates the writing. About one in ten review complaints explicitly mentions PRs sitting, stuck, stale, or delayed. This is the thousand-paraphrases sentence. Nobody needs it explained to them.
But PR size wins the voting. Cards about PRs being too big to review average 0.99 votes per card, half again above baseline and the most-voted sub-theme in the whole cut. I read this as teams knowing something they rarely say out loud: the giant PR is the upstream cause of the waiting, the rubber-stamping, and the merge conflicts. The queue is the symptom.
Feedback quality is the quiet third rail. Nitpick wars and drive-by comments make up 6.3% of complaints and vote well above baseline too. Review latency hurts throughput; review tone hurts people.
Reviewer availability rounds it out. "Only one person can review this" cards are less common than you'd think (4.8%), which suggests the problem is less about headcount and more about flow.
One genuinely hopeful stat: for every three review complaints, there are two positive cards thanking a reviewer or celebrating a smooth cycle. Teams notice when review works. It's not a hated ritual. It's a loved ritual with a queueing problem.
The AI elephant
Why is review the only growing complaint? I'll be straight about the limits: card counts can't prove causation, and I won't pretend otherwise.
But the timing is hard to ignore. The growth window, 2024 through 2026, is exactly the period when AI coding assistants went from autocomplete toys to generating a meaningful share of the code that reaches a human reviewer. The volume of code went up. The number of humans on the other side of the gate didn't. Queues grow at the constraint, and the constraint moved to the one step that still requires a person to think.
The skeptic's case deserves its airtime too. Maybe teams just got better at naming the problem — retro vocabulary evolves, and "review bottleneck" is a phrase people have now. Maybe remote-first norms made the silence more visible. And if you're a three-person team where everyone reviews everything within the hour, none of this matches your life, and that's fine. The data describes the middle of the distribution, not its edges.
Either way, the practical conclusion is the same: if review complaints are rising everywhere, the teams that fix the queue get a compounding advantage over the ones that treat it as weather.
What actually fixes it
The vote data suggests a fix order, not just a fix list.
Shrink the PRs first. It's the most-voted complaint for a reason. Small changes get reviewed sooner and more carefully, and they go stale less often. Google's engineering practices guide has made this case for years: small changelists get faster, higher-quality review. If your stories keep producing thousand-line PRs, the fix starts at refinement, not at the review stage.
Measure time-to-first-review. Teams argue in anecdotes until someone puts a number on the board. You don't need a metrics platform; a weekly script against your Git host's API will do. "PRs sit forever" becomes "median first response: 26 hours", and now it can go down.
Agree on a first-response window, not a review SLA. Most of the pain in the waiting cards is silence, not total duration. "Someone acknowledges within four working hours" is achievable and kills the re-post-the-link ritual. A full review SLA usually isn't achievable, and unachievable agreements corrode faster than no agreement.
Treat a repeat complaint as a project. In our data, action items with a named owner get completed 2.7x more often than unowned ones. A review complaint that shows up two retros in a row has stopped being feedback.
Where the retro fits
Transparency: I work on Kollabe, so season accordingly. The patterns generalise; if you use another retro tool, swap in the equivalent.
The workflow that surfaces this stuff isn't fancy. Cards go up, everyone votes, and the top-voted card gets discussed first even when a louder card wrote more words. That voting step is the whole trick — it's how a quiet "our PRs are too big" beats a loud "the deploy broke again" when the room actually cares more about the first one. Then the meeting ends with the top item owned by a person, with a date. The uncomfortable part is that the data on my own product told me most teams skip that last step: four out of five retros produce zero action items. That stat stung, and we now nag about it in the product, because writing the card was never the valuable part.
The Monday question
If you take one thing into your next retro, make it this question:
Is our review queue a fact of life, or a decision we keep re-making?
Ask it when the waiting card shows up. If the room goes quiet, you've found your next sprint's most valuable ticket.
The full analysis, with the quarter-by-quarter numbers and the testing comparison, is in the original post. And if a theme keeps reappearing on your board, the aggregate stats from a million retro cards live on our retrospective statistics page — useful for checking whether your team's weird is everyone's weird.
Top comments (1)
It’s definitely a weird time for reviews.