La mayoría de la gente sigue escribiendo prompts en un cuadro y esperando una respuesta.
Guarda esto :)
Un pequeño grupo de personas dejó de hacer eso. Ya no le hacen prompts a su IA. Construyen bucles que se los hacen por ellos, verifican el resultado, reintentan cuando falla y se detienen cuando el trabajo está realmente hecho. Se van, y el trabajo se termina mientras ellos hacen otra cosa.
La diferencia entre esos dos grupos no es talento.
Es que un grupo sigue siendo el bucle, y el otro grupo aprendió a diseñar el bucle.
En la segunda semana de junio de 2026, una idea reorganizó la forma en que la gente seria habla sobre trabajar con IA. La frase que quedó fue "loop engineering" (ingeniería de bucles). Fue nombrada y estructurada en un ensayo de Addy Osmani, y se propagó como fuego después de que Boris Cherny, creador de Claude Code, describiera su propio flujo de trabajo como bucles que le hacen prompts a Claude y deciden qué hacer a continuación, en lugar de hacerle prompts él mismo turno por turno. Un solo post, según se informa, superó los seis millones y medio de visitas en cuestión de días. Le dio un nombre a algo que los mejores usuarios de agentes ya estaban haciendo sin llamarlo de ninguna manera.
Aquí está todo el cambio en una frase: la unidad de trabajo ya no es un prompt que escribes. Es un bucle que diseñas.
Este es el roadmap de 20 pasos que te lleva de ser un prompteador a un diseñador de bucles. Trabaja en orden. Cada paso te prepara para el siguiente.
Fase 1: Entiende lo que cambió (Pasos 1–4)
Antes de construir un solo bucle, necesitas el modelo mental. Salta esto y construirás bucles frágiles que se rompen de formas que no entiendes.
Paso 1: Conoce las cuatro eras. El campo ha avanzado en etapas claras. En 2023 la habilidad era la ingeniería de prompts, formular bien una solicitud. En 2024 era la orquestación, encadenar pasos. En 2025 era la ingeniería de contexto, controlar lo que ve el modelo. En 2026 se convirtió en la ingeniería de bucles, diseñar el sistema que impulsa el modelo sin ti. Cada era no reemplazó a la anterior; se apiló sobre ella. Saber dónde estás en esa escalera te dice qué aprender a continuación.
Paso 2: Aprende la diferencia entre una cadena y un bucle. Una cadena es una secuencia fija: haz el paso uno, luego el dos, luego el tres, listo. Funciona cuando conoces cada paso de antemano. Un bucle es diferente. Intenta algo, observa lo que sucedió y decide qué hacer a continuación basándose en el resultado. Una cadena no puede arreglar una prueba que falla ni completar un trabajo donde el paso tres depende de lo que devolvió el paso dos. Un bucle sí puede. El bucle es lo que convierte un modelo de lenguaje en algo que progresa.
Paso 3: Interioriza el ciclo de razonar-actuar-observar. Cada bucle de agente es una versión del mismo ritmo de tres tiempos. El agente razona sobre qué hacer, actúa usando una herramienta y observa el resultado. Luego razona de nuevo con esa nueva información. Este patrón tiene un linaje de investigación que se remonta al trabajo de ReAct en 2022, pero no necesitas los papers. Necesitas el ritmo: pensar, hacer, mirar, repetir.
Paso 4: Acepta que tú eres el cuello de botella. Durante tres años, trabajar con IA significaba que escribías un prompt, leías la respuesta y escribías de nuevo. Tú eras el bucle. Todo el cambio de 2026 es que los agentes de codificación y conocimiento se volvieron lo suficientemente confiables en tareas largas como para que el humano en el medio se convirtiera en la parte lenta. La habilidad escasa ya no es escribir prompts. Es diseñar el sistema que los escribe por ti.
Fase 2: Domina la anatomía del bucle (Pasos 5–9)
Ahora aprendes las partes. Un bucle no es solo "ejecutar el modelo una y otra vez". Tiene estructura, y cada parte se gana su lugar.
Paso 5: Define qué significa "hecho", en términos medibles. Esto es lo más importante en la ingeniería de bucles, y es donde la mayoría falla. Antes de escribir una sola instrucción, escribe cómo se ve el trabajo terminado de una manera que una máquina pueda verificar. No "hazlo bien". "Todas las pruebas pasan". "El resultado coincide con este esquema". "Ningún elemento de la lista de verificación está sin marcar". Un bucle sin una definición clara de "hecho" nunca sabe cuándo parar.
Paso 6: Construye el verificador. El verificador es el punto de todo esto. Es la comprobación automatizada que decide si el resultado cumple con tu estándar. Aquí está la trampa en la que todos caen: dejar que el modelo califique su propio trabajo. Un modelo calificando su propia tarea casi siempre se pone una A. Cuanto más estricto y externo sea tu verificador, mejor será tu bucle. Tu criterio, codificado como una comprobación, se convierte en la función de recompensa.
Paso 7: Añade lógica de terminación, en capas. Un bucle sin salida es el error más común y más costoso en el campo. Necesitas varias salidas apiladas: un verificador que confirme que se ha cumplido el objetivo, un límite máximo de iteraciones para que no pueda ejecutarse para siempre, un presupuesto de tokens o tiempo para que no pueda vaciar tu cuenta, y detección de falta de progreso que rompa el bucle cuando los pasos recientes dejen de cambiar algo. Cualquiera de estos por sí solo no es suficiente. Juntos hacen que un bucle sea seguro para alejarse.
Paso 8: Diseña la capa de estado. Un bucle real necesita memoria que sobreviva a un reinicio. Eso significa archivos, listas de tareas y puntos de control que persistan para que si el bucle se bloquea en la iteración cuarenta, pueda retomar desde la treinta y nueve en lugar de empezar de nuevo. El estado es lo que separa un bucle de juguete de uno en el que puedes confiar para un trabajo largo.
Paso 9: Coloca el punto de control humano. Decide exactamente dónde una persona revisa antes de que suceda algo irreversible. El bucle puede investigar, redactar, refactorizar y verificar todo el día por sí solo. Pero enviar un mensaje, desplegar código, mover dinero o eliminar datos debe pausarse y esperarte. Esto no es timidez. Es lo que hace que la autonomía sea segura.
Fase 3: Construye tu primer bucle (Pasos 10–14)
Suficiente teoría. Aprendes ingeniería de bucles ejecutando bucles, sintiéndolos fallar y arreglándolos.
Paso 10: Elige una tarea repetitiva. Elige algo que ya hagas a mano, una y otra vez, donde puedas decir claramente cómo se ve un buen resultado. Una tarea repetitiva con un resultado verificable es el primer bucle perfecto. Una tarea creativa vaga es la peor. Empieza con algo concreto.
Paso 11: Hazlo manualmente primero. Ejecuta la tarea con tu IA varias veces a mano, a la antigua usanza de prompt y revisión. Esto te enseña los pasos exactos, los lugares donde falla y qué significa realmente "hecho". No puedes automatizar un proceso que aún no puedes describir. Las ejecuciones manuales son tú escribiendo la especificación.
Paso 12: Escribe el contrato del bucle. Ahora ponlo por escrito: el objetivo, la definición de "hecho", las comprobaciones que lo verifican, las iteraciones máximas y el punto en el que quieres que te pregunten. Este contrato es tu bucle. Todo lo demás es implementación.
Paso 13: Ejecútalo en cerrado y obsérvalo. Inicia el bucle y observa cada iteración. No te vayas todavía. Estás buscando los modos de fallo: ¿buclea para siempre?, ¿declara victoria demasiado pronto?, ¿se desvía del objetivo?, ¿pasa su propia comprobación débil mientras produce basura? Cada fallo que ves es una lección para tu verificador.
Paso 14: Ajusta el verificador hasta que confíes en él. Toma lo que aprendiste observando y haz que las comprobaciones sean más estrictas y estén más fundamentadas. Si el bucle seguía aprobando resultados malos, tu estándar era demasiado bajo o demasiado autorreferencial. Añade una comprobación externa. Añade un límite de longitud. Añade un criterio específico que seguía violando. Sigue ajustando hasta que el "aprobado" del bucle signifique lo mismo que tu "aprobado".
Fase 4: Escala y refina (Pasos 15–20)
Ahora pasas de un bucle funcional a un sistema, y de aficionado a diseñador de bucles.
Paso 15: Aprende sobre bucles abiertos versus cerrados. Cada bucle se sitúa entre dos polos. Un bucle cerrado repite la misma tarea acotada hacia un objetivo fijo, seguro y barato. Un bucle abierto explora, prueba enfoques novedosos y arriesga más presupuesto para obtener más beneficios. Elige deliberadamente por tarea: ¿cuánta novedad necesitas y cuánto presupuesto estás dispuesto a arriesgar? Luego escribe el verificador que coincida con la elección.
Paso 16: Entiende el arnés subyacente. Un bucle no funciona en el vacío. Funciona dentro de un arnés: todo el entorno de herramientas, gestión de contexto, estado, permisos y recuperación que envuelve al modelo. Un gran bucle sobre un arnés pobre sigue fallando. A medida que te vuelvas serio, pasarás tanto tiempo en el arnés como en el bucle, porque el arnés es donde realmente vive la fiabilidad.
Paso 17: Gestiona el costo como si importara, porque importa. Los bucles hacen de diez a cien veces más llamadas al modelo que los prompts individuales. La forma ingenua te lleva a la bancarrota. La forma disciplinada enruta cada paso al modelo más barato y capaz: uno pequeño y rápido para clasificación simple, uno mediano para redacción, uno de frontera solo para la revisión final difícil. Reutiliza partes repetidas de tus prompts para no pagar el precio completo en cada iteración. Hecho correctamente, esto reduce drásticamente el costo del bucle.
Paso 18: Añade subagentes para trabajo en paralelo. Cuando un trabajo se divide en piezas independientes, no las ejecutas una tras otra. Generas subagentes que cada uno maneja una pieza en paralelo, luego unes los resultados. Así es como un bucle que tomaría horas en secuencia se termina en minutos. El orquestador gestiona; los subagentes ejecutan.
Paso 19: Convierte el bucle en un script. El salto técnico final: en lugar de un bucle que cuidas, escribes el bucle como código que se ejecuta en un horario y maneja el agente por ti. Aquí es donde "funciona mientras duermes" deja de ser un eslogan y se convierte en un cron job. Tu bucle se convierte en infraestructura.
Paso 20: Haz del criterio tu producto. Aquí está la verdad al final del camino. Cuando el bucle escribe el código, ejecuta las pruebas y arregla sus propios fallos, tu valor ya no es escribir. Es saber cómo se ve "correcto", establecer el estándar y diseñar las comprobaciones que lo hacen cumplir. La revisión, el gusto y el criterio se convierten en las habilidades más apalancadas que tienes. En un mundo de ingeniería de bucles, tu gusto no es una habilidad blanda. Es la función de recompensa contra la que todo el sistema optimiza.
Un Ejemplo Práctico: Tu Primer Bucle Real
Déjame hacer concretos los veinte pasos con un bucle que podrías construir esta misma semana.
Digamos que mantienes un código base pequeño y estás cansado de arreglar manualmente las pruebas que se rompen cuando cambias algo. Ese es el primer bucle perfecto: repetitivo y con una definición verificable de "hecho" incorporada.
Así es como se desarrolla el roadmap. Tu definición de "hecho" (paso 5) es simple y objetiva: todo el conjunto de pruebas pasa. Tu verificador (paso 6) ya existe; es el propio comando de prueba, que sale limpio o informa fallos. No hay nada que el agente pueda halagar, porque pasar pruebas es pasar pruebas. Tu lógica de terminación (paso 7) son tres salidas apiladas: para cuando las pruebas pasen, para después de quince intentos, y para si los últimos tres intentos no cambiaron qué pruebas están fallando. Tu estado (paso 8) es una nota continua de lo que se ha intentado, para que un reinicio no repita callejones sin salida. Y tu punto de control humano (paso 9) se sitúa justo antes de que se commitée o se empuje algo a cualquier sitio compartido.
Ahora lo ejecutas. El bucle lee las pruebas que fallan, razona sobre la causa, edita el código, ejecuta las pruebas de nuevo, lee los nuevos resultados y se ajusta. Lo observas (paso 13) y notas algo: en una ejecución "arregló" una prueba debilitando la prueba misma en lugar del código. Esa es una lección. Ajustas el bucle (paso 14): las instrucciones ahora prohíben editar las pruebas, y una comprobación confirma que los archivos de prueba no han cambiado. La siguiente ejecución se comporta bien.
Después de unas sesiones de observación, confías en él. Así que lo conviertes en un script (paso 19) y lo programas para que se ejecute cada noche. Ahora te despiertas con un código base donde los errores de ayer ya están arreglados, con un resumen de lo que cambió esperando tu revisión. Pasaste de hacer esto a mano cada tarde a revisar el trabajo terminado mientras tomas café.
Ese es todo el arco en miniatura: define "hecho", fundamenta el verificador, pon las salidas en capas, observa, ajusta, luego suelta. Una vez que has sentido que funciona en una tarea, verás bucles por todas partes: un bucle de investigación que recopila y verifica hasta que un informe está completo, un bucle de escritura que redacta y se autoedita contra una rúbrica hasta que pasa, un bucle de datos que limpia y valida hasta que el archivo está bien formado. El patrón se transfiere. La tarea cambia; el roadmap no.
Cómo se Ve Esto en un Mes
La ingeniería de bucles no es una certificación de fin de semana. Es un cambio en cómo trabajas que se acumula.
Semana uno, construyes un bucle y principalmente lo observas, aprendiendo sus modos de fallo. Semana dos, ajustas ese bucle hasta que confías en él sin supervisión, y construyes un segundo para una tarea diferente. Semana tres, empiezas a programar tus bucles confiables para que se ejecuten sin ti, y sientes el primer sabor real del trabajo que se hace mientras estás en otro lado. Semana cuatro, notas que has dejado de pensar en prompts por completo. Piensas en objetivos, comprobaciones y salidas. Cuando aparece una nueva tarea repetitiva, tu instinto ya no es "cómo hago esto", es "cuál es la definición de 'hecho' y cuál es el verificador".
Ese instinto es toda la transformación. Un prompteador reacciona a cada tarea escribiendo. Un diseñador de bucles responde diseñando un pequeño sistema que maneja la tarea y cada instancia futura de ella. Uno es lineal. El otro se acumula.
Los Errores que Mantienen a la Gente Atascada como Promptedores
Algunas trampas atrapan a casi todos los que intentan dar este salto.
Automatizar antes de entender. La gente intenta construir el bucle antes de haber hecho la tarea a mano. Automatizan un proceso que no pueden describir y obtienen basura rápida y segura. Hazlo manualmente primero, siempre.
Un verificador débil o autorreferencial. Si el modelo verifica su propio trabajo con un estándar vago, siempre se aprobará a sí mismo. El bucle parece que funciona mientras produce basura. El verificador debe ser estricto, específico e idealmente fundamentado en algo fuera de la propia opinión del modelo.
Sin lógica de terminación. Un bucle sin una salida forzada o se ejecutará para siempre, agotará tu presupuesto o girará en círculos. Las salidas en capas no son opcionales. Son la diferencia entre una herramienta y un descontrol.
Saltarse el estado. Un bucle sin memoria persistente empieza desde cero cada vez que tiene un tropiezo. Para cualquier trabajo largo, el estado es lo que lo hace sobrevivible.
Eliminar al humano de las acciones irreversibles. La tentación es dejar que el bucle haga todo sin supervisión. Resiste para cualquier cosa que no se pueda deshacer. El objetivo de los bucles es el apalancamiento, no la imprudencia.
La Habilidad Detrás de la Habilidad: Desarrollar el Gusto
Aquí está lo que nadie que te vende un curso de ingeniería de bucles enfatizará, porque no se puede vender como un truco rápido: la parte más difícil y valiosa de la ingeniería de bucles es desarrollar el gusto.
Piensa en lo que realmente es un verificador. Es tu juicio sobre lo que significa "bueno", escrito con la suficiente precisión como para que una máquina pueda hacerlo cumplir. Eso significa que la calidad de tus bucles está limitada por la calidad de tu juicio. Si no puedes distinguir un resultado bueno de uno mediocre, no puedes escribir un verificador que capte la diferencia, y tu bucle producirá felizmente trabajo mediocre a escala. El bucle no tiene gusto. Tú lo proporcionas. El bucle solo lo hace cumplir incansablemente.
Por eso la ingeniería de bucles recompensa tanto a los profesionales experimentados. Un ingeniero senior sabe cómo se ve el código correcto, por lo que puede escribir una comprobación que detecte sutilezas incorrectas. Un gran editor sabe cómo se ve una escritura sólida, por lo que puede construir una rúbrica que detecte borradores débiles. La experiencia en el dominio que desarrollaste durante años no se vuelve obsoleta en un mundo de ingeniería de bucles. Se convierte en la función de recompensa. Se convierte en lo más apalancado que posees.
Así que mientras trabajas en este roadmap, invierte en tu propio juicio junto con tu configuración técnica. Estudia grandes ejemplos del trabajo que intentas convertir en bucle. Agudízate en lo que separa lo excelente de lo aceptable en tu dominio. Porque cada mejora en tu gusto es una mejora en cada verificador que escribirás, y por lo tanto en cada bucle que ejecutarás. La persona con el mejor gusto y la disciplina para codificarlo construye los mejores bucles. Esa es la competencia real, y es una que se gana lentamente, preocupándose por la calidad.
Los principiantes que luchan con los bucles generalmente no luchan con los comandos. Luchan porque nunca antes han tenido que articular lo que significa "bueno", y un bucle los obliga a hacerlo. Esa dificultad es el crecimiento. Supérala, y sales no solo capaz de construir bucles, sino más claro acerca de tus propios estándares de lo que nunca has estado.
La Verdad Honesta sobre la Ingeniería de Bucles
Un bucle no salvará una tarea que no entiendes.
Cada paso en este roadmap es realmente un paso hacia describir tu propio trabajo con la suficiente claridad como para que una máquina pueda manejarlo. El bucle es fácil. La claridad, la definición de "hecho", el verificador que realmente detecta el fallo, esa es la parte difícil, y depende completamente de ti. La ingeniería de bucles es principalmente la disciplina de pensar con precisión sobre qué es un buen resultado y cómo lo sabrías cuando lo vieras.
Pero eso es exactamente por qué esta habilidad se acumula. Las personas que aprenden a diseñar bucles no van a ser reemplazadas por modelos más capaces. Son ellos quienes apuntan esos modelos hacia un objetivo, codifican su juicio como una comprobación y dejan que el sistema funcione. A medida que los modelos mejoran en tareas largas, la persona que puede diseñar el bucle a su alrededor se vuelve más valiosa, no menos.
El movimiento que nombró todo esto tiene solo unas pocas semanas.
Lo que significa que la ventana donde saberlo te pone por delante de casi todos está abierta ahora mismo, hoy, antes de que se convierta en el obvio predeterminado.
Puedes seguir escribiendo prompts y esperando respuestas.
O puedes diseñar el bucle que espera por ti.
El primer paso es el paso uno. Empieza ahí.
Si te ha sido útil, sígueme @eng_khairallah1 para más contenido de IA como este. Publico análisis, cursos y herramientas cada semana.
espero que te haya sido útil, Khairallah ❤️
