Updated October 22, 2026. Based on the official announcement linked below.
A team can measure AI adoption and still be unsure what the number means. A comparison with peers offers context, but it can also tempt a reader to turn a dashboard ranking into a claim about quality or business value that the data does not establish.
What GitHub added on October 22
GitHub’s official changelog introduces an industry-comparison section in the Copilot impact dashboard. It is opt-in and disabled by default. The comparisons cover agentic adoption and leverage, using aggregated participating peers and a 28-day reporting period.
GitHub describes company-size and industry groups, broader fallback groups where participation is insufficient, and rankings that appear only with enough data. It also says the comparisons are dashboard-only, not part of the usage API or exports. Check the notice for ownership, policy, and regional conditions before assuming your organization can participate.
Begin with the question behind the ranking
Decide what you want to learn. “Are we giving the intended team access and support?” is different from “Is our software delivery getting better?” A usage comparison may help the first question without fully answering the second.
Write the question above the screenshot or report. It helps colleagues understand why the measure was selected and what conclusion they should avoid drawing from it.
Read the actual peer group
Check which company size and industry are being used, including any fallback to a broader group. Keep the reporting period with the result. A label matters because the comparison may not match the group a presenter originally selected.
Do not hide missing rankings. When participation is insufficient, “not enough data” is an informative result. It is not a reason to substitute a different comparison without telling the audience.
Keep adoption separate from outcomes
A higher rate of using agentic tools does not by itself establish that the team ships safer software or serves customers better. Likewise, a pull-request measure needs context about the work, review practices, and differences between groups.
Use a small set of complementary observations from your own process: review effort, rework, important defects, and time to an accepted change where you measure those appropriately. Avoid presenting any single number as a universal productivity score.
Make a proportionate improvement plan
If the dashboard reveals an adoption gap, investigate its cause with the people doing the work. Access, training, task suitability, and team policy are different explanations and call for different responses.
Choose one concrete improvement to evaluate. For example, a hypothetical team could offer a documentation workflow workshop and then review whether it helps produce accepted changes. That is more informative than setting a target to use agents more often regardless of the task.
Keep participation a deliberate decision
Read the policy and data-handling explanation before an authorized owner opts in. Document who made the decision and why it fits the organization’s needs.
When sharing a dashboard internally, preserve the scope and limitations in the accompanying note. The person reading a screenshot later should not have to guess what group, period, or metric it represented.
Frequently asked questions
Does a top ranking prove the team is more productive?
Not by itself. Interpret the measure within its definition and supplement it with evidence about the outcomes you care about.
Why might there be no ranking?
GitHub describes participation and score-calculation limits. Read the displayed explanation rather than treating missing data as poor performance.
What makes a useful monthly note?
State the question, metric, peer group, period, limitations, and one action to investigate. Keep the interpretation modest enough that the evidence can support it.
Related reading: Define an AI pilot’s acceptance criteria · Separate AI visits from visibility.