Métricas de GitHub Copilot incompletas: cómo corregirlas

Revisión del 15 de octubre de 2026: distinguimos las versiones que corrigen el incidente de la tabla general de IDE compatibles y añadimos el plazo habitual de procesamiento de métricas. Los datos perdidos siguen sin poder reconstruirse según GitHub.

Las métricas de GitHub Copilot pueden estar incompletas si parte del equipo usa versiones de IDE afectadas por un cambio de telemetría. GitHub confirmó el 6 de octubre de 2026 que algunas sesiones del modo agente no identificaban correctamente el IDE: la actividad quedó fuera de los informes o se atribuyó a Copilot CLI. La corrección ya está disponible en Visual Studio Code 1.139.0; para otros IDE se desplegará hasta noviembre. Los datos omitidos no se pueden reconstruir. La acción inmediata es inventariar versiones, actualizar cuando exista una versión corregida y anotar la discontinuidad antes de comparar productividad.

Qué ocurrió con las métricas de GitHub Copilot

El anuncio oficial de GitHub del 6 de octubre explica que varios IDE trasladaron las sesiones del modo agente al Copilot SDK. Esas sesiones no comunicaban de qué IDE procedían, por lo que GitHub no podía atribuirlas correctamente en sus informes.

El problema afecta la medición, no la facturación. GitHub indica que parte de la actividad quedó sin contar y otra parte se clasificó como actividad de Copilot CLI. Las sesiones de usuarios que permanecen en versiones anteriores, previas al cambio hacia el SDK, continúan contándose según la documentación del proveedor.

Qué datos pueden quedar subcontados

Mientras una persona permanezca en una versión afectada, pueden aparecer por debajo de la actividad real sus interacciones con agentes y las líneas añadidas o eliminadas mediante ediciones del agente. GitHub menciona expresamente métricas como loc_added_sum y loc_deleted_sum para agent_edit. El efecto alcanza informes de empresa, organización y usuario, tanto de un día como de 28 días.

También puede aparecer inflada la actividad atribuida a Copilot CLI. Esto no significa que todos los datos históricos sean falsos: describe una brecha concreta en la atribución de sesiones que usaron el SDK desde determinados clientes.

Qué versiones corrigen el problema

La disponibilidad no es simultánea. Esta es la situación comunicada por GitHub al verificar la nota:

• Visual Studio Code: versión 1.139.0 o posterior; disponible.
• Visual Studio: versión 18.12; prevista para octubre de 2026.
• IDE de JetBrains: próxima versión del complemento; prevista para finales de octubre.
• Eclipse: próxima versión del complemento; prevista para noviembre.
• Xcode: próxima versión del complemento; prevista para noviembre.

La lista puede cambiar durante el despliegue. GitHub señala que incorporará cada versión publicada a su documentación de IDE compatibles con las métricas de Copilot. Por eso conviene comprobar esa página antes de imponer una versión mínima.

Dos requisitos distintos: la tabla general de IDE compatibles no equivale a la lista de versiones que corrigen este incidente del SDK. Al 15 de octubre, el anuncio específico sigue señalando VS Code 1.139.0 y mantiene las fechas previstas para los demás clientes; no damos esas versiones futuras por publicadas. La documentación general indica además que los datos pueden tardar hasta dos días UTC completos en estar disponibles.

Por qué no debes comparar periodos sin una anotación

Hecho: GitHub afirma que no puede rellenar retrospectivamente la actividad perdida, porque las sesiones afectadas no incluyeron la información necesaria para identificar su IDE. La recuperación será gradual a medida que cada persona actualice.

Análisis: una subida posterior a la actualización puede reflejar mejor cobertura de telemetría y no necesariamente un aumento equivalente en adopción o productividad. Del mismo modo, una caída anterior no demuestra por sí sola que el equipo usó menos el agente.

Para evitar conclusiones erróneas, registra al menos tres fechas: cuándo comenzó la anomalía visible en tu panel, cuándo estuvo disponible la versión corregida para cada IDE y cuándo alcanzó el equipo el nivel de adopción definido. Si utilizas ventanas móviles de 28 días, conserva la anotación hasta que la ventana ya no incluya sesiones afectadas.

Plan práctico para administradores y equipos

1. Inventaría IDE y complementos. Reúne la versión actual del IDE, la versión de Copilot y la fecha del último uso. No presupongas que toda la organización utiliza Visual Studio Code.
2. Separa disponibilidad de adopción. Que exista una corrección no significa que todos la hayan instalado. Mide qué porcentaje del equipo ya cumple la versión mínima.
3. Actualiza de forma controlada. Prueba primero con un grupo pequeño cuando el IDE o el complemento sea crítico para compilación, depuración o extensiones internas.
4. Comprueba la telemetría. Verifica que no esté desactivada y que proxies o firewalls permitan el endpoint correspondiente. GitHub advierte que esos controles también explican discrepancias.
5. Anota la discontinuidad. Marca el periodo afectado en el tablero interno y en cualquier informe ejecutivo que reutilice los datos.
6. Revisa ambas direcciones. Espera una recuperación gradual de la actividad de agente y una posible reducción de la actividad atribuida a Copilot CLI.
7. No recalcules lo irrecuperable. Evita fabricar estimaciones retroactivas como si fueran observaciones. Si necesitas una aproximación, identifícala como modelo y publica sus supuestos.

