Nota del editor: El modo de usar los agentes de codificación con IA está pasando de "escribir prompts manualmente y avanzar tareas ronda a ronda" a "diseñar bucles para que el sistema gestione agentes de forma continua". Lo que Addy Osmani llama Loop Engineering (Ingeniería de Bucles) consiste básicamente en crear un flujo de trabajo que pueda descubrir tareas automáticamente, asignarlas, revisar resultados, registrar el progreso y decidir los siguientes pasos.
Este bucle consta aproximadamente de cinco módulos: Automations (descubrir y priorizar tareas de forma programada), Worktrees (aislar múltiples entornos de desarrollo paralelos), Skills (documentar el conocimiento del proyecto y las convenciones del equipo), Plugins/Connectors (conectar con herramientas reales como GitHub, Linear, Slack, bases de datos, etc.), Sub-agents (separar al ejecutor del revisor), más una capa de memoria externa, como archivos Markdown o tableros de Linear, para guardar el estado y los avances.
El artículo señala que el sentido de la Loop Engineering no es solo "hacer que la IA ejecute más rondas", sino adelantar el criterio del ingeniero al diseño del sistema. Los bucles pueden amplificar significativamente el apalancamiento del trabajo del desarrollador, pero no sustituyen la verificación, la comprensión y el criterio. El verdadero riesgo no está en usar bucles, sino en usarlos como excusa para evitar entender el código y el sistema. En el futuro, la habilidad clave para colaborar con la programación de IA quizás ya no sea solo escribir un buen prompt, sino diseñar flujos de trabajo de agentes confiables, verificables y que se ejecuten de forma sostenible.
A continuación, el artículo original:
La loop engineering (ingeniería de bucles) está reemplazando tu papel como "persona que escribe prompts para el agente". Diseñas un sistema para que sea este el que dé los prompts al agente. Este "bucle" puede entenderse como una meta recursiva: defines un objetivo y la IA itera continuamente hasta completar la tarea. Está compuesto aproximadamente por cinco elementos, y tanto Claude Code como Codex ya cuentan con estos cinco elementos.
Creo que esta podría ser la forma en que colaboraremos con los agentes de codificación en el futuro. Sin embargo, todo esto sigue en una fase muy temprana y mantengo mis reservas. Definitivamente hay que ser cauteloso con el costo de tokens, ya que puede variar enormemente según el patrón de uso, especialmente dependiendo de si eres "rico en tokens" o "escaso en tokens". También necesitas algún mecanismo para asegurar que la calidad no se degrade. Las preocupaciones sobre la "producción basura de IA" (slop) también son válidas. Dicho esto, veamos de qué se trata realmente.
@steipete dijo recientemente: "Ya no deberías escribir prompts para los agentes de codificación. Deberías diseñar bucles que den prompts a tu agente". De manera similar, @bcherny, responsable de Claude Code en Anthropic, dijo: "Ya no le doy prompts a Claude. Tengo varios bucles ejecutándose que le dan prompts a Claude y deciden por sí mismos qué hacer después. Mi trabajo es escribir bucles".
Entonces, ¿qué significa esto?
Durante los últimos dos años, la forma básica de hacer que un agente de codificación hiciera algo era escribir un buen prompt y dar suficiente contexto. Introducías una frase, leías la respuesta, introducías la siguiente. El agente era una herramienta que tú empuñabas, ronda tras ronda, para avanzar. Esta etapa, en cierto modo, ya ha terminado, o al menos algunos creen que está a punto de terminar.
Ahora, construyes un pequeño sistema: este descubre trabajo por sí mismo, asigna tareas, revisa resultados, registra lo completado y luego decide el siguiente paso. Es decir, haces que el sistema maneje al agente, en lugar de darle prompts personalmente una y otra vez. Antes escribí sobre su "pariente cercano" —la agent harness engineering (ingeniería de arneses para agentes), que consiste en preparar el entorno de ejecución para un agente individual— y el factory model (modelo de fábrica), que son sistemas que construyen software. La loop engineering está un nivel por encima del harness. Es como un harness, pero se ejecuta con un temporizador, genera asistentes menores y se autoalimenta.
Lo que me sorprende es que esto ya no es solo un problema a nivel de "herramientas". Hace un año, si querías un bucle, tenías que escribir un montón de scripts bash y mantenerlos para siempre. Era algo tuyo y solo tuyo. Ahora, estos componentes vienen integrados directamente en los productos. Las capacidades que enumera Steinberger se corresponden casi una a una con las de la aplicación Codex, y también se pueden corresponder casi igual con Claude Code. Una vez que te das cuenta de que tienen la misma forma, dejas de preocuparte por qué herramienta usar y te pones a diseñar un bucle: dondequiera que estés sentado, seguirá funcionando.
Cinco elementos, y algunas aclaraciones
Un bucle necesita cinco cosas, más un lugar para recordar información. Primero las enumero y luego las relaciono.
Primero, Automations (Automatizaciones): Se disparan según un programa, descubren y priorizan automáticamente.
Segundo, Worktrees (Árboles de trabajo): Evitan que dos agentes trabajando en paralelo pisen los archivos del otro.
Tercero, Skills (Habilidades): Documentan el conocimiento del proyecto para que el agente no tenga que adivinar cada vez.
Cuarto, Plugins and connectors (Plugins y conectores): Permiten al agente conectarse a las herramientas que ya usas.
Quinto, Sub-agents (Subagentes): Uno propone soluciones, otro las revisa.
Y luego una sexta cosa: memory (memoria). Puede ser un archivo Markdown, un tablero de Linear, o cualquier lugar independiente de una conversación puntual que pueda guardar "cosas hechas" y "próximos pasos". Suena tan simple que parece poco importante, pero es el mismo truco del que depende todo agente de larga duración. También escribí en detalle sobre esto en long-running agents: el modelo olvida entre ejecuciones, así que la memoria debe estar en el disco, no en el contexto. El agente olvida, pero el repositorio de código no.
Ahora, ambos productos ya tienen estos cinco elementos.
Algunos nombres difieren, pero las capacidades son esencialmente las mismas. Explico cada una porque, sinceramente, los detalles son clave para que un bucle funcione de forma estable o empiece a tener fugas por todos lados.
Automations: El latido del bucle
Las Automations son lo que hace que un bucle sea realmente un bucle, y no una tarea única que ejecutaste manualmente una vez. En la aplicación Codex, puedes crear una automatización en la pestaña Automations, eligiendo el proyecto, el prompt que ejecutará, la frecuencia, y si se ejecuta en tu checkout local o en un worktree en segundo plano. Los resultados que detecten problemas van al Triage inbox (bandeja de priorización), y los que no detecten nada se archivan automáticamente, lo cual está bien. OpenAI también lo usa internamente para tareas aburridas pero necesarias, como la priorización diaria de issues, resumir fallos de CI, escribir resúmenes de commits, rastrear bugs introducidos la semana pasada. Las automatizaciones también pueden invocar skills, así puedes mantener mantenibles las tareas repetitivas: activas $nombre-skill, en lugar de pegar un muro de texto explicativo en una tarea programada que nadie actualizará nunca.
Claude Code logra lo mismo, pero por un camino diferente: mediante programación y hooks. Puedes usar /loop para ejecutar un prompt o comando a intervalos fijos, programar una tarea cron, o usar hooks para disparar comandos shell en ciertos puntos del ciclo de vida del agente. Si quieres que siga ejecutándose después de cerrar el portátil, puedes subir todo a GitHub Actions. La idea es exactamente la misma: defines una tarea autónoma, le das un ritmo, y haces que los hallazgos lleguen a ti, en lugar de que tú tengas que ir a revisar por todas partes.
También hay un primitivo dentro de la sesión que es más cercano al núcleo de lo que realmente se discute aquí. /loop se repite según un ritmo; /goal se ejecuta continuamente hasta que se cumple una condición que escribes. Después de cada ronda, un modelo pequeño por separado juzga si la tarea está completa, así que el agente que escribe código no es el que se califica a sí mismo. Puedes darle una condición como "todos los tests en test/auth pasan y el lint está limpio", e irte. Codex tiene la misma capacidad, también llamada /goal. Trabaja de forma continua a través de rondas hasta que se cumple una condición de parada verificable, y admite pausar, reanudar y limpiar. El mismo primitivo, en ambas herramientas. Este es básicamente el patrón que aparece una y otra vez en este artículo.
Así que las Automations se encargan de sacar el trabajo a la superficie. El resto del bucle se encarga de procesar ese trabajo.
Worktrees: Evitar que el paralelismo se convierta en caos
Una vez que ejecutas más de un agente, los conflictos de archivos se convierten en un punto de fallo. Dos agentes escribiendo en el mismo archivo simultáneamente es tan problemático como dos ingenieros modificando la misma línea de código sin comunicarse. Los git worktree solucionan esto. Son un directorio de trabajo separado en una rama independiente, pero que comparte el historial del mismo repositorio, por lo que los cambios de un agente físicamente no pueden tocar el checkout de otro.
Codex tiene soporte integrado directo para worktrees, así que múltiples hilos pueden trabajar en el mismo repositorio simultáneamente sin chocar. Claude Code también logra el mismo aislamiento mediante git worktree: puedes usar el flag --worktree para abrir una sesión en un checkout independiente, o configurar isolation: worktree en un subagent para que cada asistente menor obtenga un checkout nuevo y se limpie automáticamente al terminar. Escribí sobre el aspecto humano de esto en the orchestration tax: los worktrees eliminan conflictos a nivel mecánico, pero tú sigues siendo el límite. Lo que realmente determina cuántos agentes puedes ejecutar a la vez no es la herramienta, sino tu review bandwidth (capacidad de revisión).
Skills: Para no tener que reexplicar el proyecto cada vez
Un Skill es un mecanismo para no tener que reexplicar el mismo contexto del proyecto en cada sesión como si fueras un pez dorado. Ambas herramientas usan el mismo formato: una carpeta con un archivo SKILL.md que guarda la explicación y metadatos; además puede tener scripts opcionales, referencias y archivos de recursos. Codex ejecuta un skill cuando lo invocas con $ o /skills, y también lo ejecuta automáticamente si tu tarea coincide con su descripción. Por eso una descripción concisa y sencilla suele ser mejor que una descripción inteligente y sofisticada. Claude Code hace lo mismo, ya escribí sobre este patrón en agent skills.
Los Skills también son el lugar donde dejas de consumir tu intención una y otra vez. Como dije en intent debt, el agente arranca en frío en cada sesión, y cualquier hueco en tu intención lo llenará con conjeturas seguras. El Skill es escribir esa intención externamente: convenciones del proyecto, pasos de construcción, "no hacemos esto por aquel incidente pasado", etc., todo escrito una vez en un lugar que el agente leerá en cada ejecución. Sin skills, el bucle tiene que rededucir todo tu proyecto desde cero en cada ronda; con skills, es como si acumulara interés compuesto.
Hay que distinguir: un skill es un formato de escritura, un plugin es una forma de distribución. Cuando quieres compartir un skill entre múltiples repositorios, o empaquetar varios skills juntos, los encapsulas en un plugin. Así es en Codex, y así es en Claude Code.
Plugins and connectors: Que el bucle toque tus herramientas reales
Un bucle que solo ve el sistema de archivos es un bucle muy pequeño. Los Connectors, construidos sobre MCP, permiten al agente leer tu sistema de seguimiento de issues, consultar bases de datos, llamar a APIs de staging, o enviar mensajes en Slack. Tanto Codex como Claude Code soportan MCP, así que un connector que escribas para uno normalmente funcionará en el otro. Los Plugins empaquetan connectors y skills juntos, para que tus compañeros instalen la configuración completa de una vez, en lugar de reconstruirla de memoria.
Esta es la diferencia entre "un agente que te dice 'esta es la solución'" y "un bucle que abre un PR por sí mismo, vincula un ticket de Linear, y notifica al canal cuando pasa el CI". Los Connectors son importantes porque permiten al bucle actuar en tu entorno real, no solo decirte "si pudiera, lo haría".
Sub-agents: Separar al creador del verificador
En un bucle, el diseño estructural más útil es separar claramente a "quien escribe" de "quien revisa". El modelo que escribe código tiende a ser demasiado indulgente al calificar su propio trabajo. Otro agente con instrucciones diferentes, a veces incluso usando un modelo diferente, puede detectar problemas que el primer agente pasó por alto tras convencerse a sí mismo.
Codex solo genera subagents cuando se lo pides, estos se ejecutan en paralelo y luego fusionan los resultados en una respuesta. Puedes definir tus propios agents en archivos TOML en .codex/agents/: cada uno con nombre, descripción, instrucciones, y opcionalmente modelo e intensidad de razonamiento. Así, tu revisor de seguridad puede ser un modelo fuerte con alta intensidad de razonamiento, y tu explorador puede ser un modelo ligero, rápido y de solo lectura. Claude Code también tiene capacidades similares mediante subagents y agent teams en .claude/agents/, permitiendo que múltiples agentes pasen trabajo entre ellos. La división más común en ambos casos es: un agente explora, otro implementa, un tercero verifica contra las especificaciones.
He argumentado este punto dos veces: una en code agent orchestra, y otra en adversarial code review. Es especialmente importante en un bucle porque el bucle se ejecuta cuando no estás mirando, así que un verificador en el que realmente confíes es la única razón por la que te atreves a irte. Los Subagents sí consumen más tokens, porque cada agente hace sus propias llamadas al modelo y a herramientas, así que debes usarlos donde "una segunda opinión vale la pena pagar". Esto es básicamente lo que hace /goal de Claude Code en el fondo: un nuevo modelo juzga si el bucle está completo, en lugar de que lo juzgue el modelo que hizo el trabajo. Es decir, aplica la separación entre "creador" y "verificador" a la propia condición de parada.
Cómo es un bucle
Uniendo todo esto, un hilo individual se convierte en un pequeño panel de control. Esta es una estructura que uso a menudo.
Cada mañana, una automatización se ejecuta sobre el repositorio. Su prompt invoca un skill de priorización, lee los fallos de CI del día anterior, los issues abiertos, los commits recientes, y escribe los hallazgos en un archivo Markdown o un tablero de Linear. Para cada problema que valga la pena abordar, el hilo abre un worktree aislado, envía un sub-agent para bosquejar una solución, y luego envía un segundo sub-agent para revisar esa solución contra las skills del proyecto y los tests existentes.
Los Connectors permiten que este bucle abra PRs por sí mismo y actualice tickets. Cualquier cosa que el bucle no pueda manejar va a la bandeja de priorización (triage inbox) para que yo la gestione. El archivo de estado es la columna vertebral de todo el sistema: recuerda lo que se intentó, qué pasó, qué sigue pendiente. Así, la ejecución de la mañana siguiente continúa desde donde se detuvo hoy.
Fíjate en lo que realmente haces. Solo lo diseñas una vez. Esos pasos no los prompts tú personalmente uno a uno. Esta es la versión real de la frase de Steinberger. Y el mismo bucle puede ejecutarse en Codex o en Claude Code, porque los elementos son los mismos.
Lo que un bucle todavía NO hace por ti
El bucle cambia cómo trabajas, pero no te elimina del trabajo. De hecho, a medida que los bucles se vuelven más potentes, tres problemas se agudizan, no se facilitan.
La verificación aún depende de ti. Un bucle que se ejecuta sin supervisión también puede estar cometiendo errores sin supervisión. La razón por la que separas un sub-agent verificador del creador es para que la afirmación del bucle de "está completado" tenga algo de sentido. Aun así, "completado" es una afirmación, no una prueba. Sigo repitiendo lo mismo en code review in the age of AI: tu responsabilidad es entregar código que has confirmado que funciona.
Si lo descuidas, tu propia comprensión seguirá deteriorándose. Cuanto más rápido entregue el bucle código que no has escrito personalmente, más grande será la brecha entre lo que realmente entiendes y lo que realmente existe en el sistema. Esto es comprehension debt (deuda de comprensión). Si no lees lo que produce el bucle, un bucle fluido solo hará que esta deuda crezca más rápido.
Y sí, la postura más cómoda probablemente también sea la más peligrosa. Cuando el bucle puede ejecutarse solo, es fácil dejar de formar tu propio criterio y simplemente aceptar lo que sea que devuelva. A esto lo llamo cognitive surrender (rendición cognitiva). Si diseñas el bucle con criterio, es la cura; si lo diseñas para evitar pensar, es el acelerante. El mismo gesto, resultados completamente opuestos.
Construir bucles, pero seguir siendo ingeniero
Creo que esto presagia la dirección en la que evolucionará nuestro trabajo futuro. Dicho esto, si no reviso el código personalmente, o dependo completamente de bucles automatizados para arreglar código, la calidad de mi producto se verá perjudicada. Es probable que caiga en una espiral descendente: cavándome un hoyo cada vez más profundo.
Así que, por supuesto que puedes construir tus propios bucles, pero no olvides que dar prompts directamente a tu agente sigue siendo válido. La clave está en encontrar el equilibrio adecuado.
Los resultados del bucle también variarán según la persona. Dos personas pueden construir el mismo bucle y obtener resultados totalmente opuestos. Uno lo usa para acelerar un trabajo que comprende profundamente; el otro lo usa para evitar comprender el trabajo en sí. El bucle no conoce la diferencia entre ambos. Tú sí.
Por eso diseñar bucles (loop design) es más difícil que la ingeniería de prompts (prompt engineering), no más fácil. Lo que Cherny quiere decir no es que el trabajo se vuelva más fácil, sino que el punto de palanca se desplaza.
Construye bucles. Pero constrúyelos como alguien que todavía pretende ser ingeniero, no como alguien cuyo único trabajo es pulsar el botón de "inicio".
