Una afirmación ha estado circulando en los círculos de codificación con IA: deja de dar instrucciones a tus agentes de codificación y empieza a diseñar bucles que les den instrucciones por ti. Como todo lo nuevo, esto se repite a menudo y se explica raramente. Esta es la versión práctica: qué es un bucle de agente, por qué es importante y cómo se ve uno en producción.
A continuación, puedes leer algunas de mis reflexiones (escritas con la ayuda de Claude) a partir de algunos experimentos, investigaciones y conversaciones que he tenido con algunos de nuestros estudiantes, fundadores técnicos, ingenieros de IA y startups.
También puede que te sea útil nuestra reciente sesión en vivo sobre "Agentes de Codificación Autónomos de Larga Duración" como un buen punto de partida para todo esto.*
De dónde viene la afirmación
"Ya no deberías estar dándole instrucciones a los agentes de codificación. Deberías estar diseñando bucles que le den instrucciones a tus agentes."Peter Steinberger (
@steipete ), 7 de junio de 2026. 2,2 millones de visualizaciones.
Boris Cherny, el creador de Claude Code, plantea el mismo punto desde el otro lado.
"Ya no le doy instrucciones a Claude. Tengo bucles que se están ejecutando. Son ellos los que le dan instrucciones a Claude y descubren qué hacer. Mi trabajo es escribir bucles."Boris Cherny (
@bcherny ).
El punto no es que la ingeniería de instrucciones haya muerto. Con la ingeniería de bucles, el trabajo sube un nivel, de escribir el código a escribir el sistema que escribe el código. Los desarrolladores más avanzados en este camino reportan meses en los que enviaron cientos de PRs sin abrir un IDE, con cada línea escrita por el agente.
Qué es realmente un bucle
Un bucle es un pequeño programa que escribes y que hace cuatro cosas:
- le da instrucciones al agente de codificación por ti,
- lee lo que produjo,
- decide si ha terminado,
- y si no, le vuelve a dar instrucciones con el error o el siguiente paso.
Dejas de estar sentado dentro del bucle escribiendo instrucciones; escribes el bucle, y el modelo se convierte en una subrutina que él llama.
La forma es siempre la misma: establecer un objetivo, actuar, comprobar, retroalimentar el error y repetir hasta que la comprobación se supere o el bucle se detenga solo.
"Bucle" significa al menos cinco cosas
Gran parte del desacuerdo viene de que la gente usa una palabra para cinco ideas diferentes. Aquí está la progresión, de la más antigua a la más nueva.
- ReAct (2022). El patrón de investigación original: razonar, actuar, observar, repetir.
- AutoGPT (2023). Un bucle de objetivos autoguiado, conocido por no saber cuándo parar.
- bucle ralph. Un reinicio deliberado del contexto entre iteraciones para que el agente no se ahogue en su propio historial.
- /loop y /goal. La cadencia y las condiciones de finalización están integradas en el agente, transportando el estado entre turnos.
- orquestación. Un autor despliega múltiples agentes que leen tu GitHub, Slack y chat, y deciden qué construir a continuación.
Las partes que realmente ensamblas
La progresión explica lo que la gente quiere decir con bucle; esto es de lo que un bucle está hecho. Las mismas seis partes aparecen siempre, y la mayoría ahora vienen incluidas dentro de las herramientas de codificación en lugar de ser scripts personalizados que mantienes tú mismo.
- Un disparador. Algo que inicia el bucle sin que tú tengas que presionar "ir": un horario, un webhook, un cambio en un archivo, una etiqueta que llega a un PR. Esto es lo que separa un bucle real de una ejecución única que repites manualmente.
- Aislamiento. Un checkout privado por agente, generalmente un git worktree, para que dos agentes ejecutándose a la vez no puedan sobrescribir los archivos del otro. En cuanto ejecutas más de uno, esto deja de ser opcional.
- Contexto por escrito. Las convenciones, los pasos de compilación y las reglas específicas del proyecto se guardan donde el agente las lee en cada ejecución. Si lo omites, el bucle vuelve a derivar tu proyecto desde cero en cada pasada y adivina los vacíos.
- Acceso a tus herramientas. Conectores al rastreador de incidencias, CI, base de datos y chat, para que el bucle pueda abrir el PR, vincular el ticket y publicar el resultado en lugar de imprimir una solución y esperar a que tú la lleves al resto del camino.
- Un segundo agente comprueba. Un trabajador separado que evalúa la salida se mantiene aparte del que la produjo, porque un modelo que revisa su propio trabajo aprueba casi todo.
- Estado en disco. Un archivo markdown, un tablero o una cola: cualquier cosa fuera de la conversación que registre lo que está terminado y lo que sigue. El modelo olvida entre ejecuciones; el archivo no.
Ensambla esos seis y tendrás un buen punto de partida para la ingeniería de bucles. Antes solías construir todo a mano; ahora la mayoría vienen como funciones integradas, que es por lo que el patrón ha pasado de ser una técnica marginal a un uso común.
Un bucle concreto, el cuidador de PRs
Un ejemplo concreto que puedes construir hoy:
- Disparador. Cada 15 minutos.
- Alcance. PRs abiertos etiquetados con agent-watch.
- Acción. Si el CI está en rojo por una razón determinista, intenta una solución. Si la rama principal se movió, haz rebase una vez.
- Presupuesto. Un intento de solución por PR, cinco minutos, diez archivos modificados.
- Condición de parada. CI en verde, o presupuesto agotado, luego para y notifica a un humano.
Regresas a PRs fusionados en lugar de a un backlog de compilaciones rotas. La misma forma cubre la mayoría del trabajo de operaciones:
- Estado del CI. Cada 30 minutos, extrae las ejecuciones fallidas y agrúpalas por firma, de modo que diez PRs en rojo con una causa raíz se conviertan en una sola cosa que revisar.
- Verificación de despliegue. Después de un push, golpea tus endpoints, confirma 200s y el contenido esperado, y marca las regresiones antes de que los usuarios lo hagan.
- Agrupación de comentarios. Cada 30 minutos, extrae comentarios de tus canales, agrúpalos en temas y asigna cada grupo al archivo o documento al que pertenece.
Un bucle concreto de Claude Code con /goal
El cuidador es un bucle que conectas tú mismo; también ayuda ver uno que viene incorporado en el agente. En Claude Code, el bucle completo más pequeño es /goal: le entregas un estado final verificable, y él sigue tomando turnos hasta que ese estado es verdadero.
Aquí hay un ejemplo de /goal usado como comando dentro de la sesión en Claude Code. Inicias la sesión y luego estableces el objetivo dentro de ella:
1$ claude # inicia Claude Code2$ /goal tests in test/auth pass # establece el objetivo dentro de la sesión
Es la misma forma de actuar, comprobar, repetir de antes, con el verificador integrado.
En este punto, está claro que un buen /goal se lee menos como una instrucción y más como un contrato. Los buenos especifican cuatro cosas: el estado final que quieres, la evidencia que demuestra que lo has alcanzado, las restricciones que el agente no debe violar para llegar allí, y el presupuesto de trabajo que se le permite gastar. Deja cualquiera de ellos vago, y el modelo llena el vacío con la interpretación más fácil: se detiene temprano, toma un atajo o redefine el éxito para que el transcript parezca terminado mientras el sistema real está roto.
- Establece la condición. Escribe /goal más un estado final comprobable, por ejemplo, /goal tests in test/auth pass. El primer turno comienza inmediatamente.
- El agente trabaja un turno. Edita, ejecuta las pruebas y muestra los resultados en la sesión.
- Un evaluador comprueba. Un modelo rápido lee el transcript y decide si se cumple o no, para que el agente no esté calificando su propio trabajo.
- Bucle o finalizar. No cumplido significa otro turno con orientación; cumplido significa que el objetivo se limpia solo y la ejecución se detiene.
El estado se transporta entre turnos, por lo que no abandona temprano ni deja caer una restricción a mitad de camino. Algunos controles lo mantienen fiable:
- Haz que la comprobación sea medible. Un resultado de prueba, un código de salida, un recuento de archivos o una cola vacía. "npm test exits 0" es un objetivo; "hazlo mejor" no lo es.
- Acota la ejecución. Añade algo como "o detente después de 20 turnos" para que un bucle atascado se detenga en lugar de quemar turnos.
- Combínalo con el modo automático para que los turnos se ejecuten sin supervisión, y usa /goal clear para abandonarlo temprano.
El paso del evaluador esconde una sutileza útil: el verificador no tiene que ser el mismo modelo que el codificador. Una vez que el bucle tiene roles distintos (planificador, ejecutor, evaluador, revisor visual), cada uno puede ejecutarse en un modelo diferente, y elegir qué modelo cumple qué rol se convierte en una decisión arquitectónica en lugar de una apuesta única por un "mejor" agente de codificación. Algunos modelos planifican mejor, otros ejecutan de forma más barata, otros juzgan una captura de pantalla con más precisión, y un buen orquestador te permite intercambiarlos por rol en lugar de esperar a que un solo proveedor gane en todas las categorías.
Funciona bien para migraciones de API (mover cada sitio de llamada hasta que compile y las pruebas pasen), refactorizaciones (dividir un archivo hasta que cada módulo esté dentro del presupuesto), backlogs de incidencias (trabajar una cola etiquetada hasta que esté vacía) y bucles de evaluación (ajustar una instrucción hasta que la puntuación supere un umbral). /loop es la contraparte para el trabajo sin una única línea de meta: en lugar de una condición de finalización, vuelve a dar instrucciones en un horario, que es cómo un bucle como el cuidador de PRs sigue ejecutándose.
Ejecutar muchos bucles sin supervisión
Un solo bucle /goal es un agente trabajando hacia una única línea de meta. Ejecutar muchos procesos no supervisados aumenta lo que está en juego, porque un bucle solo es tan fiable como su capacidad para verificar su propio trabajo. La configuración de Cherny para ejecutar Opus de forma autónoma durante horas se reduce a cinco pasos:
- Auto-aprobar permisos para que el agente no se detenga a preguntar en cada llamada de herramienta.
- Usar flujos de trabajo dinámicos (incluir Ultracode en la instrucción) para desplegarse entre muchos agentes en lugar de un solo hilo serial.
- Usar /goal o /loop para mantenerlo en marcha. /goal establece una condición de finalización, /loop vuelve a dar instrucciones en un horario, y ambos transportan el estado, por lo que no abandona temprano.
- Ejecutarlo en la nube (aplicación de escritorio o móvil) para que la sesión sobreviva cuando cierres el portátil.
- Darle una forma de auto-verificarse de extremo a extremo. Claude en Chrome para la web, un simulador MCP para móvil y un servidor en vivo para el backend. Este es el paso que hace seguros a los otros cuatro.
La secuencia completa:
1claude --permission-mode auto # 1 · sin solicitudes de aprobación2ultracode orchestrate sub-agents to ship the feature # 2 · desplegar3/goal all tests pass and the demo loads clean # 3 · seguir adelante4→ cloud / desktop app # 4 · cerrar el portátil5→ chrome ext · sim MCP · live server # 5 · auto-verificar, luego detener
crabfleet: la orquestación como producto
La orquestación es más fácil de visualizar con una herramienta concreta. crabfleet de Peter Steinberger, un proyecto de OpenClaw presentado como "centro de control para ejecuciones de agentes", es un bucle empaquetado como producto, y su forma se corresponde con todo lo anterior.
- Trabajo como tarjetas en un tablero. Las tareas se introducen como tarjetas construidas a partir de una instrucción, un issue de GitHub o un PR, y luego se mueven por pendiente, ejecutándose, revisión humana y completado. Ese tablero es la cola del bucle y su paso de parada e informe, hecho visible.
- Ejecuciones duraderas, no de disparar y olvidar. Cada ejecución es un intento rastreado con latidos, por lo que continúa cuando apartas la mirada y sobrevive al cierre del portátil. Tomas el control solo cuando el tiempo de ejecución anuncia que admite la transferencia.
- Agentes que generan agentes. Una ejecución puede iniciar sesiones hijas, enviar mensajes, leer transcripciones y actualizar su propio resumen desde dentro de un entorno aislado: memoria en disco y despliegue en un solo lugar, un autor y muchos agentes.
Se ejecuta en entornos aislados en la nube desechables con terminales basados en navegador, que es lo que hace seguro alejarse de una ejecución no supervisada. El punto no es la herramienta específica, sino que el bucle se ha endurecido hasta convertirse en infraestructura: una cola, ejecución duradera, despliegue y una puerta de revisión humana son ahora cosas que configuras en lugar de escribir scripts a mano cada vez.
A dónde va el coste ahora
Durante dos años, la pregunta del coste en la codificación con IA fue simple: qué modelo y cuántos tokens. Dentro de un bucle, ese instinto apunta a la capa equivocada. El gasto ya no es una sola llamada, sino cuántas veces da la vuelta el bucle, por lo que un bucle que se reintenta seis veces antes de converger cuesta seis veces más que uno que acierta en la primera pasada, en el mismo modelo.
Eso cambia lo que vale la pena optimizar:
- Las iteraciones son la línea de presupuesto, no los tokens. Un modelo más barato que se repite el doble de veces no es más barato, así que rastrea el coste por tarea terminada, no el coste por llamada.
- Un verificador débil es el error más caro que puedes enviar. Si la comprobación que decide "terminado" es laxa, el bucle o se detiene temprano con trabajo roto o insiste en trabajo que ya estaba bien, y ambos desperdician iteraciones completas. Aprieta esto antes que cualquier otra cosa.
- Fallar rápido es un control de costes. Un bucle sin límite de fallos consecutivos no tiene éxito eventualmente; eventualmente agota la cuenta, por lo que la condición de parada protege la factura tanto como el código base.
Antes ajustabas la instrucción; ahora ajustas el bucle, porque ahí es donde se acumula el coste.
Cuándo no usar un bucle
Los bucles merecen la pena cuando una tarea se repite y una máquina puede decir cuándo está terminada. Fuera de eso, un bucle solo automatiza el desgaste. Sáltatelo en estos casos:
- Ediciones de una sola vez. Si puedes terminarlo en una sola pasada, un bucle es pura sobrecarga.
- Trabajo sin alcance o exploratorio. "Descubrir por qué los usuarios se van" no tiene una condición de aprobación, por lo que el bucle nunca converge.
- Cualquier cosa sin una comprobación automatizada barata. Si el único verificador son tus propios ojos, todavía estás dentro del bucle. Construye la comprobación primero, o haz la tarea manualmente.
Qué puede salir mal
Un bucle que se ejecuta mientras duermes también comete errores mientras duermes, y los modos de fallo son predecibles.
- La carga de verificación sigue siendo humana. El bucle escribe más rápido de lo que puedes revisar, así que si dejas de leer los diffs, no has eliminado el trabajo, solo lo has pospuesto.
- Las brechas de comprensión se amplían. Enviar código que no escribiste, más rápido de lo que puedes absorberlo, erosiona el modelo de tu propio sistema, y esa deuda se cobra durante el próximo incidente.
- Deriva silenciosa con una comprobación laxa. Un verificador débil deja pasar trabajo incorrecto pero aprobado en cada iteración, por lo que el bucle parece productivo mientras cava un agujero.
Nada de esto es un argumento en contra de los bucles; es por lo que el ingeniero que diseña el bucle importa más, no menos.
Cómo construir el tuyo propio
- Elige una tarea repetible. Cuidar PRs, arreglar el CI, verificar despliegues: empieza con trabajo rutinario.
- Acótalo bien. "Arreglar la validación del webhook de facturación, tocar solo app/api/billing y lib/billing", es mejor que "arreglar el error". Un bucle laxo divaga.
- Dale un presupuesto y una condición de parada. Máximo de intentos, máximo tiempo de ejecución, máximo de archivos, máximo gasto, máximo de fallos consecutivos. Un bucle ejecutándose sin supervisión también es un bucle cometiendo errores sin supervisión.
- Añade un verificador independiente. Un sub-agente separado evalúa el trabajo, porque el agente que escribió el código es el peor juez de si está terminado.
- Ejecútalo con una cadencia. /loop para un intervalo, cron para un horario, hooks en puntos del ciclo de vida, o GitHub Actions para que sobreviva al cierre del portátil.
- Mantén la memoria en disco. El modelo olvida entre ejecuciones, por lo que el estado vive en markdown o en un tablero, no en la ventana de contexto.
La conclusión: el bucle, no el modelo, es ahora la parte cara y propensa a fallos. Constrúyelo como alguien que tiene la intención de seguir siendo el ingeniero responsable del resultado, no solo la persona que inicia la ejecución.
Si ves algún error o cosas que necesiten más aclaración, no dudes en contactar.
