Michael JohnsonDesde el 5 de noviembre, los equipos que usan GitHub Copilot Code Review pueden ver en los informes de la API a qué comentarios responden los desarrolladores. Ese mismo día, GitHub añadió campos que ayudan a los administradores a detectar lagunas en la telemetría y versiones obsoletas de los editores. Estas actualizaciones ofrecen a responsables y propietarios de organizaciones una forma más concreta de comprobar cómo funciona la revisión con IA y hasta qué punto son completos los datos de uso de Copilot.
Cómo medir la respuesta a los comentarios de la IA
A la fila diaria del informe por repositorio, repos-1-day, se ha añadido el objeto copilot_code_review. Entre sus campos están total_comments_evaluated, el número de comentarios revisados, y total_comments_addressed, el número de comentarios a los que respondió el desarrollador. Para calcular la proporción de comentarios atendidos en un repositorio, hay que dividir el segundo valor por el primero. Los nuevos campos se describen en la actualización de la API de métricas de uso de Copilot.
GitHub contabiliza una acción si el desarrollador aplica la corrección sugerida, pide a Copilot que la realice, edita el código por su cuenta o responde que incorporará la corrección en la siguiente solicitud de cambio. El informe desglosa además los comentarios por gravedad, nivel de revisión, tipo de observación y presencia de instrucciones o herramientas adicionales. Esto permite al equipo estudiar, por ejemplo, si las respuestas a los comentarios de seguridad difieren de las respuestas a otros comentarios, o qué categorías exigen más trabajo manual.
La métrica refleja una acción registrada, no la calidad verificada de la corrección. Por eso conviene consultarla junto con la revisión del código y el estado de la solicitud de cambio: una proporción alta de comentarios atendidos indica que hubo respuesta, pero no demuestra por sí sola que todos los cambios sean correctos o necesarios. También importa que los comentarios se contabilizan el día en que se fusiona la solicitud de cambio, no el día en que Copilot los publicó.
Por qué la métrica de acciones difiere de la aceptación de sugerencias
Los campos anteriores contabilizaban las ejecuciones de Copilot Code Review y los casos en que un usuario pulsaba el botón para aplicar una sugerencia preparada. La nueva métrica abarca más formas de responder: el desarrollador puede corregir el problema por su cuenta, pedir a Copilot que lo haga o aplazar el cambio hasta la siguiente solicitud de cambio. Por tanto, total_comments_addressed responde a la pregunta de qué acciones se toman sobre los comentarios, mientras que total_copilot_applied_suggestions cuenta únicamente las sugerencias que se pueden aplicar con una sola acción.
El informe también incluye total_merged_no_human_change_request_after_review: el número de solicitudes de cambio fusionadas y revisadas por Copilot en las que, después de la primera revisión, ninguna persona pidió cambios. Estas métricas describen etapas distintas del proceso y se entienden mejor en conjunto: la primera refleja la respuesta a los comentarios y la segunda, el curso de la revisión antes de la fusión.
Los nuevos campos muestran por qué los informes están incompletos
Otra actualización del 5 de noviembre añade datos sobre la telemetría del cliente y las versiones de las herramientas. El campo client_telemetry_present indica si ese día se recibieron eventos del editor del usuario; usage_metrics_requirements señala si el IDE y las extensiones cumplen los requisitos de versión mínima para las métricas. Los administradores también reciben cifras diarias de los usuarios sin telemetría y de los que tienen al menos un componente obsoleto. Los detalles se enumeran en la nota sobre las lagunas en los datos de Copilot.
Esto ayuda a distinguir la actividad del usuario de la integridad de los informes. GitHub explica que un usuario puede figurar como activo aunque no se hayan recibido eventos del editor; en ese caso, el informe pierde detalles como el desglose del uso por función y modelo. Entre las posibles causas están una versión antigua del IDE o de la extensión, la telemetría del editor desactivada y los proxies o cortafuegos que bloquean los eventos.
Los dos contadores de lagunas no se deben sumar para obtener el número de usuarios únicos: una misma persona puede aparecer en ambos grupos. Además, una versión correcta del editor no garantiza que se reciba telemetría; por ejemplo, pueden persistir las restricciones de red. Si un valor no está presente o es null, GitHub lo señala como dato no disponible, no como cero ni como ausencia de problemas.
Qué cambia para los equipos
Las novedades permiten sustituir una métrica general de actividad de Copilot por dos comprobaciones más prácticas: qué ocurre con los comentarios de Code Review y cuán fiables son los datos en que se basa el informe interno. Los responsables de ingeniería pueden comparar tipos de comentarios y repositorios, mientras que los administradores pueden identificar a usuarios que necesitan actualizar el IDE o la extensión, o revisar la configuración de red.
Los informes están disponibles a nivel de organización y empresa para usuarios con los permisos correspondientes para consultar las métricas de Copilot; la política de métricas de uso de Copilot debe estar habilitada. Los datos de Code Review aparecen en las filas de repos-1-day, mientras que los campos de telemetría y versiones están en los informes de usuarios de uno y 28 días. Esta actualización resulta especialmente útil para las organizaciones que ya administran Copilot de forma centralizada: ahora pueden investigar no solo el uso del asistente, sino también la respuesta a sus revisiones y las causas de las mediciones incompletas.
