Una afirmación ha estado circulando en los círculos de codificación con IA: deja de darle instrucciones directas a tus agentes de codificación y comienza a diseñar bucles que los instruyan por ti. Como todo lo nuevo, esto se repite a menudo y se explica rara vez. Esta es la versión práctica: qué es un bucle de agente, por qué importa y cómo se ve uno en producción.
A continuación puedes leer algunas de mis ideas (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 te puede resultar ú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 directas a los agentes de codificación. Deberías estar diseñando bucles que les den instrucciones a tus agentes."Peter Steinberger (
@steipete ), 7 de junio de 2026. 2.2M de vistas.
Boris Cherny, el creador de Claude Code, plantea el mismo punto desde el otro lado.
"Ya no le doy instrucciones directas a Claude. Tengo bucles ejecutándose. Son ellos los que le están dando instrucciones a Claude y decidiendo qué hacer. Mi trabajo es escribir bucles."Boris Cherny (
@bcherny ).
El punto no es que la ingeniería de prompts 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 está terminado,
- y si no, le vuelve a dar instrucciones con el error o el siguiente paso.
Dejas de estar dentro del bucle escribiendo instrucciones; tú escribes el bucle, y el modelo se convierte en una subrutina que éste llama.
La forma es siempre la misma: establece un objetivo, actúa, verifica, retroalimenta el error y repite hasta que la verificación se cumpla 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 auto-instruido, conocido por no saber cuándo detenerse.
- 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 distribuye el trabajo entre muchos 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 está hecho un bucle. Las mismas seis partes aparecen cada vez, 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ú presiones iniciar: un horario, un webhook, un cambio de 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 al mismo tiempo no puedan sobrescribir los archivos del otro. En cuanto ejecutas más de uno, esto deja de ser opcional.
- Contexto documentado. 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 deducir tu proyecto desde cero en cada pasada y adivina los vacíos.
- Conexión con 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 el resto del camino.
- Un segundo agente verifica. Un trabajador separado que evalúa el resultado se mantiene aparte del que lo produjo, porque un modelo revisando 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 tienes un buen punto de partida para la ingeniería de bucles. Antes construías todo a mano; ahora la mayoría viene como funciones integradas, por eso 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 corrección. Si la rama principal avanzó, rebasa una vez.
- Presupuesto. Un intento de corrección por PR, cinco minutos, diez archivos modificados.
- Condición de parada. CI en verde, o presupuesto agotado, entonces se detiene y notifica a un humano.
Regresas a PRs fusionados en lugar de a un backlog de builds fallidas. La misma forma cubre la mayoría del trabajo de operaciones:
- Salud del CI. Cada 30 minutos, extrae las ejecuciones fallidas y agrúpalas por firma, para 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 regresiones antes de que los usuarios lo hagan.
- Agrupación de comentarios. Cada 30 minutos, extrae comentarios de tus canales, agrupa por 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 configuras tú mismo; también ayuda ver uno que viene integrado en el agente. En Claude Code, el bucle completo más pequeño es /goal: le das un estado final verificable, y sigue tomando turnos hasta que ese estado es verdadero.
Aquí hay un ejemplo de /goal usado como comando dentro de una 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, verificar, repetir de antes, con el verificador incorporado.
En este punto, está claro que un buen /goal se lee menos como un prompt y más como un contrato. Los buenos especifican cuatro cosas: el estado final que quieres, la evidencia que demuestra que lo alcanzaste, las restricciones que el agente no debe violar para llegar allí y el presupuesto de trabajo que se le permite gastar. Si dejas cualquiera de ellos vago, 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 historial parezca completo mientras el sistema real está roto.
- Establece la condición. Escribe /goal más un estado final verificable, 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 verifica. Un modelo rápido lee el historial y decide si se cumple o no, para que el agente no esté calificando su propio trabajo.
- Bucle o finalización. 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 traslada entre turnos, por lo que no termina antes de tiempo ni deja caer una restricción a medio camino. Algunos controles lo mantienen confiable:
- Haz que la verificación sea medible. Un resultado de prueba, un código de salida, un recuento de archivos o una cola vacía. "npm test sale con 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 abortarlo antes.
El paso del evaluador esconde una sutileza útil: el verificador no tiene que ser el mismo modelo que el programador. 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 ocupa qué rol se convierte en una decisión arquitectónica en lugar de una apuesta única a un "mejor" agente de codificación. Algunos modelos planifican mejor, otros ejecutan más barato, 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 (mueve cada punto de llamada hasta que compile y las pruebas pasen), refactorizaciones (divide un archivo hasta que cada módulo esté dentro del presupuesto), backlogs de incidencias (trabaja una cola etiquetada hasta que esté vacía) y bucles de evaluación (ajusta un prompt hasta que la puntuación supere un umbral). /loop es la contraparte para 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 sin supervisión aumenta las apuestas, porque un bucle solo es tan confiable 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 (insertar Ultracode en el prompt) para distribuir el trabajo entre muchos agentes en lugar de un solo hilo secuencial.
- 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 termina antes de tiempo.
- Ejecutarlo en la nube (aplicación de escritorio o móvil) para que la sesión sobreviva cuando cierres la laptop.
- Darle una forma de auto-verificarse de extremo a extremo. Claude en Chrome para la web, un MCP de simulador para móvil y un servidor en vivo para 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 orquesta subagentes para enviar la función # 2 · distribuye3/goal all tests pass and the demo loads clean # 3 · sigue adelante4→ cloud / desktop app # 4 · cierra la laptop5→ chrome ext · sim MCP · live server # 5 · auto-verifica, luego se detiene
crabfleet: orquestación como producto
La orquestación es más fácil de visualizar con una herramienta concreta. El crabfleet de Peter Steinberger, un proyecto de OpenClaw presentado como "control de misión 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 ingresan como tarjetas construidas a partir de un prompt, un issue de GitHub o un PR, y luego se mueven por las etapas: por hacer, ejecutando, revisión humana y terminado. Ese tablero es la cola del bucle y su paso de detenerse e informar, 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 de la laptop. Tomas el control solo cuando el runtime 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 distribución en un solo lugar, un autor y muchos agentes.
Se ejecuta en entornos aislados en la nube desechables con terminales basadas 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 consolidado como infraestructura: una cola, ejecución duradera, distribución y una puerta de revisión humana son ahora cosas que configuras en lugar de escribir a mano cada vez.
A dónde va el costo ahora
Durante dos años, la pregunta del costo en la codificación con IA era 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 reintenta seis veces antes de converger cuesta seis veces más que uno que acierta en la primera pasada, con 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 da vueltas el doble de veces no es más barato, así que rastrea el costo por tarea terminada, no el costo por llamada.
- Un verificador débil es el error más caro que puedes enviar. Si la verificación que decide "terminado" es laxa, el bucle se detiene temprano con trabajo roto o sigue adelante con trabajo que ya estaba bien, y ambos desperdician iteraciones completas. Ajusta esto antes que cualquier otra cosa.
- Fallar rápido es un control de costos. Un bucle sin límite de fallos consecutivos no eventualmente tiene éxito; eventualmente vacía la cuenta, por lo que la condición de parada protege tanto la factura como el código base.
Antes ajustabas el prompt; ahora ajustas el bucle, porque ahí es donde se acumula el costo.
Cuándo no usar un bucle
Los bucles valen la pena cuando una tarea se repite y una máquina puede saber cuándo está terminada. Fuera de eso, un bucle solo automatiza el desgaste. Evítalo 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 están yendo" no tiene una condición de aprobación, por lo que el bucle nunca converge.
- Cualquier cosa sin una verificación automatizada barata. Si el único verificador son tus propios ojos, todavía estás dentro del bucle. Construye la verificació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, por lo 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 verificació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 hoyo.
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 tu propio bucle
- Elige una tarea repetible. Cuidar PRs, arreglar CI, verificar despliegues: comienza con trabajo rutinario.
- Acótalo bien. "Arreglar la validación del webhook de facturación, solo tocar 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 de tiempo de ejecución, máximo de archivos, máximo de 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 subagente 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 de la laptop.
- 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 costosa 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 algo que necesite más aclaración, no dudes en contactarnos.
