Bucles de codificación de agente: de una línea de comandos de Bash a /goal, verificaciones y paradas obligatorias.

Una sola frase de Peter Steinberger dominó la conversación sobre programación con IA en junio de 2026 y alcanzó dos millones de visualizaciones: los agentes de programación ya no deberían recibir instrucciones manualmente, sino que deberían diseñarse bucles que les den esas instrucciones. Las respuestas se convirtieron en un debate sobre qué significa eso. Cuando alguien preguntó cómo se vería en la práctica, la respuesta más citada bromeó diciendo que solo dos personas lo sabían. Eso es gracioso, pero incorrecto. La idea no es mística, y la forma de implementarla es con una sola orden.

En lugar de debatir si la ingeniería de prompts está muerta, lo útil es crear uno, partiendo de una línea que se pueda pegar en cinco minutos.

Tres puntos sustentan el resto:

• Un bucle es un script que envía una instrucción al agente, examina el resultado, determina si la tarea está completada y la repite si no lo está. El humano ya no está dentro del ciclo tecleando instrucciones. El bucle se crea una sola vez y el modelo funciona como una subrutina dentro de él.
• El bucle más simple y útil es una línea de bash, y el más eficaz es una sola orden con barra diagonal. No se necesita ningún marco de orquestación para iniciarlo, y comenzar con uno es un error.
• Lo que diferencia a un bucle que funciona de uno que agota el presupuesto se reduce a dos cosas: un medio para probar su propio resultado contra una verdad externa, y paradas claras que lo hagan detenerse.

Una definición y una estructura

Boris Cherny creó Claude Code, y según él, Claude Code escribió por sí mismo cada una de sus contribuciones en el último mes, 259 solicitudes de integración, mientras que su IDE fue desinstalado desde noviembre. Él describe el método de manera sencilla: ya no le pide instrucciones a Claude, los bucles se ejecutan y él mismo decide qué sucede a continuación, y su tarea consiste en escribir esos bucles.

Su escalera de tres peldaños hace concreta esta idea. Hace un año, el trabajo consistía en código escrito a mano con autocompletado. Luego surgieron varias sesiones del agente en paralelo, cada una iniciada manualmente. Ahora el programa es quien da instrucciones al agente, y el ingeniero puede dedicarse a otra cosa. El trabajo avanzó un nivel, pasando de escribir código a crear lo que escribe código. Él deja claro que esto no elimina a los ingenieros: alguien sigue decidiendo qué construir, los buenos ingenieros siguen siendo importantes, y verificar los resultados siempre es crucial. Las pulsaciones de teclado se mantienen, pero el juicio también.

El bucle más pequeño: una línea de bash

Todo el concepto cabe en una sola línea, y ejecutarla una vez permite comprenderlo. Se denomina bucle Ralph, en honor a Ralph Wiggum, y Geoffrey Huntley lo popularizó en 2025.

while :; do cat PROMPT.md | claude -p --dangerously-skip-permissions; done

Eso es todo. El mismo archivo de instrucciones se envía a Claude Code en modo sin interfaz gráfica; el agente funciona hasta que se detiene, y luego el ciclo comienza de nuevo con una instrucción idéntica. Cada ejecución nunca recuerda a la anterior, por lo que recupera la orientación a partir de los archivos, la lista de verificación y los commits dejados por ejecuciones anteriores. No hay ningún framework ni máquina de estados involucrados, solo un bucle infinito alrededor de un agente de programación.

Tenga cuidado antes de pegarlo: la opción que omite las solicitudes de permiso es tan directa como suena, y el agente ejecutará comandos sin preguntar. Un árbol de trabajo o contenedor de git desechable, en una rama que no importe perder, es el lugar adecuado, nunca la rama principal.

La inteligencia radica en el hábito, no en el código. En lugar de permitir que una conversación extensa se vuelva obsoleta, cada iteración comienza con un conjunto fijo de archivos de referencia. El archivo de instrucciones nombra siempre los mismos pocos documentos, generalmente una especificación y una lista de verificación que el agente marca y confirma a medida que avanza. Por lo tanto, cada nueva ronda comienza con una orientación clara, y al registrar los avances en cada paso se evita que el agente se desvíe o vuelva a hacer trabajo ya completado.

