GitHub lets Copilot approve pull requests, on a statistic it has not published
The 84% figure in the announcement does not appear anywhere in the changelog that the announcement links to.
The slowest part of a pull request is waiting for a colleague to look at it. GitHub has decided the fix is to stop waiting.
On 9 September 2026 the company posted a statistic, and a product to go with it. "84% of a PR's open-to-merge lifecycle is spent waiting for approval. Once it gets the green light, it takes a median of 10 minutes to merge." Then the offer: "Instead of waiting for someone to sign off, you can now get an approval as soon as Copilot reviews your pull request."
84% of a PR’s open-to-merge lifecycle is spent waiting for approval. Once it gets the green light, it takes a median of 10 minutes to merge.
Instead of waiting for someone to sign off, you can now get an approval as soon as Copilot reviews your pull request.
t.co/DBTvw6wceG
That post links to a changelog entry from 1 September. We read it. Neither figure appears anywhere in it, and there is no population, no time window and no note on whether draft or bot pull requests are counted. (A share of a lifecycle and a median duration are not even the same kind of statistic, which is a small tell about where they came from.)
Which matters more here than it usually would.
The number is the entire argument for the feature.
The shipped product is far more careful than the post
Copilot approvals are off by default, which is the right default and worth saying plainly. Every Copilot review now ends with an approval assessment in its overview comment, and GitHub states that "an approval assessment alone does not count toward merge requirements".
Turning the real thing on takes three decisions. Enterprise admins can forbid it outright or delegate; organisation admins can enable it everywhere or per repository; repository admins choose which file paths Copilot is allowed to approve. Push a new commit after Copilot approves and its approval is dismissed, exactly as a human reviewer's would be.
That path filter is the control to notice. It is GitHub conceding, in a settings page (the most honest surface any company owns), that whether a machine approval is safe depends on what the diff touches.
No amount of model improvement makes that untrue.
A queue is not a defect, and removing it is not the same as fixing it
So where does that leave the 84 percent? If most of a pull request's life is spent waiting for a person, that is a fact about your team's staffing and batching, and the fixes are unglamorous. Smaller changes. A review rota. A stated turnaround time. None of them need a purchase order.
Making the approval instant does not shorten the review. It removes the wait by removing the reviewer, and those are different products even when they produce the same green tick.
GitHub plainly understands this, which is why the shipped feature has three admin switches and a path filter while the announcement has one statistic. The gap between those two is where the misuse will happen. Some platform team will turn it on org-wide to clear a backlog, and the first time it matters will probably be a change that slipped past a path filter somebody wrote eight months earlier. We have seen this shape of gap before, in Codex ships a remote-control command its own docs say does not exist.
Here is what we would want before this leaves public preview, where it currently sits for Copilot Pro, Business and Enterprise plans. A required-approvals rule that can tell a human approval from Copilot's, so that a repository can demand two approvals with at least one from a person. Nothing in the changelog says that exists, and a repository requiring two approvals can apparently satisfy one of them with a bot.
We expect that control to ship before general availability. If it does not, GitHub has decided the two kinds of approval are interchangeable, and it should say so in a sentence rather than in a default.
The case for the other side is better than it sounds
Human approvals were never worth what the branch protection rule pretended. Plenty of reviews are a glance and a thumbs-up from somebody who has not read the diff, and a model that has read every line and itemised its findings may well be the better reviewer of the two. If you have ever rubber-stamped a colleague's pull request at five on a Friday, you know that is not a cheap shot.
But it is an argument for changing what approval means, out loud. Not for changing who supplies it, quietly, on the strength of a number nobody outside GitHub can check.
Ask your admin which file paths are on the list.
