Loop Engineering.
Autor original: Addy Osmani
Compilado por: Peggy, BlockBeats

Editorial note: The way AI coding agents are used is shifting from “humans manually writing prompts and advancing tasks step by step” to “humans designing loops that allow the system to continuously schedule agents.” Loop Engineering, as described by Addy Osmani, centers on building a workflow that automatically discovers tasks, assigns them, checks results, tracks progress, and determines the next steps.

Este ciclo consta aproximadamente de cinco módulos: Automations (detección y triaje programados de tareas), Worktrees (aislamiento de múltiples entornos de desarrollo en paralelo), Skills (acumulación de conocimientos del proyecto y prácticas del equipo), Plugins/Connectors (integración con herramientas reales como GitHub, Linear, Slack, bases de datos, etc.) y Sub-agents (separación entre ejecutores y revisores), además de una capa externa de memoria, como archivos Markdown o tableros de Linear, para guardar el estado y el progreso.

El artículo señala que el significado de Loop Engineering no es simplemente «hacer que la IA ejecute más rondas», sino integrar el juicio del ingeniero en el diseño del sistema desde el principio. Los bucles pueden amplificar significativamente la eficacia del desarrollador, pero no reemplazan la validación, la comprensión ni el juicio. El verdadero riesgo no radica en usar bucles, sino en utilizarlos como excusa para evitar comprender el código y el sistema. La capacidad clave para colaborar con la IA en la programación del futuro quizás ya no sea simplemente escribir un buen prompt, sino diseñar flujos de trabajo de Agentes confiables, verificables y sostenibles.

The following is the original text:

Loop engineering (ingeniería de bucle) está reemplazando tu rol como «persona que escribe prompts para agentes». Debes diseñar un sistema que le dé prompts al agente en tu lugar. Aquí, el bucle puede entenderse como un objetivo recursivo: defines un propósito, y la IA itera continuamente hasta completar la tarea. Está compuesto aproximadamente por cinco componentes, y Claude Code y Codex ya poseen ahora estos cinco componentes.

Creo que esta podría ser la forma en que colaboraremos con agentes de codificación en el futuro. Sin embargo, todo esto aún está en sus primeras etapas, y yo mantengo cierta escepticismo. Es absolutamente necesario tener cuidado con los costos de tokens, ya que las diferencias pueden ser enormes según el modelo de uso, especialmente si eres «rico en tokens» o «tensos en tokens». También necesitas algún mecanismo para asegurar que la calidad no disminuya. Las preocupaciones sobre la «producción de basura de IA» (slop) son también razonables. Dicho esto, veamos qué está pasando realmente.

@steipete dijo recientemente: «Ya no deberías escribir prompts para agentes de codificación. Debes diseñar ciclos que hagan que estos ciclos den prompts a tus agentes». De manera similar, @bcherny, responsable de Claude Code de Anthropic, también dijo: «Ya no le doy prompts a Claude. Tengo un conjunto de ciclos en ejecución que le dan prompts a Claude y deciden por sí mismos qué hacer a continuación. Mi trabajo es escribir ciclos».

Entonces, ¿qué significa esto?

Durante los últimos dos años aproximadamente, lo que querías hacer con un agente de codificación era básicamente escribir una buena indicación y proporcionar suficiente contexto. Ingresabas una oración, leías el resultado devuelto y luego ingresabas la siguiente oración. El agente era una herramienta, y tú siempre mantenías esa herramienta en tus manos, empujándola ronda tras ronda. Esta fase ha terminado en cierto sentido, al menos algunos creen que está a punto de terminar.

Ahora estás construyendo un pequeño sistema: que descubre tareas por sí mismo, asigna trabajos, verifica resultados, registra su finalización y decide qué hacer a continuación. Es decir, permites que este sistema impulse los agentes en lugar de tener que indicarles repetidamente tú mismo. Anteriormente escribí sobre su «pariente cercano»: la ingeniería de agent harness (ingeniería del marco de ejecución de agentes), que consiste en crear el entorno de ejecución para un solo agente; y el modelo fábrica (factory model), que es el sistema para construir software. La ingeniería Loop se sitúa un nivel por encima del harness. Es como un harness, pero se ejecuta según un temporizador, genera asistentes pequeños y se autoalimenta.

Lo que me sorprendió es que esto ya no es solo un problema a nivel de herramientas. Hace un año, si querías un loop, tenías que escribir una gran cantidad de scripts en bash y mantenerlos para siempre. Eso era algo tuyo, y solo tuyo. Ahora, estos componentes ya están integrados directamente en el producto. Las capacidades enumeradas por Steinberger se pueden mapear casi una a una en la aplicación Codex, y también casi de la misma manera en Claude Code. Una vez que te das cuenta de que su forma es la misma, ya no te preocuparás por qué herramienta usar, sino que diseñarás un loop: independientemente de en qué herramienta te sientes, seguirá funcionando.

