<code-segment id="0" lang="text">
En junio de 2026, tres personas llegaron de forma independiente a la misma idea en una sola semana.
Peter Steinberger, creador de OpenClaw, dijo públicamente que deberías dejar de darle instrucciones a los agentes de código y empezar a diseñar los bucles que les dan esas instrucciones. Casi al mismo tiempo, Boris Cherny, quien lidera Claude Code en Anthropic, comentó que ya no le da instrucciones directamente a Claude, sino que tiene bucles ejecutándose que le indican a Claude qué hacer y determinan los pasos a seguir, y que su trabajo real es escribir esos bucles. Días después, Addy Osmani, ingeniero en Google, escribió el término y le puso nombre: ingeniería de bucles.
Ninguno de ellos inventó la práctica desde cero. Le pusieron nombre a algo que ya estaba sucediendo, porque las herramientas subyacentes habían cruzado silenciosamente un umbral. Los agentes de código se habían vuelto lo suficientemente confiables como para completar una tarea real sin supervisión. La programación se había vuelto lo suficientemente económica como para que ejecutar una tarea repetidamente, con un temporizador, dejara de parecer un desperdicio. El costo de una sola ejecución de un agente había bajado lo suficiente como para que intentar algo cinco veces costara menos que pensar cuidadosamente en ello una vez.
Ese umbral es la razón por la que existe esta hoja de ruta. Dar instrucciones era la habilidad cuando un ser humano necesitaba sentarse frente al teclado dirigiendo a un agente línea por línea. La ingeniería de bucles es la habilidad ahora que se le puede dar un objetivo a un agente y dejarlo trabajar. Este es el camino completo de 20 pasos de uno a otro, en orden, porque el orden importa más que cualquier paso individual.
Aquí está por qué el orden importa específicamente, antes de los pasos en sí. La ingeniería de bucles no es una habilidad única que se tiene o no se tiene. Es una pila, donde cada capa depende de que la capa inferior sea realmente sólida. Construir un disparador de programación, paso 14, antes de tener una condición de parada real, paso 10, solo significa que has automatizado un sistema que ahora puede desperdiciar dinero sin supervisión en lugar de solo mientras estás mirando. Construir persistencia, paso 11, antes de tener una verificación real, pasos 6 y 7, significa que estás registrando cuidadosamente las lecciones aprendidas de un Juez que podría estar aprobando resultados deficientes, lo que hace que la capa de persistencia sea activamente dañina en lugar de simplemente inútil. Saltar pasos en esta lista no solo significa perder una función. Significa construir las partes que parecen emocionantes sobre una base que en realidad no puede soportarlas, y descubrirlo solo cuando algo ya ha salido mal a gran escala.
Fase Uno: El Cambio Mental (Pasos 1 al 4)
Paso 1: Acepta Que Tú Eres El Cuello De Botella, No El Modelo
El primer paso real no es técnico. Es admitir que el factor limitante en tu flujo de trabajo actual no es la capacidad del modelo, sino tu propia presencia en el bucle. Cada vez que te sientas y esperas una respuesta, la lees y luego escribes la siguiente instrucción, eres la parte más lenta del sistema por un amplio margen. El modelo puede actuar, verificar y reintentar mucho más rápido de lo que tú puedes supervisarlo.
Este paso no tiene ninguna instrucción asociada. Es una decisión. Hasta que realmente creas esto, cada paso posterior se sentirá como una sobrecarga innecesaria en lugar de lo que es: eliminar el cuello de botella real.
Paso 2: Deja De Confundir Una Instrucción Más Larga Con Un Mejor Sistema
El instinto cuando algo sale mal es agregar otra instrucción al mismo mensaje. Con el paso de los meses, esto produce una instrucción que es un muro denso y contradictorio de reglas que el modelo ya no puede mantener en la memoria de trabajo al mismo tiempo, por lo que busca patrones según lo que parece más reciente y descarta silenciosamente el resto.
La ingeniería de bucles reemplaza este instinto por completo. En lugar de agregar otra regla a una instrucción, agregas otro componente a un sistema. Un paso de verificación. Un archivo de memoria. Un disparador programado. La instrucción en sí debería acortarse con el tiempo a medida que el sistema que la rodea se vuelve más capaz, no al revés.
Paso 3: Aprende A Ver Cada Tarea Como Cinco Movimientos
Cualquier turno único de un bucle, independientemente del dominio específico, se descompone en cinco movimientos. Descubrimiento, averiguar qué es lo que realmente necesita suceder. Transferencia, pasar la tarea a quien la ejecutará. Verificación, comprobar el resultado contra algo real. Persistencia, registrar lo que sucedió para que no se pierda. Programación, decidir cuándo se ejecuta esto de nuevo.
El flujo de trabajo actual de la mayoría de las personas solo tiene dos de estos movimientos explícitos, descubrimiento y transferencia, realizados manualmente, en una ventana de chat. Los otros tres o no existen o suceden de manera invisible en la propia cabeza de la persona. La ingeniería de bucles es la práctica de hacer que los cinco movimientos sean explícitos y automáticos.
Paso 4: Identifica Tu Primera Tarea Candidata Real
Antes de construir cualquier cosa, elige una tarea que ya hagas repetidamente, con un estándar que puedas escribir si te lo piden. No tu problema más difícil. No algo completamente novedoso. Una tarea con una definición de finalización real y reconocible, algo que un colega pueda mirar y estar de acuerdo de inmediato en que se completó correctamente o no. Esta restricción importa más de lo que parece. Una tarea sin una definición clara de finalización no puede tener construido el paso tres, verificación, y un bucle sin verificación real no es un bucle, es solo una suposición sin supervisión.
Fase Dos: Construyendo El Primer Bucle (Pasos 5 al 9)
Paso 5: Escribe La Definición De Finalización Antes De Escribir Cualquier Instrucción
Este es el paso que la mayoría de la gente omite y el que determina si todo lo que viene después funciona. Antes de escribir una sola instrucción para el agente, escribe, en lenguaje sencillo, exactamente cómo se ve un resultado correcto. Criterios específicos y verificables, no una vaga sensación de calidad.
DEFINICIÓN DE FINALIZACIÓN para [nombre de la tarea]:
- [Criterio específico y verificable 1]
- [Criterio específico y verificable 2]
- [Criterio específico y verificable 3] Esta tarea NO está finalizada si falta alguno de los anteriores, incluso si el resultado se ve completo o pulido.
Si no puedes completar esto para la tarea que elegiste, vuelve al paso 4 y elige una diferente.
Paso 6: Separa El Constructor Del Juez
La decisión arquitectónica más importante en cualquier bucle. El rol que produce el trabajo y el rol que verifica el trabajo deben estar separados, porque un modelo que revisa su propio resultado en el mismo momento en que lo produjo tiende a defender ese resultado en lugar de examinarlo genuinamente.
El Constructor tiene libertad creativa y produce un primer intento. El Juez recibe el resultado del Constructor más la definición de finalización del paso 5, y nada más que pueda persuadirlo. Idealmente, el Juez también tiene acceso a algo que el Constructor no tiene, un conjunto de pruebas, el documento fuente original, datos en vivo, para que su veredicto provenga de evidencia real, no solo de una segunda opinión formada de la misma manera que la primera.
Paso 7: Dale Al Juez Verdad Fundamental, No Solo Una Opinión
Un Juez que solo ve el resultado del Constructor puede decirte si parece coherente. No puede decirte si es realmente correcto. Para tareas de codificación, la verdad fundamental es el conjunto de pruebas y el resultado de la ejecución real. Para tareas de contenido, es el material fuente original y el resumen, lado a lado con el borrador. Para tareas de investigación, son los documentos reales que se suponía que debían usarse.
Si no puedes nombrar la verdad fundamental específica contra la que tu Juez verificará, tu bucle aún no tiene verificación real, sin importar cuán seguro suene el lenguaje del Juez.
Paso 8: Escribe El Formato De Transferencia Antes De Escribir La Instrucción De Transferencia
Tanto el resultado del Constructor como el veredicto del Juez necesitan una estructura definida, no prosa libre, o el Gestor en el siguiente paso no tiene nada confiable en lo que basarse.
RESULTADO DEL CONSTRUCTOR: entregable + confianza + incertidumbres conocidas
VEREDICTO DEL JUEZ: APROBADO / REPROBADO / NECESITA REVISIÓN + problemas específicos encontrados +
verdad fundamental contra la que se verificó esto
Paso 9: Ejecútalo Manualmente Una Vez, De Principio A Fin, Antes De Automatizar Cualquier Cosa
Antes de configurar la programación o los reintentos automáticos, ejecuta la secuencia completa de Constructor y luego Juez tú mismo, manualmente, una vez. Lee críticamente el veredicto del Juez. ¿Habrías estado de acuerdo con él? Si el Juez aprobó algo que sabes que está mal, o reprobó algo que en realidad estaba bien, corrige la verdad fundamental o los criterios antes de continuar. Automatizar un paso de verificación defectuoso solo produce resultados defectuosos más rápido.
Un Ejemplo Práctico De Los Pasos 5 Al 9
Para hacer concretos los últimos cinco pasos, aquí te mostramos cómo se desarrollan en una tarea real y común: convertir un documento fuente en bruto en una pieza de contenido terminada.
La definición de finalización, del paso 5: cada afirmación fáctica en el borrador se remonta a algo realmente presente en el documento fuente. El borrador cumple con todos los requisitos específicos del resumen, extensión, tono, estructura requerida. El argumento central sobrevive claramente, sin ser diluido por relleno.
El Constructor, del paso 6, recibe la fuente y el resumen y produce un borrador, junto con una declaración explícita de lo que no estaba seguro mientras escribía, un número del que no estaba completamente seguro de que estuviera en la fuente, una afirmación que infirió en lugar de encontrar expresamente establecida.
El Juez, del paso 7, recibe el borrador y la fuente original uno al lado del otro, nunca el borrador solo, y verifica cada uno de los tres criterios de definición de finalización por separado, devolviendo un aprobado o reprobado en cada uno individualmente en lugar de una puntuación general combinada. Colapsar tres verificaciones distintas en un solo veredicto oculta exactamente qué dimensión falló realmente, que es la forma más común en que un bucle funcional deja silenciosamente de dar retroalimentación útil.
El formato de transferencia, del paso 8, significa que el veredicto del Juez llega como un objeto estructurado, no un párrafo de prosa evasiva, tres resultados explícitos de aprobado o reprobado con una razón específica adjunta a cualquier falla.
Ejecutar esto manualmente una vez, según el paso 9, antes de automatizar cualquier cosa, es lo que detecta el caso en que tu Juez es demasiado indulgente, aprobando un borrador con una estadística inventada porque el estilo de escritura era pulido, o demasiado estricto, reprobando un borrador por una preferencia estilística que nunca estuvo realmente en el resumen. Ambos modos de falla son comunes en un primer intento, y ambos son mucho más baratos de detectar manualmente una vez que de descubrir después de que el bucle ya se haya ejecutado cincuenta veces sin supervisión.
Fase Tres: Agregando Las Piezas Faltantes Del Bucle (Pasos 10 al 14)
Paso 10: Construye El Gestor Y Su Condición De Parada
El Gestor lee el veredicto del Juez y decide qué sucede a continuación. Aquí es también donde reside la condición de parada del bucle, y debe escribirse como lógica dura, no como una instrucción suave que el modelo pueda eludir.
CONDICIONES DE PARADA:
Revisiones máximas: 3. En el tercer veredicto reprobado, escalar a un humano
con el historial completo, no intentar un cuarto ciclo.
Umbral de calidad: cada elemento de la definición de finalización debe mostrar APROBADO.
Límite de presupuesto: si esta tarea excede [X] costo o [Y] tiempo, detenerse
inmediatamente independientemente del estado actual.
Un bucle sin una condición de parada real no es un sistema. Es un pasivo que espera el día en que la tarea resulte ser genuinamente irresoluble. Vale la pena entender la razón específica por la que una instrucción suave falla aquí, no solo aceptarla. "Detente cuando sea lo suficientemente bueno" dentro de una instrucción es una sugerencia, y un modelo bajo suficiente presión, después de haber fallado varias revisiones, a menudo se convencerá a sí mismo de que el intento actual está lo suficientemente cerca para aprobar, precisamente porque quiere producir una resolución satisfactoria de la tarea. Un contador de iteraciones duro verificado mecánicamente por código, o por una regla explícita que el Gestor no puede eludir mediante el razonamiento, no tiene ese modo de falla.
Paso 11: Agrega Persistencia, Para Que El Bucle Recuerde Entre Ejecuciones
Un bucle que comienza desde cero cada vez que se ejecuta no tiene memoria de lo que aprendió la última vez. Agrega una capa de persistencia simple, un archivo por cada lección genuinamente nueva, con un resumen de una línea en la parte superior, registrando lo que se aprendió o corrigió y por qué era importante. Críticamente, solo registra lo que ya no está capturado en otro lugar, la memoria duplicada es ruido, no conocimiento.
La disciplina que hace que este paso funcione realmente a largo plazo es la moderación al momento de escribir. El instinto es registrar todo lo que sucedió en una sesión, lo que produce exactamente el problema de transcripción inflada contra el que esta hoja de ruta advirtió en el paso 2, solo que trasladado a una carpeta de memoria en lugar de a una instrucción. Una lección que vale la pena escribir es algo que costaría tiempo real redescubrir si se olvida, no un registro de trabajo rutinario que tuvo éxito exactamente como se esperaba.
Paso 12: Agrega Una Pasada De Consolidación En Un Horario
La persistencia por sí sola eventualmente produce el mismo problema que una instrucción inflada, docenas de archivos, muchos diciendo versiones ligeramente diferentes de la misma cosa. En un horario recurrente, semanal es razonable, revisa los archivos de memoria, fusiona duplicados en lecciones únicas y más precisas, y elimina cualquier cosa que desde entonces haya demostrado ser incorrecta. El objetivo es menos archivos con más densidad cada uno, no un montón cada vez más grande.
Este paso es el que la mayoría de la gente omite por completo, porque no produce ninguna nueva capacidad visible por sí solo, solo previene un problema futuro. Esa invisibilidad es exactamente por qué necesita ser programado explícitamente en lugar de dejarse para cuando alguien note que la carpeta de memoria se ha vuelto difícil de manejar, lo que en la práctica significa que nunca sucede hasta que el rendimiento del bucle ya ha comenzado a degradarse bajo el peso de lecciones contradictorias y semirrelevantes que compiten por la misma ventana de contexto.
Paso 13: Agrega El Paso De Recuperación
Al comienzo de cualquier nueva ejecución, haz que el bucle escanee los resúmenes de una línea en la memoria, identifique qué lecciones son realmente relevantes para la tarea actual y cargue solo esas. Indícale explícitamente que diga cuando nada en la memoria aplica, en lugar de forzar una lección pasada irrelevante a una nueva situación solo porque existe la memoria.
Paso 14: Agrega Un Disparador De Programación
Decide cuándo se ejecuta este bucle sin que lo inicies manualmente. Un trabajo cron. Un vigilante de archivos. Un disparador recurrente basado en calendario. Este es el paso que convierte un sistema que ejecutas bajo demanda en uno que se ejecuta mientras duermes, y suele ser el paso más fácil de toda esta lista, y el que la mayoría de la gente nunca se molesta en implementar incluso después de construir todo lo demás.
Fase Cuatro: Escalando Y Fortaleciendo (Pasos 15 al 18)
Paso 15: Prueba De Estrés El Bucle Antes De Confiar En Él
Antes de confiar en este bucle para cualquier cosa real, pruébalo deliberadamente contra cuatro modos de falla.
Dale una versión genuinamente irresoluble de la tarea y confirma que el Gestor realmente se detiene en lugar de repetir infinitamente, ya que un bucle que solo se prueba en tareas que puede completar nunca ha demostrado realmente que sabe cómo fallar con gracia.
Aliméntale al Juez un resultado que sabes que es sutilmente incorrecto, algo que se lee bien pero contiene un error fáctico o lógico específico que plantaste deliberadamente, y confirma que realmente detecta la falla en lugar de aprobar algo que suena plausible.
Si el Constructor y el Juez comparten el mismo modelo subyacente, aliméntale al Juez un error que ese modelo comete característicamente y mira si deja pasar el error, ya que un Juez que comparte los puntos ciegos del Constructor anula todo el propósito de la separación del paso 6.
Calcula el costo en el peor caso del bucle ejecutándose hasta su límite máximo de revisión, usando tus llamadas de modelo más caras y el resultado razonable más largo, y decide honestamente si ese número, que aparece en una factura real, te alarmaría.
Ejecutar estas cuatro pruebas antes de confiar en un bucle con cualquier cosa que importe detecta la gran mayoría de las fallas que de otra manera aparecerían por primera vez frente a un cliente, un jefe o tu propio estado de cuenta bancario, en lugar de en una prueba controlada que realizaste a propósito.
Paso 16: Enruta Las Tareas Al Modelo Correcto, No Al Mismo Todo El Tiempo
Una vez que un bucle funciona, resiste el hábito de ejecutar cada parte de él en tu único modelo favorito. El rol de Constructor generalmente se beneficia de tu modelo más capaz, ya que está haciendo el razonamiento difícil real y un modelo más débil aquí produce un primer borrador peor que cuesta más ciclos de revisión arreglar de lo que habría costado generarlo bien la primera vez.
El rol de Juez, verificando contra un estándar escrito específico, a menudo se desempeña igual de confiablemente en un modelo más pequeño, más barato y más rápido, ya que no se le pide que sea creativo, solo consistente, y un modelo más pequeño que verifica contra una lista de verificación extremadamente bien especificada frecuentemente iguala a uno más grande a una fracción del costo y la latencia.
El Gestor, enrutando según reglas que ya escribiste, casi nunca necesita tu modelo más caro, ya que su trabajo es ejecutar lógica que ya especificaste, no razonamiento abierto, y se ejecuta al menos una vez por iteración independientemente de cómo se desempeñen el Constructor y el Juez, lo que hace que su costo por llamada importe más que su capacidad bruta.
Este enfoque escalonado, modelo caro para construir, modelo barato y consistente para juzgar verificaciones rutinarias, modelo barato para enrutar, suele ser de donde provienen los ahorros de costos reales en un bucle. La mayoría de la gente asume que el control de costos significa menos bucles o menos revisiones. En realidad, proviene de igualar el costo del modelo con la dificultad real de cada rol específico dentro del bucle que ya construiste.
Paso 17: Expande A Un Segundo Bucle, No A Cinco A La Vez
La tentación una vez que el primer bucle funciona es construir varios más de inmediato, abordando cinco tareas diferentes en paralelo porque la arquitectura técnicamente lo soporta ahora. Resiste esto más tiempo del que te sientas cómodo. Haz que un bucle funcione lo suficientemente confiable como para que hayas realmente dejado de revisar su resultado de cerca, lo que significa que pasa consistentemente tus propias verificaciones puntuales manuales durante un período de tiempo real, no solo una única demostración exitosa que todos observaron de cerca. Solo entonces comienza el segundo bucle, en una tarea diferente, idealmente una que se mapee a algo completamente diferente de la primera, para que estés probando si el esqueleto subyacente se generaliza en lugar de solo ajustar la misma tarea aún más.
Paso 18: Date Una Vista Compartida De Todos Los Bucles En Ejecución
Una vez que tengas más de un bucle ejecutándose, rastrea una vista compartida del costo y los disparadores de condición de parada en todos ellos, no por bucle de forma aislada. Un solo bucle con un presupuesto razonable por tarea se ve completamente bien por sí solo. Diez bucles, cada uno individualmente dentro del presupuesto, aún pueden sumar un total alarmante que nadie nota hasta que llega la factura agregada, precisamente porque el seguimiento de cada bucle individual se veía bien de forma aislada.
Registra cada disparador de condición de parada específicamente, no solo las finalizaciones exitosas. Un bucle que alcanza su límite de revisiones constantemente, mientras que otros rara vez lo hacen, te está diciendo que el estándar de su Juez está mal calibrado, es demasiado estricto para aprobar realmente, o está verificando contra la verdad fundamental incorrecta por completo, no que la tarea subyacente sea simplemente difícil. Ese patrón es invisible si solo estás rastreando éxitos y tratando cada escalada como un evento aislado y sin importancia en lugar de un punto de datos sobre el diseño de ese bucle específico.
Fase Cinco: Convirtiéndote En Un Diseñador De Sistemas (Pasos 19 y 20)
Paso 19: Deja De Medirte Por Las Instrucciones Escritas
La señal más clara de que el cambio realmente ha ocurrido es un cambio en lo que prestas atención día a día. Un instructor rastrea cuántas buenas instrucciones escribió. Un diseñador de sistemas rastrea cuántos bucles están funcionando, qué tan confiable es cada uno y cuánto de su propio tiempo le fue devuelto por sistemas que ya no necesitan supervisión. Si todavía estás midiendo tu propia productividad en instrucciones escritas, el cambio mental del paso uno no se ha asentado completamente todavía, independientemente de cuántos bucles hayas construido técnicamente.
Paso 20: Enséñale A Alguien Más Los Cinco Movimientos
El paso final ya no se trata realmente de tus propios sistemas. Se trata de confirmar que realmente internalizaste el cambio explicándoselo a otra persona sin recurrir a jerga. Descubrimiento, transferencia, verificación, persistencia, programación. Si puedes guiar a otra persona a través de la construcción de su propio primer bucle usando solo esos cinco movimientos y los pasos anteriores, has hecho la transición real que describe esta hoja de ruta. Ya no eres la persona dentro del bucle, escribiendo la siguiente instrucción. Eres la persona que lo diseñó, parada afuera, observándolo ejecutarse.
Los Cuatro Costos Que Se Acumulan Silenciosamente Si Omitas Pasos
Vale la pena cerrar con una advertencia, ya que saltarse pasos en esta hoja de ruta no falla ruidosamente, falla silenciosamente, de maneras que solo se muestran mucho más tarde.
La deuda de verificación se acumula cuando omites los pasos 6 y 7, construyendo bucles sin un Juez real o sin verdad fundamental real. El bucle parece que está funcionando porque el resultado se ve bien, justo hasta que un error se compone silenciosamente a lo largo de docenas de ejecuciones antes de que alguien lo note.
La podredumbre de comprensión se instala cuando omites el paso 20, ejecutando bucles que construiste una vez pero que ya no podrías explicar o depurar si se rompieran, porque nunca tuviste que internalizar por qué existía cada pieza.
La rendición cognitiva ocurre cuando el paso 1 nunca realmente se asienta, cuando sigues verificando manualmente cada resultado por costumbre mucho después de que el sistema de verificación ya se ha demostrado a sí mismo, derrotando todo el propósito de construir el sistema en primer lugar.
La explosión de tokens es lo que sucede cuando omites el paso 10, ejecutando bucles sin una condición de parada real, descubriendo el costo real solo cuando llega la factura.
Cada uno de estos costos es evitable, y cada uno de ellos se evita con la misma disciplina. Construye los pasos en orden. No omitas los que parecen poco glamorosos. Los pasos aburridos, la definición de finalización, la condición de parada, la verdad fundamental, son los que realmente están haciendo el trabajo. Las partes que suenan interesantes, la instrucción inteligente, el diagrama de arquitectura elaborado, importan mucho menos que si el sistema que construiste realmente sabe cuándo está correcto, cuándo está incorrecto y cuándo detenerse.
Esa es toda la distinción entre un instructor y un diseñador de sistemas. No es inteligencia. Es disciplina sobre las partes que son aburridas de construir y fáciles de omitir.
Sigue a @cyrilXBT para las plantillas de bucle exactas y las configuraciones de Constructor-Juez-Gestor detrás de cada paso en esta hoja de ruta.
</code-segment>
