The State of Code Review 2026

So, how is code review actually going these days?

Let me spare you the foreplay: most code review is a click, not a read.

We pulled every merged pull request from 261 active public GitHub repos — all 77,949 of them — and went through the full record of each one. Every approval. Every comment. Every timestamp. Then we went back and re-measured the same repos in 2022 (right before ChatGPT showed up) and 2019 (just to have a baseline that predates all this AI stuff). What fell out is what a lot of us suspected but couldn't prove:

• 62% of approvals contain zero words. No comment, no question, no nothing. Just the green button.
• +8.5 points more silent approvals on the same repos since 2022. This drift is recent — it wasn't there before. That's the part that bugs me.
• The typical PR grew from 85 to 124 lines between 2022 and 2026, after barely moving for years before. The diffs really are bigger now.
• 4× less attention per line on big PRs (1,000+ lines) than mid-sized ones. Big diffs get scrolled, not read.
• +47% more lines through the busiest reviewer's hands since 2022 — flat in the window before. Teams added approvers, the average reviewer's load stayed level, and the flood still found its bottleneck.
• +40% more code per author since 2022. Through the placebo window, hiring outpaced the code; the AI era flipped the direction.
• 40% of a typical repo's approvals come from a single person.
• 1 in 23 merged PRs gets a "changes requested." Review almost never says no.
• 1 in 3 team-repo PRs merges with nobody approving it at all.
• 509 approvals landed faster than a human could physically read the diff.
• The 5–14 dev sweet spot — that's the worst-reviewing team size in this whole dataset. Which, depressingly, is most of the industry.

Let's be clear about what "silent approval" means

First, a quick word so nobody quotes me wrong. I'm going to call this rubber-stamping — the old factory-floor term, where they had pre-inked "APPROVED" stamps so managers could sign off faster than they could actually check. It's a description of a behavior, not a verdict on any one person.

What I can actually measure is the trace that behavior leaves: an approval with no words, no questions, no inline comments, from a real human who isn't the author. That's the metric behind every number here.

One important caveat: I'm not claiming 62% of reviewers didn't read the code. Some of those silent approvals were discussed in Slack, or over someone's shoulder, where I can't see it. What I'm claiming is that 62% of approvals leave no evidence that anyone engaged. And when that number shows up across tens of thousands of PRs, the absence of evidence kind of is the finding.

Also, before you accuse me of padding: trivial PRs, docs-only changes, dependency bumps, and bot work are all stripped out before any rate gets computed. Approving a three-line typo fix without a comment is correct behavior. What's left in these numbers is real, substantive code. The full definition of "eligible" is in the methodology.

The question everyone asks: did AI break code review?

You can't answer it the obvious way. We tried. The plan was to compare repos "with AI" against repos "without." That comparison doesn't exist anymore. 87% of eligible repos carry AI tooling files, editor-side assistants don't leave any trace in the PR data, and the honest assumption in 2026 is that most code in most active repos is AI-assisted whether or not we can see it. There's no control group left on public GitHub.

But there's a control group hiding on the time axis: the same repositories, before mass AI code generation.

