To measure GitHub Copilot success, track four things in order: how many licensed developers actively use it, how much of their code it produces, whether pull requests move faster, and how developers feel about it. Adoption comes first, because Copilot cannot change delivery speed for developers who rarely open it.
This guide lists the metrics that matter at each stage, where GitHub reports them today, and what GitHub's own data leaves out. The same approach works for measuring AI adoption across any tool: start with active use, then look for changes in how work gets done.
Worklytics measures this across your organization. See Microsoft 365 Copilot Analytics for adoption, AI fluency and impact by app and by team.
| Metric | What it tells you | Where GitHub reports it |
|---|---|---|
| Active users | How many people used Copilot in a day, week or month | Daily, weekly (trailing 7 days) and monthly (trailing 28 days) active users in the usage metrics dashboard and API |
| Adoption rate | Active users as a share of licensed seats | Active users from usage metrics, divided by seats from the Copilot user management API |
| Acceptance rate | How often developers accept code completion suggestions | "Code completion acceptance rate" in the usage metrics dashboard |
| AI share of code | How much code Copilot adds, and how much comes from agents | Lines of code suggested, added and deleted, plus "Agent contribution" (share of changed lines made by agents) |
| PR cycle time | Whether code gets merged faster | Median minutes to merge, including a separate figure for pull requests created by Copilot |
| PR throughput | Whether teams ship more | Pull requests created, reviewed and merged per day |
These are usage and delivery metrics. They tell you whether Copilot is being used and whether work is changing. To turn them into a cost and payback figure, see our guide to GitHub Copilot ROI.
GitHub reports these metrics in its Copilot usage metrics dashboard, its Copilot impact dashboard and the Copilot usage metrics REST API (GitHub Docs: Copilot usage metrics; metric reference). A few things to know before you build a scorecard on them:
The first sign of success is adoption. Are licensed developers actively using Copilot, and how often?
Track these adoption metrics:
High adoption is the foundation for every downstream benefit. If only a few developers use Copilot, its overall impact will be small. To find adoption gaps, segment usage by team, department or role, and look at where support or training is needed.
Once Copilot is in active use, attention shifts to efficiency. Does it help teams ship software faster?
Key metrics:
Compare these metrics before and after rollout, and between teams with higher and lower Copilot use. Change takes time, so look at trends over several sprints rather than the first few weeks.
Speed alone is not enough. Teams also want to know how much code Copilot contributes and whether quality holds.
How much code Copilot writes. GitHub reports lines of code Copilot suggested, lines actually added in the editor, and the share of changed lines made by agents. There is no single "percent of the codebase written by AI" figure, so use lines added by Copilot as a share of lines changed as a practical proxy. In an Accenture study, developers accepted about 30% of Copilot's suggestions and kept 88% of the characters Copilot generated in their editor (GitHub and Accenture study).
Code quality. Track the same quality signals you use today:
In the same Accenture study, the pull request merge rate rose 15% and successful builds rose 84%. Treat vendor-run studies like this as a guide to what to measure, not a forecast for your own teams.
Good practice includes running automated tests and static analysis on AI-generated code, and keeping human review for every pull request.
One of Copilot's most powerful impacts is on developer experience. Beyond productivity metrics, Copilot enhances day-to-day enjoyment, reduces frustration, and boosts morale.
According to a GitHub survey of more than 2,000 developers (GitHub research):
In the Accenture enterprise study (GitHub and Accenture), the feedback was even stronger:
This qualitative data matters. Happier developers are more productive, more creative, and less likely to burn out. Copilot appears to relieve the "drudgery" of boilerplate code, allowing engineers to focus on interesting, high-value problems.
As one senior engineer put it:
"With Copilot, I have to think less about the boring stuff, and when I do think, it's about the fun stuff. It sets off a little spark that makes coding more fun and more efficient."
To track these softer success metrics, organizations are implementing developer feedback loops. Regular surveys, such as after the first month and then quarterly, are used to gauge:
Keep the questions the same each time so you can compare results over time, and read them next to usage data. Developers who report higher satisfaction often keep using the tool.
Conversely, lukewarm feedback might signal problems such as poor integration into workflows, lack of training, or low fit for certain project types.
By treating developers as experts of their own workflows, organizations gain nuanced visibility into Copilot's real-world performance. Metrics are essential, but human sentiment is equally critical for understanding Copilot's long-term value.
Measuring Copilot's success is not a one-and-done effort. It requires continuous monitoring and a blend of metrics. Engineering leaders often think in terms of both leading indicators (immediate signals close to the development process) and lagging indicators (broader business outcomes that manifest later). Copilot primarily shows up in leading indicators first – things like commit frequency, code review turnaround time, and developer sentiment will shift before higher-level outcomes like product release frequency or customer satisfaction are directly impacted.
One practical tip is to establish a baseline before rolling out Copilot: collect data on how fast and happily the team is working without the AI assistant (e.g. average PR completion time, deploy frequency, developer NPS score, etc.). Then compare those benchmarks to post-adoption numbers. Any significant deltas – especially when combined with subjective feedback attributing some credit to Copilot – can be taken as signs of success. It's also wise to continue surveying developers periodically to catch any drift in experience.
Worklytics puts Copilot adoption next to the rest of your work data, aggregated and pseudonymized, without reading code, prompts or message content.
Copilot adoption by team. Worklytics reads GitHub's Copilot seat and usage data daily and reports, for each period, whether people used Copilot, their active days and days since last use, and which editor they were last active in. Because it counts observed activity rather than assigned seats, you see the real active-user number, which can be lower than a license count. With your HR data connected, adoption is reported by department, manager and role, so you can see which groups have adopted Copilot and which are lagging.
Copilot next to engineering activity. Copilot data sits alongside general GitHub activity from the GitHub connector, so you can compare work patterns for heavier and lighter Copilot users over time.
All your AI tools in one view. Worklytics also tracks coding assistants such as Cursor and Claude Code, and workplace AI such as Microsoft Copilot, Gemini, ChatGPT and Claude, so you can measure AI adoption across the company, not just in engineering. See the Worklytics AI adoption dashboard.
What Worklytics does not show. GitHub's seat API provides last-activity and seat data only, so Worklytics does not report per-suggestion detail such as acceptance rate or lines of code. For those, use GitHub's own dashboards and read them next to Worklytics' team-level adoption view.
Turning data into action. The loop is simple: measure usage, find teams with low adoption, give them targeted training or support, and measure again. For a deeper look at delivery impact, see how to measure GitHub Copilot's impact on your team.
GitHub Copilot success should be measured across four dimensions: adoption, efficiency, code contribution and quality, and developer satisfaction. Start with active users and adoption rate, because nothing else moves without them. Then watch PR cycle time, throughput and quality trends, and check how developers feel. Set a baseline, compare teams with higher and lower usage, and revisit the numbers every quarter. That is how a Copilot rollout moves from adoption to efficiency.
To see these metrics for your own teams, visit Microsoft 365 Copilot Analytics or book a demo.
Start with monthly and weekly active users, then divide monthly active users by licensed seats to get an adoption rate. Add how many days a week people use Copilot and how many use chat or agent mode, not just code completion. Break the numbers down by team and role to find where adoption is lagging.
GitHub's Copilot usage metrics dashboard and API report daily, weekly and monthly active users, code completion acceptance rate, lines of code suggested, added and deleted, usage by feature, IDE, language and model, and pull request activity such as median time to merge. Data is available within two full UTC days and is reported at enterprise, organization, repository and user level.
GitHub does not publish a target. In a GitHub and Accenture study, developers accepted about 30% of Copilot's suggestions. Acceptance rate only covers code completions, so read it next to lines added, pull request cycle time and active usage rather than using it as a success metric on its own.
GitHub reports lines of code Copilot suggested and lines actually added in the editor, plus the share of changed lines made by agents. There is no single figure for the share of your codebase written by AI, so most teams use lines added by Copilot as a share of lines changed as a proxy.
Measure active use first: how many people use each AI tool in a week or month, how often, and in which teams. Compare active users with licenses, track the trend over time, and then look at whether work patterns change for heavier users. A platform like Worklytics combines usage from tools such as GitHub Copilot, Microsoft Copilot, ChatGPT and Claude in one view, broken down by team.
