GitHub lets Copilot approve pull requests, on a statistic it has not published
The 84% figure in the announcement does not appear in the changelog the announcement links to.

GitHub posted a number on September 9th 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." The offer that follows: "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
The post links to a changelog entry from September 1st. We read it. Neither the 84% nor the ten-minute median appears anywhere in it. No population, no time window, no note on whether draft or bot pull requests are counted (a share of a lifecycle and a median duration are also not the same kind of statistic, which is a small tell about where they came from).
Which matters more than it usually would, because that number is the entire argument for the feature.
The feature itself is more careful than the tweet. Copilot approvals are off by default (which is the right default, and worth saying). Every Copilot review now ends with an approval assessment in its overview comment, and GitHub is explicit that "an approval assessment alone does not count toward merge requirements". Turning the real thing on is a three-level decision: enterprise admins can forbid it outright or delegate, org admins can enable it everywhere or per repository, and 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-scoping control is the one to notice. It is GitHub conceding, in a settings page, that whether a machine approval is safe depends on what the diff touches — which is true, and which no amount of model improvement makes untrue.
So where does that leave the 84%?
A queue is not a defect. If most of a pull request's life is spent waiting for a human, 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 which 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.
Our read is that GitHub knows this, which is why the shipped feature has three admin switches and a path filter while the marketing has one statistic. The gap between the two is where the misuse will happen. Somebody's platform team will enable it org-wide to clear a backlog, and the first time it matters will probably be a change that slipped through a path filter written eight months earlier.
Here is what we would want before this leaves public preview. A required-approvals rule that can distinguish a human approval from Copilot's — so a repository can say "two approvals, at least one from a person". Nothing in the changelog says that exists today, and a repo requiring two approvals can seemingly 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 fair case for the other side is that human approvals were never worth what the branch protection rule pretended. Plenty of reviews are a glance and a thumbs-up from someone who has not read the diff, and a model that has actually read every line and says so in an itemised comment may be the better reviewer of the two. That is a real argument, and if you have ever rubber-stamped a colleague's PR at 5pm on a Friday you know it is not a cheap shot.
But it is an argument for changing what approval means, in the open. Not for changing who supplies it, quietly, on the strength of a number nobody can check.
Ask your admin which file paths are on the list.
