Half Your Merges Might Have Zero Review. Do You Know the Number?

Here is a number most engineering leaders have never looked at:

What percentage of your merged pull requests had zero recorded review?

Not "review felt light." Not "we trusted the author." Zero. No approval, no comment review, no bot review event in the GitHub metadata at all.

If you do not know that number, you are not alone. GitHub records the underlying review events, but it does not surface this as a clean org-level metric. Most velocity dashboards do not either. And yet it may be one of the clearest signals that review capacity is no longer keeping up with merge volume.

What the industry data shows

The more useful question now is not whether AI changed code review, but what happens after more code gets written. Teams are starting to measure the downstream effects: review latency, defect rates, and how often PRs merge with nothing on the record.

Faros AI's Engineering Report 2026 tracked 22,000 developers across 4,000 teams as AI adoption scaled. The headline throughput numbers are real: more tasks completed, more epics shipped, more code written. Then the numbers from the review stage:

• PRs merged with no review at all: up 31.3%
• Median time in review: up 441.5%
• Median time to first review: up 156.6%
• Bugs per developer: +9% in the 2025 report → +54% in the 2026 dataset

Faros is explicit about what they think is happening. This is probably not teams deliberately turning off quality gates. Reviewers cannot keep pace with the volume arriving for attention. Some PRs wait. Some get a shallow pass. Some merge with nothing on the record.

Addy Osmani's "Agentic Code Review" describes the same tension: AI is already reviewing a meaningful share of code on GitHub, but zero-review merges are still climbing and human review times are up triple digits. Automated review is running at scale. PRs are still merging with no review event logged.

GitHub has also reported that Copilot code review has run 60 million reviews, with AI now involved in more than one in five reviews on the platform. Copilot code review also now consumes GitHub Actions minutes under usage-based billing.

So we are spending more on automated review, running more automated review, and still seeing more code merge with no review event at all.

The explanation is that automation participation and review coverage are different metrics.

What "zero review" actually means

GitQuick defines merged without review the same way we would if you queried GitHub yourself:

A merged PR where review_count = 0 - no APPROVED, CHANGES_REQUESTED, or COMMENTED review from any account.

That includes bot reviewers. If Dependabot left a review, it counts. If Copilot code review commented, it counts. If the PR merged with literally nothing in the review log, it counts as zero review.

This is a process signal, not a verdict on code quality. Some teams intentionally auto-merge docs fixes, dependency bumps, or generated code. Fine. But that policy should be known, not accidental.

The industry-wide 31.3% increase in zero-review merges is not "teams decided reviews are optional." It is what a saturated queue looks like when input volume jumps and review capacity does not.

What the showcase data shows

GitQuick's showcase uses the same window, May–June 2026, across ten public organizations. Same pipeline, public GitHub metadata only.

Live data from git-quick.dev/showcase.

Three patterns stand out in the table.

1. Speed and zero-review are not opposites

Netflix has the fastest median merge time in this table, 3.4 hours, and the highest zero-review rate, 52.4%. That is not a bug in the metric. It is a tradeoff made visible.

A team can optimize hard for throughput and still have half its merges leave no review trail. Whether that is acceptable depends on repo, risk tolerance, and what is actually in those PRs. But "we merge fast" and "we review everything" often are in tension.

2. Automation does not automatically close the gap

Netflix also has the highest bot-review share, 58.0%. Microsoft is second, 33.9%, with only 8.9% zero-review merges. Google has relatively low bot activity, 12.3%, and a 45.4% zero-review rate.

Bot and AI review volume - measured separately in GitQuick - tells you how much automation is participating. Merged-without-review rate tells you how often the process recorded nothing at all. Those are related questions, not the same question.

An org can run Copilot code review on every PR and still show zero-review merges if reviews are not attributed the way you expect, if auto-merge paths bypass the review log, or if whole classes of changes never trigger review in the first place. You will not catch that by counting AI adoption alone. You need to measure how often PRs merge with no review event on the record.

3. Anthropic is the useful contrast

