AI adoption map: who uses what, and where it has not landed

We rolled out AI coding assistants, but I do not know who actually uses them, how deeply, or where adoption never happened. I want the map before I spend on training or on more seats. ## Context - Assistants we have: [Cursor, Claude Code, GitHub Copilot, Devin] - Seats and monthly price per tool: [for example 40 Cursor seats at $40, 25 Copilot seats at $19]. Only the seats sheet needs them. If I gave none, build the map anyway and leave seats and cost empty. - Scope: [all squads | squad names] - Period: [last 30 days], with the 30 days before it for direction - Not using AI is not underperformance. Some of the best engineers use it least. This map is for enablement, never for evaluation. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats 1. List Squads and List Players 2. The AI Activity tool for each assistant, per player: active days, sessions or requests, modes used (autocomplete, chat, agent), acceptance rate, AI lines accepted 3. The same AI Activity for the whole organization, both periods 4. PR List, merged, fields repository, player_login — to see which repositories and stacks each person works in 5. Player Metrics — only for aggregate comparisons between groups, never person by person ## How to analyze - Define adoption by active days, not by lines of code: not using (no activity), trying (a few days), habitual (most working days), power user (habitual and using agent mode or more than one tool). - Look for clusters. Non-adoption concentrated in one squad, repository or stack is an environment problem: a language the tool handles badly, a legacy codebase, security rules, or missing licenses. It is not a people problem. - High usage with a low acceptance rate means people are fighting the tool. That is usually setup: missing project rules, no context files, the wrong model. - Autocomplete-only users are leaving the larger gain on the table. Agent workflows are where the time goes. That is a training opportunity, and power users are the trainers. - List the power users as internal champions. Frame it as recognition, never as surveillance. - A paid seat with no activity in 30 days should be reclaimed. People holding licenses for two or three tools and using one are a consolidation opportunity. - Direction matters: a squad going from trying to habitual is a success even if its level is still low. ## Deliver A spreadsheet (.xlsx) and a short summary: 1. **Squads** sheet — squad, seats, active users, share habitual or above, main tool, direction vs the previous period, the gap. This is the sheet I can share. 2. **People** sheet — player, squad, tools, active days, level, modes used, acceptance rate, note. For my eyes only; say so at the top of the sheet. 3. **Seats to reclaim** sheet — tool, person, last activity, monthly cost using the prices I gave you 4. **Summary** — five findings, clusters first 5. **Enablement plan** — three actions, for example champions pairing with one squad, fixing the setup for one stack, reclaiming a number of seats, each with the effect I should expect in 30 days