Loops Explicados: Claude, GPT, Mira y Lo Que Realmente Funciona

Mirá de cerca el hábito de un pedido por vez, porque ese es todo el problema. Cada paso pasa por vos. Vos decidís qué preguntar, vos juzgás la respuesta, vos decidís qué sigue. La IA nunca se mueve a menos que la empujes, y en el momento en que parás, se frena.

Esto está bien, pero tiene un techo. Vos sos el motor. La IA es solo la herramienta en tu mano, y una herramienta no hace nada por sí sola.

Hay otra forma de trabajar, y es la razón por la que los mejores ingenieros del mundo están cambiando cómo construyen. En vez de guiar a la IA paso a paso, le das el objetivo una sola vez y dejás que ejecute los pasos ella sola. Planea, hace el trabajo, revisa su propio resultado, arregla lo que está flojo, y repite hasta que se cumple el objetivo. Vos te corrés. El trabajo sigue.

Dos de los ingenieros más respetados del mundo dijeron exactamente lo mismo con distintas palabras. La mayoría de la gente leyó frases como esas y, en silencio, no tenía idea de qué significaban en la práctica. Así que vamos a desglosarlo como corresponde.

Un prompt es una instrucción única. Un loop es un objetivo que la IA sigue trabajando hasta alcanzarlo. Pensalo como una meta recursiva: definís un propósito, y la IA itera hasta completarlo.

Un prompt te da una respuesta y después espera a que vos decidas qué sigue. Un loop corre el ciclo completo por su cuenta:

Tres de estas cinco partes hacen todo el trabajo real, y es justo donde la gente se equivoca con los loops.

Verificar es el corazón del loop. Sin una verificación real del resultado, no tenés un loop: tenés al agente coincidiendo consigo mismo en repeat. La verificación es lo que convierte la repetición en progreso. Puede ser un test duro ("¿el código pasa?"), una condición medible ("¿el número está por encima de X?"), o una rúbrica contra la que el modelo se puntúa. Sin gate, el agente se corrige su propia tarea, y el modelo que hizo el trabajo es un corrector demasiado generoso.

El estado es lo que hace que el loop aprenda. En cada pasada, la IA tiene que recordar lo que ya intentó, o repite el mismo error para siempre. Un loop real mantiene un registro mínimo al costado: qué está hecho, qué falló, qué sigue. La corrida de mañana retoma en vez de empezar de cero. Esto también es exactamente donde empieza a salir caro — ya vamos a eso.

Una condición de parada es lo que lo mantiene cuerdo. Un loop sin salida corre hasta que tiene éxito, se rompe o te vacía la cuenta. Todo loop serio tiene dos formas de parar: éxito, y un límite duro ("después de 8 intentos, pará y reportá"). Salteate esto y construiste una máquina que puede correr toda la noche para nada.

Un prompt le da una instrucción a la IA. Un loop le da un trabajo, una forma de saber cuándo el trabajo está terminado, y una regla de cuándo rendirse.

La mayoría de los artículos te venden el loop antes de decirte cuándo es un error. Este es el test que la gente seria realmente usa. Un loop vale la pena solo cuando estas cuatro condiciones son verdaderas:

• La tarea se repite, al menos semanalmente. Menos que eso y el costo de setup nunca se paga solo. Un one-off sigue siendo mejor servido por un buen prompt.
• Algo puede rechazar automáticamente output malo. Un test, un type check, un build, un linter, una regla dura. Si nada puede fallarte el trabajo, el loop solo gira en falso.
• El agente puede realmente hacer el trabajo por sí mismo, de punta a punta, no pasarte la mitad de vuelta.
• "Terminado" es objetivo, no un juicio de gusto. Si la calidad es cuestión de criterio, un humano todavía gana.

Fallaste una caja: mantenelo como prompt manual. La versión honesta de todo este tema: la ingeniería de loops es real, y la mayoría de la gente no necesita la versión pesada todavía. Lo que todos pueden usar es la versión liviana, a la que vamos a llegar. Pero deberías saber dónde está la línea.

Los loops despegaron en software primero, porque el código es lo más fácil del mundo de verificar. Un test pasa o falla. No hay discusión posible, así que la IA siempre sabe si terminó.

Un loop de código recibe un objetivo y una forma estricta de verificarlo.

Por dentro, un loop real se arma con cinco bloques. Claude Code y Codex ya traen los cinco.

1. La automatización (el latido)

Este es el trigger que lo convierte en un loop y no en algo que corriste una vez. Definís un prompt, una cadencia y un objetivo, y corre en horario sin que vos lo arranques. En Claude Code, /loop re-ejecuta un prompt en un intervalo, /goal mantiene una sesión andando hasta que una condición que escribiste es efectivamente verdadera, los hooks disparan comandos en puntos del ciclo de vida del agente, y pushearlo a un cron job o GitHub Actions lo mantiene corriendo después de que cerrás la laptop. Los hallazgos te llegan a vos. No sos vos el que va dando vueltas chequeando.

2. El skill (instrucciones reutilizables)

En vez de pegar una pared de instrucciones en cada corrida, las guardás una vez como un archivo que el loop lee siempre: las reglas, los patrones a seguir, y una lista dura de lo que nunca debe tocar. Ahora la automatización simplemente llama al skill por nombre, y el trabajo recurrente se mantiene mantenible en vez de pudrirse adentro de un schedule que nadie actualiza.

