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 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.

There is a hard line around this metric that this edition draws explicitly: measure the gap, never set it as a target, and never substitute token spend or seat activity for it. Both are Goodhart-complete. Once a spend or activity number becomes the thing people are judged on, the community evidence from August shows exactly what follows - engineers burning tokens to satisfy a spend metric, one developer put on a performance improvement plan for not using Copilot despite delivering his tickets cleanly, and engineers buying personal Claude subscriptions to work around a corporate Copilot mandate. Metering adoption by token spend or seat activity is evidence of immaturity, not progress. It is an anti-level.

In September the largest experiment in doing exactly that ended. Meta dropped AI usage from engineer performance reviews around 2026-09-03 (The Decoder), closing roughly ten months of grading engineers on "AI-driven impact" and scrapping a token leaderboard that covered about 85,000 employees. The Information reported 60.2 trillion tokens consumed in 30 days. What replaces it is telling: budget controls and a central dashboard, planned for 2027 - cost governance, not an adoption score. When a company with Meta's measurement capability concludes that token counts cannot be used to grade people, the case for anyone else trying is closed.

Zalando's platform team shows the mature form. Roughly 2,000 monthly active users across 250-plus engineering teams, deliberately no mandated tool, and the numbers they report are outcomes rather than activity: 33% of pull requests auto-approved as low-risk by a classifier trained on their own incident history, and a 20-40% reduction in lead time. They also report that engineers gamed the classifier by splitting pull requests, which is the point - measure outcomes, expect them to be optimised against, and keep looking.

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.

• 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
• Unused seats stopped being free - GitHub announced on 2026-08-28 that every Copilot Business and Enterprise seat assignment requires upfront payment, applying to existing customers from 2026-10-01, with new sign-ups reopening 2026-09-01 under stronger vetting and admins asked to review policy before 2026-09-28; the utilization gap now shows up in cash rather than in a renewal conversation
• The biggest token-leaderboard experiment has already failed in public - Meta scrapped its 85k-employee token leaderboard and pulled AI usage out of performance reviews in September after tokenmaxxing backfired; there is no need to rerun that experiment on your own team
• 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

1. 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.
2. 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. Accepted suggestions count here as evidence that a seat is in use and nothing more - this is a utilization measure, not a quality one. "Active this week" is a strict definition - track it weekly and also compute a rolling monthly average.
3. 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.
4. 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.
5. 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.
6. Write down what you will never target - put it in the same document as the metric definition: not token spend, not seat activity, not suggestion acceptance rate. State the reason, which is that all three are trivially satisfiable without doing better work, and that people will satisfy them. The teams that skipped this step spent the next quarter explaining tokenmaxxing to their finance department, and Meta spent ten months on it before scrapping its 85,000-person token leaderboard. If AI usage appears anywhere in performance reviews today, remove it as part of this step.
7. Check the seat inventory against the new billing terms - with upfront payment per seat assignment landing for existing Copilot customers on 2026-10-01, reconcile assigned seats against active users before that date rather than after. This is the one case where the utilization gap has a hard deadline attached.
8. 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.

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.

Promoting the metric from diagnostic to target. Utilization rate is a useful question and a terrible objective. The moment a team is measured on it, the cheapest path to a good number is activity that looks like usage, and the evidence from August is that engineers find that path within weeks. Keep the metric in the diagnosis column: it tells you where to go and ask what is blocking people, and nothing more.

Mandating a tool instead of measuring an outcome. The mandate produces the worst version of every problem on this page - developers using the mandated tool badly to satisfy the mandate while paying out of pocket for the one they actually want. Zalando's deliberate refusal to mandate a tool, paired with outcome measurement, is the counter-example worth copying. And note how quickly apparent policy reversals turn out to be budgetary rather than philosophical once subscription pricing gives way to API pricing.

Putting usage into performance reviews. This is the target pitfall in its most damaging form, because it attaches pay and promotion to a number that is trivially inflated. Meta ran it at the scale of 85,000 employees and withdrew it in September; the replacement it announced is budget controls and a dashboard, not a better usage score. Usage data belongs in enablement conversations, never in an individual's review.

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.