Cinco componentes, así como algunas explicaciones

Un loop necesita cinco cosas, más un lugar para recordar información. Primero las enumero, luego las correspondí.

Primero, Automations (tareas automatizadas): se activan según programación y realizan automáticamente el descubrimiento y la derivación.

En segundo lugar, Worktrees (árboles de trabajo): permiten que dos agentes que trabajan en paralelo no se interrumpan entre sí con sus archivos.

Tercero, Skills (habilidades): Escriba el conocimiento del proyecto para evitar que el agente tenga que adivinar cada vez.

Cuarta, Plugins and connectors (插件和连接器): permite que el agente se conecte a las herramientas que ya estás utilizando.

Quinto, sub-agentes: uno responsable de proponer soluciones y otro de revisarlas.

Luego viene lo sexto: memory (memoria). Puede ser un archivo Markdown, un tablero de Linear o cualquier lugar independiente de la conversación individual que guarde los «elementos completados» y los «próximos pasos». Suena tan simple que parece insignificante, pero es la misma técnica en la que confían todos los agentes de larga duración. También lo escribí detalladamente en agentes de larga duración: el modelo olvida entre cada ejecución, por lo que la memoria debe guardarse en el disco, no en el contexto. El agente olvida, pero el repositorio de código no.

Ahora, ambos productos ya cuentan con estos cinco componentes.

Sus nombres varían en algunos aspectos, pero sus capacidades son esencialmente lo mismo. A continuación, los explicaré uno por uno, porque, francamente, lo que determina si un bucle funciona de manera estable o está filtrándose silenciosamente por todas partes son los detalles.

Las automatizaciones son lo que convierte a loop en un verdadero loop, en lugar de una tarea única que ejecutaste manualmente una vez. En la aplicación Codex, puedes crear una automatización en la pestaña Automations, seleccionando el proyecto, la instrucción que debe ejecutar, la frecuencia de ejecución y si debe correr en tu checkout local o en un worktree en segundo plano. Los resultados de las ejecuciones que detectan problemas se envían al buzón de Triage, mientras que las ejecuciones sin problemas se archivan automáticamente, lo cual es muy útil. OpenAI también lo utiliza internamente para tareas repetitivas pero necesarias, como el desglose diario de issues, la resumen de causas de fallos en CI, la redacción de boletines de commit y el seguimiento de bugs introducidos la semana pasada. Las automatizaciones también pueden invocar skills, por lo que puedes mantener tareas recurrentes fácilmente mantenibles: activa $skill-name en lugar de pegar una pared entera de instrucciones en una tarea programada que nadie actualizará jamás.

Claude Code también puede lograr el mismo efecto, solo que con un camino diferente: lo logra mediante programación y hooks. Puedes ejecutar un prompt o comando a intervalos fijos usando /loop, programar una tarea cron o activar comandos shell en ciertos puntos del ciclo de vida del agente mediante hooks. Si deseas que continúe ejecutándose después de cerrar tu computadora, también puedes implementar todo el sistema en GitHub Actions. La idea es exactamente la misma: defines una tarea autónoma, le das un ritmo y permites que los resultados lleguen a ti, en lugar de tener que buscarlos tú mismo.

Otro primitivo dentro de la sesión que es más cercano al núcleo verdadero de este artículo es /loop, que se ejecuta repetidamente según un ritmo; /goal, en cambio, se ejecuta continuamente hasta que alguna condición que hayas especificado se cumpla realmente. Después de cada ciclo, un pequeño modelo independiente evalúa si la tarea se ha completado, por lo que el agente que escribe el 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 es limpio», y luego irte. Codex también tiene la misma capacidad, llamada igualmente /goal. Funciona de forma continua a través de ciclos hasta que se cumple una condición de parada verificable, y admite pausa, reanudación y limpieza. El mismo primitivo está presente en ambas herramientas. Este es básicamente el patrón que aparece una y otra vez en este artículo.

Entonces, Automations se encarga de hacer visible el trabajo; el resto del bucle se encarga de procesarlo.

Cuando ejecutas más de un agente, los conflictos de archivos se convierten en puntos de fallo. Dos agentes que escriben simultáneamente en el mismo archivo es tan problemático como dos ingenieros que modifican la misma línea de código sin comunicarse. Git worktree resuelve este problema. Es un directorio de trabajo independiente en una rama separada, pero comparte el mismo historial del repositorio de código, por lo que los cambios de un agente no pueden tocar físicamente el checkout de otro agente.