3. Sub-agentes (mantené al que hace lejos del que revisa)

El truco estructural más útil en un loop es separar al agente que hace el trabajo del agente que lo revisa. El modelo que escribió el código es demasiado bueno corrigiendo su propia tarea. Un segundo agente, con instrucciones distintas y a veces un modelo más fuerte en mayor esfuerzo, encuentra las cosas de las que el primero se convenció. Tu escritor puede ser rápido y barato, tu revisor lento y estricto. Esa separación es la mayor parte de la calidad.

4. Conectores (para que actúe, no sugiera)

Esta es la diferencia entre un agente que dice "acá está el fix" y un loop que abre el pull request, linkea el ticket y pinguea el canal cuando el build está verde, solo. Los conectores son lo que permite que el loop actúe adentro de tu entorno real en vez de describir lo que haría si pudiera.

5. El verificador (el gate)

El test, type check o build que automáticamente rechaza trabajo malo. Este es el bloque que decide si el loop te ayuda o solo te gasta la plata. Todo lo demás es cañería. Esta es la parte que lo hace real.

Apilalos y obtenés lo que los equipos grandes ahora corren a escala: flotas de agentes loopando sobre el mismo trabajo, docenas o miles a la vez. Un ingeniero usó un loop así para reescribir una codebase entera de un lenguaje de programación a otro en unos seis días, trabajo que hubiera llevado cerca de un año a mano. Es un cambio genuino en cómo se construye software serio. Y viene con una trampa que las demos nunca muestran.

Los loops corren sobre tokens, y los tokens son plata. El problema no es que cada paso cueste algo. El problema es cómo el costo se compone.

Cada vez que el loop da una vuelta, el agente re-lee su contexto: el objetivo, el código, el último resultado, lo que falló. Todo ese bloque se pasa por el modelo de nuevo en cada iteración, y crece en cada pasada. Un loop que corre diez veces no cuesta diez prompts. Cuesta diez prompts que cada vez son más grandes. El truco del que hace y el que revisa, que levanta la calidad, también duplica la cuenta, porque ahora dos modelos leen el trabajo en vez de uno.

La métrica que realmente importa, y casi nadie trackea, es el costo por cambio aceptado. No los tokens gastados ni los loops corridos. Si el loop te da diez resultados y tirás seis, estás haciendo el trabajo de revisión que se suponía que te ahorraba. Por debajo de un 50% de tasa de aceptación, cuesta más de lo que devuelve.

Los loops también fallan en silencio. El ingeniero Geoffrey Huntley lo llama el "loop de Ralph Wiggum": el agente decide que terminó demasiado temprano, sale con un trabajo a medio hacer, y el loop sigue corriendo y gastando sin producir nada. Sin un gate duro que pueda fallar el trabajo, los loops no crashean: te facturan en silencio.

Por eso la versión pesada es para equipos con el presupuesto y los guardrails para correrla: topes de iteración, presupuestos de tokens, modelos baratos en los pasos aburridos, monitoreo. Si ese no sos vos, no te estás perdiendo de nada. La idea central funciona a una fracción del costo y sin nada del setup.

Si vas a construir uno, el orden importa más que las herramientas. La gente que saca loops que sobreviven en producción lo hace todo de la misma manera: primero manual, después automático.

Saltearte pasos, schedulear algo que no hiciste confiable a mano, es exactamente cómo los loops explotan mientras dormís. Probá una vez, endurecé, después automatizá.

No necesitás un agente de código para sentir cómo funciona esto. Podés correr un loop simple a mano adentro de cualquier LLM ahora mismo, solamente con un prompt. El truco es darle al modelo las tres partes del loop de una: un objetivo, criterios de éxito estrictos, y un protocolo que lo obligue a verificarse antes de que se le permita parar.

Mirá lo que pasa. El modelo redacta, se pone una nota contra tus criterios, encuentra el punto débil, y reescribe, una y otra vez, hasta que efectivamente pasa la barra en vez de entregarte lo primero que parecía cerca. Eso es un loop. Acabás de construir uno con un párrafo.

Pero fijate lo que todavía falta, porque es el punto central de lo que viene. Vos sos el trigger. Abriste el chat, pegaste el prompt, estás sentado mirándolo iterar. Cerrá la pestaña y desaparece. No hay schedule. No hay "hacé esto cada mañana", no hay "despertate cuando llega un email". No puede contactarte, porque solo existe mientras lo estás mirando.

Sacale el código y el costo, y lo que queda es un concepto simple y genuinamente útil: una tarea que se corre sola, en un horario o en el momento en que algo pasa, sin necesidad de que vos te acuerdes o estés ahí. No necesitás ser ingeniero para eso. Solo necesitás loops construidos para la vida en vez de para codebases.

Hay opciones gratuitas donde creás uno describiéndolo en palabras comunes. Sin código, sin hosting, sin keys, sin pestañas que mantener abiertas, sin orden de build para equivocarte.

Un loop real: un trigger de tiempo, una acción multi-paso entre dos apps conectadas, corriendo solo y llegándote a vos. Lo escribiste como un solo mensaje.