So we re-measured them. Every comparison is paired within the same repo — a repo only counts if it had 30+ eligible PRs in both time periods, and we test each repo against its own past. No cherry-picking averages across wildly different repos (that's exactly how studies like this produce confident numbers that fall apart later — more on that in a minute). And every line you see below comes from the constant panel: the 41 repos that were alive and eligible in all three windows. Same repos, every point.

The 2019→2022 window is my placebo. If review culture was just eroding on its own, it should erode in both windows.

For silent approvals — the headline metric of this report — it didn't. Silence stayed flat before AI, and only jumped after 2022.

The result: silence jumped exactly in the AI window

The chart above shows how common silent approvals were in each year. The chart below answers a simpler question: how much did each repo change, compared with its own past?

Before AI, the same repos barely changed at all. After 2022, they jumped by 8.4 points. That is the main finding of this report.

Here's how the pattern splits:

Process got better before AI, and held. Zero-review merging dropped from 14% to 5% between 2019 and 2022 — the era of branch protection and required reviews. The gates went up and they've stayed up. Nobody is dismantling code review.

What changed is attention. Silent approvals were flat from 2019 to 2022, then jumped after 2022. Pushback ("changes requested") is a different story: it has been slowly fading since 2019, at the same rate before and after AI. So the AI era didn't kill pushback — that was already happening. What the AI era changed is the silence.

The ritual got stronger. The attention got weaker. And for silent approvals specifically, it got weaker in the AI-era window.

Before you blame AI — two honest checks

"Maybe bots are causing the spike?" We checked. After removing every PR where a bot reviewed before the human approval, the increase actually grew — to +12.3 percentage points. So bots don't explain the trend. Full checks in the methodology.

Does this prove AI caused it? No. The timing fits AI — but it also fits two other things: people going back to offices (talking at a desk leaves no trace on GitHub), and the 2022–23 layoffs. Our data shows when review went silent, not why. So that's the claim we make: it happened in the AI era. We don't claim AI did it.

The PRs themselves got bigger

One more thing changed in the AI window, and it isn't about how people review — it's about what lands in front of them.

For years, the typical PR stayed the same size. Then, in the AI window, it grew by half. And it's not a few huge repos pulling the average — three out of four repos grew. Same pattern as the silent approvals: flat for years, then one jump.

How much more code is that in total? Rough math, but the direction is clear:

• The median repo now ships about twice as much code per half-year as in 2022 (+69%, p = 0.005).
• Teams barely grew: 36 → 38 active authors. That works out to about 40% more code per person.
• Repos did add approvers (13 → 17). It didn't help where it matters: the busiest reviewer now approves 47% more lines than in early 2022, after a flat window before.

So the median repo did the obvious thing — it added reviewers — and the extra load still landed on the one person who already carried the repo. (How we count lines, and why totals are a noisy number, is in the methodology.)

Now put that next to the 4× finding below: big diffs get a fraction of the per-line attention. The AI era makes exactly the kind of PR that gets scrolled, not read — and it lands on the reviewer who was already the bottleneck.

The bigger the change, the less it's read

Read that headline precisely: most small PRs draw zero inline comments anywhere, which is often perfectly correct behavior. Attention peaks on mid-sized PRs (200–999 lines) at about 0.2 per 100 lines. And PRs over 1,000 lines drop to 0.05 — roughly a quarter of the per-line attention of mid-sized changes, on exactly the diffs carrying the most risk. This is a claim about mid-sized versus large diffs, not a clean line from tiny to huge. Our own medians aren't monotonic, and I'm not pretending they are.

One honest caveat: some of that drop on huge diffs is content, not attention — 1,000-line PRs skew toward migrations, refactors, and generated code, which legitimately need fewer words per line. But the reviewer's experience is still the one this number describes. And anyone who has stared down a 2,000-line diff knows the exact moment: the point where you stop reading and start scrolling.

This one held almost exactly from our pilot, on four times the data.

Review rests on one person, and that person is drowning

In the median repository, one reviewer gives 40% of all approvals. In 51 of 215 repos, one person gives more than three-quarters.

Here's the part that reframes the whole report: concentration is not new. The top reviewer's share was 41% in 2019, 33% in 2022, 31% in 2026 — flat, even a bit better. Review has rested on one person for as long as we can measure.

What changed is the load, and where it landed. Since 2022 the typical PR swelled from 85 to 124 lines and total code per repo grew about 69%. The approver bench stretched enough to hold the average reviewer's line-load flat — but concentration didn't move, and the busiest reviewer now approves 47% more lines than in early 2022.

So the story here is not "engineers got lazy." It's "review has too few people for the amount of code, and the AI era made the code grow faster than the people." A single reviewer facing a queue that never ends approves fast, because the alternative is blocking everyone. That's triage, not negligence. And triage is a structural problem — which means it has structural fixes.

The one number nobody can argue with

For the strictest possible measure, we required three independent conditions at once: a silent approval and faster than human reading speed and 50+ lines changed. That's 1% of PRs — 509 cases where arithmetic alone proves the diff wasn't read after the review clock last started.

Even this has an escape hatch, so here it is: a reviewer who read round one, requested changes, then approved a small fixup seconds after being re-requested would trip the clock legitimately — the reading happened before the final "ready for review" anchor. Stacked and re-reviewed PRs can do the same. That's why we report 509 as a floor: no reading after the final anchor, not "nobody ever read these."

In the other direction it dramatically understates the problem, because most unread approvals don't conveniently happen at superhuman speed. Whatever you believe about Slack threads and side conversations, at least this much post-anchor reading provably never happened.

Who rubber-stamps? The answer is uncomfortable

The averages hide the useful question: who is this happening with?

A repo with 5–14 active authors silently approves twice as often as one with 40+ (rank-sum p = 0.005). But read the sample sizes before you quote that: the contrast leans on a 117-repo band against a measly 12-repo band, and each thin tail is one unlucky repo away from moving several points. The methodology flags both.

The 5–14 band isn't the exception, though — it's 117 of 215 comparable repositories. More than half the sample. The ordinary team of eight is the worst-reviewing shape in the data.

The mechanism is plausible even if I can't prove it here: a team of eight has no reviewer bench. Everyone's busy, and the reviewer is usually the one other person who actually understands that part of the code. A team of forty has real redundancy and, usually, a written process. There's also an innocent reading for the smallest teams — three people who designed the change together at one desk have little left to say in writing. Silence there can be shared context, not neglect. Our data can't tell those apart.

If you run a team of five to fifteen engineers: these numbers are about you, statistically speaking.

Company repos aren't more careful. They just never skip the approval.

Here's a comparison that surprised us:

Companies rubber-stamp exactly as often as communities (68.5% vs 65.1% — statistically identical). The difference is that in a company, someone always clicks approve: 4% of PRs merge with no approval, versus 44% in community repos. The approval is guaranteed. The attention isn't.

Two honest readings fit those numbers, and you deserve both. The generous one: companies put a reviewer in front of nearly every PR with the same per-review verbal quality as communities — so in total, they simply do more review. The uncomfortable one: the required approval guarantees a record of review exists, not that scrutiny happened — and when the postmortem asks "was this reviewed?", a wordless approval answers "technically yes."

The data supports the numbers. Choosing between those readings is interpretation, and the first one is what the table supports most directly. What the data does not support — and we said otherwise in an earlier draft — is that required approvals are somehow emptier. They aren't.

You can't tell how carefully a team reviews by looking at their repo

This surprised me the most. We correlated the silent-approval rate against everything we could observe:

• Stars: r = −0.02
• Distinct authors: −0.12
• PR volume: −0.05
• Reviewer concentration: −0.08

Nothing predicts review quality. A 50,000-star project is no more likely to review carefully than a 300-star one — the star bands run 65.7%, 72.2%, 66.7%, 66.7%, 63.5% from smallest to largest. No pattern at all.

This also answers a fair objection to the entire study — "you just sampled badly-run projects." No. The worst-reviewing repos are indistinguishable from the best on every structural measure we can observe. Careless review isn't a property of bad projects. It's ambient.

The finding we withdrew — and why you can trust us because of it

At 55 repositories, our strongest result was this: PRs that merged without review looked twice as likely to need a bug fix within two weeks. Big gap. Tight confidence intervals. Great story. It's exactly the stat a code-review company would kill to lead with.

At 261 repositories, it fell apart.

Mix all repos into one big number and the gap still looks huge: 47.9% of unreviewed PRs later needed a fix versus 31.4% of reviewed ones. But compare each repository against itself and the effect vanishes — 43 of 81 repos point the opposite way. Sign test p = 0.78. That's a coin flip.

Why the flip? Because most zero-review PRs come from repos that barely review anything — and those repos are different in many other ways too: smaller teams, older code, more release pressure. So the big mixed number wasn't comparing reviewed PRs against unreviewed ones. It was comparing repos that review against repos that don't — and giving review the credit for everything else that separates them. (Statisticians call this Simpson's paradox.)

So, plainly: we could not detect a defect cost to skipping review in this data. That's not evidence it's safe — our way of spotting "this PR needed a bug fix later" is a rough guess, and it misses a lot. But we won't claim what the data doesn't show.

One more correction while I'm here: an early pass suggested heavy-AI repos rubber-stamped less — a fun counterintuitive headline. Also wrong. Unequal group sizes, and a handful of big repos drove it. The real correlation between visible AI usage and silent approvals is r = 0.05 across 162 repos: nothing. Show more AI usage, doesn't predict worse reviewing. The AI signal lives in the era comparison, not in comparing repos against each other.

We publish the reversals because how a number fails tells you more than the number ever did — and because a study willing to kill its own best headline earns the right to be believed on the ones that held. And this wasn't the only cut: when we re-tested our AI-era claims with a stricter method, the drop in pushback also fell out — it was already falling before AI, at the same speed, so it's an old trend, not an AI-era finding. Every correction is in the corrections log.

The language table (for arguing responsibly on the internet)

This chart is here for fun, not as evidence. The differences say nothing about the languages themselves — a project's language comes bundled with everything else: the kind of project, the size of the team, company or community. And these numbers are shaky: Rust's alone moved almost 40 points when we grew the sample. Enjoy, share, don't cite.

What this study can't see (read this before quoting us)

• Out-of-band review is invisible. Pair programming, Slack, calls, a walk to someone's desk — none of it leaves an API trace. Some silent approvals were genuinely reviewed somewhere we can't observe. This is the study's single biggest caveat, and it has an era-shaped edge: the amount of invisible review plausibly changed across 2019→2026. Peak remote pushed discussion into writing; the return to offices pulled some of it back out. Every number here is a floor on invisible review, not a verdict on individuals.
• Timing is a proxy. We see when the approve button was clicked, not when reading began — and the clock restarts on re-request, so re-reviewed fixups can look faster than they were.
• Only merged PRs enter the sample. The sharpest form of review — a PR argued down and closed without merging — never merges and is therefore invisible here. Our 4.4% changes-requested rate is measured among survivors of that filter. Relatedly, many teams deliberately avoid the request-changes button (it hard-blocks the merge) and push back in plain comments instead. Some of that long-run decline may be button etiquette drifting rather than objection dying. Collecting closed PRs is on the roadmap.
• Public repos aren't private ones. Volunteer dynamics shape public review. Our company-cohort findings narrow that gap, but the same analysis on private repos would be genuinely new information (and we're building exactly that).
• The era comparison observes survivors. Only repos still alive in 2026 have a past to measure — and repos already mature in 2019 are the oldest in the sample, where growing mutual trust quiets review naturally. It's a natural experiment: the change is located in the period; the cause is not established, and three candidates fit (mass AI code generation, return-to-office, layoffs).

The full methodology — eligibility rules, the exclusion ledger (all 77,949 PRs accounted for: 51,065 analyzed, 26,884 excluded under named reasons), metric definitions, pairing rules, the robustness suite, the corrections log, and every confound we chose to report rather than correct for — is in the published methodology. The pipeline is reproducible: the analyzer is a pure function of collected data, and re-running it produces byte-identical output. We store metadata only — no code, no diffs, no titles, no review text ever touches disk, verified mechanically across all records.

So what does this actually mean?

In most repositories, review functions as a gate to pass, not a process that changes the code. That was already true before AI. What the AI era coincides with is the 8.5-point rise in wordless approvals on the same repos — and whether the driver is generated-code volume, emptier offices, or thinner teams, every candidate explanation points at the same bottleneck: more change flowing past the same finite human attention.

Here's what all of it adds up to: more and more code enters these repositories without anyone really checking it. And code nobody checked is code nobody knows. Every silent approval widens the gap between what's in the codebase and what the team actually understands about it. That gap compounds quietly, PR by PR — until the day you need to fix something, change something, or just work in that code, and nobody on the team remembers how it works or why it's there.

We built Reviewsaur to stop that gap at the door. It walks the team through each PR — explaining, from the actual diff, what changed and why it matters — and then checks that the people really understood it, before the merge. But you don't have to take the product to take the point: the cheapest moment to understand code is before it merges. Every merge after that moment turns understanding into archaeology.

One more thing: this report is meant to be argued with. If you think a number is wrong, a method is unfair, or we missed something — write to [email protected]. This is a living document: it has already changed under its own corrections, every change lands in the corrections log, and the version number at the top tells you which revision you're reading. Good criticism doesn't threaten this report. It's how it gets better.

See where your own repo stands. We turned this study's engine into a free scanner — same metrics, benchmarked against these 77,949 PRs, on your repo, in about thirty seconds.

The State of Code Review 2026 · v1.1 · Reviewsaur Research · Data collected August 2026 · 261 repositories, 77,949 merged PRs (2026 arm), 17,521 (2022 arm), 8,031 (2019 arm) · Questions and recomputations welcome: methodology and definitions published in full.