INGENIERÍA DE BUCLES: EL CAMINO DE 20 PASOS DE PROMPTER A DISEÑADOR DE SISTEMAS

En junio de 2026, tres personas llegaron de forma independiente a la misma idea en una sola semana.

Peter Steinberger, el creador de OpenClaw, dijo públicamente que deberías dejar de dar instrucciones a los agentes de codificación y empezar a diseñar los bucles que les dan instrucciones. Casi al mismo tiempo, Boris Cherny, quien lidera Claude Code en Anthropic, dijo que ya no le da instrucciones directamente a Claude: tiene bucles ejecutándose que le dan instrucciones a Claude y deciden qué hacer, y su trabajo real es escribir 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 de la nada. Nombraron algo que ya estaba sucediendo, porque las herramientas subyacentes habían cruzado silenciosamente un umbral. Los agentes de codificación 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 barata como para que ejecutar una tarea repetidamente, con un temporizador, dejara de parecer un desperdicio. El costo de una sola ejecución del 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. El prompting era la habilidad cuando un 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 el agente puede recibir un objetivo y dejarse ejecutar. Este es el camino completo de 20 pasos de uno a otro, en orden, porque el orden importa más que cualquier paso individual.

He aquí 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 de abajo 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 malos resultados sin criterio, lo que hace que la capa de persistencia sea activamente dañina en lugar de meramente inútil. Saltar adelante en esta lista no solo significa perder una característica. Significa construir las partes que parecen emocionantes sobre una base que en realidad no puede sostenerlas, y descubrir eso solo cuando algo ya ha salido mal a escala.

Fase Uno: El Cambio Mental (Pasos 1 a 4)

Paso 1: Acepta que 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 ningún prompt asociado. 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 un prompt más largo con un mejor sistema

El instinto cuando algo sale mal es agregar otra instrucción al mismo prompt. Con el paso de los meses, esto produce un prompt que es un muro denso y contradictorio de reglas que el modelo ya no puede mantener en su memoria de trabajo a la vez, por lo que se ajusta al patrón 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 un prompt, agregas otro componente a un sistema. Un paso de verificación. Un archivo de memoria. Un disparador programado. El prompt en sí debería acortarse con el tiempo a medida que el sistema que lo rodea se vuelve más capaz, no al revés.

Paso 3: Aprende a ver cada tarea como cinco movimientos

Cualquier turno individual de un bucle, independientemente del dominio específico, se descompone en cinco movimientos. Descubrimiento: averiguar qué es lo que realmente debe 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 forma invisible en la 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 pidieran. No tu problema más difícil. No algo completamente novedoso. Una tarea con una definición de hecho real y reconocible, algo que un colega pudiera mirar y acordar de inmediato si se completó correctamente o no. Esta restricción importa más de lo que parece. Una tarea sin una definición clara de hecho no puede tener el paso tres, verificación, construido para ella, 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 a 9)

Paso 5: Escribe la definición de hecho antes de escribir cualquier prompt

Este es el paso que la mayoría de la gente se salta 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 HECHO 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á hecha si falta alguno de los anteriores, incluso si el resultado parece completo o pulido.

Si no puedes completar esto para la tarea elegida, vuelve al paso 4 y elige otra.

Paso 6: Separa al 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 acto 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 hecho del paso 5, y nada más que necesite ser convencido de lo contrario. 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 ejecución real. Para tareas de contenido, es el material fuente original y el briefing, 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 lo seguro que suene el lenguaje del Juez.

Paso 8: Escribe el formato de transferencia antes de escribir el prompt de transferencia

El resultado del Constructor y 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 para enrutar.

RESULTADO DEL CONSTRUCTOR: entregable + confianza + incertidumbres conocidas

VEREDICTO DEL JUEZ: PASAR / FALLAR / NECESITA REVISIÓN + problemas específicos encontrados +

contra qué verdad fundamental se verificó

Paso 9: Ejecútalo manualmente una vez, completamente, antes de automatizar cualquier cosa

