Loops de agentes de IA: cómo un agente de código se autocorrige solo

La forma en que la mayoría sigue usando un agente de código de IA parece un partido de ping-pong. Tú lanzas el prompt, él responde, tú detectas lo que falla, vuelves a lanzar el prompt. Eres tú el motor de corrección, y estás dentro del bucle en cada turno.

Un loop le da la vuelta a eso. Tú describes lo que quieres, el agente se pone a trabajar, escribe su propia checklist, detecta sus puntos débiles y vuelve a intentarlo hasta que el resultado aguante. Dejas de ser quien atrapa los errores. El agente atrapa los suyos.

Ese giro no es puro humo. La gente que construyó estas herramientas se apoya en él. Boris Cherny y Cat Wu, los creadores de Claude Code, hablan de programar en agent loops. Geoffrey Huntley, que bautizó el "Ralph loop", deja agentes corriendo de noche en un simple bucle while. El patrón ya tiene nombre, y vale la pena entenderlo antes de copiar tres prompts vistos en Instagram.

Del ping-pong de prompts al loop

Un prompt aislado es un disparo único. Pides, obtienes una respuesta, la transacción termina. Para mejorarla, tienes que notar el hueco y volver a lanzar el prompt. Llévalo a la escala de una feature de verdad y acabas encadenando decenas de microcorrecciones a mano.

Un loop de agente de IA cierra ese hueco dentro del propio agente. Tú fijas un objetivo, el agente planifica, actúa, mira el resultado y corrige, una y otra vez, hasta cumplir el objetivo. No desapareces, revisas al final. Pero dejas de ser el cuello de botella en cada iteración.

El ping-pong de prompts te mete en el bucle en cada turno. Un loop de verdad mete ahí al agente.

Qué es de verdad un loop de agente de IA

Todo loop agéntico gira sobre los mismos cuatro tiempos: planificar, actuar, observar, corregir. El agente decide el siguiente paso, lo da (escribe código, lanza un comando, lee un archivo), lee lo que ha pasado y se ajusta. Claude escribe código, lanza los tests, ve un fallo, lo corrige, vuelve a lanzar los tests. Ese feedback es todo el truco. Es lo que hace que el loop sea autocorrectivo y no solo repetitivo.

La versión más sólida del loop reparte esos tiempos entre tres roles: uno que planifica, uno que construye, uno que revisa. Mantenerlos separados es lo que impide que el agente se corrija su propia tarea en el mismo aliento en que la escribe.

El loop en tres comandos que puedes copiar hoy

Este es el montaje que circula ahora mismo, rehecho como tres slash commands de Claude Code. Pegas cada uno una vez, el agente crea el comando, y luego los lanzas en orden.

El planificador, /spec:

Entrevístame una pregunta a la vez hasta entender del todo lo que quiero.
Luego escribe un plan preciso en specs/project.md: el objetivo, los
requisitos exactos, los casos límite, y qué entra y qué queda fuera del
alcance. Mantenlo corto y afilado, no una novela.

El constructor, /build:

Lee specs/project.md y construye exactamente lo que describe, nada más.
Cuando termines, lista cada requisito del plan e indica cuáles has
cubierto.

El revisor, /review:

Compara lo que se ha construido con specs/project.md, requisito por requisito.
Para cada uno, di si está cubierto. Escribe las correcciones necesarias y
devuélveselas a /build. Solo da el visto bueno cuando todo el plan esté cubierto.

Tres comandos, un loop: spec escribe el plan, build lo implementa, review lo compara con el plan y devuelve las correcciones a build. Sigue dando vueltas hasta que cada requisito esté cumplido.

El plan es la fuente de verdad. La revisión mide la construcción frente a él, no frente a una sensación.

Esto es spec-driven coding por debajo: lo que rinde cuentas el agente es el spec escrito, no el historial de chat. El Spec Kit open-source de GitHub formaliza la misma idea con /specify, /plan, /tasks e /implement, y corre igual de bien en Claude Code, Copilot, Cursor, Codex CLI y Gemini CLI.

Por qué un contexto fresco hace funcionar el loop: el Ralph loop

Geoffrey Huntley bautizó la versión más cruda de todo esto a mediados de 2025: el Ralph loop. La idea es un simple bucle de shell que le sirve al agente el mismo prompt frente a un spec escrito, lo deja elegir una tarea y entregarla, y luego arranca un agente totalmente nuevo con un contexto limpio y le sirve el prompt idéntico otra vez.

while quedan_todos; do
  agent --prompt "Trabaja en la siguiente tarea de todo.md" --non-interactive
done

