Licenses vs usage rate

Licenses vs. usage rate is the first uncomfortable AI metrics discovery. Teams that invest in AI coding tools - GitHub Copilot, Cursor, Claude Code - routinely find that the number

·DORA metrics are tracked consistently with a dashboard
·AI tool license count vs. active usage rate is measured
·PR throughput per developer is tracked

·AI acceptance rate (% of AI suggestions accepted) is measured per tool
·Metrics are reviewed in team retrospectives at least monthly

Evidence

·DORA metrics dashboard with current data
·License utilization report (licenses purchased vs. active users)
·PR throughput chart showing per-developer breakdown

What It Is

Licenses vs. usage rate is the first uncomfortable AI metrics discovery. Teams that invest in AI coding tools - GitHub Copilot, Cursor, Claude Code - routinely find that the number of active users is dramatically lower than the number of licenses purchased. The gap is rarely small. Industry data consistently shows that 30-50% of purchased AI coding licenses are inactive in any given month, meaning the organization is paying for tools that a significant portion of the team either doesn't use at all or uses so infrequently that the investment produces no productivity return.

"Active usage" needs a precise definition. A developer who opens their IDE with Copilot installed but never accepts a suggestion is technically using the tool. A developer who uses Claude Code once a month to autocomplete a function is technically a user. Neither is the usage pattern that produces productivity gains. The meaningful threshold is something like: using the AI tool as a primary part of the development workflow on 3+ days per week. Below that threshold, the tool isn't embedded enough in daily work to change habits or throughput.

The licenses vs. usage rate gap reveals two separate problems. The first is adoption: developers who have licenses but aren't using them. This is a training, culture, or workflow-fit problem. The second is retention: developers who tried the tools enthusiastically at first but gradually stopped using them as they hit friction points - poor context window management, inconsistent output quality, slow CI feedback loops. Both problems require different interventions, but neither is visible without measuring usage rate separately from license count.

At L2, measuring this gap is the starting point for making the AI investment productive. The gap size defines the adoption opportunity: if 40% of your team isn't actively using AI tools, and you can bring that 40% to active usage, you've dramatically increased the expected return on your existing license investment without spending another dollar.

Why It Matters

Budget accountability - paying for unused licenses is pure waste; measuring usage rate turns license cost from a fixed budget line into a managed investment with an expected return
Identifies adoption barriers - low usage in a specific team or role almost always traces to a specific problem: poor IDE integration, lack of training, workflow friction, or skepticism; the metric makes the barrier visible so it can be removed
Reframes the AI investment conversation - "we have 100 Copilot licenses" sounds like a strong AI program; "60% of those licenses were inactive last month" reframes the conversation accurately; honest usage data drives better decisions
Correlates with productivity outcomes - usage rate is the strongest predictor of AI-driven productivity improvement available at L2; high-usage developers consistently show better throughput, cycle time, and PR quality metrics
Creates urgency for adoption programs - presenting usage rate data to leadership creates organizational pressure to invest in developer enablement; the gap between licensed and active users is a problem that demands a solution

Getting Started

Pull usage data from your AI tool admin consoles - GitHub Copilot Business has a usage API and an admin dashboard with weekly active user data. Cursor Teams, JetBrains AI Pro, and most enterprise AI tools have similar admin panels. Log in to each admin console and export usage data for the past 90 days.
Define "active user" with a concrete threshold - Choose a threshold and document it. A reasonable definition: a developer who had at least one AI suggestion accepted on 3+ distinct days in the week. "Active this week" is a strict definition - track it weekly and also compute a rolling monthly average.
Compute the license utilization rate - Divide active users by licensed users. This is your utilization rate. A utilization rate below 70% at L2 is a flag that needs attention. Below 50% is a significant problem.
Segment by team and role - Don't report a single average. Break down usage rate by engineering team, by role (frontend/backend/platform), and by tenure. The segmentation will reveal which groups are underadopting and why. Different groups will have different barriers.
Run discovery conversations with low-usage developers - Don't assume you know why developers aren't using the tools. Have 30-minute conversations with 5-10 developers who have licenses but low usage. Ask: what's blocking you? What did you try? What didn't work? The qualitative findings from these conversations are more actionable than the quantitative gap alone.
Set a utilization target and track progress monthly - Set a 90-day target: move utilization rate from current baseline to X%. Assign an owner. Review monthly. The target creates accountability for the adoption gap that the metric revealed.

Tip

