How to measure AI tool adoption

Measuring AI tool adoption means tracking how deeply engineers use the tool over time, not how many have access to it, and pairing that usage with delivery outcomes that should move if the tool is working. A license count tells you what procurement did. Adoption is what engineers did next.

This page sits under LinearB's AI in software development library, and it exists because most adoption dashboards stop at the first number.

It also answers one part of a bigger question, whether your AI coding investment is paying off.

You need three things: a usage signal from the tool itself (acceptance rate, active days, or the vendor's equivalent), a delivery baseline from before rollout (merge time, PR size, review time), and a decision about what adoption means for your organization. Without the baseline, every later number is a guess about direction.

You also need to accept that this will take longer than a tool rollout. Martin Woodward, VP of Developer Relations at GitHub, was the sixth person at the company to use Copilot. Even there, getting from six users to the whole engineering org took years.

"With copilot and with, I think with all AI tools, it follows this Moore adoption curve, 'cause individuals have to take the time to start using it in their workflow and start learning how to prompt the AI, learning what, where copilot can help."

— Martin Woodward, VP of Developer Relations at GitHub, on Dev Interrupted, You can't have AI without DevOps

That curve is the frame for everything below. A DevOps practice or an Agile process rolls out team by team. AI tools adopt individual by individual, which means the measurement has to work at the individual level too.

The first real adoption metric is an engagement histogram, not a percentage of seats assigned. GitHub's own primary measures are acceptance (how often engineers accept what the tool suggests) and active-day cohorts.

"The primary measure that we take is around like code acceptance, like how much people are accepting the suggestions from copilot and using them. And this usage as well is another key metric. Like, you know, are you a one day 28, a 10 day 28, a 28 day 28 kind of user?"

— Martin Woodward, VP of Developer Relations at GitHub, on Dev Interrupted, You can't have AI without DevOps

Build that histogram for your own org: how many engineers used the tool on one day in the last 28, on ten, on all 28. The shape tells you where you are on the curve. A long tail of one-day users with a small cluster of daily users means the tool has early adopters and nothing else yet, whatever the license count says.

Usage on its own is still an input. The adoption question only gets answered when a delivery metric moves alongside it. Woodward's team watched for exactly that.

"What's happening to our PR merge times? What's happening to our security vulnerability response times? Are we seeing correlative improvements in those alongside the percentage adoption of copilot that we're seeing?"

— Martin Woodward, VP of Developer Relations at GitHub, on Dev Interrupted, You can't have AI without DevOps

In GitHub's case, the outcomes did move: merge times fell, PR count rose, and PR size came down rather than up, which he says surprised him. Your rollout may produce different results. What transfers is the method: watch those three signals from the start, or you can't tell whether a rising adoption line is doing anything.

Pick the outcomes before rollout. Merge time, PR size and review time are the usual three because they're already in your git data and they respond quickly. If adoption climbs and none of them move, you have usage without impact, which is a different problem with a different fix.

The adoption curve stalls after the early adopters, and the stall is rarely about the tool.

"They're not missing out on it because they're bad or lazy. They're missing out on it 'cause they're busy and they need the help to get on board."

— Martin Woodward, VP of Developer Relations at GitHub, on Dev Interrupted, You can't have AI without DevOps

GitHub's answer was peer evidence rather than leadership advocacy: an internal channel where engineers post what the tool did for them, because, in Woodward's words, people will believe their peers before they believe a VP who "deletes emails all day." The measurement implication is that your one-day-user cohort is the audience for that work, and the histogram from Step 1 is how you know whether it's working.

The last step is the one most rollouts skip. Adoption measurement should be able to tell you a tool isn't worth keeping. Manik Surtani, CTO of the Agentic AI Foundation, puts the posture bluntly.

"Always have a skeptical mindset, right? Always come in to say, 'I actually don't know how much value this is gonna provide. It's very possible it'll be zero.'"

— Manik Surtani, CTO and co-founder of the Agentic AI Foundation, on Dev Interrupted, A neutral home for MCP, A2A, goose, and more

Write down, before rollout, what the outcome metrics have to show by a given date for the tool to stay. That turns adoption measurement from a report into a decision.

The 28-day-active cohort is growing quarter over quarter, and at least one delivery metric is moving with it. Both conditions. Adoption rising with flat outcomes means the tool is used but changes nothing downstream; outcomes improving with flat adoption means something else is driving them.

LinearB's AI developer productivity insights put the active cohort and the delivery metrics on one screen, so both conditions are checked in the same place.

Reporting seat assignment as adoption. Measuring usage without a pre-rollout baseline. Reading a plateau as a tool problem when it's a time-and-support problem. And never having written down what would make you turn the tool off, so the dashboard can only ever say yes.

Is acceptance rate a good adoption metric?

It's a good usage metric. It tells you engineers are taking what the tool offers. It only becomes an adoption signal when paired with active-day cohorts and a delivery outcome.

How long should adoption take?

Longer than a rollout. Because AI tools adopt individual by individual, expect a Moore-style curve with a stall after early adopters, and plan the support for the stall from the start.

What outcome metrics should we watch?

Merge time, PR size and review time are the usual starting set, because they're already in your git data and respond within weeks rather than quarters.