Dale mejores herramientas a un agente y debería hacer mejor trabajo. Esa es la intuición, al menos. El equipo de GitHub Copilot descubrió que la intuición fallaba, y la historia de por qué es una lección valiosa para cualquiera que construya sobre agentes de IA.

Cuando abres un pull request, la revisión de código de Copilot lee el diff y explora el código circundante para encontrar los problemas que importan antes de que lleguen a producción. Para eso usaba sus propias herramientas de exploración de código. Así que cuando el equipo las cambió por las herramientas compartidas y mejor mantenidas que dan vida a la CLI de Copilot (grep, glob y view), esperaban una mejora limpia. En cambio, en sus benchmarks internos, el costo de las revisiones subió y se detectaban menos problemas.

Pero las herramientas no eran el problema. Lo eran las instrucciones. Una vez que las reescribieron para reflejar cómo lee realmente un revisor un pull request, la regresión se transformó en una ganancia: alrededor de un 20% menos de costo promedio por revisión, manteniendo la misma calidad.

¿Por qué fallaron las mismas herramientas?

Si alguna vez construiste sobre un framework de agentes, probablemente heredaste también sus herramientas. Funcionan, así que te las quedas, hasta el día en que tu caso de uso se aleja lo suficiente de aquello para lo que fueron diseñadas y empiezan a jugar en tu contra en silencio.

Las herramientas originales de la revisión de Copilot se inspiraban en sistemas agénticos previos, con ideas de la navegación de repositorios estilo SWE-agent y de GitHub Copilot Autofix: listar directorios, buscar archivos, buscar en directorios y leer código. Funcionaban, pero estaban pensadas para cómo se comportaban los modelos en su momento: los modelos de codificación más antiguos hacían menos llamadas a herramientas y eran peores incorporando contexto automáticamente, así que era más importante meter toda la información relevante en las pocas llamadas que hacía el modelo.

La CLI de Copilot, en cambio, tiene un conjunto compartido de herramientas de exploración de inspiración Unix: grep, glob y view. Ese harness lo usa un número creciente de productos con agentes, así que las mejoras benefician a más de uno. Sobre el papel, la migración parecía simple: reemplazar list_dir por glob, search_file/search_dir por grep y read_code por view.

El rastro reveló un bucle de exploración

Los benchmarks internos de la revisión de Copilot son útiles porque muestran más que una nota final: exhiben el camino que tomó el agente, qué herramientas llamó, cuánta salida volvió, dónde hubo errores y si se estaba acercando a la evidencia o ensanchando la búsqueda.

Al probar las herramientas compartidas, el agente a menudo se comportaba como si estuviera navegando un repositorio en lugar de investigar un pull request. Buscaba de forma amplia, adivinaba rutas probables, leía en exceso, encontraba más cosas que buscar y arrastraba todo ese contexto extra.

Ese patrón es entendible. La exploración amplia sirve cuando la tarea es "entender este repo". Pero no es como un revisor examina un pull request. Cuando alguien revisa un pull request, parte del diff y hace preguntas dirigidas:

  • ¿Dónde se llama esta función?
  • ¿Se usa esta clave de configuración en algún otro lado?
  • ¿Hay un test o un helper con el mismo patrón?
  • ¿Cuál es el mínimo rango de código cercano que explica este comportamiento?

Un revisor no quiere abrir gran parte del repositorio antes de saber qué busca. Quiere el mínimo contexto necesario para responder la pregunta. Y eso importa porque cada resultado de herramienta pasa a formar parte del contexto de trabajo del agente: los contenidos extra se arrastran al razonamiento posterior, encareciendo la revisión y, a veces, volviéndola menos enfocada. Para un agente, el resultado de una herramienta no es una impresión desechable, son tokens extra que se quedan en la ventana de contexto.

La solución: instrucciones con forma de revisor

