AI coding tools have had a measurement problem.
It is easy to count seats. It is easy to ask developers whether Copilot feels useful. It is much harder to answer the question an engineering lead actually cares about:
Which repositories are getting real workflow lift, and which ones are just burning licenses?
GitHub's July 17 Copilot metrics update does not solve every attribution problem. But it gives teams a much cleaner starting point: repository-level pull request reporting for Copilot coding agent and Copilot code review.
That matters because AI adoption is moving from "who has access?" to "where is this changing delivery?"
GitHub announced that the Copilot usage metrics REST API now includes repository-level activity.
The release adds two daily report endpoints:
GitHub says the reports return per-repository pull request activity for Copilot coding agent and Copilot code review. That includes pull requests created and merged by Copilot coding agent, plus Copilot code review activity. GitHub's changelog also says the code review activity includes suggestion counts broken down by comment type, although teams should still inspect the exact downloaded report schema before wiring dashboards around that field.
In plain English: admins can now see which repositories are getting Copilot-driven pull request work, instead of only seeing high-level organization or user activity.
Most companies adopted coding assistants before they had a good measurement layer.
That created a familiar problem:
Repository-level reporting helps narrow that gap. It lets a team compare Copilot activity against the actual parts of the codebase where work happens: product apps, internal tools, legacy services, design systems, shared packages, infrastructure repos, and documentation repos.
That is useful because AI coding value is rarely uniform. A coding agent might be great for dependency upgrades in one repo and mostly irrelevant in another. AI code review might catch useful defects in a backend service but add noise in a small marketing site.
Without repository-level data, those differences get flattened.
GitHub's changelog confirms that the new reports cover a single day and are available for both enterprise and organization scopes.
The REST API docs confirm the organization endpoint:
GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
The docs also describe the enterprise version:
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
The API returns download links to report files, not the full report inline. GitHub says the reports are generated daily, cover a complete processed day, and are made available through signed URLs with limited expiration.
The repository report includes only repositories that had activity on the specified day. That is an important detail: a missing repo does not necessarily mean "Copilot is disabled here." It may simply mean there was no reportable Copilot pull request activity for that date.
Access is also gated. GitHub lists owner, billing, or custom-role permissions for viewing Copilot metrics, and the Copilot usage metrics policy must be enabled.
This update is most useful when you pair it with a small set of operational questions.
For engineering leaders:
For platform teams:
For executives:
The practical win is not a vanity dashboard. The win is knowing where to invest next.
Do not treat this as a complete productivity score.
Repository-level pull request metrics can show activity, merge behavior, review volume, and suggestion activity. They do not prove that the code was good, the work was strategically valuable, or the team shipped faster because of Copilot.
The data also needs context:
That is the trap: measuring AI coding tools like a scoreboard instead of a signal.
Use the repository data to ask better questions. Do not use it to shame teams or declare victory.
If you manage a GitHub organization, start small.
First, pull the daily repository report for the last few complete days. Look for repositories with clear Copilot coding agent or code review activity.
Second, group repositories by workflow type:
Third, compare Copilot activity with the repo's normal pull request flow. Look at whether AI-created pull requests are merging, whether Copilot-reviewed pull requests are producing useful review signals, and whether the activity is happening in the places you expected.
Fourth, pick two or three repositories for deeper enablement. Do not roll out the same AI workflow everywhere. A documentation repo, a mature test-heavy service, and a fragile legacy app need different rules.
Fifth, tighten the repo environment before pushing harder:
This is where repository-level metrics become useful. They tell you where the next boring operational improvement will make AI coding safer and more valuable.
AI coding tools are becoming part of the delivery system, not just a developer perk.
That means the buying question changes.
The old question was: "Should we give developers Copilot?"
The better question is: "Which parts of our software delivery system are ready for agentic help, and how will we know whether it is working?"
GitHub's repository-level reports help answer that second question. They give managers a way to see adoption at the codebase level, spot uneven rollout, and separate promising use cases from noise.
For a small business or growing product team, this can be the difference between "we bought AI tools because everyone else did" and "we know which repos can safely benefit from AI-assisted maintenance, review, and incremental feature work."
That is a more serious version of AI adoption. Less theater. More evidence.
If your team already uses GitHub Copilot Business or Enterprise, check whether you have access to Copilot usage metrics and whether the policy is enabled.
Then pull one week of repository reports and make a simple table:
Do not automate decisions from that table yet. Use it to choose where to improve repo readiness.
The highest-upside move is usually not "turn agents on everywhere." It is picking one repo where tasks are well-scoped, tests are trustworthy, and reviewers can quickly tell whether AI work is helping.
That is where AI coding stops being a novelty and starts becoming an engineering operating system.
day parameter, and access requirements.No trend-only sources were used for this article. The business recommendations are Medianeth's interpretation of the confirmed GitHub release and documentation, not a claim that the metrics alone prove productivity gains.
Note: This article was prepared with AI assistance and checked against primary sources before publication.
Tell us what you're building. We'll show you the fastest path to a production-ready launch.
Get My Free Proposal