Anthropic merges in 3.2 hours with 0.1% zero-review merges. Median PR size: 16 lines.

Faros warns that AI-generated code can look correct even when it is wrong. Smaller PRs make that risk easier to manage because reviewers have less code to inspect. Anthropic’s public repos show the pattern clearly: small PRs, fast merges, and almost no zero-review merges.

Why this metric matters now

The CEPR/NBER study of 100,000+ GitHub developers found the same attenuation many teams are now experiencing: autonomous agents raised commit activity ~180%, but releases only rose ~30%. Writing got faster. Shipping did not.

Zero-review merge rate is one of the places that gap shows up in metadata. Code lands. The release train moves. But the review log is empty.

GitLab's 2026 AI Accountability Report, based on 1,528 DevSecOps professionals surveyed by The Harris Poll, reported that 85% agree AI has shifted the bottleneck from writing code to reviewing and validating it. The Faros data points to one visible failure mode: more PRs ending up merged with no recorded review.

That is not sustainable.

And if you are an EM being asked whether AI made the team faster, then merged-without-review rate is the uncomfortable follow-up question:

Faster at what cost?

What to do with this number

You do not need a process revolution. You need visibility first.

Audit the rate before debating policy

Pull merged-without-review % for the last 30 days at org level, then break it down by repo, author, and PR size bucket. GitQuick does this from GitHub metadata without reading file contents.

You are looking for:

• Is the rate climbing week over week?
• Is it concentrated in a few repos?
• Are large PRs more likely to skip review, or small ones?
• Does the rate correlate with specific authors or automation accounts?

A steady 10% might be healthy if those PRs are docs and lockfile updates you have consciously exempted. A climbing 30% is a different conversation.

Separate intentional bypass from accidental bypass

Some zero-review merges are policy. Many others may not be.

Tag exempted paths explicitly: auto-merge for dependabot, generated clients, translation files. Everything else should either get a human review or a recorded bot/AI review. If exempted paths are not documented, you are guessing about risk.

Pair it with reviewer load

Zero-review merges often rise when a small set of reviewers carries most of the load. The queue grows, teams stop waiting for review, and PRs merge without a recorded review.

Check reviewer load distribution alongside your zero-review merge rate. If two engineers review 60% of everything and zero-review merges are climbing, you have a capacity problem masquerading as a quality gate.

Do not treat AI review adoption as a proxy

GitHub says one in five reviews on the platform now involves an agent. Good. That does not tell you whether your org's unreviewed merge rate is 5% or 50%.

Measure both. AI review participation and merged-without-review rate belong on the same dashboard.

What I would check this week

If I were staffing a team that just turned on agentic coding across the org, I would want three numbers before the next planning meeting:

1. Merged-without-review % at org level and for top repos
2. Week-over-week trend on that rate
3. P90 time to first review on PRs that did get reviewed

The first tells you how often PRs merge with no review on the record. The second tells you whether that rate is getting worse. The third tells you whether reviewed PRs are also waiting too long.

Those are exactly the signals GitQuick surfaces - plus rule-based flags when zero-review rate, reviewer concentration, or tail latency cross thresholds worth acting on.

See it on public orgs first

The Showcase is the fastest way to calibrate your intuition. Pick an org you think you understand and look at merged-without-review rate next to median merge time and bot-review share.

You will find organizations that are fast with a higher unreviewed-merge rate, fast with a tighter review trail, and slower in ways that still look governed. The spread is the lesson. Your org is somewhere in that distribution. Probably not where you assume.

Sign in to see reviewer load and org comparison. No GitHub App install required for public datasets.

Try it on your org

The conversation is not whether AI writes code. It does.

The conversation is whether your review process still matches the volume - and whether code is being merged with no one on the record as having looked.

Most teams have never measured that.

Browse the Showcase →

Try GitQuick on your org →

Showcase metrics are derived from public GitHub metadata only. They reflect review-process signals, not code quality or internal engineering culture. Figures come from one-month showcase windows (May–June 2026) and will change as underlying data refreshes. GitQuick is not affiliated with or endorsed by the organizations featured.