Mapa de adoção de IA: quem usa o quê e onde ela ainda não chegou

Fizemos o rollout de assistentes de código com IA, mas eu não sei quem realmente os usa, com que profundidade, nem onde a adoção nunca aconteceu. Quero o mapa antes de gastar com treinamento ou com mais licenças. ## Contexto - Assistentes que temos: [Cursor, Claude Code, GitHub Copilot, Devin] - Licenças e preço mensal por ferramenta: [por exemplo 40 licenças de Cursor a US$ 40, 25 licenças de Copilot a US$ 19]. Só a aba de licenças precisa disso. Se eu não informei nenhum, monte o mapa mesmo assim e deixe licenças e custo vazios. - Escopo: [todos os squads | nomes dos squads] - Período: [últimos 30 dias], com os 30 dias anteriores para dar a direção - Não usar IA não é baixo desempenho. Algumas das melhores pessoas de engenharia são as que menos usam. Este mapa é para capacitação, nunca para avaliação. - Se eu deixei algo entre [colchetes], mantenha o que for um padrão (um período, um número de dias, a primeira de várias opções) e me pergunte o resto de uma vez só, antes de puxar qualquer dado. - Escreva tudo, inclusive o entregável, no idioma deste prompt. ## Puxe estes dados do DevStats 1. List Squads e List Players 2. A ferramenta de AI Activity de cada assistente, por player: dias ativos, sessões ou requests, modos usados (autocomplete, chat, agente), acceptance rate, linhas de IA aceitas 3. A mesma AI Activity para a organização inteira, os dois períodos 4. PR List, merged, campos repository, player_login — para ver em quais repositórios e stacks cada pessoa trabalha 5. Player Metrics — só para comparações agregadas entre grupos, nunca pessoa por pessoa ## Como analisar - Defina adoção por dias ativos, não por linhas de código: não usa (nenhuma atividade), experimentando (alguns dias), habitual (a maioria dos dias úteis), power user (habitual e usando o modo agente ou mais de uma ferramenta). - Procure agrupamentos. Não adoção concentrada em um squad, repositório ou stack é um problema de ambiente: uma linguagem com que a ferramenta lida mal, um código legado, regras de segurança ou falta de licenças. Não é um problema de pessoas. - Uso alto com acceptance rate baixo significa que as pessoas estão brigando com a ferramenta. Isso geralmente é configuração: faltam regras de projeto, não há arquivos de contexto, o modelo é o errado. - Quem usa só autocomplete está deixando o ganho maior na mesa. É nos fluxos com agentes que está o ganho de tempo. Isso é uma oportunidade de treinamento, e os power users são os treinadores. - Liste os power users como champions internos. Enquadre isso como reconhecimento, nunca como vigilância. - Uma licença paga sem atividade em 30 dias deve ser recuperada. Pessoas com licenças de duas ou três ferramentas que usam só uma são uma oportunidade de consolidação. - A direção importa: um squad indo de experimentando para habitual é um sucesso mesmo que o nível ainda seja baixo. ## Entregue Uma planilha (.xlsx) e um resumo curto: 1. Aba **Squads** — squad, licenças, usuários ativos, parcela habitual ou acima, ferramenta principal, direção contra o período anterior, a lacuna. Esta é a aba que eu posso compartilhar. 2. Aba **Pessoas** — player, squad, ferramentas, dias ativos, nível, modos usados, acceptance rate, observação. Só para os meus olhos; diga isso no topo da aba. 3. Aba **Licenças a recuperar** — ferramenta, pessoa, última atividade, custo mensal usando os preços que eu informei 4. **Resumo** — cinco achados, agrupamentos primeiro 5. **Plano de capacitação** — três ações, por exemplo champions pareando com um squad, corrigir a configuração de uma stack, recuperar um número de licenças, cada uma com o efeito que devo esperar em 30 dias