Un agente propuso seis cambios nocturnos a un código de 205.000 líneas. Los ingenieros se quedaron con dos
Google dejó a Gemini 4 Argon trabajar solo 11 horas en su Agent Development Kit. Entraron dos cambios, cuatro se rechazaron con razón y una ronda sin reglas rompió un esquema público.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
La mayoría de los relatos sobre agentes de código en bases grandes describen lo que produjo el agente. El de Google sobre una ejecución nocturna en su Agent Development Kit es más útil, porque dedica el mismo espacio a lo que los ingenieros descartaron.
El planteamiento, publicado el 13 de octubre: Gemini 4 Argon, ejecutándose en Google Antigravity, trabajó sin supervisión durante 11 horas a partir de las 21:11 sobre google/adk-python, unas 205.000 líneas en casi 800 archivos con cerca de 17.000 pruebas unitarias. El objetivo era encontrar y eliminar sobrecarga de rendimiento entre archivos en el arranque, en sesiones largas y en configuraciones multiagente, sin cambiar las entradas del modelo ni la API pública, y abrir un único pull request sin fusionar con cifras de antes y después.
El primer intento es el que enseña
Antes de la ejecución nocturna, el equipo hizo una ronda de dos horas sin directrices del repositorio. El agente dedicó unos 70 minutos a medir antes de editar, que es buena práctica, y encontró cuellos de botella reales. También modificó un esquema JSON público a través de un hook del modelo de autenticación, pasó por alto casos límite en eventos simulados, ejecutó solo 216 pruebas cercanas y no incluyó las cifras del benchmark en su pull request.
Ninguno de esos es un fallo de razonamiento. Son los errores que comete un ingeniero nuevo y capaz en un código cuyas reglas no escritas nadie le ha contado. La segunda ronda lo resolvió de dos maneras: directrices de los mantenedores guardadas en el propio repositorio como .agents/skills, cada una un índice breve que remite a archivos de referencia cargados cuando hacen falta (el agente leyó 12 antes de editar), y un modo de objetivo que mantiene la meta fijada a través de las compactaciones de contexto. En la segunda ronda el agente respetó las convenciones, midió una línea base en cuatro cargas de trabajo con 30 ejecuciones cada una y ejecutó la batería completa antes de terminar.
Seis propuestas, dos merges
| Propuesta | Resultado | Motivo |
|---|---|---|
| Filtrar el historial de sesión antes de copiarlo | Fusionada | Cerca de un 40% menos de sobrecarga previa al modelo en sesiones largas en memoria |
| Carga diferida de paquetes pesados | Fusionada | Importación en frío un 21% más rápida, conservando atributos sustituibles en pruebas |
| Caché de eventos multiagente | Rechazada | 17% en una prueba sintética, pero podía devolver datos obsoletos entre sesiones |
| Comprobación de telemetría | Rechazada | Leía un atributo privado de una librería que podía romperse al actualizarla |
| Reescritura del formato del historial | Rechazada | Más difícil de leer, sin mejora de extremo a extremo en el benchmark aparte |
| Índice de reproducción de flujos | Rechazada | Más complejidad de estado, útil solo en pruebas sintéticas |
El cambio aceptado tocó 22 archivos, añadió 17 funciones de prueba y llegó a main con la nota “Argon generated these changes”. Los resultados se midieron en un benchmark aparte que el agente nunca vio, como medianas de 6 a 12 ejecuciones, con peticiones al modelo idénticas byte a byte antes y después. Una ejecución de 158 turnos con llamadas a herramientas bajó de 65,6 a 56,1 segundos. El tiempo hasta la primera petición en un proceso nuevo no cambió, porque los módulos diferidos ahora se cargan en el primer turno.
El cambio de carga diferida muestra el tipo de trabajo que los agentes hacen bien. Eliminar sin más las importaciones del principio rompió 25 objetivos de prueba internos de Google que sustituyen atributos de módulo directamente. La solución usó accesores diferidos que mantienen esos atributos sustituibles, un detalle entre módulos que ningún profiler habría mostrado.
Lo que sirve para un código empresarial
El resumen del propio equipo es “el agente explora, el mantenedor resta”. De ahí salen tres lecciones para los responsables de ingeniería que planean agentes de código de larga duración.
Escriba las reglas antes de la ejecución. La mayoría de los errores de la primera ronda vinieron de convenciones que vivían en la cabeza de los mantenedores. Las skills de repositorio son baratas de escribir y reutilizables por cualquier agente y por cualquier persona que se incorpore. En códigos regulados, también es donde se deja escrito lo que un agente nunca debe tocar.
Separe el benchmark del agente del suyo. La caché de eventos rechazada parecía una mejora del 17% en un benchmark sintético. Un benchmark aparte que el agente no puede ver es el equivalente en código a que la prueba venga de fuera del modelo: impide que el agente optimice para la prueba.
Presupueste la revisión como el costo principal. Generar seis propuestas en una noche es barato. Juzgar el riesgo de datos obsoletos en una caché, el riesgo de actualización en un atributo privado y la legibilidad de una ruta central exigió mantenedores con experiencia. Una tasa de aceptación de dos de seis no es una debilidad de la ejecución; es el aspecto de una revisión que funciona. Un programa de agentes que mida el éxito por propuestas generadas premiará justo los cuatro cambios que este equipo rechazó. Mida los cambios aceptados, con su evidencia, como defendimos para los cambios escritos por agentes en general.
El caso es el repositorio de Google, con sus herramientas y sus ingenieros, y las mejoras se refieren a operaciones concretas de ADK. No demuestra que los agentes nocturnos reduzcan el costo de desarrollo en general. Sí es una buena prueba de cómo ejecutar uno para que lo que llega a main merezca estar ahí.