GitHub ya mide Copilot por repositorio: la adopción de agentes necesita su propio tablero

GitHub habilitó el 17 de julio de 2026 métricas de uso de Copilot con alcance de repositorio. La actualización agrega endpoints REST que devuelven, para un día concreto, actividad de Copilot coding agent y Copilot code review por repositorio, tanto en reportes de empresa como de organización.

El cambio parece administrativo, pero resuelve un problema técnico: contar usuarios activos o solicitudes de chat no dice qué repositorios están recibiendo cambios agentic, cuáles acumulan revisiones automáticas ni dónde la adopción necesita más enablement. El repositorio es una unidad mucho más cercana a ownership, riesgo, lenguaje, pipeline y calidad.

Qué entregan los nuevos endpoints

GitHub documenta dos rutas nuevas para reportes de un día:

• GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
• GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD

La respuesta incluye pull requests creados y fusionados por coding agent, además de pull requests revisados por code review y el desglose de sugerencias por tipo de comentario. Para acceder, el administrador debe tener habilitada la política de métricas de Copilot y un permiso que permita ver esos reportes.

Esto no es telemetría completa de ingeniería. No demuestra que un pull request de Copilot haya sido correcto, que el equipo haya aceptado sus cambios ni que el review haya encontrado todos los problemas. Sí crea una base para relacionar actividad agentic con repositorio, fecha y resultados posteriores.

El tablero útil no es un ranking de equipos

Un error sería convertir la métrica en una competencia de “qué repositorio usa más IA”. Más pull requests no significa más valor; incluso puede señalar una configuración que produce cambios pequeños y ruido. Un tablero responsable debería combinar cuatro capas:

1. Adopción: repositorios con actividad de coding agent o code review durante el periodo.
2. Flujo: pull requests abiertos, fusionados y tiempo hasta la revisión humana.
3. Calidad: pruebas, reversiones, comentarios críticos, incidentes y defectos posteriores.
4. Control: permisos, herramientas conectadas, instrucciones del repositorio y quién aprobó la integración.

La API solo cubre una parte de ese modelo. El resto exige unir los reportes con tus datos de CI, pull requests y ownership. Hazlo con cuidado: los reportes de uso no deben terminar convertidos en vigilancia individual ni en un sustituto de la evaluación del cambio.

Cómo lo probaría en una organización pequeña

Empieza con un repositorio de referencia y una ventana de 14 días. Descarga el reporte diario, guárdalo con la fecha de extracción y normaliza el nombre del repositorio antes de mezclarlo con GitHub Actions. Luego responde preguntas concretas: ¿qué porcentaje de pull requests agentic llega a merge?, ¿cuánto tarda su revisión?, ¿qué categorías de sugerencia aparecen?, ¿qué repositorios no tienen tests suficientes para aceptar automatización?

Mantén la métrica fuera del camino crítico de producción. Si la API falla o entrega un día incompleto, el despliegue debe continuar y el tablero debe marcar la ausencia. También documenta que los datos son agregados y que ciertas dimensiones pueden excluirse o tener retraso de procesamiento.

La demanda se infiere, sin SEO tooling conectado, por el lanzamiento oficial, la documentación REST y búsquedas como Copilot usage metrics API, Copilot metrics repository, coding agent analytics y Copilot code review adoption. Agente IA puede competir en español si explica el salto desde el entusiasmo por la IA hacia una operación medible por código, owners y riesgos.

Si estás construyendo tu primer flujo con herramientas, el curso gratis ayuda a separar permisos, pruebas y manejo de errores. La lectura clave de este cambio es: medir por repositorio no prueba que el agente sea bueno; te permite descubrir dónde debes medir calidad antes de ampliar su autonomía.