GitHub Copilot's admin dashboard shows "active users" but uses a low threshold (at least one suggestion shown, not necessarily accepted). For a more meaningful active usage definition, use the API to pull "suggestions accepted" data and set your own threshold. The built-in "active user" count often overstates real engagement by 20-30%.

6 steps to get from here to the next level

Common Pitfalls

Treating low usage as a developer attitude problem. When usage rate is low, managers sometimes conclude that developers aren't trying hard enough or are resistant to change. This is almost never the root cause. Low usage almost always reflects specific, solvable friction: poor IDE performance with the AI plugin, lack of training on effective prompting, bad output quality for the team's specific tech stack, or a workflow where the AI tools don't fit naturally. Diagnose before blaming.

Focusing only on usage rate without measuring impact. A team with 95% utilization rate is not necessarily getting value if developers are accepting suggestions mechanically without improving throughput. Usage rate is a leading indicator, not an outcome metric. Pair utilization tracking with throughput metrics (PR volume, cycle time) to confirm that high usage is translating into productivity gains.

Not distinguishing between tool types. Usage patterns for autocomplete (Copilot, Tabnine) are different from usage patterns for chat-based agents (Claude Code, Cursor chat). Autocomplete usage is passive and hard to measure precisely. Agent usage is explicit and easier to track via session data. Track them separately and set different utilization thresholds.

Canceling licenses instead of fixing adoption. When leadership sees a 40% utilization rate, the instinct is often to cut licenses to the utilization level. This is the wrong response. It reduces cost but doesn't fix the underlying adoption problem. The better response is to invest in the enablement programs that raise utilization - better training, dedicated office hours, pair programming sessions with high-usage developers. Fix adoption, don't just cut cost.

Monthly reporting instead of weekly. AI tool usage fluctuates significantly week to week. A developer who is active 3 weeks out of 4 will look like a high-user on monthly averages but may actually have a significant friction point that blocks them one week per month. Weekly tracking surfaces these patterns and makes them addressable.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob discovers that despite buying 80 Copilot licenses, only 47 developers showed active usage last month. He initially assumed the team had strong AI adoption, but the utilization data reveals that 33 developers are paying for a tool they're not using.

What Bob should do: Bob should treat the utilization gap as a prioritized engineering problem, not an administrative inconvenience. He should assign an engineering manager to run a 30-day adoption sprint with the 33 low-usage developers: structured training sessions (2 hours), pairing sessions with high-usage developers (1 session each), and a shared Slack channel for prompting tips and use case sharing. After 30 days, re-measure. The goal: move at least 20 of the 33 to active usage. If after a structured intervention some developers still show no usage, then a conversation about whether the tool fits their role is appropriate. But the default response to low usage should always be enablement before license reduction.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is building the quarterly developer productivity report and includes the AI tool utilization section. She notices that two teams have very different utilization rates: Team Alpha at 85% and Team Beta at 35%. Both teams have the same tools available and went through the same onboarding.

What Sarah should do: Sarah should treat Team Alpha as a model to study and Team Beta as an intervention target. She should schedule conversations with the highest-usage developers on Team Alpha: what does AI tool usage look like in their daily workflow? What practices do they recommend? What makes it fit their work naturally? Then she should interview Team Beta's low-usage developers: what's blocking them? Is it the tech stack, the IDE, the type of work, or something else? Sarah should write up the findings as a case study and use it to design Team Beta's intervention - targeted, specific to their barriers, modeled on Team Alpha's successful practices. This is the pattern that turns a metric into an action.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has 100% AI tool utilization in his own workflow and thinks about utilization rate as a lagging indicator - it tells you about adoption, not about sophistication. He's more interested in driving the team toward L3 metrics, but he recognizes that most of the team is still stuck in the utilization gap.

What Victor should do: Victor should run internal office hours specifically for the low-usage cohort. Not general AI training - specific, practical sessions tailored to the types of work low-usage developers do. Victor should identify the three or four use cases where AI tools provide the clearest, fastest value for their tech stack (e.g., writing tests for existing functions, generating database migration scripts, documenting API endpoints) and build short demos of each. These "quick wins" sessions are the most effective adoption accelerator because they give developers an immediate, concrete reason to keep using the tool. Victor's goal is to raise utilization rate to 80%+ team-wide, not because the metric matters for its own sake, but because you can't move the team to L3 metrics until most of the team is actively using the tools.

What Victor should do - role-specific action plan