Un creciente número de desarrolladores está dejando de escribir código directamente y, en su lugar, diseña bucles que ejecutan tareas en cola y dejan que un agente de programación las intente, las evalúe y decida si seguir o detenerse. Esos bucles externos rodean al bucle interno que cualquier agente ya tiene: leer un archivo, llamar a una herramienta, ejecutar pruebas y responder. La diferencia es que la tarea sobrevive más allá del punto en que el modelo por sí solo habría dicho «he terminado», porque un orquestador continúa la misma sesión, abre una nueva con contexto modificado o reasigna el trabajo a otra máquina.
El artículo, firmado por Armin Ronacher, defiende que ese patrón funciona extraordinariamente bien en翻译 para tareas de duración corta o verificación clara: portar código entre lenguajes (como el traslado de partes de Bun de Zig a Rust o el porte de MiniJinja a Go), explorar rendimiento, escanear seguridad o investigar problemas complejos. En cambio, para código duradero que el autor quiere entender y defender, los bucles producen resultados peores que los del otoño pasado: código demasiado defensivo, complejo, local en su razonamiento, lleno de resguardos en vez de invariantes fuertes, con abstracciones torpes y duplicación.
Ronacher teme que meter ese comportamiento detrás de bucles lo amplifique: cada iteración añade otra pequeña defensa y el sistema se vuelve menos comprensible aunque parezca más robusto. Para juniors sin guía, además, el patrón enseña malas prácticas difíciles de desmontar. La metáfora que propone es el paso de software como máquina determinista a software como organismo, un cambio que, en su entorno formativo, siempre se consideró indeseable. La conclusión matiza: el bucle sí sirve para experimentar, medir y quitar tareas aburridas, pero todavía no para escribir código que importe mantener y comprender.