Si ya utilizas observabilidad de agentes, distingue este fallo de atribución de la configuración de capturas. La guía de telemetría de GitHub Copilot trata los controles de observabilidad; no recupera las sesiones históricas que carecían de identificación del IDE.

Qué señales sirven para comprobar la recuperación

Después de actualizar, observa la actividad por IDE y por usuario, no solo el total de la empresa. GitHub recomienda revisar en los informes por usuario totals_by_ide, donde aparecen last_known_ide_version y last_known_plugin_version. Estas dimensiones ayudan a localizar clientes rezagados.

Compara además los usuarios activos registrados por el servidor con los detalles enviados por el cliente. La documentación sobre qué uso incluyen las métricas distingue datos del servidor y telemetría del editor. El servidor puede confirmar que una persona estuvo activa, pero algunos detalles —como lenguaje, modelo, líneas modificadas o sugerencias aceptadas— dependen del cliente.

Qué no demuestra la recuperación

Un panel más completo no demuestra que Copilot haya reducido tiempos, mejorado calidad o generado valor financiero. Las métricas de actividad describen uso; para evaluar resultados hay que relacionarlas con tiempos de ciclo, defectos, revisiones, satisfacción del desarrollador y resultados de entrega, evitando atribuir automáticamente cualquier cambio a una sola herramienta.

Oportunidades y precauciones

Oportunidad: la incidencia ofrece un buen motivo para revisar la gobernanza de métricas antes de convertirlas en objetivos. Un equipo puede documentar las fuentes, versiones mínimas, responsables y reglas para interpretar ausencias o cambios de instrumentación.

Precaución: no utilices el descenso afectado para evaluar individualmente a desarrolladores ni para justificar licencias o recortes sin contexto. Además de ser metodológicamente débil, una lectura aislada puede confundir problemas de cliente, red o telemetría con comportamiento humano.

Esta revisión encaja con otros controles técnicos ya tratados por GitCoders: la compatibilidad del nuevo formato de tokens de GitHub Apps, la automatización de reglas de cobertura mediante API y las protecciones de ejecución de GitHub Actions. Son problemas distintos, pero comparten una práctica: leer el estado real antes de automatizar decisiones.

Alcance internacional y limitaciones

El aviso se refiere a GitHub Copilot y a IDE compatibles; no depende del país del equipo. La disponibilidad efectiva puede variar por versión, canal de actualización, política de dispositivos y plan. La información se basa principalmente en GitHub, que es la fuente primaria para una anomalía de su propia instrumentación. No se encontró una auditoría independiente capaz de reconstruir los datos ausentes.

La corrección no modifica el historial ni garantiza que todas las discrepancias desaparezcan. Telemetría desactivada, redes que bloquean eventos, clientes no compatibles y nuevas diferencias entre medición del servidor y del editor pueden seguir afectando los informes.

Preguntas frecuentes

¿La incidencia cambió la facturación de GitHub Copilot?

GitHub dice que no. El problema afectó la atribución de actividad en los informes, no los cargos.

¿Se pueden recuperar las métricas históricas omitidas?

No, según GitHub. Las sesiones afectadas no indicaron de qué IDE procedían, por lo que el proveedor no puede atribuirlas después.

¿Basta con actualizar Visual Studio Code?

Solo para quienes trabajan en Visual Studio Code. Cada IDE tiene su propia versión corregida y su calendario. El equipo debe inventariar todos los clientes utilizados.

¿La subida posterior a la actualización prueba más productividad?

No. Puede reflejar mejor cobertura de telemetría. La productividad requiere indicadores de resultado y contexto adicional.

¿Qué ocurre si la telemetría está desactivada?

Los detalles enviados desde el editor pueden seguir faltando aunque el IDE esté actualizado. Revisa la política de privacidad, la configuración del cliente y las restricciones de red antes de interpretar el panel.

Fuentes y fecha de verificación

• GitHub Changelog: actualización de IDE para restaurar la actividad del agente en métricas, publicado y actualizado el 6 de octubre de 2026.
• GitHub Docs: métricas de uso de Copilot, consultado el 7 de octubre de 2026.

Verificado el 7 de octubre de 2026 a las 03:10, America/Lima. Es una corrección de producto y una recomendación operativa, no una norma ni una garantía de productividad, ahorro o precisión total.