How to measure AI adoption in software engineering teams

Someone in leadership asks how many engineers use the AI tools the company pays for, and the answer that comes back is the number of seats. Seats tell you what you bought. They say nothing about whether the frontend team opens Cursor every day while half of the backend team tried it once in March and went back to their old workflow.

Why is a license count not a measure of AI adoption?

A license count is a measure of spend, not of adoption, because a seat is assigned whether or not anybody uses it. Logins are only a little better. DX, which publishes one of the better known AI measurement frameworks, warns that total logins mislead because one-time use and regular use look the same in that number.

Adoption is a behavior: people reaching for an AI tool as part of how they work, week after week, on real tasks. You measure a behavior with activity over time, and you need more than one number to see its shape.

What does the research say about AI adoption right now?

Industry surveys put adoption close to universal, which is exactly why a team needs its own numbers. The 2025 DORA report, built on responses from nearly 5,000 technology professionals, found that 90% of respondents use AI at work, with a median of two hours a day spent working with it. The 2025 Stack Overflow Developer Survey, with about 49,000 responses, found that 84% of developers use or plan to use AI tools and that 51% of professional developers use them daily.

The same surveys show the catch. In Stack Overflow’s data, 46% of developers distrust the accuracy of AI output and only 33% trust it. In DORA’s, 30% report little or no trust. A team can be “adopted” on paper and still use AI only for boilerplate because nobody trusts it with anything else. Industry averages hide that. Your own breadth, frequency and depth numbers do not.

Which AI adoption metrics should an engineering team track?

Track four dimensions, each with one primary metric, and add a fifth for the capabilities you rolled out on purpose.

Dimension	Metric	The question it answers	Watch out for
Breadth	Share of members active with AI in the period	How many people use it at all?	“Active” must mean real use, not a login
Frequency	Active days or sessions per person	Is it a habit or an experiment?	A few heavy users can inflate an average; look at the median
Depth	Share of commits and pull requests with AI evidence	How much of what ships was touched by AI?	Detection is a heuristic, not proof
Concentration	Share of usage from the top 10% of users	Is adoption spread out or held by a few people?	High concentration is normal early in a rollout
Capability use	Invocations of the shared skills and MCP servers	Is the setup the team agreed on actually used?	Only works if those capabilities are tracked per name

Two practical notes. Pick one definition of “active” and keep it: “used an AI tool on at least one day in the week” is simple and hard to argue with. And keep the period fixed (seven days, thirty days) so that every number compares with the previous period of the same length.

How do you set up AI adoption measurement, step by step?

1. Write down what counts as active. One sentence in the team’s docs. Everyone reads the dashboard the same way after that.
2. List every AI tool in use, including the unofficial ones. Ask the team. A tool with no telemetry shows up as “not adopted” when it is actually the favorite.
3. Connect the sources you already have. GitHub’s Copilot usage metrics dashboard and API report daily and weekly active users, agent adoption and lines added. Claude Code exports OpenTelemetry metrics such as claude_code.session.count, claude_code.commit.count and claude_code.pull_request.count. Git gives you commits and pull requests.
4. Take a 30-day baseline before you change anything. A rollout, a training session or a new shared setup is only measurable against a before.
5. Segment by tool and repository. A single adoption number for a 200-person organization averages away the team that never started.
6. Add one short survey question each quarter. “How much time did AI tools save you last week?” is the only way to see the value side that telemetry cannot. DX’s framework pairs telemetry with exactly this kind of self-reported time saving.
7. Review monthly, with the previous period next to the current one. The direction matters more than the level.

For Claude Code, turning telemetry on is a handful of environment variables, which an admin can also set for everyone through managed settings:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4317

That gets one tool into one collector. A team that uses Claude Code, Cursor and Copilot at once still has to join three sources, which is where most homemade adoption dashboards stall.

How does HubBound measure AI adoption?

HubBound Metrics measures adoption from two sources: the agent telemetry that the HubBound Runtime and CLI report from each developer’s machine, and the organization’s GitHub. The Sessions section shows Sessions over time, Active with AI (distinct people who used AI at least once in the period), an Activity calendar and Sessions by tool. The Skills & MCP section shows the most used skills and MCP servers, which is the capability-use row of the table above.

The Insights tab reads the period and writes findings such as Adoption rate, Dormant members and Adoption concentration, each compared with the previous period of the same length. An Org Admin sees the whole organization and can narrow it to one member; everyone else sees only their own activity. Metrics are not split by team, so a per-team breakdown still needs a filter by member or a second tool.

When do AI adoption numbers mislead?

Adoption numbers mislead the moment someone reads them as productivity. A team where everyone uses AI every day can ship at the same pace as before: adoption measures how much the tools are used, not what that use changed downstream. Report adoption as adoption, and put delivery numbers next to it when the conversation turns to output.

They also mislead when they become a ranking of people. Publishing “least active users” turns a measurement into surveillance, and people respond by opening the tool without using it. Use person-level data to find who needs help getting started, privately, and report the team-level number upward.

Finally, coverage gaps look like non-adoption. If one tool is not instrumented, its users appear dormant. Before you act on a low number, check that the tool those people actually use is reporting at all.

What should a team measure first?

Start with breadth and concentration, not depth. Depth (how much of the code carries AI evidence) is the number people want, but it is noisy and easy to argue about. Breadth and concentration are hard to argue with, and together they answer the question that decides what to do next: is AI use spread across the team, or carried by three enthusiasts?

The most useful list is usually not the most active people but the ones who were active once and then stopped. A person who never started may not need AI for their work. A person who tried and quit hit something: a setup that did not work, a rules file that fought their codebase, a tool that could not reach their systems. That is an enablement problem, and it is the cheapest adoption gain a team will ever find.