GitHub descubrió que mejores herramientas empeoraban su code review: el arreglo fue cambiar las instrucciones
GitHub contó el 10 de julio de 2026 cómo migrar Copilot Code Review a grep, glob y view aumentó el coste hasta que rediseñó el flujo alrededor del diff. La lección para builders: una tool no funciona fuera del contexto para el que fue descrita.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
GitHub publicó el 10 de julio de 2026 una autocrítica que vale más que otra lista de capacidades de un coding agent: al cambiar las herramientas internas de Copilot Code Review por las herramientas compartidas de Copilot CLI, el agente revisó peor y gastó más. El arreglo no fue volver atrás. Fue cambiar las instrucciones para que esas mismas tools entendieran que estaban revisando un pull request, no explorando un repositorio desde cero.
El resultado final fue aproximadamente 20 % menos coste promedio por review, sin una señal de calidad que bloqueara el envío. La noticia es buscable por Copilot code review tools, grep glob view agent y GitHub agent workflow, pero la decisión útil para un builder es más general: la superficie de herramientas y la descripción de su uso forman un solo producto.
El cambio que parecía mecánico
GitHub quería compartir infraestructura entre productos. El flujo antiguo de Code Review tenía herramientas propias para listar directorios, buscar archivos y leer código. El harness de Copilot CLI ya usaba una interfaz inspirada en Unix:
globpara descubrir rutas;greppara buscar texto, símbolos y llamadas;viewpara leer un archivo o rango concreto.
La migración tenía sentido en mantenimiento: menos implementaciones duplicadas y mejoras que podían viajar entre Copilot CLI, Code Review y el agente cloud. En benchmarks offline ocurrió lo contrario de lo esperado: aumentó el coste promedio y bajó la cantidad de hallazgos útiles.
La traza explicó por qué. El agente recibía instrucciones genéricas de exploración y empezaba a comportarse como un asistente que quiere mapear todo el repositorio: buscaba ampliamente, adivinaba rutas, abría más archivos y arrastraba ese contexto a los siguientes pasos. Para un coding agent interactivo esa curiosidad puede ser válida. Para un reviewer anclado a un diff, es una fuga de tokens y atención.
El diff debe ser el ancla
La revisión de un pull request no empieza con “entiende este repositorio”. Empieza con preguntas más pequeñas:
- ¿Qué comportamiento cambia en el diff?
- ¿Dónde se llama la función modificada?
- ¿Hay una prueba o configuración que dependa de la conducta anterior?
- ¿Cuál es el rango mínimo de código que permite confirmar el riesgo?
GitHub reescribió sus instrucciones alrededor de esa secuencia: arrancar en el diff, hacer descubrimiento barato con grep y glob, leer con view solo cuando ya existe una hipótesis y agrupar búsquedas independientes antes de abrir archivos. También definió una recuperación más estrecha: si una búsqueda falla, corregirla o simplificarla; si una ruta es incorrecta, buscarla con glob en vez de leer vecinos al azar.
Qué debería copiar un equipo builder
No copies literalmente las tres tools. Copia el método de diagnóstico:
- Define el trabajo antes de elegir la tool. Un reviewer, un agente de coding y un agente de investigación pueden usar
grep, pero necesitan instrucciones distintas. - Mide la trayectoria. Registra llamadas, volumen de salida, errores, repeticiones y tiempo, además del resultado final.
- Escribe preguntas operativas. “Busca contexto relevante” es demasiado abierto; “encuentra callers de esta función y lee solo los rangos necesarios” produce una conducta comprobable.
- Separa descubrimiento de lectura. Las búsquedas baratas pueden agruparse; leer archivos completos debería requerir una razón.
- Prueba el prompt de tools como código. Un cambio pequeño en la descripción puede alterar coste, cobertura y orden de las acciones.
La cautela importante está en el contraejemplo: GitHub dice que las mismas instrucciones focalizadas no produjeron la misma mejora en Copilot CLI. Allí el usuario puede cambiar de objetivo, no hay un diff único y explorar el repositorio forma parte del trabajo. Compartir tools sí escala; compartir ciegamente el flujo no.
La demanda se infiere de la publicación técnica, la conversación sobre coding agents y queries como Copilot code review, agent tool instructions y reducir tokens en code review. No hay volumen SEO conectado. Para probar esta idea en tu propio stack, empieza con cinco pull requests reales y compara trazas antes de cambiar modelos o añadir más herramientas. También puedes cruzarla con la nota sobre Code Quality en GitHub: un gate sirve más cuando el agente llega a él con evidencia focalizada.
La conclusión: un agente no hereda automáticamente el buen comportamiento de una tool madura; necesita instrucciones y evals diseñadas para el trabajo exacto que debe hacer.