How do you measure AI coding tool adoption?

Seats assigned is not adoption

Almost every AI tool rollout is first reported as a seat count, because a seat count is available on day one and needs no instrumentation. It measures procurement. The next number people reach for is licences activated, which measures whether somebody logged in once, in a quarter, under mild social pressure.

Neither tells you whether the tool changed how anyone works, and both flatter the rollout at exactly the moment when honest numbers would be most useful.

Number one: weekly active engineers, over a denominator you can defend

Count engineers with at least one session in a rolling seven days. Then decide, explicitly and in writing, what you are dividing by. Over total engineering headcount it answers whether the org has adopted the tool. Over engineers holding a seat it answers whether the money is being used, which is a different question with a different owner.

Report both. The gap between them is the whole story, and reporting only the flattering one is how a rollout gets declared a success six months before anyone notices it was not.

Number two: did the code survive?

This is the hard one and the honest one. Two tools answer it, differently, and neither answer is transferable to the other.

Claude Code emits claude_code.code_edit_tool.decision, documented as a count of code editing tool permission decisions. That is an accept-or-reject at the moment of the edit. It is available, it is cheap, and it stops at the moment of the decision: it does not know whether the accepted edit was reverted an hour later.

Cursor answers a better version of the question with AI Code Tracking, which scores git commits against code signatures. It reaches further into the lifecycle, and it comes with two constraints Cursor documents itself.

All code signatures are stored on-device. The git commit must be scored on the same machine as the AI code was authored.

AI Code Tracking has not been implemented for Background Agents, or the Cursor CLI yet.

So a Cursor AI-authored percentage is a floor. Work committed from a different machine than it was written on, or produced by a background agent or the CLI, is not counted. That is not a criticism of the design, it is a property of it, and reporting the number without the caveat is how a floor becomes a target.

Where each signal actually comes from

Repository and branch are missing from that table on purpose. None of the vendor surfaces carry them, which is why questions like "which codebases has this actually changed" tend to go unanswered. An endpoint agent that reads the tools' local telemetry does carry repo, branch and project on each event, and that is the main thing it adds to this particular list.

Five ways teams measure this wrong

• Counting suggestions instead of decisions. Suggestions measure how chatty the tool is. Decisions measure whether anyone agreed with it.
• Averaging across a bimodal population. Adoption is almost never normally distributed: a few people use it constantly and a long tail barely touches it. The mean describes nobody. Report the distribution, or at least the median and the share of engineers above some floor.
• Reading a stopped agent as a stopped engineer. If your collection depends on config that can drift, or on an agent that can be paused, then zero is ambiguous. Distinguish "no activity" from "not reporting" or you will investigate the wrong person.
• Comparing tools whose telemetry has different depth. Claude Code emits permission decisions, Cursor does not, Codex's decision events arrive classified as meta. A cross-tool acceptance-rate chart is comparing a measurement with an absence.
• Believing week one. Every rollout has a novelty spike. The number worth watching is week six, and the number worth acting on is whether week twelve is above week six.

What none of this measures

Productivity. Not one signal in this article measures output quality, delivery speed or business value, and combining several of them does not produce one that does. Lines of code modified is the oldest bad proxy in software and attaching a model to it does not improve it.

There is a practical reason to be strict about this, beyond intellectual honesty. The moment engineers believe usage telemetry feeds a performance review, the numbers stop describing the tool and start describing what people think you want to see. In Germany, Austria, France and the Netherlands there is also a works council or CSE that will ask you directly whether this is a performance measurement system, and "no" needs to be true when you say it.

What Synopt's adoption view shows

Feature events, subagent runs, org acceptance rate, distinct features used, lines added and removed, commits, pull requests, active hours and sessions, sliced by team, tool and engineer. The coverage caption sits on the page itself rather than in a footnote, because the differences between tools are the first thing that will mislead you.

Feature detail varies by tool: Claude Code (tools + permission decisions), Cursor (tools + subagents), Codex (tools only: no decisions yet). Copilot/ChatGPT report no feature detail.

There is also an org setting that stores events with no user attribution at all. With it on, the ingest pipeline nulls the user id, the session id and the branch before anything is written, so team-level adoption still works and per-engineer adoption stops existing. For an EU rollout that is often the difference between a works council agreement and a long argument.