La parte que no es obvia es el reseteo de contexto. Una sesión larga se pudre: la ventana se llena de razonamientos viejos, callejones sin salida y contenidos de archivos caducados, y el modelo empieza calladamente a soltar instrucciones. Cada iteración Ralph es un agente nuevo que lee el repo y la lista de tareas desde el disco, hace una unidad de trabajo, hace commit y sale limpio. Huntley lo nombró así por el personaje de los Simpsons a propósito: parece demasiado tonto para funcionar, y funciona. Si alguna vez has visto una sesión larga empezar a alucinar, ya sabes por qué una ventana fresca le gana a una saturada.

Los comandos /loop y /goal de Claude Code

Claude Code trae primitivas de loop de serie. /goal fija un estado final persistente, cómo se ve "terminado", y Claude evalúa su progreso frente a él después de cada pasada, en lugar de limitarse a lanzar el siguiente paso. /loop repite una tarea con una cadencia o hasta que se cumpla una condición, con formas como /loop every 10m o /loop until: <condición>. Juntos crean un loop autodirigido y que se termina solo: Claude trabaja la diferencia entre el estado actual y el objetivo, y se detiene cuando el objetivo está satisfecho o cuando haces Ctrl+C.

El detalle que importa: un loop mantiene la continuidad. Recuerda lo que probó y por qué falló, así que cada pasada se apoya en la anterior en vez de repetir el mismo callejón sin salida. Es el compromiso inverso al reseteo de contexto limpio de Ralph, y los dos son válidos. Continuidad para una autocorrección apretada, contexto fresco cuando la ventana se pudre. Saber cuál sacar es la verdadera habilidad.

El mismo loop, en cada provider

Los loops no son una feature de Claude, son hacia donde va todo el sector. Los nombres cambian, la forma no.

Codex CLI llevó el loop más lejos en público. El equipo de OpenAI presentó su /goal como su versión del Ralph loop, y Andrew Chen, de a16z, lo dejó corriendo toda una noche sobre un driver de dispositivo, 14 horas seguidas sin intervención. También señaló que iba a "multiplicar por 10 000 el consumo de tokens", que es el coste honesto de dejar a un agente moliendo durante media jornada.

La trampa: un loop amplifica todo

Un loop no solo amplifica el buen output, también amplifica un mal plan. Apunta un agente autocorrectivo a un spec vago y construirá la cosa equivocada con todo el aplomo, la revisará frente al mismo spec vago y dará el visto bueno. El plan es la palanca. Un spec afilado ahorra diez prompts, uno borroso desperdicia cien.

Dos modos de fallo que vigilar. El coste se dispara: cada iteración quema tokens, y un loop sin tope sobre un objetivo poco claro puede quemar muchísimos. Y el loop puede dar vueltas sin fin, cantando victoria o persiguiendo una meta que nunca podrá satisfacer. Ponle límites: una condición until clara, un techo de tokens, o un punto de control humano antes del merge. Un loop sin parada no es autonomía, es una fuga descontrolada.

Correr loops sobre toda una flota

Un solo agente autocorrectivo es fácil de vigilar. La palanca aparece cuando corres varios a la vez, cada uno en su propio loop sobre su propia tarea, y ahí es justo donde vigilar una terminal deja de escalar.

Para eso está hecho AgentsRoom. Es una cabina multiagente: cada agente tiene un rol, un punto de estado en vivo y su propio color, y supervisas toda la flota desde una sola ventana. Suelta un ticket en el backlog y un agente lo recoge, despliega su loop plan-build-review y te entrega un diff limpio. Esto es el spec-driven AI coding en la práctica: el ticket es el spec, el agente despliega el loop, tú revisas el resultado.

Como los loops largos pudren el contexto, AgentsRoom lo vigila. Cada agente escribe un estado de una línea al final de cada turno, y cuando un agente deja de actualizarlo dos turnos seguidos, aparece un aviso con un reinicio en un clic sobre un contexto limpio, exactamente el mismo reseteo de ventana en el que se apoya el Ralph loop. Descubre cómo funciona en la página de detección de deriva de contexto.

Y como el loop es agnóstico del provider, no quedas atado a ninguno. Lanza un ticket en Claude Code, el siguiente en Codex, otro en Gemini CLI, todo en el mismo dashboard, cada uno corriendo en su propio git worktree para que los agentes en paralelo nunca choquen. Ponlos en marcha antes de desconectar y revisa los diffs por la mañana, ese es todo el sentido de los agentes de código en segundo plano y del turno de noche.

Fija el objetivo una vez, deja que el loop lo cierre, revisa al final. Descarga AgentsRoom, consulta la matriz de compatibilidad de providers y lee más sobre la revisión por agente y el soporte multi-provider. </content> </invoke>