¿Valdrá la pena un truco tan rudimentario? Un equipo en un hackathon de Y Combinator creó seis repositorios en una sola noche utilizando un bucle ralph y gastando unos 297 dólares en API, lo cual valoraron en aproximadamente cincuenta mil dólares en mano de obra de contratistas. Huntley desarrolló todo un lenguaje de programación pequeño de la misma manera. Aunque como herramienta sencilla llega a ser insuficiente, enseña los conceptos básicos en medio minuto.

El problema es por qué quienes están más familiarizados con esto lo consideran algo obsoleto. El bucle Ralph asume que la terminal permanece abierta y nunca pregunta si la tarea se ha completado. Simplemente sigue ejecutándose indefinidamente, y las siguientes dos secciones abordan ese tema.

Un comando: /goal y /loop

No es necesario escribir bash a mano. Claude Code incluye dos comandos que encapsulan el mismo bucle de manera más segura.

El comando /goal mantiene al agente trabajando hasta que se cumpla una condición especificada, y esa condición es donde radica la clave del asunto.

/goal all tests in test/auth pass and the lint step is clean,
      or stop after 20 turns

Lo que lo diferencia de un bucle while-true es el paso siguiente. Al finalizar cada turno, Claude Code transfiere la condición y la conversación a un modelo pequeño y rápido separado, por defecto Haiku, el cual responde sí o no y proporciona una razón. Si la respuesta es no, esa razón se utiliza como guía para el turno siguiente. El modelo encargado de las tareas nunca puede declarar que ha terminado.

La limitación más importante es que el juez ni realiza pruebas ni examina el repositorio. Solo ve la transcripción, por lo que la condición debe poder demostrarse a partir de la propia salida del agente. Superar las pruebas en la carpeta de autenticación es suficiente, ya que el agente las ejecutó y el resultado se encuentra en la conversación. Una afirmación de que la autenticación es sólida no lo es, ya que nada en la transcripción puede confirmarlo. El juez lee los comprobantes y no audita el código; por lo tanto, la verificación real sigue siendo una orden ejecutada por el agente, y el juez decide si el comprobante indica que la prueba fue aprobada.

Una condición de sonido define un estado final medible y especifica cómo el agente lo demostrará en la salida. Mejorar la autenticación no constituye una condición. Que las pruebas de autenticación den éxito, que no haya salida del comando de prueba y que el estado de git muestre cambios únicamente en los archivos de autenticación sí lo son, ya que cada cláusula aparece en el registro como un comando ejecutado por el agente. Añada un límite, como detenerse después de 20 turnos, además de una bandera de máximo de turnos como medida de seguridad, para que una ejecución sin supervisión no continúe indefinidamente.

Una ejecución única sin supervisión utiliza el modo sin interfaz gráfica con esa bandera y el objetivo entre comillas. El proceso debe permanecer activo mientras funciona, por lo que necesita una terminal abierta o un servidor, no una computadora portátil cerrada. Para cerrar la tapa, Claude Code en la nube es la opción adecuada. Ctrl+C finaliza prematuramente una ejecución local.

Una ejecución breve en la práctica, con dos turnos y aproximadamente cuarenta centavos, se ve así.

> /goal all tests in test/auth pass, npm test exits 0, or stop after 15 turns

◎ /goal active · turn 1
  ran: npm test
  ✗ 2 failing in test/auth/login.test.ts
  judge: not done, expired-token case still throws◎ /goal active · turn 2
  edited src/auth/token.ts
  ran: npm test
  ✓ 41 passing, exit 0
  judge: done, npm test exits 0 and only auth files changed✓ goal achieved · 2 turns · ~$0.40

Todo es visible allí: el agente realiza la verificación, el resultado se incluye en la transcripción, y el juez lo lee para decidir si continúa o se detiene el proceso.

La orden /loop es el pariente programado que supervisa todo. El ejemplo inicial de Cherny merece ser copiado, cambiando solo los sustantivos.

/loop babysit all my PRs. Auto-fix build issues, and when
      comments come in, use a worktree agent to fix them.

Se repite a intervalos, maneja todo lo nuevo desde la pasada anterior y continúa hasta que alguien lo detiene o concluye que el trabajo está terminado. Esto es polling y no manejo de eventos, lo cual es suficiente para monitorear las solicitudes de pull y reparar errores. Lo que se escribe es la intención y el comportamiento de detención, dejando de lado los pasos concretos.

