Un agente de IA coló 57 parches en proyectos de Google, NVIDIA o Netflix
Jeffy Loop, un bucle de control open source para Claude Code, ha logrado que mantenedores ajenos acepten 57 parches en 45 proyectos, y publica también los 28 que fracasaron.
A las 00:03 del 6 de septiembre, un pull request llegó contra la librería de compresión snappy de Google. El fallo era casi cómico: comprime un archivo de 4 GiB con cualquier build de release y la cabecera que escribe jura que el fichero ocupa 0 bytes. El mantenedor lo fusionó al día siguiente. Detrás no había una persona leyendo código a mano, sino un bucle de control llamado Jeffy Loop.
Jeffy Loop es un bucle de control open source para Claude Code. Audita un repositorio, ataca lo que encuentra, lo arregla y demuestra el arreglo con una comprobación que puede fallar. Cada iteración es un commit local; si la verificación se rompe, se revierte. Nada se sube hasta que aguanta. Lo interesante del diseño es que el agente nunca tiene la última palabra: un evaluador adversarial y una puerta de shell revisan cada afirmación de que el trabajo está hecho. En una de las builds ese evaluador se invocó 8 veces y rechazó 7. El merge, el único veredicto que el bucle no puede darse a sí mismo, lo firma un desconocido.
Según el recuento del autor, eso son 57 parches aceptados en 45 proyectos, en código de NVIDIA, Meta, Tesla, Google, Apple, Microsoft, Netflix, Apache, Oracle, IBM, Cisco, Square, Cloudflare, JetBrains, Canonical y el parser de URL de Node.js. En NVIDIA, un ajuste vacío de configuración pasaba la validación y arrancaba un contenedor sin acceso a GPU y sin error. En Netflix, cualquier parámetro de query con mayúsculas en el nombre volvía vacío. En Tesla, un proxy leía el cuerpo de cada petición sin límite. El arreglo para snmalloc de Microsoft se fusionó dos horas después de abrirse, y el del parser de Node.js tardó doce minutos.
La review que casi lo tumba
Un mantenedor de Apache Commons pasó a draft un parche sobre commons-lang y dejó dos frases: "Creo que este PR crea 2 bugs, así que parece que nos faltan tests, porque el build salió en verde" y "tu IA se está imaginando cosas cuando habla del PR #1427, porque ese PR se cerró sin fusionarse". Tenía razón en las dos. El arreglo metía dos fallos que el build verde no cazaba, y la descripción había sacado su historial de una tabla de resumen en vez del registro del propio código. Cada caso se reprodujo, se arregló y se cubrió con un test; el mantenedor pidió un tercero y el 9 de septiembre fusionó el rework. De ahí salió maquinaria: el historial de un pull request se lee ahora con git blame, nunca de una tabla.
Los números que no salen
El autor publica también los 28 proyectos que fallaron. mruby aguantó 10 ejecuciones y 113 iteraciones sin converger, y aparece en la misma tabla pública que los merges. Las reglas que deciden qué sale de la máquina viven en housebroken, publicado en PyPI como housebroken-cli, y cada una nació del veredicto de un mantenedor sobre un pull request real.
Son cifras que da el propio autor, en primera persona y sin auditoría externa. Lo comprobable está a la vista: los parches están fusionados en repositorios ajenos y el scorecard es público. El problema de fondo es el que se le viene encima a cualquier equipo. Los agentes ya escriben código, y el cuello de botella no es generarlo sino que alguien con criterio lo acepte. Un bucle que exige evidencia y se revierte cuando falla es una manera de comprar esa confianza merge a merge. Habrá que ver si aguanta con más manos mirando que las de su autor.
