The short version
Count sessions, repositories, tools and connectors. That is enough to see who uses AI, how often, where and with what. Never collect prompts, code or file names: you don't need them, and collecting them is how measurement turns into surveillance.
Read the numbers week by week, treat a quiet Mac as a gap rather than a zero, and use what you learn to help people, not to rank them.
Why measure instead of asking
A survey tells you what people think and feel about AI: what they believe it can do, what holds them back, how confident they are. It is less good at how often they use it. People remember the big session last week and forget the quiet weeks around it.
The tools already keep a record of every session on the engineer's machine. Counting from those records gives you the habit itself: who used AI on which days, in which projects, with which tool.
Three sources, one picture
Telemetry shows how often people use AI, but not how well, or what stops them. Put it next to a survey, for what people think and what holds them back, and a skills quiz, for what they can do. Each one alone can mislead; together they tell you what to do next.
One team, three sources
Self-reportsWhat people think, and what holds them back“No one showed us how”
AssessmentsWhat people can actually doBeginner on the Claude quiz
TelemetryHow often people really use AIAI on 18 of 20 days
The full picture
The team uses AI almost every day but isn't good at it yet, and says no one showed them how. Start with training, not more licences.
What to count
- Sessions. Each conversation with a coding assistant. Sessions per day, and the days with at least one, show whether AI is part of the work or an occasional extra.
- Repositories. The project each session ran in. It shows where AI is used and where it isn't, which is often a question of the codebase rather than the people.
- Tools. Which assistant ran the session, such as Claude Code or Codex. It tells you which licences are used, and which people have settled on.
- Connectors. The tools the AI reached during a session, such as GitHub or Linear. Connectors are a sign people let the AI work in their real systems, not just chat.
What never to collect
- Prompts and the AI's answers
- Code, diffs and file names
- The text of commands
- Session titles
None of these is needed to answer the questions above, and every one of them can hold customer data, secrets or personal notes. Leaving them on the machine is what lets engineers say yes to being measured at all. Tell people this before they connect, and show them the full list of what is shared.
Reading the numbers
- Days beat totals. How many days someone used AI says more than how many sessions they had: one long day can look like a busy month.
- Watch weeks, not days. People using AI in each of the last four weeks shows a habit forming or fading. One quiet week is a holiday more often than a trend.
- A gap isn't a zero. A laptop that was off, or left at home, sends nothing. Count those days as unknown, not as days without AI.
- Most and least use are for help. The people who use AI on the most days can show others what works; the people on the fewest may need time, access or training.
- Compare a team with itself. Teams with different work use AI differently. The useful question is whether a team is moving, not whether it beats another.
Rolling it out
- Start with one team that is curious, and share what you learn with it first.
- Say why before you ask. What you want to learn, what is shared, what never is, and who will see the report.
- Let people connect themselves. An engineer who pastes the line knows what they agreed to; nothing should arrive on a machine without its owner.
- Let people choose what they share. Personal projects live on work laptops too. Show each engineer the repositories you'd count and let them untick any, before anything is sent.
- Make stopping easy. A way to disconnect at any time keeps the people who stay connected honest about it.
- Show the results back within a few weeks, with what you'll change because of them.
Mistakes to avoid
- Lines of code as productivity. More lines written by AI isn't more value, and people quickly learn to inflate it. We don't report it.
- Usage in performance reviews. Once the numbers decide pay or promotion, people stop connecting or start gaming them.
- Collecting content just in case. Prompts and code are the riskiest data you could hold, and the questions above don't need them.
- Judging from a week. Wait for a month of data before you decide that something is working or isn't.
How we do it
AI Coding Usage follows this page. Each engineer connects their Mac once with one line and chooses which repositories to share; a small add-on reads what Claude Code and Codex already record and, when a session ends, sends that session's numbers to the report. Prompts, code and file names stay on the Mac.