AI Code Review Is in 80% of Firms and the Review Bottleneck Hasn't Moved

Two stories went up on October 15 and 16 about the same problem, and they read as opposites. The Register said Postgres 19 is late because AI reviewers found more bugs than humans can fix.^[1] The Claude Code team said most of its changes are now reviewed and fixed by Claude before a person looks.^[2]

One is AI review drowning people. The other is AI review replacing them.

Read on their primaries, they are the same story. The finding was never the expensive part of review. Deciding what a finding means for this codebase is, and the two projects that are coping both wrote that decision into the process.

Why was Postgres 19 delayed?

PostgreSQL 19 moved from an early-October release to November 19, with a second release candidate on November 12, after the release team cited the volume of fixes added to the back branches.^[3] About 8 to 10 significant features were reverted during beta.^[4] The committers' own accounting puts one of those reverts on an AI finding.

Tomas Vondra, a PostgreSQL committer, read the mailing-list threads behind twelve reverts between May 20 and September 16 and classified each one. Eight were not AI. Two were probably not. One was possibly AI, and one was.^[5]

His summary sentence rounds that to "only 4," which is looser than his own table.

What changed was timing. The project handled about five CVEs last year and 44 so far this year, and senior contributors spent April to August on security fixes instead of beta review. Vondra calls that "one of the primary reasons for the lower review activity during the stabilization period."

Christophe Pettus, a PostgreSQL consultant at PGX, put the chart into one line: "Review did not increase. Review happened late."^[7]

Peter Eisentraut, a PostgreSQL committer and a vice president at EDB, describes the long tail from the receiving end: with LLM-assisted review "you're staring at a list of like forty defect reports," and even at a three-line fix each, "there is a fixed overhead to dealing with each of these, and then you run out of time."^[4]

Nothing in his account is an unfixable bug. Everything is a finding waiting for a person to decide it.

The dispute is real and I am not settling it. Snowflake's Elizabeth Garrett Christensen wrote in September that "AI has to be part of the story,"^[6] and Eisentraut treats LLM review as part of it. Vondra and Pettus argue its share was small. Both readings are about what it costs to dispose of a finding.

The one clear AI case is a person deciding

Noah Misch ran Opus 5 over commit d516974, the CREATE SCHEMA object-type expansion. The review's most important finding was not in that commit at all but in a sibling commit, and of the four findings in the commit he had asked about, he dismissed three and accepted one as real but unconcerning.^[7]

Then he wrote the paragraph that carried the revert, which was his own: modest benefit, a parser burden for every supported command, a risk of painting the project into a corner.

What did the Claude Code team actually change about review?

They moved the reading to machines, kept the decisions with people, and tuned the reviewer on how authors disposed of its comments. Claude writes about 90 percent of Claude Code's code, and from June to September merged pull requests more than doubled while the share reverted fell by more than 40 percent.^[2]

The numbers are self-reported, and the authors do not present them as benchmarks.

When they ran git blame on what the reviewer kept flagging, about 59 percent was code that had been there since its first pass. One pull request went through more than fifty rounds of review and fixes overnight. The team capped pull requests at three rounds and tagged every finding Important, Nit or Pre-existing, so an old bug does not look like the author's fault.

The tuning signal is what authors did with each comment

They sort every comment by what the person on the pull request did with it: fixed it, said it was wrong, said the behavior was intentional, or decided it did not matter.

After that work, pull requests passing after one round went from 65 to 78 percent, those needing five or more rounds fell from 8.9 to 1.5 percent, and mean reviews to pass dropped from 2.08 to 1.32.

Their replacement for "did a human read the code?" is a judgment. In their words that question is an imprecise proxy for what could go wrong with this change and which check, automated or human, should catch it. A classifier sets a risk tier per change: low needs no person, medium one, high two.

An agent's approval never counts as a person's. That is the rule the empty review seat we wrote about in September was missing.

Revert and incident rates are the numbers they watch, with a plain caveat: there are no circuit breakers yet, and if those rates rise they have moved human time rather than saved it. That is the loop as an architecture decision, not a vigilance one, run at 30,000 merges a day.

Why doesn't AI code review clear the bottleneck?

Because the bottleneck is the decision about each finding, and a review tool produces findings. Across 718 firms, nearly 80 percent had AI in code review by March 2026, yet AI wrote 23 percent of review comments and touched 11 percent of pull requests, and the review bottleneck persisted.^[8]

