Your Best Judgment Is Being Spent in Arrival Order.

My developers spend more time on reviews than they are happy with. On my team, a handful of employees can approve code, and a larger team of consultants cannot. Compliance requires an employee to review and sign off on every pull request, so the consultants' work, plus our own, runs through those few people. Without even considering AI, my team struggles to keep up with that volume.

My developers are watching what they love evaporate through outsourcing and AI, and I am concerned it is more than they can adapt to.

Now add AI. A Harvard working paper by Fiona Chen and James Stratton studied 718 companies through March 2026. After AI agents arrived at those firms, the share of pull requests sent back for changes nearly doubled. Nearly 80% of the firms had used AI tools in code review, yet across the study, only 10.8% of pull requests received even one AI review comment. As the paper puts it, humans are still heavily involved with review.

If you run a review gate, the fix you have been offered is throughput. Add an AI code reviewer, set a review SLA, rotate reviewers so the load spreads, and treat reviewing as part of every engineer's job. More code going out reads as productivity, and review is the cost of doing business.

It is both a quality problem and a cadence problem, and the two compound: more code arrives, more of it is sent back, and on a team like mine, where only employees can sign off, it lands on the same people who were already carrying the load. The paper found the bottleneck persisted even after firms adopted AI review tools. A review SLA and a rotation are reasonable steps, and neither one decides which pull request matters most. Unless someone decides, review runs in the order work arrives, and on my team there is currently no direction on what order to review pull requests. What I call The Cadence is the rhythm that gives a team predictable decision closure, and on my team, an employee signs off on every pull request before it closes.

The cost is not the hours themselves. If my best people's time and judgment are spent on review, they are not spending it on solving business problems, whether by writing code directly or by building prompts. The highest-impact change can sit behind routine ones, with its cycle time set by its place in line rather than its value.

Your reviewers are not slow, and your team is not failing; a queue nobody ranks spends its best judgment in arrival order, whoever runs it. To succeed in this world, you first have to burn your current process to the ground and rebuild it around maximizing business value, considering both build time and review time. Rank what comes in by business impact. Put your strongest reviewers on the changes where their judgment changes the outcome, keep an employee's sign-off wherever the rule requires it, and protect a share of those same people's time for coding on purpose. Coding is what they love.

The hard part is saying out loud that some pull requests matter more than others, and letting the less important ones wait. Arrival order feels fair, which is exactly what keeps it in place.

Take last week's merged pull requests. Rank them by business impact, then list how long each one waited for review. If the two lists do not line up, your best judgment is being spent in arrival order.

LeadershipOS™ has the full Cadence layer, the rhythm that gives a team predictable decision closure: https://TheLeadershipOSBook.com