GitHub updated its Copilot usage metrics API on June 26, 2026, so enterprise and organization reports can now show the total number of pull requests merged by users in each AI adoption phase. That sounds like a small schema change, and in a narrow technical sense it is. But for engineering leaders trying to prove whether AI coding tools are changing delivery, the new field matters because it shifts the conversation from average behavior to organizational throughput. The metric will not settle the ROI argument by itself, but it gives enterprises a more honest starting point.
The new field,
The distinction is not cosmetic. Averages are useful when you want to compare a typical user in one cohort with a typical user in another. Totals are useful when you want to know where the work is actually moving through the system.
That is the difference between saying “advanced Copilot users merge more pull requests per person” and saying “advanced Copilot users account for 38 percent of merged pull requests this month.” The former is a behavioral insight. The latter is an operational fact that can show up in planning meetings, platform engineering reviews, and budget renewals.
GitHub says the metric is available in both 1-day and 28-day organization and enterprise reports. It uses the same attribution method as the existing average pull request merge metric, which matters because a new denominator or attribution model would have made historical comparisons harder to trust.
Imagine an enterprise with 1,000 licensed Copilot users. If 30 highly engaged users are merging many pull requests, their per-user average might look impressive. But if those 30 users represent only a small slice of total engineering activity, the business impact may be modest. Conversely, a large middle cohort with a lower per-user average may be carrying most of the actual delivery load.
That is the problem GitHub’s new field helps address. By exposing total merged pull requests by adoption phase, GitHub makes it possible to calculate each phase’s share of total merged work, rather than simply comparing the behavior of an average user in each phase.
This matters because AI adoption programs often suffer from “champion bias.” The most enthusiastic developers generate the cleanest demos, the strongest anecdotes, and the easiest success stories. But enterprise software delivery is not transformed by a few power users alone; it changes when ordinary teams alter their daily workflow at scale.
That classification is important because it turns Copilot from a licensed product into a managed program. Instead of asking only who has a seat or who used Copilot yesterday, an organization can ask which developers are moving through adoption stages and whether those stages correlate with delivery behavior.
This is where the new merge total fits. A phase model without delivery metrics is mostly an enablement dashboard. A phase model with pull request creation, review, merge, and time-to-merge data starts to resemble an engineering operating system.
The risk, of course, is that GitHub’s taxonomy becomes a proxy for developer value. That would be a mistake. Adoption phase is a telemetry-derived classification, not a performance review. It can show patterns in tool engagement, but it cannot explain architecture complexity, incident load, code ownership, or whether a developer is doing the invisible work that keeps a system stable.
That bluntness is useful. Enterprises already have too many squishy AI dashboards filled with proxy metrics that look precise but collapse under scrutiny. Lines accepted, suggestions shown, chats opened, and generated tokens can all say something about usage, but they say less about whether work is reaching the mainline.
Merged pull requests are not perfect either. A pull request can be tiny or enormous, valuable or reckless, routine or strategically critical. But merge activity sits closer to the actual software delivery pipeline than many AI usage counters do.
For WindowsForum’s IT-pro audience, the practical implication is straightforward: if your organization uses GitHub Enterprise and Copilot, this update can help your platform or DevEx team connect AI adoption cohorts to a delivery signal that engineering managers already understand. It will not replace DORA-style metrics, incident analysis, or quality gates. It can, however, make the Copilot conversation less dependent on vibes.
That uncertainty is exactly why this kind of metric matters. GitHub is not merely adding another analytics field; it is giving enterprises a way to test their own assumptions against their own workflows. If higher AI adoption phases account for a growing share of merged pull requests, that is evidence worth investigating. If the share stays flat while usage costs rise, that is evidence too.
The key word is investigating. A rise in merged pull requests does not automatically mean Copilot caused the increase. Teams may have changed release practices, split work into smaller pull requests, shifted staffing, or moved repositories. A downturn may reflect holidays, code freezes, major refactors, or security review delays rather than AI adoption failure.
Good measurement does not remove judgment. It gives judgment something firmer to stand on.
The new total-merge field helps because it supports proportion-based analysis. Administrators can calculate what share of merged pull requests comes from each adoption phase, then compare that with seat allocation, active use, team structure, and enablement efforts.
That can sharpen budget conversations. If a large group remains in a low-adoption phase and contributes little merged work, the answer may be training, workflow integration, or license reassignment. If a high-adoption group contributes a large share of merges but also shows slower review times or higher rework, the next question should be quality and governance, not celebration.
This is where enterprise reporting needs to mature. The useful question is not “Did Copilot make developers more productive?” in the abstract. The useful question is “Which teams changed their delivery patterns after adopting AI assistance, and what else changed at the same time?”
For those organizations, AI coding telemetry is becoming part of the same governance universe as identity, compliance, auditability, and software supply-chain risk. The people approving Copilot are often the same people being asked to explain where AI is used, who has access, how data flows, and whether the organization is getting enough value to justify the operational risk.
That does not mean every sysadmin needs to parse Copilot metrics JSON tomorrow morning. It does mean Windows and Microsoft-platform administrators should expect AI developer tooling to show up in governance reviews with more concrete telemetry attached.
GitHub’s move also reflects a broader Microsoft pattern: bring AI into the workflow, then wrap it in admin controls, reporting surfaces, and enterprise APIs. The adoption story is not just about developers accepting suggestions in an editor. It is about whether Microsoft and GitHub can make AI assistance legible to the people who manage large organizations.
Merged pull requests are especially vulnerable because they are easy to increase in ways that do not improve software delivery. Teams can split changes more aggressively, merge smaller increments, reduce review standards, or push work through less thoughtfully. None of those behaviors are guaranteed by this metric, but all are possible if leadership treats merge volume as a scoreboard.
That is why GitHub’s field should be read alongside other measures. Time to merge, review activity, incident rates, change failure rate, deployment frequency, escaped defects, and developer sentiment all matter. A phase that merges more pull requests but creates more operational pain is not necessarily a success story.
There is also a privacy and labor-management concern. GitHub’s documentation positions these metrics for enterprise administrators and organization owners, and the phase breakdown is aggregated in organization and enterprise reports. Still, any telemetry system that classifies developer behavior can become sensitive if used carelessly. Leaders should be explicit that adoption cohorts are for program measurement, not individual ranking.
Smaller organizations may still benefit, but the value will depend on whether someone turns the raw metric into a meaningful view. A JSON field by itself does not change management behavior. A dashboard that shows adoption phases, merge share, review latency, and team-level context might.
The 28-day window is particularly important because AI adoption is noisy at daily resolution. A single day can be distorted by release trains, outages, vacations, or review freezes. A rolling monthly view is more likely to show whether AI-assisted workflows are becoming normal rather than merely spiking during demos or training weeks.
Still, enterprises should resist the urge to overfit. A few reporting periods are not enough to declare victory or failure. The useful pattern is sustained movement across phases paired with stable or improving delivery outcomes.
By adding totals to adoption-phase reporting, GitHub is acknowledging that averages are not enough for enterprise buyers. Procurement and engineering leadership need aggregate impact, not just engagement stories. They need to know whether AI-assisted developers are contributing a meaningful share of the organization’s throughput.
That does not make the metric cynical. It makes it strategic. Enterprise software is won or lost on control planes, audit trails, reporting APIs, and the ability to turn a tool into a managed estate. GitHub is building that estate around Copilot.
The open question is whether customers will use the data critically or merely import it into slide decks. The difference matters. Telemetry can reveal uncomfortable truths, including that adoption is shallow, benefits are uneven, or the best outcomes are concentrated in teams that already had strong engineering discipline.
GitHub Turns Copilot Adoption Into an Operations Metric
The new field, total_pull_requests_merged, appears inside the existing totals_by_ai_adoption_phase breakdown in Copilot usage metrics reports. Previously, that breakdown reported per-user averages for each adoption cohort, including avg_pull_requests_merged; now, each phase can also report the total number of pull requests merged on a given day by users in that phase.The distinction is not cosmetic. Averages are useful when you want to compare a typical user in one cohort with a typical user in another. Totals are useful when you want to know where the work is actually moving through the system.
That is the difference between saying “advanced Copilot users merge more pull requests per person” and saying “advanced Copilot users account for 38 percent of merged pull requests this month.” The former is a behavioral insight. The latter is an operational fact that can show up in planning meetings, platform engineering reviews, and budget renewals.
GitHub says the metric is available in both 1-day and 28-day organization and enterprise reports. It uses the same attribution method as the existing average pull request merge metric, which matters because a new denominator or attribution model would have made historical comparisons harder to trust.
The Average Was Always Too Easy to Misread
Per-user averages are seductive because they compress complex engineering activity into a tidy number. They are also dangerous because they can make a small, unusually active cohort look more important than it is.Imagine an enterprise with 1,000 licensed Copilot users. If 30 highly engaged users are merging many pull requests, their per-user average might look impressive. But if those 30 users represent only a small slice of total engineering activity, the business impact may be modest. Conversely, a large middle cohort with a lower per-user average may be carrying most of the actual delivery load.
That is the problem GitHub’s new field helps address. By exposing total merged pull requests by adoption phase, GitHub makes it possible to calculate each phase’s share of total merged work, rather than simply comparing the behavior of an average user in each phase.
This matters because AI adoption programs often suffer from “champion bias.” The most enthusiastic developers generate the cleanest demos, the strongest anecdotes, and the easiest success stories. But enterprise software delivery is not transformed by a few power users alone; it changes when ordinary teams alter their daily workflow at scale.
Adoption Phases Are Becoming GitHub’s Management Layer
GitHub’s AI adoption phases were added to the Copilot usage metrics API before this merge-total update. They classify engaged users based on Copilot product usage over a rolling 28-day window, giving administrators a way to group developers by how deeply they appear to be using AI-assisted workflows.That classification is important because it turns Copilot from a licensed product into a managed program. Instead of asking only who has a seat or who used Copilot yesterday, an organization can ask which developers are moving through adoption stages and whether those stages correlate with delivery behavior.
This is where the new merge total fits. A phase model without delivery metrics is mostly an enablement dashboard. A phase model with pull request creation, review, merge, and time-to-merge data starts to resemble an engineering operating system.
The risk, of course, is that GitHub’s taxonomy becomes a proxy for developer value. That would be a mistake. Adoption phase is a telemetry-derived classification, not a performance review. It can show patterns in tool engagement, but it cannot explain architecture complexity, incident load, code ownership, or whether a developer is doing the invisible work that keeps a system stable.
The Metric Is Useful Because It Is Blunt
The best thing abouttotal_pull_requests_merged is that it is not trying to be too clever. It does not claim to measure productivity, code quality, developer happiness, or business value. It counts merged pull requests attributed to users in a given adoption phase.That bluntness is useful. Enterprises already have too many squishy AI dashboards filled with proxy metrics that look precise but collapse under scrutiny. Lines accepted, suggestions shown, chats opened, and generated tokens can all say something about usage, but they say less about whether work is reaching the mainline.
Merged pull requests are not perfect either. A pull request can be tiny or enormous, valuable or reckless, routine or strategically critical. But merge activity sits closer to the actual software delivery pipeline than many AI usage counters do.
For WindowsForum’s IT-pro audience, the practical implication is straightforward: if your organization uses GitHub Enterprise and Copilot, this update can help your platform or DevEx team connect AI adoption cohorts to a delivery signal that engineering managers already understand. It will not replace DORA-style metrics, incident analysis, or quality gates. It can, however, make the Copilot conversation less dependent on vibes.
GitHub Is Building the Instrument Panel Before the Verdict Is In
The industry still does not have a settled answer on how much AI coding assistants improve real-world software delivery. Some teams report faster iteration and happier developers. Others see uneven adoption, review bottlenecks, increased code churn, or a productivity boost concentrated among specific roles and repositories.That uncertainty is exactly why this kind of metric matters. GitHub is not merely adding another analytics field; it is giving enterprises a way to test their own assumptions against their own workflows. If higher AI adoption phases account for a growing share of merged pull requests, that is evidence worth investigating. If the share stays flat while usage costs rise, that is evidence too.
The key word is investigating. A rise in merged pull requests does not automatically mean Copilot caused the increase. Teams may have changed release practices, split work into smaller pull requests, shifted staffing, or moved repositories. A downturn may reflect holidays, code freezes, major refactors, or security review delays rather than AI adoption failure.
Good measurement does not remove judgment. It gives judgment something firmer to stand on.
Enterprise Admins Get a Cleaner Budget Argument
Copilot is no longer just a developer-experience perk tucked into a tools budget. For many enterprises, AI coding assistants now sit in the same conversation as cloud consumption, security tooling, developer platforms, and productivity suites. Administrators need evidence that licenses and usage costs are producing something measurable.The new total-merge field helps because it supports proportion-based analysis. Administrators can calculate what share of merged pull requests comes from each adoption phase, then compare that with seat allocation, active use, team structure, and enablement efforts.
That can sharpen budget conversations. If a large group remains in a low-adoption phase and contributes little merged work, the answer may be training, workflow integration, or license reassignment. If a high-adoption group contributes a large share of merges but also shows slower review times or higher rework, the next question should be quality and governance, not celebration.
This is where enterprise reporting needs to mature. The useful question is not “Did Copilot make developers more productive?” in the abstract. The useful question is “Which teams changed their delivery patterns after adopting AI assistance, and what else changed at the same time?”
The Windows Angle Is Developer Platform Governance
At first glance, this GitHub changelog item may look distant from Windows administration. It is not. Many Windows-heavy enterprises now run mixed developer environments that include GitHub Enterprise Cloud, Visual Studio Code, GitHub Copilot, Microsoft Entra ID, endpoint management, and corporate data controls.For those organizations, AI coding telemetry is becoming part of the same governance universe as identity, compliance, auditability, and software supply-chain risk. The people approving Copilot are often the same people being asked to explain where AI is used, who has access, how data flows, and whether the organization is getting enough value to justify the operational risk.
That does not mean every sysadmin needs to parse Copilot metrics JSON tomorrow morning. It does mean Windows and Microsoft-platform administrators should expect AI developer tooling to show up in governance reviews with more concrete telemetry attached.
GitHub’s move also reflects a broader Microsoft pattern: bring AI into the workflow, then wrap it in admin controls, reporting surfaces, and enterprise APIs. The adoption story is not just about developers accepting suggestions in an editor. It is about whether Microsoft and GitHub can make AI assistance legible to the people who manage large organizations.
The Merge Count Can Be Abused
Every engineering metric has a shadow. Once a number becomes visible, someone will be tempted to optimize for it.Merged pull requests are especially vulnerable because they are easy to increase in ways that do not improve software delivery. Teams can split changes more aggressively, merge smaller increments, reduce review standards, or push work through less thoughtfully. None of those behaviors are guaranteed by this metric, but all are possible if leadership treats merge volume as a scoreboard.
That is why GitHub’s field should be read alongside other measures. Time to merge, review activity, incident rates, change failure rate, deployment frequency, escaped defects, and developer sentiment all matter. A phase that merges more pull requests but creates more operational pain is not necessarily a success story.
There is also a privacy and labor-management concern. GitHub’s documentation positions these metrics for enterprise administrators and organization owners, and the phase breakdown is aggregated in organization and enterprise reports. Still, any telemetry system that classifies developer behavior can become sensitive if used carelessly. Leaders should be explicit that adoption cohorts are for program measurement, not individual ranking.
The API Shape Rewards Teams That Already Have Data Discipline
This update will be most useful to organizations that already know how to handle engineering analytics. The data arrives through the REST API in reports with specific scopes and granularities, including 1-day and 28-day views. That favors teams with data pipelines, internal dashboards, and enough context to join Copilot metrics with repository, team, and delivery data.Smaller organizations may still benefit, but the value will depend on whether someone turns the raw metric into a meaningful view. A JSON field by itself does not change management behavior. A dashboard that shows adoption phases, merge share, review latency, and team-level context might.
The 28-day window is particularly important because AI adoption is noisy at daily resolution. A single day can be distorted by release trains, outages, vacations, or review freezes. A rolling monthly view is more likely to show whether AI-assisted workflows are becoming normal rather than merely spiking during demos or training weeks.
Still, enterprises should resist the urge to overfit. A few reporting periods are not enough to declare victory or failure. The useful pattern is sustained movement across phases paired with stable or improving delivery outcomes.
GitHub Is Also Selling Trust in Its Own Telemetry
There is a commercial subtext here. GitHub needs enterprise customers to trust Copilot metrics because Copilot’s expansion depends on administrators being able to defend the purchase. The more Copilot spreads across code generation, review, CLI workflows, agents, and IDEs, the more customers will ask what they are getting in return.By adding totals to adoption-phase reporting, GitHub is acknowledging that averages are not enough for enterprise buyers. Procurement and engineering leadership need aggregate impact, not just engagement stories. They need to know whether AI-assisted developers are contributing a meaningful share of the organization’s throughput.
That does not make the metric cynical. It makes it strategic. Enterprise software is won or lost on control planes, audit trails, reporting APIs, and the ability to turn a tool into a managed estate. GitHub is building that estate around Copilot.
The open question is whether customers will use the data critically or merely import it into slide decks. The difference matters. Telemetry can reveal uncomfortable truths, including that adoption is shallow, benefits are uneven, or the best outcomes are concentrated in teams that already had strong engineering discipline.
The Number GitHub Added Is Small, but the Management Shift Is Not
The concrete change is easy to summarize, and that is part of its appeal.- GitHub has added
total_pull_requests_mergedto thetotals_by_ai_adoption_phasebreakdown in Copilot usage metrics reports. - The field reports total merged pull requests by adoption phase for a given day, complementing the existing per-user average merge metric.
- The metric is available in 1-day and 28-day organization and enterprise reports for administrators and owners with access to Copilot usage metrics.
- The new total allows organizations to calculate each adoption phase’s share of merged pull requests, rather than relying only on per-user averages.
- The metric should be interpreted alongside review, quality, reliability, and team-context data, because merge volume alone is not a productivity measure.
total_pull_requests_merged is a small field in an API response, but it points toward a bigger future in which AI adoption is judged less by demos and more by the shape of work moving through the pipeline.