Antes de conectar la programación o los reintentos automáticos, ejecuta la secuencia completa de Constructor y luego Juez tú mismo, a mano, una vez. Lee el veredicto del Juez críticamente. ¿Estarías de acuerdo con él? Si el Juez aprobó algo que sabes que está mal, o falló algo que en realidad estaba bien, corrige la verdad fundamental o los criterios antes de continuar. Automatizar un paso de verificación roto solo produce resultados rotos más rápido.

Un ejemplo práctico a través de los pasos 5 a 9

Para hacer concretos los últimos cinco pasos, aquí se muestra cómo se desarrollan en una tarea real y común: convertir un documento fuente en bruto en un contenido terminado.

La definición de hecho, del paso 5: cada afirmación factual en el borrador se remonta a algo realmente presente en el documento fuente. El borrador satisface todos los requisitos específicos del briefing: 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 briefing y produce un borrador, junto con una declaración explícita de qué 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 explícitamente.

El Juez, del paso 7, recibe el borrador y la fuente original lado a lado, nunca el borrador solo, y verifica cada uno de los tres criterios de la definición de hecho por separado, devolviendo un aprobado o fallo 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 de dar retroalimentación útil silenciosamente.

El formato de transferencia, del paso 8, significa que el veredicto del Juez llega como un objeto estructurado, no como un párrafo de prosa evasiva: tres resultados explícitos de aprobado o fallo con una razón específica adjunta a cualquier fallo.

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 fabricada porque el estilo de escritura era pulido, o demasiado estricto, fallando un borrador por una preferencia estilística que nunca estuvo realmente en el briefing. Ambos modos de fallo 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 a 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í también reside la condición de parada del bucle, y debe escribirse como lógica estricta, no como una instrucción blanda que el modelo pueda eludir.

CONDICIONES DE PARADA:

Revisiones máximas: 3. En el tercer veredicto fallido, escalar a un humano

con el historial completo, no intentar un cuarto ciclo.

Umbral de calidad: cada elemento de la definición de hecho 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. La razón específica por la que una instrucción blanda falla aquí vale la pena entenderla, no solo aceptarla. "Detente cuando sea lo suficientemente bueno" dentro de un prompt es una sugerencia, y un modelo bajo suficiente presión, habiendo fallado ya varias revisiones, a menudo se convencerá a sí mismo de que el intento actual es lo suficientemente cercano 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 pueda eludir mediante razonamiento, no tiene ese modo de fallo.

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 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 no está ya capturado en otro lado: la memoria duplicada es ruido, no conocimiento.

La disciplina que hace que este paso funcione realmente a largo plazo es la moderación al 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 un prompt. Una lección que vale la pena escribir es algo que costaría tiempo real redescubrir si se olvidara, 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 sola eventualmente produce el mismo problema que un prompt inflado: docenas de archivos, muchos diciendo versiones ligeramente diferentes de lo mismo. En un horario recurrente, semanal es razonable, revisa los archivos de memoria, fusiona los duplicados en lecciones únicas y más precisas, y elimina cualquier cosa que desde entonces haya resultado incorrecta. El objetivo es menos archivos con más densidad cada uno, no un montón cada vez mayor.

Este paso es el que la mayoría de la gente se salta por completo, porque no produce ninguna capacidad nueva 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 semirelevantes 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 a encajar una lección pasada irrelevante en una nueva situación solo porque la memoria existe.

Paso 14: Agrega un disparador de programación

Decide cuándo se ejecuta este bucle sin que lo inicies manualmente. Una tarea cron. Un observador 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 haber construido todo lo demás.

Fase Cuatro: Escalando y Fortaleciendo (Pasos 15 a 18)

Paso 15: Prueba de esfuerzo del bucle antes de confiar en él

Antes de confiar en este bucle para algo real, pruébalo deliberadamente contra cuatro modos de fallo.

Dale una versión genuinamente irresoluble de la tarea y confirma que el Gestor realmente se detiene en lugar de entrar en un bucle infinito, ya que un bucle que solo se prueba en tareas que puede completar nunca ha demostrado realmente que sabe cómo fallar con elegancia.

