Loop Engineering - Addy Osmani

El siguiente paso para los agentes de codificación con IA: la “ingeniería de bucles”

Este texto, centrado en “Loop engineering” de Addy Osmani, aborda la idea de que los agentes de codificación pueden pasar de un modelo en el que las personas les dan instrucciones directas en cada paso a otro en el que se diseña un sistema iterativo donde el propio agente encuentra trabajo, lo divide, lo verifica y decide la siguiente tarea. Aquí, el bucle se parece más a “un flujo de trabajo que la IA ejecuta repetidamente varias veces hacia un objetivo definido”. Aun así, el texto no lo presenta como una solución universal. También subraya costos reales como el gasto de tokens, la responsabilidad de verificación y la posible pérdida de comprensión por parte de los desarrolladores.

Resumen clave

Qué significa la ingeniería de bucles

Hasta ahora, el desarrollador escribía prompts para el agente de codificación, leía el resultado y volvía a dar instrucciones. La ingeniería de bucles que describe el texto es un enfoque que convierte ese proceso en una estructura automatizada. Es decir, en lugar de indicar cada paso manualmente, se diseña como sistema “qué buscar, cómo procesarlo y cuándo detenerse”.

Componentes

El autor propone como elementos para construir un bucle la ejecución automática, worktrees, skills, plugins y conectores, subagentes y memoria externa. Los worktrees son una función de Git que divide el mismo repositorio en varios espacios de trabajo para reducir conflictos. Las skills son un mecanismo para documentar reglas y conocimiento del proyecto y evitar que el agente tenga que adivinar cada vez. Los conectores son el canal para enlazarse con herramientas externas como Linear, Slack o bases de datos.

Ventajas

En términos de reducir trabajo repetitivo, se pueden automatizar tareas como resumir fallos de CI, clasificar issues o revisar commits recientes. En cuanto al procesamiento en paralelo, varios agentes pueden trabajar cada uno en distintos worktrees para reducir conflictos de archivos. Desde la perspectiva de reutilización de conocimiento, las prácticas del proyecto y los procedimientos de build pueden conservarse como skills, evitando repetir las mismas explicaciones en cada sesión.

Desventajas y riesgos

La carga de verificación no desaparece. Los resultados que produce el bucle siguen necesitando revisión humana. El costo de tokens también puede crecer. Si aumentan los subagentes, cada uno utilizará por separado el modelo y las herramientas. También existe el problema de la deuda de comprensión. Si los desarrolladores aceptan los resultados sin leerlos, la base de código puede crecer, pero el alcance de lo que realmente entienden las personas puede reducirse.

Diferencias

Mientras que la ingeniería de prompts tradicional se enfoca en “una buena pregunta única”, la ingeniería de bucles se acerca más al diseño de “un sistema de trabajo repetible”. El autor considera que, a medida que Codex y Claude Code incorporan componentes similares como automatización, skills, conexiones basadas en MCP y subagentes, el diseño del bucle se está volviendo una preocupación más importante que la herramienta en sí.

Aspectos destacados

La separación entre quien escribe y quien valida es una característica importante. Si el agente que generó el código evalúa por sí mismo el resultado, puede volverse indulgente, por lo que se propone una estructura donde otro subagente se encargue de la revisión. Mantener memoria externa también es clave. Es necesario dejar el estado fuera de la conversación, por ejemplo en archivos Markdown o tableros de issues, para poder retomarlo en la siguiente ejecución.

La ingeniería de bucles se lee menos como una historia sobre reemplazar a los desarrolladores y más como una sobre cambiar los puntos en los que intervienen. El peso se desplaza de seguir escribiendo prompts manualmente hacia diseñar estructuras repetitivas, condiciones de validación, distribución del trabajo y métodos de registro. Aun así, un buen bucle no sustituye el buen juicio. Si no existe la capacidad de ingeniería para leer código, verificar resultados y entender los límites del sistema, la automatización puede aumentar primero el riesgo antes que la velocidad.