GitHub Copilot Reduce el Costo de Revisión de Código un 20% Después de Reescribir Instrucciones

El equipo de revisión de código de GitHub Copilot logró una reducción aproximada del 20% en los costos promedio de revisión después de resolver un problema derivado de una migración a herramientas CLI más limpias y compartidas. Inicialmente, el cambio resultó en un rendimiento más lento, más costoso y menos efectivo del agente. La regresión no se debió a una infraestructura defectuosa, sino a las instrucciones del agente que trataban las revisiones de solicitudes de extracción como tareas de exploración de repositorio abiertas, lo que hizo que el modelo entrara en un bucle de navegación que aumentó el contexto y oscureció las señales relevantes.

El equipo pasó de primitivas específicas de Copilot, como list_dir, search_file, search_dir y read_code, a un enganche de CLI de estilo Unix compartido utilizado en Copilot CLI y el agente en la nube de Copilot: glob para la detección de archivos, grep para la búsqueda de símbolos y texto, y view para la lectura del contenido del archivo. Las herramientas antiguas incluían automáticamente líneas circundantes con cada resultado, un patrón adecuado para modelos anteriores que realizaban menos llamadas de herramienta y esperaban respuestas individuales más ricas. Las nuevas herramientas proporcionaron una salida más liviana, lo que era mejor para modelos más nuevos capaces de manejar un volumen de llamadas más alto. A pesar de un mapeo uno a uno en papel y la promesa de una mantenimiento más fácil e mejoras entre productos, las mediciones sin conexión revelaron un aumento en los costos promedio de revisión y una disminución en el volumen de comentarios útiles.

El agente había entrado en un bucle de navegación, guiado por instrucciones diseñadas para 'entender este repositorio' en lugar de 'investigar esta diferencia'. Buscaba ampliamente, especulaba sobre posibles rutas, extraía rangos de archivos grandes y dejaba que cada resultado desencadenara otra búsqueda. Cada salida de herramienta se añadía a la ventana de contexto como tokens permanentes, lo que hizo que la exploración en aumento inflara los costos y sumergiera el enfoque del modelo en el área de superficie del repositorio no relacionada. El equipo de GitHub señaló que un resultado de herramienta no es una impresión desechable para un agente; son tokens adicionales que permanecen en la ventana de contexto y se acumulan hasta que se alcanza el límite.

La solución fue reescribir las instrucciones del sistema para enfocarse en la diferencia. El nuevo flujo de trabajo requiere preguntas dirigidas y mínimas, como dónde se llama a una función, si una clave de configuración se duplica o si una prueba refleja un patrón cambiado, y restringe al agente al rango de código más pequeño que responda a la pregunta específica. Después de la reescritura de las instrucciones, el equipo revertió la regresión y redujo los costos promedio de revisión en aproximadamente un 20% por debajo de la línea de base de las herramientas personalizadas originales, manteniendo la calidad de la revisión, tal como se mide por el número de comentarios útiles y la tasa de captura de problemas.

Este episodio subraya dos riesgos para las pilas de agentes de producción. Primero, compartir infraestructura entre productos es beneficioso solo si también se migran las instrucciones del flujo de trabajo del agente; descuidar la capa de indicaciones mientras se cambia la superficie de la herramienta puede convertir una refactorización en una regresión silenciosa. Segundo, las puntuaciones agregadas de medición son insuficientes. El equipo enfatiza que los rastros de llamadas de herramienta, que capturan qué herramientas se invocaron, cuanta salida retornaron y si el agente se estaba acercando a la evidencia o se desviaba hacia afuera, son señales de depuración cruciales. Sin ellos, las regresiones de costo y calidad pueden ser malentendidas como desviación del modelo en lugar de un mal ajuste de herramientas.

Para los arquitectos que gestionan agentes de revisión de código o RAG, instrumenten sus rutas de llamadas de herramienta antes de medir la precisión de los titulares, y traten la versionado de instrucciones como un paso de migración crítico junto con cualquier lanzamiento de herramientas compartidas.