GitHub amplió el 25 de septiembre su API de métricas de Copilot para incluir tiempos de revisión de pull requests. Las empresas podrán medir la mediana y el percentil 90 de tres etapas: desde que un PR está listo hasta la primera revisión, desde la primera revisión hasta la última y desde esa última revisión hasta el merge. La compañía lo detalló en su changelog oficial.
Tres tiempos nuevos para detectar cuellos de botella
El nuevo campo pull_request_review_times aparece en los informes de uso a nivel de repositorio para empresas y organizaciones. GitHub ofrece tanto la mediana como el p90, lo que permite distinguir el comportamiento habitual de los casos que se atascan mucho más de lo normal.
Las etapas separan el proceso de revisión en tres momentos. El primero mide la espera hasta que alguien revisa el cambio; el segundo, el tiempo que consume el ciclo de revisión; y el tercero, cuánto tarda el equipo en fusionar un PR una vez terminada la revisión.
Solo cuenta revisiones humanas
GitHub especifica que estas métricas se basan en revisiones humanas. Eso evita mezclar el tiempo de respuesta de herramientas automáticas con el proceso real de aprobación del equipo y permite utilizar el indicador para analizar capacidad, carga de revisores y fluidez del proceso de entrega.
La compañía advierte además de que los datos se generan hacia adelante y no se rellenan para periodos anteriores al 21 de septiembre. Una empresa que empiece a consultar el indicador ahora no debe esperar una serie histórica completa previa a esa fecha.
Quién puede consultar las métricas
El acceso requiere permiso para ver Copilot Metrics y que la política correspondiente esté habilitada. Por tanto, antes de integrar los nuevos campos en un cuadro de mando, conviene comprobar permisos, política de métricas y repositorios incluidos.
Cómo utilizar el dato sin convertirlo en una métrica de presión
Para una pyme de software, el valor principal está en localizar esperas estructurales: PR que pasan horas sin revisor, ciclos de cambios excesivamente largos o merges que se retrasan después de estar aprobados. El p90 es especialmente útil para detectar esos extremos.
La métrica no mide calidad del código ni productividad individual. Utilizarla para clasificar personas puede generar incentivos contraproducentes; tiene más sentido analizar tendencias por repositorio y proceso, comparándolas con incidencias, tamaño de cambios y carga del equipo.
Para equipos que gestionan desarrollo y seguridad, esta novedad conviene leerla junto con otros cambios recientes: el parche crítico de GitLab, los fallos detectados en StockAgile, la migración hacia passkeys empresariales, la evolución de Microsoft Defender con agentes de IA, la remediación automática de Cloudflare CASB y las capacidades agénticas de Google Workspace.
Fotografía: Daniil Komov / Pexels.
