Code Review Automation Fixed the Wrong Problem

Code review automation was supposed to make review faster. The 2026 numbers say the opposite happened.

Faros AI's telemetry across 22,000 developers found that median time remaining in code review is up 441.5% year over year, and pull requests merged without any review, human or automated, are up 31.3%. Reviewers aren't approving faster because a bot is helping. They're skipping the step entirely, because there's too much to look at.

That's the part "code review automation" tends to skip over when it's used as a selling point. Automating a comment is not the same as automating a review.

What automation actually does today

Most of what gets called code review automation falls into a few buckets.

All three are useful. None of them touch the actual constraint, which is a person deciding whether a change is safe to ship.

Why the bottleneck moved instead of disappearing

LinearB's analysis of 8.1 million pull requests across 4,800 teams shows where the time actually went. Pull requests written with AI assistance run about two and a half times larger than ones without it, over 400 lines at the 75th percentile versus 157 lines. Bigger diffs take longer to reason about, so reviewer pickup time on AI assisted work runs more than 16 hours on average, against roughly 200 minutes for unassisted work. Measured a month out, only 32.7% of AI assisted pull requests have merged, compared with 84.5% of the rest.

Code got faster to write. Review didn't get faster to do. The queue moved from the keyboard to the reviewer's desk, and automated comments on a 400 line diff don't shrink the diff, they just add more text to read alongside it.

Automating the comment isn't automating the review

A review comment answers "what's wrong with this line." A review decision answers "should this ship, and what happens if it's wrong." Those are different jobs, and most code review automation is built for the first one.

The first job is mechanical and automation handles it well: flag the missing null check, point out the duplicated logic, catch the style violation. The second job requires knowing what the change actually touches. Whether it sits under a shared authentication boundary used by 300 other call sites, or a single screen nobody depends on. Faros calls the result of skipping that judgment the "senior engineer tax": the people best equipped to catch a subtle, high reach defect are the ones stuck reviewing the most volume, because the mechanical layer cleared everything else through first.

What automation would need to fix the actual bottleneck

Not more comments. A way to tell which of the pull requests waiting in that 16 hour queue actually need a senior engineer's attention, and which are safe to clear without one. A defect's reach is invisible to a diff; a three line change to a shared boundary carries more risk than a 300 line change to a leaf component, and no amount of comment generation on either one tells a reviewer which is which. Pre-screening and review are already different jobs; the tools that help are the ones that keep them separate instead of dressing up the first as a replacement for the second.

That's the layer Tomosu is built to sit in. Not another comment generator competing for the reviewer's attention, but a way to know, before a human opens the diff, whether this is one of the changes that actually needs their judgment. Which changes have broken before is a matter of record, not intuition — and it's the record that tells you where the judgment belongs.

Frequently asked questions

Tomosu builds merge-gate governance infrastructure that reads the whole codebase to tell you which pull requests in the queue actually need a senior engineer — by reach, not by line count. If your review queue is growing faster than your reviewers, we are opening a small design partner cohort. Book a call →