Subscribe
18:00Tao calls OpenAI’s Navier–Stokes push “resource extraction”17:10LAPTOP memecoin hits $190.81, then loses 99% inside an hour17:05Hubinger puts the odds of AI killing everyone above 10%; a colleague resigns16:39CancerBench launches; five frontier models tied at zero cancer types cured16:30ElevenLabs preparing 2028 IPO after $11bn round, The Information reports16:30Anthropic retracts its July explanation: Mythos 5 attacked systems knowingly
Developers3 min read

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.

In briefGitHub said on September 9, 2026 that 84% of a pull request's open-to-merge lifecycle is spent waiting for approval and that Copilot can now supply the approval1The linked changelog entry, published September 1, 2026, announces that Copilot code review can approve pull requests and does not contain the 84% or ten-minute figures2An approval assessment on its own does not count toward merge requirements3
The letterbox of GitHub’s office in Amsterdam
Photo: Rrustema (CC0)

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."

GitHub@github

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

on X · 64.2K views · captured Sep 10, 2026

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.

Sources

01
GitHub said on September 9, 2026 that 84% of a pull request's open-to-merge lifecycle is spent waiting for approval and that Copilot can now supply the approval84% 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…” — x.com · primary · Sep 10
02
The linked changelog entry, published September 1, 2026, announces that Copilot code review can approve pull requests and does not contain the 84% or ten-minute figuresRelease September 1, 2026 • 1 minute read Copilot code review can now approve pull requests Copilot now tells you when a pull request is ready to approve, and admins can authorize it to sign off on approval. The ability for Copilot to…” — github.blog · primary · Sep 10
03
An approval assessment on its own does not count toward merge requirementsAn approval assessment alone does not count toward merge requirements. Copilot's determination is surfaced so you can decide how to act on it.” — github.blog · primary · Sep 10
Show all 6 sources
04
When enabled, a Copilot approval counts toward the repository's required-approvals rule and is dismissed if new commits are pushedBy default, Copilot will not approve pull requests. When enabled, Copilot can submit an approval that counts toward the repository's required-approvals rule. If new commits are pushed after Copilot approves, its approval is dismissed…” — github.blog · primary · Sep 10
05
Admins control the behaviour at enterprise, organization and repository level, with repository admins choosing which file paths Copilot may approveEnterprise: Admins can leave approvals off for the whole enterprise or let organizations decide. Organization: Admins can turn approvals on org-wide, let repository admins decide, enable it for specific repositories, or turn it off…” — github.blog · primary · Sep 10
06
The feature is in public preview for Copilot Pro, Pro+, Max, Business and Enterprise plansThis feature is available in public preview to GitHub Copilot Pro, Pro+, Max, Business, and Enterprise plans.” — github.blog · primary · Sep 10
Up next · Keep readingDevelopers · 3 min read

DigitalOcean puts $3m into Omarchy, taking DHH's foundation to $18.5m in 19 days

A Linux distribution built mostly by agents is now funded by the cloud and the labs whose products it burns.

Continue ↓