That measurement is the spine of this post. Fiona Chen and James Stratton at Harvard used Jellyfish's engineering-analytics data: 725,938 workers at 718 firms and about 300 million GitHub, Jira and calendar events from January 2021 to March 2026, compared across firm adoption dates.

Coding agents raised lines of code 30 percent, commits 20 percent and pull requests 23 percent. Issues and epics resolved did not move, with any gain capped at 12 percent of baseline. It is the firm-level version of more commits, not more releases, and the paper finds where the gain went.

• Days from pull request open to merge rose 3.45 on a 7.03-day baseline, a 49 percent increase.
• The share of pull requests with changes requested went from 13 percent to about 25 percent.
• Comments per pull request rose 35 percent.
• The share of workers doing review rose 14 percent.

The caveats are the authors' own: a job market paper, not yet peer reviewed; a vendor data partner; a firm-level treatment that averages over people who never used the tools; output measured as Jira resolution; data ending in March.

What a review agent does and does not do

A Microsoft Research and Carnegie Mellon benchmark of 1,800 review tasks measures the finding side.^[9] The best agent catches 79.6 percent of the bugs humans found before merge and 64.2 percent of those found after, at $2.97 a task. It does up to 25.5 points worse on proprietary code and executes the code it reviews in about 8 percent of its turns.

The authors call the failure overtrust: agents accept the author's claims as evidence that the code works.

The human side matches. In a survey of 239 practitioners across 31 countries, 61.1 percent require more evidence for an AI-authored pull request, and the share who would block approval under residual uncertainty rises from 19.4 percent to 43.9 percent.^[10] The survey is self-selected, and its authors say so.

Reviewers want evidence they can own, and a finding is not evidence until someone has decided it is.

Anthropic measured the attention bill in its own building. Its workforce report says agents work six times the hours of their employee handlers, about 80 percent of interactive session time is spent waiting for human input, and "this acceleration makes human attention the bottleneck for agent output."^[11] Stack Overflow's 30,903 developers say the same: 48 percent trust AI only when they can easily validate the answer.^[12]

What does a finding cost?

It costs the time of the person who has to decide what it means, and that is now a line item. Code Review for Claude Code averages $15 to $25 per review, billed through usage credits, with a Quick, Standard or Deep setting per repository and an admin spend cap, and a review does not approve or block the pull request.^[13]

The product went generally available on October 15 for Team and Enterprise plans, and its findings carry the same three tags as the internal reviewer, with Normal in place of Important. I am not pitching it. The price is here because the other half of the cost does not appear on the invoice.

A finding is a claim on a person's judgment, and the review is the disposition of that claim. Martin Fowler, Addy Osmani and others have said a version of this before me, and the Postgres half belongs to Vondra and Pettus, who said it first with the numbers. What I have not seen is the two primaries and the 718-firm measurement in one place.

Three setups that wrote the disposition down

Both projects that are coping stopped treating findings as an inbox. The Claude Code team tags them, tiers the change, caps the rounds, and measures noise by what authors do. Pettus's proposed policy for Postgres is the same shape in three lines: disclose the tool, verify and reproduce every point before posting it, and hold reviews to a stricter standard than patches.^[7]

The Linux kernel, as Hackaday reports it, dropped its tag requirement for AI-assisted patches and runs several frontier models over each patch to weed out confabulations before a maintainer reads the result.^[14]

This is the per-item verification record from the other side of the gate. That post was about the column nobody checked. This one is about the column the tool checked and flagged, and who decides what the flag means. Both end at the same place: review is the control point, and the control is a recorded decision.

What should you decide about your own review setup?

Four things, and none of them needs a new tool: where findings go and who owns each one, what a human approval is and is not, the budget per finding, and the number you will watch instead of whether someone read the diff.

1. Give every finding an owner. A finding with no one obliged to answer it is a backlog entry, and the Claude Code team's rule that every comment is fixed or closed with a reason is the whole of the mechanism.
2. Define a human approval. Decide which changes need one person and which need two, and write down that an agent's approval never fills either slot.
3. Budget the finding. A round cap, a pre-existing bucket so old bugs stop being the author's problem, and a cost per review that someone can see.
4. Watch reverts and incidents. The proxy you used to watch, did someone read it, stopped meaning anything once agents started reading.

A $15 to $25 review that produces findings nobody disposes of is a backlog with a receipt.

Postgres 19 will ship six weeks late and, in Eisentraut's words, "very robust, after all the additional scrutiny." Anthropic merges 30,000 changes a day. Both are paying the same bill, in judgment, and both wrote the price down. The finding was never the hard part.