Codex incorpora directamente el soporte de worktree, por lo que múltiples hilos pueden procesar simultáneamente el mismo repositorio sin interferencias. Claude Code también puede lograr la misma aislación mediante git worktree: puedes abrir una sesión en un checkout independiente con la bandera --worktree, o configurar isolation: worktree en los subagentes para que cada asistente obtenga un checkout completamente nuevo y se limpie automáticamente al finalizar. Ya escribí sobre el lado humano del costo de orquestación: los worktrees eliminan conflictos mecánicos, pero tú sigues siendo el límite. Lo que realmente determina cuántos agentes puedes ejecutar simultáneamente no son las herramientas, sino tu ancho de banda de revisión.

Skill es un mecanismo que te permite evitar explicar nuevamente el mismo contexto de proyectos en cada sesión, como si fueras un pez dorado. Ambas herramientas utilizan el mismo formato: una carpeta que contiene un archivo SKILL.md con instrucciones y metadatos; además, pueden incluirse scripts opcionales, referencias y archivos de recursos. Codex ejecutará un skill cuando lo llames con $ o /skills, y también lo ejecutará automáticamente cuando tu tarea coincida con la descripción del skill. Por eso, una descripción concisa y sencilla suele ser mejor que una descripción inteligente pero elaborada. Claude Code sigue el mismo enfoque; ya escribí sobre este patrón en agent skills.

Las habilidades también son el lugar donde evitas que las intenciones consuman una y otra vez tu energía. Ya mencioné en la deuda de intención que cada sesión de un agente comienza en frío; siempre que haya espacios en blanco en tus intenciones, el agente los llenará con suposiciones seguras. Las habilidades consisten en escribir estas intenciones externamente: acuerdos del proyecto, pasos de construcción, «no lo hacemos así porque ocurrió ese accidente antes», etc., todo en un solo lugar que el agente lee cada vez que se ejecuta. Sin habilidades, cada ciclo debe volver a derivar todo tu proyecto desde cero; con habilidades, es como si estuvieras obteniendo interés compuesto.

Hay que aclarar un punto: skill es el formato de escritura, mientras que plugin es el método de distribución. Cuando deseas compartir un skill entre varios repositorios de código o empaquetar varios skills juntos, los encapsulas como un plugin. Así lo hace Codex, y así lo hace Claude Code.

Un loop que solo puede ver el sistema de archivos es un loop muy pequeño. Los conectores, construidos sobre MCP, permiten a los agentes leer tu seguimiento de incidencias, consultar bases de datos, llamar a APIs de staging o enviar mensajes en Slack. Codex y Claude Code admiten MCP, por lo que un conector que escribas para uno generalmente también funcionará en el otro. Los plugins empaquetan conectores y habilidades juntos, para que tus compañeros puedan instalar toda la configuración de una sola vez, en lugar de tener que reconstruirla de memoria.

Esta es la diferencia entre «un agente te dice 'esta es la solución de reparación'» y «un bucle abre automáticamente una PR, vincula un ticket de Linear y notifica al canal una vez que la CI pase». Los conectores son importantes porque permiten que el bucle actúe en tu entorno real, en lugar de solo decirte 'si pudiera hacerlo, lo haría'.

Dentro de un bucle, el diseño estructural más útil es separar claramente a la persona que escribe de la que revisa. Los modelos que escriben código tienden a ser demasiado indulgentes al calificar su propio trabajo. Un agente con instrucciones diferentes, e incluso a veces utilizando un modelo distinto, puede detectar problemas que el primer agente ignora tras autoconvencerse.

Codex solo generará subagents cuando lo solicites; estos se ejecutarán en paralelo y luego combinarán los resultados en una única respuesta. Puedes definir tus propios agents mediante archivos TOML en .codex/agents/: cada agent tiene un nombre, una descripción, instrucciones, y un modelo y intensidad de razonamiento opcionales. Por lo tanto, tu revisor de seguridad puede ser un modelo potente con alta intensidad de razonamiento, mientras que tu explorador puede ser un modelo ligero, rápido y solo de lectura. Claude Code también logra una capacidad similar mediante subagents y equipos de agents en .claude/agents/, permitiendo que múltiples agents se transfieran el trabajo entre sí. La división más común en ambos casos es: un agent explora, un agent implementa y un agent valida según las especificaciones.

