AI Code Review Can Now Approve Pull Requests That Get No Human Review

On September 1, GitHub added a sentence to the Copilot changelog that changes what a green check means: "When enabled, Copilot can submit an approval that counts toward the repository's required-approvals rule."^[1]

It is off by default. An administrator has to switch it on, it can be limited to specific file paths, and a new push dismisses it the way it would dismiss a human's approval. It is in public preview across every paid Copilot plan.

Read plainly: a pull request can now be written by a model, approved by a model, and recorded by the repository's branch protection as reviewed.

What did GitHub actually ship on September 1?

GitHub shipped two things. Every Copilot code review now includes an approval assessment, a read on whether the pull request looks ready, which on its own does not count toward merge requirements. Separately, administrators can let Copilot submit a real approval that satisfies a required-approvals rule the way a human reviewer's does.

The generous reading of why is easy to give, because it is true. Generation outran review. Teams that let agents open pull requests found the review queue growing faster than the reviewers, and automating the review is the obvious answer to a real queue.

GitHub is also changing Copilot's default review effort from Lite to Balanced on September 28, which is more scrutiny per review rather than less^[2]. PostHog was already letting its own review agent give the final stamp on roughly one in three merged pull requests when we wrote in July that review is the control point.

Nobody in that picture is being reckless. They are answering a queue.

Do developers review AI-generated pull requests?

Mostly not. A May 2026 study of 33,596 agent-authored pull requests in popular GitHub repositories found that 61.38% received no review comment from anyone, 22.6% were reviewed only by other AI agents, and 15.9% show any human participation. The queue the approve button answers was never full of humans waiting.

The study comes from a team at Nicolaus Copernicus University in Toruń, working on the AIDev dataset of pull requests opened by agents such as Copilot, Devin, Claude and CodeRabbit in repositories with 100 or more stars^[3].

Their scoping is careful and worth carrying. "No review" means no review comment from anyone, and the authors say a silent approval falls on that side because nothing in the record distinguishes it from nobody looking. They report no merge rates, and they do not control for pull request size or complexity.

The human contribution, where it exists, is thinner than the count suggests. Of all comments on AI-authored pull requests, 71.58% were written by agents. Of the human comments, 28.37% were steering the agent ("try again with X") rather than judging the code.

The paper's own conclusion is methodological, and it is the sentence that matters most for anyone who reads review counts as a safety signal.

The July prescription assumed a reader

That July post prescribed keeping a named human on every consequential merge, and I still think that is right. The Toruń numbers say it was optimistic. For six AI pull requests in ten, the named human was not there before any vendor offered to replace them.

The prescription assumed a reader who, on the measured data, mostly was not reading. That is a correction, and I would rather make it in the open.

Why did the reviewers leave?

Because reading is labor, and AI-written code asks for more of it than its author supplied. Sonar's January 2026 survey of more than 1,100 developers found that 96% do not fully trust AI-generated code, yet only 48% always verify it before committing, and 38% say reviewing AI code takes more effort than reviewing a colleague's^[4].

The gap between the first two numbers is where reviewers are opting out, and the third says why.

The practitioners say the same thing

The practitioner texture matches. In a Lobsters thread this month, a developer described coworkers' AI pull requests running to thousands of lines and asked how anyone survives reviewing them^[5].

One reply set the norm: "6k diffs are completely unreviewable, and would be rejected in our workplace. We have rules that PRs with diffs cannot be > 400 lines." Another admitted the quieter response: "Now I only review PRs people directly ask me to review."

Neither of those people is being automated away. They are declining to read what nobody wrote, and the pull requests keep merging around them. It is the problem we described in why AI-built apps get harder to change every week, seen from the reviewer's chair, where the trouble is not that nobody can read the code but that nobody will.

Is the reader revolt the same thing?

Yes, and it is measured. A June 2026 survey of 668 developers found 78% stop reading when they suspect a model wrote a piece, 71% avoid the author afterward, and 98% prefer an imperfect human-written piece to a polished machine-written one. A code reviewer refusing a 6,000-line AI diff is the same person making the same call.

The survey is self-selected and anonymous, recruited on X, Bluesky and LinkedIn, and its authors say so^[6]. Read it as a measured signal from developers who read technical blogs, not as a population estimate. The signal is loud enough either way.

Bryan Cantrill, co-founder of Oxide Computer Company, named the mechanism in an essay on September 5^[7]. Oxide now requires its public writing to register as human-authored on a detector, which is the reader refusing on the record.

Put the two refusals side by side and they are one judgment. Reading is labor, and the labor was supposed to be matched by the writer's. When the writer is a model, the reader's half of the contract is the only half left, and people are declining to hold it alone.

That applies to a design document, a blog post and a pull request in exactly the same way.

What does the approve button change?

It does not remove a human reviewer, because on the measured data there mostly was not one. It removes the visible gap. Before September 1, an unreviewed AI pull request looked unreviewed. After it, the same pull request can carry an approval that satisfies branch protection, and the history will say that someone checked.

The absence becomes invisible, and that is the change that matters.

It is the trade the review layer for agent actions already made one level down, moved up to the pull request itself.

The supply side is moving the same way, and openly. Vercel's AI SDK team now has its own agents author between 25 and 35% of the pull requests it merges, and Lars Grammel, an engineer there, describes the trust as being in "that particular agent configuration" rather than in the community of contributors^[8].

That is a reasonable position for a team that built and tuned the agent. It is also a review process in which the reviewer and the author are the same configuration.

What GitHub got right

To be fair to GitHub, the controls are careful. Approvals are off by default. They are gated at the enterprise, organization and repository level. A repository administrator can restrict which file paths Copilot may approve. A new push dismisses the approval, and an approval assessment on its own never counts toward merge requirements^[1].

Those are the controls of a company that knows this is a judgment seat. The decision to enable it is the one that needs a human, and it lands on the same teams whose reviewers have already stopped reading.

Which merges still need a human reader?

The ones where a test suite cannot tell you what a reviewer would have. A September 2026 benchmark called SWE-Gate found that of 644 agent repairs that passed their functional tests, 221 still violated review constraints that real maintainers had imposed on the same kind of change. That gap is what a reader supplies.

SWE-Gate covers Python repositories, one agent scaffold and only the constraints that can be written as executable tests, so treat it as a benchmark result rather than a field rate^[9]. It still puts a number on the seat: roughly a third of the changes that passed the tests would not have passed the people.

The practical response fits in four moves.

• Decide, per repository, which changes still require a named human reader: authentication, payments, data migrations, anything that touches a trust boundary. Express that as a required review Copilot's approval cannot satisfy, using the path restrictions GitHub itself provides.
• Cap the size of an AI pull request at a number a human will actually read. The 400-line norm from that Lobsters thread is as good a starting point as any.
• Treat "no human comment" on an AI pull request as a metric to watch. The Toruń paper says it is the majority case, so it is not a rare failure you will notice by accident.
• If your reviewers have stopped reading, ask why before buying a tool that stops asking.

Human review of AI output was always a courtesy the system could not enforce, and the data says the courtesy is being withdrawn on both sides of the keyboard. A review record that no human produced is a receipt for a decision nobody made.