La autoverificación lo hace confiable

Un bucle que escribe código sin verificarlo comete errores cada vez con mayor frecuencia. Debe probar su salida contra algo externo y objetivo, y no contra su propia visión del código.

Las personas que utilizan estos sistemas se alinean en un principio: es una verificación externa, y no la propia evaluación del modelo, la que determina si se ha completado la tarea. El bucle continúa hasta que docker build tiene éxito, el contenedor se inicia y la verificación de estado pasa; en ese caso, la indicación del agente de que todo parece estar bien no cuenta para nada. Los criterios objetivos sustituyen a las intuiciones. En pseudocódigo, un cuerpo de bucle sólido se ve así.

loop:
  agent: make progress on the task
  run:   npm test  (or the build, or the linter)
  if check passes:   done, exit
  if check fails:    feed the failure back, try again
  if no progress in N tries, or budget hit: stop and ping me

Los usuarios de producción introducen dos mejoras. Una consiste en que otro modelo revise el código distinto al que lo escribió, ya que un modelo tiene sus propios puntos ciegos y un nuevo revisor puede detectar lo que el autor pasa por alto. Dan Kornas creó roborev con este propósito: revisa cada commit en segundo plano y envía los hallazgos al agente mientras el contexto sigue siendo reciente. La otra mejora es realizar al menos dos rondas de revisión incluso si la primera es satisfactoria, y limitar el número de rondas a cinco o seis para que el ciclo no oscile indefinidamente.

El bucle no es donde está la magia; la magia está en los comentarios de retroalimentación que contiene. Con una verificación real funciona como un motor, mientras que sin ella solo genera una factura.

Medidas que mantienen el presupuesto intacto

Dado que la generación de código es casi gratuita, el costo recae en el bucle que lo ejecuta, y un bucle sin límites representa un verdadero riesgo financiero. Uber limitó a cada ingeniero a 1,500 dólares por herramienta al mes para Claude Code y Cursor, después de haber gastado todo su presupuesto anual en inteligencia artificial en solo cuatro meses. Lo que temen los equipos de producción es el bucle que nunca termina, donde una terminal olvidada se convierte en una factura de cuatro dígitos para la mañana siguiente.

Cada bucle serio presenta los mismos tres puntos de parada obligatorios, y todos deben estar en su lugar antes de que se ejecute sin supervisión.

max_iterations:   stop after N turns           (the runaway cap)
no_progress:      stop if M turns change nothing (the stuck cap)
budget_ceiling:   stop at $X or T tokens         (the wallet cap)
on_stop:          ping me with the state and the reason

La orden /goal casi otorga gratuitamente el límite máximo permitido al incluir una condición que indica detenerse después de 20 turnos y pasar la bandera de turno. Los dos restantes deben añadirse manualmente. No existe una función integrada para detectar la falta de progreso, y el enfoque más sencillo es utilizar un hook Stop o un pequeño wrapper que compare los resultados de git diff --stat entre turnos y detenga el proceso después de unas pocas rondas sin cambios. El techo presupuestario debe formar parte de los controles de gasto del proveedor, como un límite monetario fijo configurado una vez en la consola antes de que se ejecute cualquier bucle. Suena como si se estuvieran escribiendo bucles mientras mil agentes construyen una empresa de la noche a la mañana, pero en la práctica, la mayor parte del esfuerzo de ingeniería se dedica a asegurar que se detengan.

El recurso interno es una habilidad

El bucle es la infraestructura necesaria, y lo valioso es lo que este recurso permite hacer.

Steinberger repite un segundo consejo que tiene mayor duración. Todo lo que se hace dos veces se convierte en una habilidad reutilizable, y todo lo que es difícil se vuelve una habilidad una vez resuelto, lo que permite realizar la siguiente ejecución sin problemas. Un bucle que redescubre cómo ejecutar pruebas, localizar la configuración y formatear la salida en cada iteración obliga al modelo a volver a aprender el proyecto indefinidamente. Uno que hace uso de una pequeña biblioteca de habilidades probadas y nombradas, como ejecutar el conjunto de pruebas, abrir una solicitud de integración al estilo del equipo o desplegar en el entorno de pruebas, se construye sobre sí mismo, ya que cada iteración comienza con competencia. Cuesta menos y sufre menos desviaciones. Las habilidades son las que aportan valor, y el bucle simplemente las invoca en secuencia.