Las herramientas no eran el problema: sus instrucciones, afinadas para el uso dentro de la CLI de Copilot, sugerían el flujo de trabajo equivocado. El agente usaba grep, glob y view como un asistente de codificación amplio en vez de como un revisor.

Las siguientes iteraciones hicieron la guía específica para la revisión de código. El flujo que el equipo quería era:

  • Partir del diff y formular preguntas de revisión específicas.
  • Usar glob cuando la ruta es incierta y grep para encontrar archivos, símbolos y llamadas candidatas.
  • Agrupar el descubrimiento barato antes de leer archivos.
  • Usar view solo cuando el agente ya sabe qué archivo o rango de líneas necesita.
  • Agrupar lecturas enfocadas en vez de alternar entre una búsqueda y una lectura.

Por ejemplo, imagina que el diff modifica un helper de autorización que decide si una operación está permitida. La pregunta de revisión relevante no es "muéstrame el contenido completo de cada archivo que llama a este helper", sino la más acotada: "¿algún manejador de solicitudes depende del comportamiento antiguo?". El camino previsto es corto: partir del helper cambiado en el diff, usar grep para hallar quién lo llama, glob para ubicar rutas o controladores probables, view para leer los rangos más relevantes y decidir si algún llamador cambia el riesgo.

La guía también cambió cómo el agente se recuperaba de búsquedas fallidas. Si una entrada hacía fallar a grep, el mejor paso siguiente era una búsqueda más simple y corregida. Si una ruta estaba mal, el mejor paso era glob, no adivinar rutas vecinas y leer lo que hubiera. Eso alejó al agente de convertir una pequeña falla de herramienta en un bucle de exploración mayor. El cambio fue pequeño en palabras y grande en efecto: pasó el ritmo del agente de "navegar, leer, buscar de nuevo" a "preguntar, acotar, leer, decidir".

Los benchmarks sirvieron para depurar comportamiento, no solo notas

El harness compartido dio las herramientas; los benchmarks internos dieron el ciclo de retroalimentación. El equipo podía correr los mismos ejemplos, comparar los rastros de herramientas, actualizar las instrucciones y volver a correr, preguntándose cosas concretas: ¿el agente acotó primero o leyó de forma amplia?, ¿agrupó búsquedas independientes?, ¿llamó a view solo cuando tenía una razón?

La señal más útil no fue "las instrucciones son mejores", sino algo más concreto: el agente hacía un número similar de llamadas a herramientas, pero gastaba más de ellas en evidencia relevante en vez de expandir la búsqueda una y otra vez.

El resultado y la lección para construir con agentes

En producción, el comportamiento afinado mostró alrededor de un 20% menos de costo promedio por revisión frente al control, sin una señal de calidad que impidiera desplegarlo. La reducción no vino de las herramientas por sí solas, sino del flujo de trabajo a su alrededor.

Ese marco importa al construir con agentes. Es tentador tratar las herramientas como detalles de implementación, cambiar una por otra y comparar la respuesta final. Pero para un agente, la superficie de herramientas es parte de la experiencia del producto: cambia qué nota el agente, cómo busca, cuánto contexto arrastra y cuándo decide que tiene suficiente evidencia. Las descripciones de herramientas y las instrucciones del sistema se parecen más a la documentación de una API: un pequeño cambio de redacción puede afectar el costo, la calidad y la forma de la investigación.

El equipo también intentó aplicar el mismo tipo de instrucciones enfocadas en la propia CLI, donde no produjo la misma ganancia. Es un contraejemplo útil: la revisión de código está anclada a un diff y a una pregunta, mientras que la CLI maneja tareas interactivas más amplias donde explorar es parte del trabajo. Las mismas herramientas grep, glob y view pueden servir a ambos productos, pero el flujo a su alrededor tiene que coincidir con la tarea. La conclusión es simple: las herramientas compartidas escalan cuando las instrucciones y los benchmarks calzan con el trabajo.