New Copilot Dashboard Shows Enterprises Which Developers Are Actually Using AI — Not Just Who’s Logged In

GitHub has released a new dashboard that gives enterprise administrators a much clearer picture of how their developers are actually using Copilot, not just whether they’re using it at all. The move addresses a gap that’s dogged IT leaders since AI coding tools went mainstream: Seat counts and login data tell you who has access, but they say nothing about whether that access is translating into real engineering output.

The new Copilot metrics impact dashboard, rolled out July 22, is available to enterprise administrators and organization owners with access to Copilot usage metrics. It builds on the AI adoption phase cohorts that GitHub added to its Copilot usage metrics API back in May, turning what was previously raw API data into a visual dashboard that admins can actually act on.

From Activity Counts to Adoption Depth

The core idea behind the dashboard is straightforward: not all Copilot usage looks the same, and lumping every licensed user into a single “active” bucket hides more than it reveals. GitHub now groups engaged users into three adoption phases, plus a fourth “passive” category for developers who hold a license but aren’t meaningfully engaging with the tool.

Phase 1 covers what GitHub calls “code-first” usage — developers relying on Copilot mainly for inline suggestions and completions. Phase 2, “agent-first,” captures developers who’ve moved into agentic workflows. Phase 3 represents the deepest tier: multi-agent usage or engagement with the standalone Copilot app. Each cohort gets its own card showing average pull requests merged per user per month, median PR merge velocity, the number of users in that phase, and average lines of code per day per user.

That last detail matters for how this data gets used internally. Instead of an engineering leader asking “how many people have Copilot licenses,” they can now ask “how many of our developers have actually moved past basic autocomplete, and what’s it doing for their output.” The dashboard also includes what GitHub calls an adoption multiplier — a direct throughput and speed comparison between the passive cohort and the average of engaged users — along with six-month trend charts and a set of recommended next steps for nudging more developers into deeper adoption tiers.

Why This Matters for Budget Conversations

This kind of granularity lands at a useful moment. Broader industry research backs up the idea that adoption alone isn’t the whole story. Google Cloud’s 2025 DORA report found that AI adoption among software professionals reached 90%, a 14-point jump from the prior year, with developers spending a median of two hours a day working with AI tools. But the same research made clear that adoption by itself doesn’t guarantee results — DORA’s authors introduced a capabilities model specifically because simply adopting AI isn’t enough to realize its potential; organizations also need the culture, processes, and systems to support it.

That’s the exact problem this dashboard is trying to solve for GitHub’s enterprise customers. A CIO defending a Copilot renewal to the CFO doesn’t want to present “80% of our developers logged in this month.” They want to show that developers who moved into agentic or multi-agent workflows are shipping more pull requests, merging faster, and producing measurably more code per day than developers who barely touch the tool. That’s a business case built on outcomes, not activation.

“Login data was always a vanity metric dressed up as an adoption metric. It matters even less as agents increasingly do the code and workflow management. Pull requests merged and code shipped are the only Copilot numbers that matter. Enterprises finally have a way to see whether developers moved past autocomplete into real agentic work,” said Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group.

“The harder number is still coming,” Ashley added. “Once agents start merging code with less human review, the throughput this dashboard tracks becomes a governance question, not just a budget one. GitHub built the measurement layer before it built the oversight layer, and that gap won’t close itself.”

A Governance Layer, Not Just a Vanity Metric

Ashley’s point about oversight lagging measurement is worth sitting with. As organizations push developers toward agentic and multi-agent workflows, understanding who’s actually operating in those modes — and how that usage maps to throughput — becomes a prerequisite for any serious conversation about AI risk, agent permissions, or non-human identity management. A dashboard that segments users by adoption depth gives security and platform teams a starting point. But it’s a starting point, not an answer, for where governance controls need the most attention as agents take on more of the merge decision itself.

GitHub’s cohort classifications reset on a rolling 28-day window, so the picture stays current as usage patterns shift. For enterprises that have struggled to justify or refine their Copilot investment, that’s a meaningful upgrade from static seat reports — and a sign that GitHub is treating usage measurement as a product feature in its own right, not an afterthought bolted onto billing. Whether GitHub — or anyone else — builds the oversight layer Ashley says is missing remains the open question.

from DevOps.com https://ift.tt/SfY2lDI