Bucles que supervisan otros bucles

En la frontera, y en lo que Steinberger y Cherny realmente quieren decir, los bucles vigilan a otros bucles. Un bucle supervisor asigna tareas a muchos agentes simultáneamente, los monitorea y elige el siguiente paso, manteniendo un estado duradero respaldado por Git para que una caída no acabe con todo. Gas Town, un proyecto de código abierto de Steve Yegge, lo ilustra con veinte a treinta instancias de Claude Code gestionadas por un agente alcalde, mientras que los agentes de patrulla realizan bucles de forma continua. Los flujos de trabajo dinámicos en Claude Code representan la forma empacada, donde el agente escribe el script de orquestación y opera una flota de subagentes.

Nadie comienza allí. El orden es primero un /goal, luego una autoverificación, después los tres límites máximos, y la orquestación solo cuando un bucle individual no puede manejar el trabajo, lo cual ocurre más tarde de lo que sugiere el alboroto mediático.

Un primer bucle esta semana

1. Pruebe la verificación manualmente en una rama desechable. Cree una rama como loop-test y ejecute usted mismo la orden de prueba, confirmando que la salida no sea cero cuando algo falla. Donde el agente no puede distinguir entre éxito y fracaso, el evaluador tampoco podrá hacerlo.
2. Elija una tarea con límites claros y una línea de meta definida. Una prueba inestable, una migración pequeña o una limpieza de errores son adecuadas. Omita cualquier tarea cuya finalización dependa del criterio subjetivo de alguien.
3. Formulela como un /goal con un límite. Utilice una orden real y no una estructura vaga, como una llamada sin interfaz con un techo de 15 intentos, una condición que especifique las pruebas de autenticación, una salida cero de la orden de prueba y una detención después de 15 intentos.
4. Verifique que el agente pueda ejecutar la comprobación de principio a fin. Las dependencias deben estar instaladas, nada debe esperar a una tecla presionada, y el fallo debe generar un código de salida distinto de cero. Las primeras ejecuciones se detienen silenciosamente en este punto.
5. Quédese para la primera ejecución. Observe dónde el evaluador responde que no está listo y cómo reacciona el agente ante una comprobación fallida. Ctrl+C lo detiene.
6. Establezca límites de gasto antes de que algo se ejecute sin supervisión. Un límite estricto en dólares para el espacio de trabajo en la consola, además del límite de turnos en cada ejecución: el primero evita que las ejecuciones se salgan de control y el segundo impide pérdidas lentas de recursos.
7. Conserva la parte repetida como una habilidad. La orden de prueba, los pasos de la solicitud de integración o cualquier explicación recurrente se incluyen en un SKILL.md para que el siguiente ciclo comience partiendo de la competencia ya adquirida.

Para el final de la semana ya hay trabajo real que nadie escribió, un bucle que se verifica y corrige a sí mismo, y un límite que impide que supere un punto crítico. Esa es toda la práctica en miniatura.

La respuesta a lo que es un bucle no tiene nada que ver con la desaparición de la ingeniería de prompts. Consiste en salir del interior del ciclo: escribir el bucle una vez, añadir una verificación real y habilidades reutilizables, establecer un límite para que se detenga, y dedicar la atención liberada a decidir qué construir. Steinberger y Cherny describen al mismo concepto desde dos perspectivas, y la puerta de entrada hoy en día es una sola orden de barra invertida.

Leer más

• Notas prácticas: 21 patrones de diseño agente explicados simplemente — Guía detallada de las Notas prácticas: 21 patrones de diseño agente explicados simplemente: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
• Un entorno de sandbox para Claude Code: entornos de agente aislados en una laptop — Cómo un sandbox local de Kubernetes proporciona a los agentes de programación su propia máquina, credenciales específicas, una lista de permisos de salida y una vista general del conjunto de agentes, junto con las ventajas y desventajas de desarrollar en lugar de comprar soluciones.

Ornith-1.0: Modelos de codificación de peso abierto de 9B a 397B bajo licencia MIT — Qué logra la versión Ornith-1.0 en SWE-Bench y Terminal-Bench, cómo entrena el marco con la solución, y qué podría significar para los agentes de codificación cerrados.