He planteado esta idea dos veces: una vez en code agent orchestra y otra en adversarial code review. Es especialmente importante dentro del loop, porque el loop se ejecuta cuando no estás mirando, por lo que un verifier (verificador) en quien realmente confías es la única razón por la que puedes permitirte alejarte. Los subagents realmente consumen más tokens, ya que cada agent realiza sus propias llamadas al modelo y llamadas a herramientas, por lo que debes utilizarlos en situaciones donde una «segunda opinión merece la pena pagar». Esto es esencialmente lo que hace /goal de Claude Code en su nivel más profundo: un nuevo modelo evalúa si el loop ha terminado, en lugar de dejar que el mismo modelo que realizó el trabajo lo determine. Es decir, aplica la separación entre «creador» y «revisor» directamente a la condición de finalización.

¿Cómo se ve un loop?

Juntar estas cosas, un solo hilo se convierte en un pequeño panel de control. A continuación, la estructura que uso con frecuencia.

Cada mañana, una automatización se ejecuta en el repositorio de código. Su prompt invoca una habilidad de triage que lee los fallos de CI del día anterior, los issues abiertos y los commits recientes, y registra los hallazgos en un archivo Markdown o en un tablero de Linear. Para cada problema que merezca atención, el hilo abre un worktree aislado, asigna un sub-agente para redactar una solución y luego asigna un segundo sub-agente para revisar la solución según las habilidades del proyecto y las pruebas existentes.

Los conectores permiten que este loop abra automáticamente un PR y actualice el ticket. Cualquier cosa que el loop no pueda manejar se enviará al buzón de triage para que yo la procese. El archivo de estado es la columna vertebral del sistema completo: registra qué se ha intentado, qué ha pasado y qué aún queda pendiente. Por lo tanto, la ejecución de la mañana siguiente continuará desde donde se detuvo hoy.

Ten en cuenta lo que realmente hiciste. Solo diseñaste una vez. Esos pasos no los indicaste manualmente uno por uno. Esta es la versión real de la frase de Steinberger. Y el mismo loop puede ejecutarse en Codex o en Claude Code, porque los componentes son los mismos.

Loop aún no hará nada por ti

Loop cambió la forma de funcionar, pero no te eliminará del trabajo. De hecho, a medida que loop se vuelve más fuerte, tres problemas se vuelven más agudos, no más fáciles.

La verificación sigue dependiendo de ti. Un bucle que se ejecuta sin supervisión también podría estar cometiendo errores sin supervisión. La razón por la que separaste al sub-agente verificador y al maker es para que la frase del bucle «completado» tenga algún significado. Incluso así, «completado» sigue siendo una afirmación, no una prueba. He repetido una y otra vez en «code review in the age of AI» la misma frase: tu responsabilidad es entregar código que hayas confirmado que funciona.

Si lo dejas pasar, tu propia comprensión seguirá deteriorándose. Cuanto más rápido Loop te entregue código que no escribiste tú mismo, mayor será la brecha entre lo que realmente entiendes y lo que realmente existe en el sistema. Esto es lo que se llama deuda de comprensión. Si no lees lo que produce Loop, 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 un loop puede funcionar por sí solo, es fácil dejar de formar tus propios juicios y simplemente aceptar cualquier cosa que devuelva. Llamo a esto "cognitive surrender" (rendición cognitiva). Si diseñas un loop con juicio, es la cura; si diseñas un loop solo para evadir el pensamiento, es un acelerador. El mismo gesto puede producir resultados completamente opuestos.

Construye un loop, pero sigue siendo ingeniero

Creo que esto predice la evolución futura de nuestro trabajo. Sin embargo, si no reviso personalmente el código o confío completamente en un bucle automatizado para arreglarlo, mi calidad de producto se verá afectada. Es muy probable que caiga en una espiral descendente: seguir cavando hoyos más profundos.

Entonces, por supuesto puedes crear tu propio bucle, pero no olvides que indicar directamente a tu agente sigue siendo efectivo. Lo clave es encontrar el equilibrio adecuado.

Los resultados del Loop también variarán según la persona. Dos personas pueden construir el mismo loop exactamente, pero obtener resultados completamente opuestos. Una lo usa para acelerar su trabajo en algo que comprende profundamente; otra lo usa para evitar comprender el trabajo en sí. El Loop no conoce la diferencia entre ambos. Tú sí la conoces.

Por eso el loop design (diseño de bucle) es más difícil que el prompt engineering (ingeniería de prompts), no más sencillo. Cherny no quiso decir que el trabajo se volvió más fácil, sino que el punto de palanca cambió.

Construye el bucle. Pero constrúyelo como alguien que aún planea ser ingeniero, no como alguien que solo se encarga de presionar el botón de «iniciar».

[Enlace original]

Haz clic para conocer los puestos disponibles en BlockBeats

¡Bienvenido a la comunidad oficial de律动 BlockBeats!

Grupo de suscripción de Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia