A adoção de inteligência artificial para programar cresceu mais rápido que nossa capacidade de explicar o resultado. Contar licenças ou conversas mostra que uma ferramenta está presente, não que o software ficou melhor, chegou antes ou custou menos para manter.
O novo painel de impacto do GitHub Copilot tenta reduzir essa distância. Em vez de exibir apenas usuários ativos, ele organiza pessoas em fases de adoção e relaciona cada grupo a pull requests incorporados, velocidade de integração e volume de código. É uma mudança pequena na interface, mas importante na pergunta: sai “quem abriu a ferramenta?” e entra “como o trabalho mudou?”.
Da licença à forma de trabalhar
O painel separa usuários engajados em três coortes: uso centrado em código, trabalho centrado em agentes e uso multiagente ou pelo aplicativo Copilot. Há ainda um grupo passivo, formado por pessoas licenciadas que não se engajaram. A classificação considera os 28 dias anteriores.
Para cada grupo, administradores podem acompanhar a média mensal de pull requests incorporados por pessoa, a mediana do tempo de integração, o número e a proporção de usuários e a média diária de linhas de código. Tendências de seis meses mostram se as coortes e as entregas estão mudando.
Antes, uma organização podia concluir que a implantação funcionou porque o número de usuários ativos aumentou. Agora ela consegue formular hipóteses melhores: equipes que passaram de sugestões pontuais para agentes integram mudanças com outra frequência? A velocidade melhora sem concentrar revisões ou aumentar correções posteriores?
Essa segunda pergunta revela o limite do painel. Linhas de código e pull requests medem movimento, não valor. Um reparo pequeno pode ser mais valioso que uma grande alteração; integrar rápido pode esconder uma revisão superficial. As métricas servem para localizar diferenças e iniciar uma investigação, não para transformar produtividade individual em placar.
O custo também pertence ao sistema
No mesmo dia, o GitHub publicou uma comparação entre Copilot e acesso direto a modelos. O ponto mais útil não é comercial: o preço de uma tarefa depende do modelo e também do sistema que seleciona contexto, oferece ferramentas, preserva instruções, repete chamadas e conduz o trabalho até uma revisão.
Uma avaliação anterior do próprio GitHub procurou isolar o efeito desse sistema de execução. Modelo, tarefa, janela de contexto, esforço de raciocínio e ferramentas foram normalizados para comparar diferentes ambientes de agente. O estudo relata taxas de resolução semelhantes e menor consumo de tokens na maioria das configurações testadas.
Há cautelas importantes. Os resultados vêm do fornecedor, alguns testes têm menos de cem casos e, nesses conjuntos menores, foi informado o melhor resultado entre cinco execuções. No TerminalBench 2.0, cada combinação foi executada cinco vezes e a variação entre tentativas apareceu no gráfico. Portanto, a evidência sustenta que o ambiente ao redor do modelo pode alterar custo e desempenho; não sustenta uma vitória universal.
A pergunta adulta
Para uma equipe, a aplicação prática é combinar três camadas. Primeiro, adoção: quem usa e de que modo. Depois, fluxo: tempo de integração, entregas e custo por tarefa. Por fim, qualidade: falhas em produção, retrabalho, segurança, manutenção e satisfação de quem revisa. Nenhuma camada substitui as outras.
Ferramentas de código com IA estão entrando numa fase menos espetacular e mais útil. O modelo continua importante, mas a decisão já não pode depender apenas de uma demonstração convincente. A pergunta adulta é se o sistema inteiro melhora o trabalho sob condições reais, com custo, variabilidade e consequências visíveis.