GitHub added total merged pull requests by adoption phase to enterprise and organization reports, giving admins a much cleaner way to connect AI rollout stages to delivery throughput.
Admin AI reporting is usually full of activity theater.
Seats assigned. Active users. Interactions counted. Some average nudged upward.
Useful, maybe. Persuasive, not really.
GitHub's latest Copilot reporting update is more interesting because it gets a little closer to delivery proof.
GitHub says enterprise and organization reports now include total_pull_requests_merged inside the adoption-phase breakdown.
That sounds small.
It is not.
Butler already covered GitHub's earlier adoption-cohort maturity map, which gave admins a better way to separate code-first, agent-first, and multi-agent behavior.
The obvious next question was: great, but what are those phases actually producing?
This update is GitHub's first better answer.
Average merged pull requests per user can be directionally useful, but it leaves too much ambiguity.
A small advanced cohort can look great on averages while still contributing a tiny share of actual delivery. A broad but lighter cohort can look boring while moving a lot more real work.
Total merges by phase help fix that blind spot.
Now an admin can ask how much of the organization's merged pull-request volume is actually coming from code-first, agent-first, or multi-agent behavior. That is a much more practical planning input than a generic engagement number.
As Copilot usage grows, admin analytics are no longer just interesting dashboards. They are budget and governance tools.
Butler has already tracked GitHub's move to AI Credits and GitHub's per-user AI credit accountability push. Once costs and approval expectations rise, leadership needs a cleaner story than people seem active.
Throughput evidence does not solve ROI by itself, but it gives rollout owners something closer to operational proof.
If a phase is expensive and contributes little merged output, that matters. If a more advanced phase contributes a disproportionately large share of merged work, that matters too.
This is where teams should stay disciplined.
More merged pull requests do not automatically mean the AI rollout is good. Higher totals can coexist with lower quality, more review churn, or work that should not have been accelerated in the first place.
So the right use of this metric is not triumphalism. It is comparison.
Pair the phase totals with review quality, cycle-time context, and budget and escalation rules for AI agent workflows. Use it to spot where adoption is producing real movement and where it is mostly expensive enthusiasm.
The bigger pattern here is that GitHub keeps adding controls and measurements around how Copilot behaves at scale.
That means the product story is shifting. Copilot is not just a developer tool anymore. It is an operating system for rollout decisions, training decisions, budget decisions, and proof-of-impact arguments.
This metric update is small in UI terms. It is large in management terms.
First, check whether advanced adoption phases are contributing a meaningful share of merged work or merely generating heavier interaction counts.
Second, compare those totals against spend and review burden instead of celebrating raw volume.
Third, use the metric to refine training and enablement. If one phase shows stronger throughput without chaos, that may be where more rollout energy belongs.
GitHub's new merge totals by adoption phase matter because they move Copilot analytics one step closer to delivery proof.
That is the kind of reporting enterprises actually need.
This article was researched and drafted with AI assistance, then reviewed and edited for clarity, accuracy, and editorial quality.