Michael JohnsonDesde 5 de novembro, equipes que usam o GitHub Copilot Code Review podem consultar nos relatórios da API quais comentários levaram os desenvolvedores a agir. No mesmo dia, o GitHub adicionou campos que ajudam administradores a identificar lacunas na telemetria e versões desatualizadas dos editores. Essas atualizações dão a líderes e responsáveis pelas organizações uma maneira mais concreta de avaliar como funciona a revisão por IA e quão completos são os dados de uso do Copilot.
Como medir a reação aos comentários da IA
Um objeto `copilot_code_review` foi adicionado à linha diária do relatório do repositório `repos-1-day`. Entre seus campos estão `total_comments_evaluated`, o número de comentários avaliados, e `total_comments_addressed`, o número de comentários aos quais o desenvolvedor reagiu. Para calcular a proporção de comentários atendidos em um repositório, basta dividir o segundo valor pelo primeiro. Os novos campos estão descritos na atualização da API de métricas de uso do Copilot.
O GitHub considera que houve uma ação quando o desenvolvedor aplica a correção sugerida, pede ao Copilot que a faça, edita o código por conta própria ou responde que a correção será incluída na próxima solicitação de pull. O relatório também separa os comentários por gravidade, nível de revisão, tipo de comentário e presença de instruções ou ferramentas adicionais. Isso permite, por exemplo, investigar se as reações a comentários de segurança diferem das reações a outros comentários ou quais categorias exigem mais trabalho manual.
A métrica registra uma ação, mas não confirma a qualidade da correção. Por isso, é útil analisá-la junto com a revisão do código e o estado da solicitação de pull: uma proporção alta de comentários atendidos indica que houve resposta aos comentários, mas não significa, por si só, que todas as alterações estejam corretas ou sejam necessárias. Outro detalhe importante: os comentários são contabilizados no dia em que a solicitação de pull é integrada, e não no dia em que o Copilot os publicou.
Por que a métrica de ações difere da aceitação de sugestões
Os campos anteriores contabilizavam execuções do Copilot Code Review e situações em que o usuário clicava no botão para aplicar uma sugestão pronta. A nova métrica abrange mais formas de reação: o desenvolvedor pode fazer a correção por conta própria, pedir ao Copilot que a faça ou adiar a alteração para a próxima solicitação de pull. Assim, `total_comments_addressed` responde à pergunta sobre ações em resposta aos comentários, enquanto `total_copilot_applied_suggestions` contabiliza apenas a aceitação de sugestões aplicáveis com uma única ação.
O relatório também inclui `total_merged_no_human_change_request_after_review`: o número de solicitações de pull integradas e revisadas pelo Copilot após cuja primeira revisão nenhuma pessoa solicitou alterações. Essas métricas descrevem etapas diferentes do trabalho e são mais úteis quando analisadas em conjunto: a primeira mostra a reação aos comentários; a segunda, o andamento da revisão até a integração.
Novos campos mostram por que os relatórios estão incompletos
Uma atualização separada, também publicada em 5 de novembro, acrescenta informações sobre a telemetria do cliente e as versões das ferramentas. O campo `client_telemetry_present` indica se eventos do editor do usuário foram recebidos em um determinado dia; `usage_metrics_requirements` informa se a IDE e as extensões atendem aos requisitos mínimos de versão para as métricas. Os administradores também recebem contagens diárias de usuários sem telemetria e de usuários com pelo menos um componente desatualizado. Os detalhes estão na nota sobre lacunas nos dados do Copilot.
Isso ajuda a distinguir a atividade do usuário da integridade dos relatórios. O GitHub explica que um usuário pode ser contabilizado como ativo mesmo que não tenham chegado eventos do editor; nesse caso, o relatório perde detalhes como a distribuição do uso por recurso e modelo. Entre as causas possíveis estão versões antigas da IDE ou da extensão, telemetria do editor desativada e proxies ou firewalls que bloqueiam os eventos.
Os dois contadores de lacunas não devem ser somados para obter o número de usuários únicos: uma mesma pessoa pode estar nos dois grupos. Além disso, uma versão correta do editor não garante que a telemetria será recebida — por exemplo, as restrições de rede podem continuar. Se um valor estiver ausente ou for `null`, o GitHub o indica como dado indisponível, e não como zero ou como ausência de problema.
O que isso muda para as equipes
As novidades permitem substituir uma métrica geral de atividade do Copilot por duas verificações mais práticas: o que acontece com os comentários do Code Review e quão confiáveis são os dados usados nos relatórios internos. Líderes de engenharia podem comparar tipos de comentários e repositórios, enquanto administradores podem identificar usuários que precisam atualizar a IDE ou a extensão, ou verificar as configurações de rede.
Os relatórios estão disponíveis no nível da organização e da empresa para usuários com as permissões necessárias para visualizar as métricas do Copilot; a política de métricas de uso do Copilot precisa estar habilitada. Os dados do Code Review estão nas linhas `repos-1-day`, enquanto os campos de telemetria e versão aparecem nos relatórios de usuários de um e 28 dias. Isso torna a atualização especialmente útil para organizações que já administram o Copilot de forma centralizada: agora elas podem investigar não apenas se o assistente está sendo usado, mas também como os usuários reagem às revisões e por que as medições estão incompletas.
