How to Measure AI Adoption in Your Engineering Org

TL;DR: "How many people have licenses" is a procurement fact. "How many use it weekly" is a survey mood. Real AI adoption is measured in the repo: the share of commits and merged PRs that carry an AI signal, the share of PRs an AI bot reviewed, and the split by tool. All of it is queryable from git, deterministically and with receipts, as long as you're honest that git only sees AI that signs its work.

Why the usual adoption numbers are theater

Every AI adoption review starts with the same three numbers: seats purchased, seats "active," and a survey where most of the team says they use AI weekly. All three are real facts. None of them measures adoption.

Seats measure spend. Vendor "active user" counts measure logins and suggestion events inside one vendor's tool, defined however that vendor likes. And surveys measure mood, which would be fine if mood tracked reality. The strongest evidence says it doesn't. In METR's randomized trial, experienced developers estimated AI made them about 20% faster while the measurement showed them 19% slower on real tasks. People who can't perceive the direction of AI's effect on their own work are not a reliable instrument for reporting its quantity.

Meanwhile the stakes on getting the number right went up. The Stack Overflow 2024 survey put 76% of developers as using or planning to use AI tools, so the question stopped being "are we adopting AI?" years ago. The question now is how much of the work you ship actually involves it. That share is the denominator under every downstream question: is the spend returning anything, is it degrading the codebase, and should you buy more seats.

What counts as AI adoption - a working definition

AI adoption is the share of shipped work that carries an AI signal. Not people, not licenses, not sentiment - shipped work. That definition forces two useful clarifications:

1. Authored and reviewed are different facts. A PR written with an agent and a PR reviewed by Copilot or CodeRabbit are two separate adoption stories, and mixing them into one "AI %" hides both. Track them separately.
2. Every git-derived number is a floor. Explicit signals - trailers, bot accounts, co-author lines - only catch AI that signs its work. Tab-completions and IDE chat-applies leave zero git trace. "Unattributed" means "no fingerprint," not "human-certified." An honest adoption metric says so out loud.

The five metrics that actually measure it

1. AI commit share

Of all non-merge commits in the window, what share carries an explicit AI signal: a co-author trailer, a bot or agent identity, an agent branch pattern? This is the finest-grain adoption number and the one that moves first when a new tool lands.

2. AI PR share

Of merged PRs, what share is AI-attributed? PR grain is the one leadership decisions live at, because a merged PR is a unit of delivered change, and it's the grain where you can attach outcomes (cycle time, review latency, rework) to build the ROI comparison later.

3. AI-reviewed share

Of merged PRs, what share drew a review from an AI review bot? This is adoption on the consumption side of the review market, and it moves independently of authoring: teams that barely use agents often lean hard on AI reviewers, and vice versa. It deserves its own number.

4. Signal coverage - the honesty metric

What share of commits carries any AI signal at all, and what share of commit messages have you actually parsed for trailers? This is the metric about your measurement: if coverage is low because your agents don't sign their work, fix the convention before quoting the adoption number. The mechanics of trailers, co-author lines, and bot accounts are covered in how much of our code is AI-written, the ten-minute setup that makes every metric above a plain query.

5. Per-tool split

One blended "AI %" is where adoption dashboards go to lie. Cursor agents, Claude Code, Copilot's coding agent, and an AI review bot are different tools with different signatures and different failure modes, and later different verdicts. Keep the split from day one; it costs nothing and it's the difference between "AI is 30% of our delivery" and "tool X ships clean and tool Y is a churn machine."

Should you track adoption per developer?

You can - the signals are attributable to authors - and you shouldn't. A "who uses AI most" leaderboard gets gamed exactly like commit-count leaderboards: the moment attribution feeds a personal score, people add or strip trailers to manage their number, and the measurement dies of its own misuse. Every decision adoption data actually feeds (seat purchases, guardrails, review policy, training) is made at tool and team grain. Measure there. (The same logic applies to every individual metric; the longer argument is in individual developer performance metrics. The vendors genuinely disagree on this one: Typo tracks AI usage per individual and crowns "AI champions," a fork examined in Busfactor vs Typo.)

What's a good number?

Honest answer: nobody has a defensible benchmark for AI commit share, and anyone selling you one is quoting their own customer mix. What research offers instead is a warning about the slope: DORA's 2024 report estimated that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability - individual productivity up, system outcomes dented. And GitClear's 623-million-change dataset shows what unmanaged adoption did to industry code: duplication up 81%, refactoring line-moves down about 70%.

So treat adoption share the way you'd treat deploy frequency without change failure rate: a denominator waiting for its outcome metrics. Adoption climbing while rework holds flat is a tool earning its keep. Adoption climbing while rework climbs with it is you paying twice. Whether your org can absorb a higher share at all is a separate, answerable question: that's the AI readiness assessment.

Measuring it without building it

You can assemble all five metrics yourself: a trailer convention, bot accounts, a script over git log, a join against your PR data, and a registry of review-bot logins. Budget a few days to build and a permanent tax to maintain the tool patterns as agents multiply.

Or connect your repos to Busfactor's AI impact view and get the whole strip computed deterministically: AI commit share, AI PR share, AI-reviewed share with per-bot receipts, signal coverage, and the per-tool split with each tool's merged-PR cohort compared against your unattributed baseline. Every number is quoted from the same engine, and every share links to the actual PRs behind it.

The blind spots, stated up front: attribution covers agentic AI that signs its work (trailers, bot identities, agent branches, PR-body markers). Tab-completion use is invisible to git, so the measured share is explicitly a floor. Above that floor there's an opt-in, clearly-labeled heuristic estimate band: an estimate, never quoted as fact, never shown per-person. If a vendor shows you one precise "AI adoption %" with no floor and no disclosure, you're looking at a guess wearing a suit. (A worked example of asking for the method and not finding one: Busfactor vs Waydev.)

Start with the floor. It's the only adoption number you can defend in front of a board. Once it exists, every harder question about AI in your org finally has a denominator.