GitHub añade la actividad de VS Code Agents a las métricas de Copilot y permite medir adopción sin mezclar superficies distintas

GitHub amplió qué puede medirse. El 11 de septiembre, GitHub anunció que sus reportes de métricas de uso de Copilot incluyen datos generalmente disponibles sobre actividad en la ventana dedicada VS Code Agents. Los reportes agregados de empresa y organización pueden incluir usuarios activos diarios, número de sesiones y mensajes; los reportes por usuario añaden indicadores de uso y totales de sesiones y mensajes. La actualización no dice si una sesión fue productiva. Su valor inicial es ofrecer una señal más granular de dónde y cómo se está utilizando una superficie agentic dentro de una organización.

La separación de superficies evita una lectura engañosa. GitHub aclara que estas métricas cubren la ventana específica de VS Code Agents y se mantienen separadas de Agent Mode dentro de la ventana del editor y de otros agregados genéricos. Esa decisión parece pequeña, pero es importante para producto. Dos interfaces pueden usar tecnología relacionada y provocar comportamientos muy distintos. Si se mezclan en un único “uso de IA”, un administrador no puede saber qué experiencia está creciendo, cuál se estancó ni dónde debería invertir en capacitación o rediseño.

Actividad no equivale a valor. Contar sesiones, mensajes o usuarios activos ayuda a medir adopción, pero puede premiar una experiencia que obliga a conversar demasiado. Un agente que necesita veinte mensajes para completar una tarea puede parecer más utilizado que uno que resuelve el mismo trabajo en tres interacciones. La métrica debe interpretarse junto con outcomes: tareas terminadas, tiempo hasta resultado, correcciones, aceptación de cambios o recurrencia voluntaria. El objetivo no es reducir toda actividad, sino evitar confundir volumen de interacción con impacto sobre el trabajo.

Los datos por usuario requieren contexto y gobernanza. GitHub indica que ciertos propietarios, billing managers y roles con permiso para ver métricas pueden acceder a reportes, siempre que la política correspondiente esté habilitada. Cuando la analítica baja al nivel individual, la organización necesita decidir para qué se usa. Medir adopción para mejorar una herramienta es distinto a convertir mensajes o sesiones en una evaluación simplista de desempeño laboral. Una política clara sobre propósito, acceso y retención evita que una métrica útil de producto se convierta en una fuente de incentivos perversos.

El comportamiento de campos ausentes también forma parte del contrato. GitHub señala que los nuevos campos son opcionales y pueden estar ausentes o ser null cuando no existe información correspondiente, preservando compatibilidad. Esa decisión de API permite que integraciones anteriores no fallen solo porque apareció una nueva dimensión. Es una lección de diseño para analítica: añadir mediciones sin romper consumidores existentes exige tratar ausencia como estado válido. Un dashboard serio distingue “cero actividad” de “dato no disponible” porque ambos significan cosas operativamente diferentes.

La métrica útil conecta adopción con una hipótesis. Si un equipo habilita VS Code Agents para reducir tiempo de una tarea repetitiva, el tablero debería observar no solo cuántas personas abrieron la ventana, sino qué ocurrió después. Puede construir un embudo: acceso habilitado, primera sesión, uso recurrente, artefacto aceptado y resultado confirmado. Cuando una etapa cae, la intervención cambia. Baja primera sesión puede ser problema de onboarding; muchas sesiones sin resultados sugiere fricción; buen resultado con baja recurrencia puede indicar que el caso de uso no aparece con frecuencia.

Lectura Goatify. Cada agente que ofrecemos debería venir con una definición de adopción que no premie ruido. Podemos registrar activación, tarea iniciada, acción aprobada, acción verificada y regreso voluntario, manteniendo cada superficie separada. Eso permite responder una pregunta comercial mucho más útil que “¿cuántas conversaciones hubo?”: ¿qué porcentaje de personas llegó a un resultado comprobable y quiso volver a usar la habilidad? Diseñar estas métricas desde el inicio hará que nuestras demos se conviertan en productos medibles y que el cliente pueda justificar renovación con evidencia real.