Alimenta al Juez un resultado que sabes que es sutilmente incorrecto, algo que se lee bien pero contiene un error factual o lógico específico que plantaste deliberadamente, y confirma que realmente detecta el defecto en lugar de aprobar algo que suena plausible.

Si el Constructor y el Juez comparten el mismo modelo subyacente, alimenta al Juez un error que ese modelo comete característicamente y observa si lo deja pasar sin cuestionar, 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 de los casos del bucle ejecutándose hasta su límite máximo de revisión, utilizando tus llamadas de modelo más costosas y la salida razonable más larga, y decide honestamente si ese número, apareciendo en una factura real, te alarmaría.

Ejecutar estas cuatro pruebas antes de confiar en un bucle con algo que importa detecta la abrumadora mayoría de fallos que de otro modo se mostrarían por primera vez frente a un cliente, un jefe o tu propio extracto bancario, en lugar de en una prueba controlada que realizaste a propósito.

Paso 16: Enruta las tareas al modelo correcto, no al mismo todas las veces

Una vez que un bucle funciona, resiste el hábito de ejecutar cada parte en tu modelo favorito único. 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 corregir 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 funciona igual de confiable 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 a menudo iguala a uno más grande a una fracción del costo y la latencia.

El Gestor, enrutando basado en 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 reales de costos 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 de lo que te resulte cómodo. Consigue que un bucle funcione lo suficientemente confiable como para que realmente hayas dejado de revisar de cerca su resultado, lo que significa que pasa consistentemente tus propias comprobaciones puntuales manuales durante un período de tiempo real, no solo una única ejecución de 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 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 desencadenantes de la 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 desencadenante de condición de parada específicamente, no solo las finalizaciones exitosas. Un bucle que alcanza su techo de revisión constantemente, mientras que otros rara vez lo hacen, te está diciendo que el estándar de su Juez está mal calibrado: demasiado estricto para aprobar realmente, o 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éndose en un Diseñador de Sistemas (Pasos 19 y 20)

Paso 19: Deja de medirte por los prompts escritos

La señal más clara de que el cambio realmente ha ocurrido es un cambio en lo que atiendes día a día. Un prompter rastrea cuántos buenos prompts escribió. Un diseñador de sistemas rastrea cuántos bucles están ejecutándose, 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 prompts escritos, el cambio mental del paso uno no se ha asentado completamente, 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 trata realmente de tus propios sistemas. Se trata de confirmar que realmente internalizaste el cambio explicándoselo a alguien más 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ñó, de pie fuera, observándolo funcionar.

Los cuatro costos que se acumulan silenciosamente si te saltas 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 después.

La deuda de verificación se acumula cuando te saltas los pasos 6 y 7, construyendo bucles sin un Juez real o sin verdad fundamental real. El bucle parece que funciona porque el resultado se ve bien, justo hasta que un error se acumula silenciosamente a través de docenas de ejecuciones antes de que alguien lo note.

El deterioro de la comprensión se instala cuando te saltas 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 renuncia cognitiva ocurre cuando el paso 1 nunca se asienta realmente, cuando sigues revisando manualmente cada resultado por costumbre mucho después de que el sistema de verificación ya se haya demostrado a sí mismo, anulando todo el propósito de construir el sistema en primer lugar.

La explosión de tokens es lo que ocurre cuando te saltas 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 se evita con la misma disciplina. Construye los pasos en orden. No te saltes los que parecen poco atractivos. Los pasos aburridos: la definición de hecho, la condición de parada, la verdad fundamental, son los que realmente hacen el trabajo. Las partes que suenan interesantes: el prompt inteligente, el diagrama de arquitectura elaborado, importan mucho menos que si el sistema que construiste realmente sabe cuándo está en lo correcto, cuándo está equivocado y cuándo detenerse.

Esa es toda la distinción entre un prompter y un diseñador de sistemas. No es inteligencia. Es disciplina sobre las partes que son aburridas de construir y fáciles de saltar.

Sigue a @cyrilXBT para las plantillas de bucles exactas y las configuraciones de Constructor-Juez-Gestor detrás de cada paso en esta hoja de ruta.