What your current adoption number is hiding
If you have ever reported "we're at 90 percent Copilot adoption" and then watched a senior engineer admit they turned it off in week two, you already know the official number is soft. Most teams measure AI adoption with the two data sources that happen to be free: the licence count and the vendor's admin dashboard. Both mislead, in different ways.
Quick Answer
To measure AI adoption across an engineering team, stop counting licences and start measuring four things: the share of coding sessions that involve an agent, the agent share of the diff that actually ships, token spend per shipped PR, and how evenly all of that is spread across the team. Seat counts and vendor admin dashboards overstate adoption because a seat assigned is not a seat used, and an accepted suggestion is not shipped work. Below: the steps, where to get the data, the trade-offs of each source, and what to do with the number once you have it.
The licence count fails first. Procurement assigns 20 seats, the dashboard says 20, and the true number of people using an agent daily might be six. A seat assigned is not a seat used, and a seat used once in onboarding week is not adoption. You will often see this gap widen over time, because nobody ever unassigns a seat.
The vendor dashboard fails more subtly. It reports activity from that vendor's perspective: suggestions shown, suggestions accepted, an acceptance rate. Acceptance rate is not impact. An engineer can accept 60 percent of suggestions on code that never merges, while another accepts almost nothing but ships a week of work through Claude Code in the terminal, which the IDE-plugin dashboard never saw. In 2026, with terminal agents like Claude Code and Codex CLI doing whole features end to end, the work most worth measuring is the work vendor dashboards are least able to see.
The adoption figure most teams report is a claim: seats bought, boxes ticked, a rate from one vendor's telemetry. What you actually want is evidence of use, tied to what shipped. The rest of this guide is about measuring that instead.
Step 1: Define active use, then count it
Before you touch a dashboard, decide what counts as "using AI." A loose definition produces a flattering number and no information. A workable definition in 2026: an engineer had at least three coding sessions involving an agent (Claude Code, Cursor, Codex, Copilot) in the past week. Weekly beats monthly, because monthly counts the person who tried Cursor once on the 3rd.
Count people who meet that bar, divide by team size, and you have a real adoption rate. In practice this number lands well below the licence figure, often at half. That drop is the first accurate thing you have known about your team's AI usage.
Step 2: Measure the share of sessions with agent involvement
Headcount adoption tells you who uses agents at all. Session share tells you how deep it goes: of all the coding sessions your team ran this week, what fraction involved an agent? A team where 80 percent of engineers touch an agent in 10 percent of their sessions is a very different team from one where 50 percent of engineers run agents in most of their working blocks.
This is the metric that separates "we have AI tools" from "we work with AI." It also moves in useful ways: when you fix onboarding for one agent, or ship a better internal prompt library, session share responds within a week or two, long before delivery metrics do.
Step 3: Measure the agent share of shipped diff
Sessions measure input. Shipped diff measures whether the input became product. For each merged PR, ask what fraction of the final diff originated in an agent session rather than human typing. Aggregated across the team, this is the honest core of "how much of our code does AI write," and we cover the mechanics in detail in how to track your AI-generated code percentage.
Two cautions. First, do not treat a high agent share as automatically good. Agents are strong at scaffolding, CRUD, and first-pass features, weak at the decisions and integration edges. A refactor of the payments webhook at 20 percent agent share can be worth more than a settings screen at 95. Second, never read diff size as effort. An agent writes a 3,000-line diff in a minute; a one-line fix can follow an hour of reading. Adoption metrics that lean on lines of code inherit everything that was already wrong with lines of code.
Step 4: Track token spend per shipped PR
Adoption without a cost denominator is a feel-good chart. Token spend per shipped PR connects the two: what did the AI usage cost, and what merged because of it? A team spending $9 in tokens per shipped PR and a team spending $60 are having different experiences, and the difference is usually workflow, not talent. High spend per shipped PR tends to mean agent thrash: context resets, abandoned sessions, re-prompting the same feature four times.
This is also the metric your finance conversation eventually needs. "We spent $2,100 on tokens last month" invites a budget fight. "Token cost per shipped PR fell from $14 to $8 as the team learned the tools" invites renewal. The full version of that argument lives in measuring the ROI of AI coding assistants.
Step 5: Look at the spread, not the average
Most teams that measure adoption at all stop at a team average, and the average is where the most important fact hides. Almost always, early AI adoption is concentrated: two engineers generate 70 percent of the agent sessions while a third of the team has not run one in a month. A team average of "40 percent of sessions involve agents" can describe a team that has broadly adopted, or a team with two power users and ten holdouts. Those need opposite interventions.
So plot the distribution per person: sessions with agent involvement, agent share of their shipped work, token spend. You are looking at the shape, not the names. A tight cluster means the practice has spread. A barbell means your rollout has stalled and your average is a rounding error away from fiction. Comparing that spread against other teams is its own topic, covered in benchmarking AI leverage across a team.
This step is where the surveillance line matters. Per-person adoption data exists to find who needs help, and that is the only mode in which collecting it stays legitimate. The moment it feeds a ranking, engineers will game it, and every number in this guide goes soft at once. Tell the team what is measured and why, and keep the individual view out of performance reviews.
Step 6: Choose your data source and accept its trade-offs
None of the metrics above fall out of a spreadsheet. There are two ways to get the data, and they see different worlds.
Vendor admin APIs and git analysis are the established route. Platforms like DX and Waydev measure AI-generated code at the commit and PR level and pull adoption telemetry from vendor admin APIs (the Copilot admin API, Cursor org telemetry). This route is real: it needs nothing installed on laptops, it aggregates cleanly for executive reporting, and DX in particular pairs it with serious survey research. Its limits are structural. It sees each vendor's tools from that vendor's admin plane, so a terminal Claude Code session on a personal API key is invisible. And it starts at the commit, so the four agent sessions that were abandoned before anything was committed, along with their token cost, never appear. If your question is "which half of my team hasn't started," this data answers it late and partially. See how the approaches differ in practice in DevClocked vs DX and DevClocked vs Waydev.
Session-level capture is the other route: a lightweight tracker on each engineer's machine records agent sessions as they happen, whichever vendor, IDE or terminal, whether or not the work ever becomes a commit. This is the only way to get session share, cross-vendor attribution, and true token spend per shipped PR. The trade-off is equally real: it requires installing something per engineer and it produces individual-level data, which is exactly why Step 5's ground rules are not optional. Both routes are honest tools. Pick based on which blind spot you can afford.
Where DevClocked fits
DevClocked is the session-level route. It captures work from IDEs, terminals, and AI agents (Claude Code, Cursor, Codex CLI) and ties agent runs, human hours, and token costs to shipped commits and PRs, so every metric in this guide (session share, agent share of shipped diff, spend per shipped PR, spread across the team) comes from audited session data rather than one vendor's roll-up. No screenshots, no keystroke logging, no file contents: session metadata only. The team workspace puts the distribution view from Step 5 on one org dashboard.
It is not the answer for everyone. Full disclosure: I build DevClocked. A 200-developer organisation that needs survey programmes, resource allocation, and board-level reporting is better served by DX or Jellyfish today, and they are good at that job. DevClocked wins for teams of roughly 2 to 50 that live in AI agents and want ground truth about adoption, including the work that never reached a commit.
Related Guides
- How to measure AI coding productivity: the parent guide, covering impact rather than adoption.
- Track your AI-generated code percentage: the shipped-diff metric from Step 3 in full.
- Measure the ROI of AI coding assistants: turning spend per shipped PR into a budget case.
- Benchmark AI leverage across a team: comparing the spread once you can see it.
- Track Claude Code usage: measuring the terminal agent your dashboards miss.
