Ingeniería de bucles: bucles, rutinas y flujos de trabajo de Claude Code

TL;DR: Loop engineering es la disciplina de hacer que los agentes repitan ciclos de trabajo hasta que se cumpla una condición de detención, en lugar de darles instrucciones turno por turno. Boris Cherny, de Anthropic y creador de Claude Code, describe su propio flujo de trabajo sin rodeos: «Ya no le doy instrucciones a Claude. Tengo loops en ejecución. Son ellos los que le dan instrucciones a Claude y determinan qué hacer. Mi trabajo es escribir loops».¹ Claude Code ahora incluye una gama completa de mecanismos para ejecutar loops: /goal (repite hasta que un modelo independiente confirma que se cumple una condición), /loop (ejecuciones locales recurrentes), el plugin oficial Ralph (itera hasta cumplir una promesa), routines (cron en la nube) y dynamic workflows (Claude escribe un grafo de orquestación de JavaScript y ejecuta hasta 1.000 subagents sobre él). El elemento esencial no es ninguna de esas funciones, sino la verificación. Un loop converge únicamente cuando algo externo al generador —una prueba, un modelo evaluador, una comparación de píxeles o una comprobación automatizada— determina que el trabajo está «terminado». Si lo haces bien, los loops potencian sus resultados; si lo haces mal, terminas pagando por un paseo aleatorio extremadamente costoso. Esta guía abarca todos los mecanismos para ejecutar loops con referencias de versión, el patrón Ralph y sus modos de fallo, cuándo los loops deben convertirse en grafos, la jerarquía de verificación, la disciplina de costos y seguridad, y cómo operar una flota permanente. Actualizada para Claude Code v2.1.234 (agosto de 2026).

¿Qué es loop engineering?

Hace dos años, los ingenieros escribían el código fuente a mano. Después, los agentes comenzaron a escribirlo a partir de prompts humanos. El cambio que está ocurriendo ahora se sitúa un nivel más arriba: los agentes envían prompts a otros agentes y el humano escribe el sistema que decide qué prompts se envían. Cherny dimensiona el cambio sin rodeos: «Así como el paso del código fuente a los agentes fue enorme, los loops son igual de importantes y representan un cambio de la misma magnitud».²

Su definición es gratamente cotidiana: «Un loop es, en esencia, una tarea cron que se ejecuta de forma local para Claude. Una routine es lo mismo, pero se ejecuta en la nube».³ Esta práctica de apariencia exótica —«cientos, a veces miles de agentes ejecutándose durante 5, 10 o 20 horas» durante la noche,⁴ Claude Code «escrito al 100 % por Claude Code durante más de seis meses»⁴— se reduce a un pequeño conjunto de elementos básicos: un prompt que vuelve a ejecutarse según un horario o una condición, un estado que persiste entre iteraciones y una comprobación que finaliza la ejecución.

Anthropic dio nombre a la disciplina en junio de 2026: los loops son «agentes que repiten ciclos de trabajo hasta que se cumple una condición de parada», y «la calidad del resultado de un loop depende del sistema que lo rodea».⁵ Esta guía trata precisamente sobre ese sistema.

Una nota sobre la procedencia, porque el debate evolucionó rápidamente a mediados de 2026: el término «graph engineering» —que suele atribuirse a Cherny en publicaciones virales— fue acuñado por la comunidad (la publicación de Peter Steinberger del 18 de julio, «are we still talking loops or did we shift to graphs yet?», amplificada por Hamel Husain), no por Anthropic ni por Cherny.⁶ La cita ampliamente compartida «85% of our engineers… the way you do it is graph engineering» solo circula en publicaciones de terceros; durante la preparación de esta guía no pudimos encontrarla en ningún registro primario de sus charlas (la conversación de YC Startup School, Odd Lots de Bloomberg y el informe de TechCrunch sobre Meta @Scale), así que debe considerarse una atribución no verificada. Su práctica real sí tiene forma de grafo (orquestadores que generan subagents implementadores, verificadores y correctores, anidados hasta una profundidad de 5), pero el vocabulario verificado es loops, routines y workflows, que es el que utiliza esta guía.

Ruta ideal de cinco minutos

Tres comandos te llevan de los prompts a los loops:

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

La diferencia entre estos comandos y un prompt es estructural, no cosmética: cada uno tiene una regla de reejecución (una condición, un reloj o una tarea cron) y necesita una regla de parada. El resto de esta guía explica cómo hacer que esas dos reglas sean confiables.

El loop central y la única regla

Todos los sistemas de agentes ejecutan el mismo ciclo interno, que la documentación de Agent SDK de Anthropic consagra como recopilar contexto → actuar → verificar el trabajo → repetir.⁷ El propio proceso de Claude Code es un loop: evalúa el prompt, llama a herramientas, lee los resultados y repite hasta que una respuesta no contiene llamadas a herramientas.⁸

Loop engineering envuelve ese ciclo interno con loops externos y hereda su única regla innegociable, formulada en todas las fuentes rigurosas del sector:

El agente que realiza el trabajo nunca lo evalúa.

• La documentación de /goal de Anthropic: «la finalización la decide un modelo nuevo, no el que realiza el trabajo».⁹
• El ensayo de Anthropic sobre el diseño de harness: «Separar al agente que realiza el trabajo del que lo evalúa demuestra ser una herramienta eficaz para abordar este problema».¹⁰
• Cherny, sobre lo que los profesionales suelen pasar por alto: «La verificación es probablemente lo más importante que las personas no hacen bien».³ En su ejemplo práctico, al dar instrucciones para reescribir una aplicación de Electron en Swift en dos semanas: «ejecuta la aplicación de Electron en la máquina virtual Mac, toma una captura de pantalla y examínala píxel por píxel. Compárala con la versión de Swift. No te detengas hasta terminar».³

La razón es mecánica, no moral: un modelo al que se le pregunta «¿terminaste?» presenta un sesgo positivo de autoevaluación, y una transcripción expresada con seguridad puede convencer a una condición de salida evaluada por un modelo de declarar prematuramente que el trabajo está «terminado».¹¹ La verificación externa —un conjunto de pruebas, un compilador, una comparación de píxeles o un modelo nuevo que no tenga interés en la respuesta— es la única señal que resiste este efecto.

La escalera de autonomía

Las superficies de loop de Claude Code forman una escalera que va desde «volver a presionar Enter» hasta «ejecutarse sin ti». Cada peldaño intercambia mayor autonomía por una carga de verificación más alta:

(La organización en peldaños sigue la taxonomía de pardel.dev de julio de 2026, el mapa independiente más claro de este ámbito.¹¹)

La disciplina de la escalera: comienza en el peldaño más bajo que resuelva tu problema y sube solo cuando se haya demostrado la verificación de ese peldaño. Un /goal cuya condición no pueda formularse de manera comprobable no está listo para convertirse en una routine.

Las superficies de loop en detalle

(Esta guía aborda las superficies de loop propiamente dichas. La guía de Claude Code es la referencia completa de CLI —configuración, permisos, hooks, MCP— y la guía de arquitectura de agentes explica cómo se combinan los componentes del harness; los loops son lo que ejecutas encima de ambos.)

/goal: el loop evaluador-optimizador

/goal <condition> mantiene a Claude trabajando hasta que se cumple la condición: «Después de cada turno, un modelo pequeño y rápido comprueba si se cumple la condición. De no ser así, Claude inicia otro turno en lugar de devolverte el control».⁹ El evaluador (Haiku de forma predeterminada) devuelve sí o no junto con una razón que Claude utiliza como orientación para el siguiente turno. También funciona en modo headless: claude -p "/goal ..." ejecuta el loop hasta completarlo.

Notas de elaboración: haz que la condición sea observable («las pruebas pasan», «el endpoint devuelve 200», «cero errores de TypeScript») en lugar de aspiracional («el código está limpio»). Un verificador impreciso no ofrece ninguna dirección al loop; además, una transcripción expresada con seguridad puede convencer a una condición evaluada por un modelo para que dé su aprobación, por lo que conviene combinar /goal con una comprobación automatizada siempre que exista alguna.¹¹

Dos cambios de la versión v2.1.234 refuerzan el propio loop. Ahora, un goal se borra y muestra un aviso cuando un turno falla por un error irrecuperable —autenticación revocada, saldo de créditos agotado o desbordamiento del contexto—, en lugar de permanecer activado en una sesión que ya no puede actuar. Además, cuando las tareas en segundo plano mantienen un goal en espera durante más de 30 minutos, Claude consulta su estado en lugar de esperar indefinidamente (CLAUDE_CODE_GOAL_CHECKIN_MINUTES permite ajustar el umbral; 0 restaura el comportamiento anterior de espera ilimitada).³³

/loop: ejecuciones locales recurrentes

/loop [interval] <prompt> vuelve a ejecutar un prompt según un horario: fijo (/loop 5m check the deploy), con ritmo autogestionado (Claude elige la siguiente demora en función de lo observado) o simplemente /loop para realizar una pasada de mantenimiento integrada. Por debajo utiliza CronCreate/CronList/CronDelete (cron de 5 campos, 50 tareas por sesión y caducidad de 7 días) y la herramienta Monitor, que transmite la salida de un script en segundo plano en lugar de consultarlo repetidamente.¹² El ejemplo de lanzamiento del propio Cherny: «/loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them».¹³

La limitación importante: /loop vive dentro de tu sesión. Si cierras la terminal, el loop muere; para eso existen las routines.

El plugin Ralph: iterar hasta cumplir la promesa

El plugin oficial ralph-wiggum de Anthropic convierte en producto el patrón de fuerza bruta favorito de la comunidad: un Stop hook intercepta el intento de Claude de finalizar la sesión y vuelve a insertar el prompt, de modo que el modelo itera continuamente dentro de una misma sesión. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" lo inicia; /cancel-ralph lo interrumpe. El README afirma expresamente que --max-iterations es «tu principal mecanismo de seguridad», ya que la coincidencia exacta de la cadena de finalización puede fallar indefinidamente.¹⁴

Workflows dinámicos: Claude escribe el grafo

Introducidos con Claude Code v2.1.154 (mayo de 2026) y descritos en detalle en la publicación de lanzamiento de Anthropic del 2 de junio de 2026, los workflows dinámicos representan el mayor salto conceptual: «Ahora Claude puede escribir su propio harness sobre la marcha, creado específicamente para la tarea en cuestión».¹⁵ Describes la tarea (o simplemente dices «use a workflow»); Claude escribe un script de orquestación de JavaScript: agent() genera un subagent con salidas opcionales basadas en el esquema de JSON, pipeline() hace pasar los elementos por distintas etapas, mientras que await, los loops y los condicionales convencionales controlan el flujo; después, un runtime lo ejecuta en segundo plano. «Un workflow traslada el plan al código… Un script de workflow contiene el loop, las bifurcaciones y los resultados intermedios, de modo que el contexto de Claude solo conserva la respuesta final».¹⁶

Límites y estructura: 16 agentes simultáneos y 1.000 por ejecución («evita loops fuera de control»), sin intervención del usuario durante la ejecución; los scripts guardados en .claude/workflows/ se convierten en comandos slash reutilizables; las ejecuciones pueden reanudarse gracias a los resultados de agentes almacenados en caché.¹⁶ La topología distintiva es expandir / refutar / converger: buscadores independientes, seguidos de verificadores adversariales a los que se les pide refutar cada hallazgo, con iteraciones hasta que las respuestas resistan el escrutinio. El resultado principal del lanzamiento: el traslado realizado por Bun de su base de código Zig de 535.496 líneas a Rust —que produjo una base de código Rust de más de un millón de líneas— en once días (del 3 al 14 de mayo de 2026), mediante 64 agentes en paralelo, según el relato de Jarred Sumner.¹⁵

Agent teams: el grafo entre pares

Detrás de CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (versión preliminar de investigación desde v2.1.32, febrero de 2026): un líder de equipo y compañeros que «trabajan de forma independiente, cada uno en su propia ventana de contexto, y se comunican directamente entre sí»; es un grafo entre pares, en lugar de un árbol de subagents, coordinado mediante una lista de tareas compartida con dependencias, asignación mediante bloqueo de archivos y buzones por agente. Los quality gates impuestos por hooks (TaskCompleted con código de salida 2 bloquea la finalización) interponen comprobaciones automatizadas entre un compañero y el estado «terminado».¹⁷

Routines: loops que sobreviven a tu laptop

Una routine es «una configuración guardada de Claude Code: un prompt, uno o más repositorios y un conjunto de conectores, empaquetados una sola vez y ejecutados automáticamente» en la nube administrada por Anthropic o en tus propios runners self-hosted.¹⁸ Hay tres tipos de activadores que pueden combinarse: horario cron (mínimo de 1 hora), activación mediante API (POST .../routines/{id}/fire) y eventos de GitHub. Se crean mediante /schedule o claude.ai/code/routines. Las ejecuciones son autónomas —sin solicitudes de aprobación—, razón por la cual la advertencia de la documentación resulta fundamental: un estado de ejecución verde «no significa que la tarea de tu prompt haya tenido éxito. Abre la ejecución, lee la transcripción y confirma qué hizo realmente Claude».¹⁸

Anthropic ejecuta «quizá 20 o 30 de estas routines cada día» en sus propias bases de código: eliminación de código muerto, cobertura de pruebas y publicación de experimentos.³

El reparto de apoyo

Los subagents en segundo plano (predeterminados desde v2.1.198) mantienen el trabajo delegado fuera de tu contexto; el panel /agents permite supervisarlos. La mensajería entre sesiones (v2.1.224) convierte sesiones independientes en un grafo de intercambio de mensajes mediante SendMessage, con un principio de seguridad que vale la pena adoptar: un mensaje de otra sesión «nunca cuenta como tu consentimiento».¹⁹ Los runners self-hosted (v2.1.224, Team/Enterprise) ejecutan sesiones en la nube y routines en tus propias máquinas: la infraestructura subyacente para flotas a escala organizacional.²⁰

El patrón Ralph

La comunidad llegó primero. En julio de 2025, Geoffrey Huntley publicó el ensayo que bautizó la técnica en honor al personaje de Los Simpson: Ralph es, literalmente,

while :; do cat PROMPT.md | claude-code ; done

—su frase de una línea exactamente como fue publicada—: un repositorio, una tarea por iteración, contexto nuevo en cada pasada, con archivos de especificaciones y progreso en el sistema de archivos que mantienen el estado entre iteraciones, y pruebas y linters que actúan como «contrapresión».²¹ La forma headless moderna de esta misma estructura es claude -p "$(cat PROMPT.md)" dentro de un bucle de shell, que es, en esencia, lo que ejecutó el harness del compilador de C de Anthropic.²³ Los resultados que afirmó haber obtenido (MVP de un contrato de $50K por $297 en tokens; seis repositorios durante una noche en un hackathon) vinieron acompañados de límites igual de claros: solo para proyectos greenfield, implementaciones provisionales y duplicadas como modos de fallo recurrentes, y «los LLMs son espejos de la habilidad del operador».

Anthropic nunca usa ese nombre en su material de ingeniería, pero el patrón ya forma parte de la doctrina oficial por partida doble: el ensayo de noviembre de 2025 sobre agentes de larga duración prescribe exactamente esta estructura —un agente inicializador que crea listas de funciones y archivos de progreso, seguido de agentes de programación nuevos para cada ventana de contexto, que «comienzan la sesión leyendo el archivo de notas de progreso y los registros de commits de git»²²—, y el proyecto del compilador de C de febrero de 2026 ejecutó dieciséis agentes Claude en paralelo —«construí un harness que coloca a Claude en un bucle sencillo», según lo describe Nicholas Carlini—, con bloqueos de tareas basados en archivos y git como capa de sincronización; el resultado fue de unas 100K líneas de Rust a lo largo de unas 2.000 sesiones por alrededor de $20K.²³ La frase del ensayo sobre la verificación resume toda la teoría del patrón: «es importante que el verificador de tareas sea casi perfecto».

Por qué un contexto nuevo supera a una sesión prolongada: la eficacia se deteriora a medida que se llena el contexto de una sesión —el consenso entre profesionales sitúa el umbral de desviación alrededor de los 100K tokens—, y los resúmenes de compactación son paráfrasis con pérdida que convierten errores en prosa convincente.²⁴ El diseño de Ralph, basado en instancias nuevas y archivos, evita ambos problemas. (Los bucles dentro de una misma sesión del plugin oficial sacrifican parte de esta ventaja a cambio de comodidad; para ejecuciones prolongadas, la forma headless con estado externo sigue siendo el patrón más sólido).

La historia aleccionadora del patrón también resulta instructiva: un profesional ejecutó el plugin con un prompt impreciso y max_iterations: 0 —que significa infinito, no desactivado—, y Claude se hizo la misma pregunta aclaratoria 1.966 veces, mientras el Stop hook secuestraba cada mensaje posterior.²⁵ Los límites de iteraciones no son opcionales.

Cuando los bucles se convierten en grafos

Un solo bucle presupone que sus iteraciones son independientes o estrictamente secuenciales. En cuanto el trabajo paralelo tiene dependencias —la tarea B necesita el resultado de A, dos agentes editarían el mismo archivo—, los bucles de forma libre chocan entre sí y necesitas una estructura explícita: una lista de tareas con matrices de dependencias, asignación exclusiva de archivos y disciplina de integración. Ese es el verdadero contenido del debate entre bucles y grafos: bucles para un repositorio y un objetivo; grafos cuando el trabajo paralelo necesita un orden.²⁶

Las opciones de grafos, en orden ascendente de infraestructura:

1. Flujos de trabajo dinámicos — dependencias expresadas en el flujo de control de JavaScript; barreras únicamente cuando una etapa realmente necesita todos los resultados anteriores. Las topologías que Anthropic menciona: distribución y síntesis, verificación adversarial, generación y filtrado, torneo («Genera N agentes para que cada uno intente resolver la misma tarea con enfoques distintos» y luego evalúalos por pares) y bucle hasta terminar.¹⁵
2. Equipos de agentes — una lista de tareas compartida con seguimiento de dependencias y un líder que aprueba los planes; el grafo son datos, no código.¹⁷ Un valor predeterminado cambió con este patrón: desde la versión v2.1.233, las herramientas de tareas (TaskCreate/Get/Update/List, TodoWrite) están desactivadas de forma predeterminada en Opus 4.8, Sonnet 5, Fable 5 y versiones posteriores. La documentación indica explícitamente que los agentes sin las herramientas Task «se coordinan mediante mensajes en lugar de utilizar la lista de tareas compartida», por lo que, con la configuración predeterminada de la generación actual, la lista de tareas simplemente no está disponible. Configura CLAUDE_CODE_ENABLE_TODO_TOOLS=1 para restaurarla.³³
3. Orquestadores externos — la expansión a escala de la comunidad: Gas Town, de Steve Yegge, ejecuta entre 20 y 30 instancias de Claude Code sobre DAG de «beads» respaldados por git (75K líneas de Go en 17 días y, según su propio relato, también «un devorador de dinero» que exige mucha habilidad del operador);²⁷ claude-flow/Ruflo (unas 31K estrellas) organiza enjambres en una jerarquía de reina y trabajadores; los motores al estilo de LangGraph superponen una máquina de estados tipada con Claude Code dentro de los nodos.

La propia formalización de Cherny sobre esta trayectoria es la escala Steps of AI Adoption, publicada a través de Anthropic en julio de 2026: Con restricciones (0 agentes) → Con asistencia (~1) → En paralelo (~10) → Autonomía supervisada (~100, donde «la mayoría de los agentes los inicia Claude, no los humanos») → Nativo de IA (más de 1.000). Su consejo al respecto: «en cada etapa… necesitas encontrar y eliminar el siguiente conjunto de cuellos de botella, y desarrollar el siguiente conjunto de medidas de protección».²⁸

Ingeniería de verificación

Todo lo anterior es infraestructura. Esta sección es el producto.

La escala de intensificación de Anthropic, según el documento actual de prácticas recomendadas: dale a Claude algo que produzca un resultado de aprobado o reprobado y «el bucle se cierra por sí solo» → una condición /goal que un evaluador independiente vuelve a comprobar → un Stop hook como «una barrera determinista» → «un subagente de verificación o un flujo de trabajo dinámico que compruebe sus propios hallazgos hace que un modelo nuevo intente refutar el resultado, de modo que el agente que realiza el trabajo no sea quien lo califica».²⁹ La norma probatoria asociada: «Haz que Claude muestre evidencia en lugar de limitarse a afirmar que tuvo éxito».

Las tres clases de retroalimentación, según el ensayo sobre Agent SDK: retroalimentación basada en reglas («reglas claramente definidas para un resultado, seguidas de una explicación de qué reglas fallaron y por qué» —la mejor modalidad), retroalimentación visual (capturas de pantalla, diferencias entre píxeles) y LLM-como-juez (rúbricas imprecisas; en palabras de Anthropic, «por lo general, no es un método muy robusto»).⁷ Prefiérelas en ese orden; una comprobación determinista que existe es mejor que un juez que se limita a opinar.

Condiciones de convergencia. El análisis crítico más incisivo de los bucles —el de Yoko Li, de agosto de 2026— reduce la convergencia a cuatro requisitos: un estado objetivo definido, un estado actual observable, ediciones locales precisas y reglas de detención externas al generador. La cifra que debes recordar de su experimento instrumentado es esta: el 67% del gasto de tokens del bucle no produjo ninguna mejora porque nada le indicaba que los rendimientos se habían vuelto logarítmicos.³⁰ Los límites presupuestarios no son solo un mecanismo de control de costos; son una regla de detención de último recurso.

Integridad de las pruebas. Según la doctrina de Anthropic para agentes de larga duración: «Es inaceptable eliminar o editar pruebas, porque esto podría provocar que se pasen por alto funciones ausentes o defectuosas».²² Los bucles manipulan las especificaciones —superan las pruebas visibles mientras incumplen la intención oculta—, por lo que el propio verificador necesita protección frente al agente que evalúa.

Califica los resultados, no los caminos. Según el ensayo sobre evaluaciones: «Califica lo que produjo el agente, no el camino que tomó»; usa evaluadores basados en código cuando el criterio sea objetivo y evaluadores basados en modelos para las rúbricas, y calibra: «No sabrás si tus evaluadores funcionan bien hasta que leas las transcripciones y las calificaciones de muchos ensayos».³¹

Hay otra distinción que la mayor parte del debate pasa por alto: cuando todas las comprobaciones de un bucle son deterministas, ningún modelo debería formar parte del bucle. Un vigilante de desviaciones que compara marcas de tiempo, un verificador de enlaces o un centinela de compilación son scripts de shell programados: cero tokens, segundos por ejecución y una repetibilidad perfecta. Reserva los bucles impulsados por modelos para iteraciones que requieran criterio. El bucle más económico es el que nunca llama a un modelo.

Disciplina de costos y seguridad

La objeción más ruidosa de la comunidad contra la ingeniería de bucles es el costo, y los análisis posteriores a los incidentes la respaldan: un error que genera subagents y consume 4M tokens en cinco minutos; bucles nocturnos que gastan miles de dólares; límites de uso alcanzados «mucho más rápido de lo esperado».³² Desde entonces, uno de esos límites se ha desplazado: a partir de la versión v2.1.234, una sesión continúa automáticamente cuando se restablece un límite de uso de claude.ai (puedes desactivarlo en /config → «Continue automatically at usage limit»). Un bucle nocturno que antes se detenía al llegar al límite ahora se reanuda cuando vuelve a abrirse la ventana, lo que hace que los controles presupuestarios descritos a continuación sean más importantes, no menos.³³ La disciplina que surgió, con cada elemento asociado a un control ya publicado:

Esa última fila merece su propio párrafo, porque así se mantienen seguros los profesionales más agresivos: haz que el pull request sea el radio de impacto. Los agentes permanentes en segundo plano de Cherny —uno que mejora continuamente la arquitectura y otro que busca abstracciones duplicadas— envían PR sin intervención humana;² nada se integra sin revisión. Un bucle siempre activo cuyo peor escenario sea «una rama sin integrar» puede ejecutarse intensamente; uno que escribe en main no puede hacerlo. Promueve los bucles de forma gradual: comienza en modo de solo observación (informes, sin escrituras), gánate la confianza mediante ejecuciones rutinarias y, después, pasa a proponer cambios, con la prueba de orden («la depuración solo se ejecuta después de que la verificación devuelve el marcador nuevo») y una declaración exhaustiva del radio de impacto documentadas antes de instalar la programación. La economía de esta ruta de promoción es el tema de Los bucles triunfan cuando verificar es barato: el costo de verificación, no la construcción del bucle, determina qué puede ejecutarse sin supervisión.

La objeción más profunda no es el costo, sino la capacidad de revisión: los bucles producen código más rápido de lo que los humanos pueden revisarlo de manera significativa.³⁴ No existe una respuesta ingeniosa; solo honestidad al definir el alcance: los bucles desatendidos corresponden exactamente a los ámbitos donde la verificación puede realizarse automáticamente, y a ningún otro. «Si no puedes verificarlo, no lo publiques».²⁹

Operación de una flota

El estado final de la ingeniería de loops no es un solo loop, sino una flota permanente. Así se ve esta práctica cuando se estabiliza:

• Especificaciones como archivos. Cada loop es una especificación versionada —nombre, nivel, programación, objetivo, verificador, herramientas permitidas, presupuesto y tiempo de espera— que reside en el repositorio al que sirve. Si has realizado manualmente la misma comprobación tres veces, se convierte en una especificación.
• Dos niveles, promoción por mérito. Los loops de observación pueden leer cualquier cosa, escribir únicamente en su propio directorio de informes y programarse de inmediato. Los loops de acción interactúan con el mundo y requieren una prueba del orden de ejecución, una declaración del radio de impacto y un verificador distinto del creador, todo por escrito antes de que exista la programación. Los loops comienzan como observadores y deben ganarse la promoción.
• La separación entre ejecución y modelo. Las comprobaciones deterministas se ejecutan como scripts (cero tokens, entre 1 y 2 segundos); los loops de modelos se reservan para tareas que exigen criterio. El pulso diario de una flota puede no costar nada.
• Contratos de informes. Una línea por comprobación, PASS|FAIL <check>: <reason>, agregada a un archivo de informe fechado. Si no puedes definir una línea PASS comprensible de un vistazo, el loop aún no está listo. Un loop de resumen lee los informes de la flota para que la persona revise una página, no treinta.
• Líneas base que se mantienen solas. Los mejores observadores de desviaciones derivan sus expectativas del artefacto que protegen —las marcas de tiempo registradas en la propia guía, los hashes del propio lockfile—, de modo que actualizar el artefacto también actualiza el observador y no existe una segunda fuente de verdad que pueda olvidarse.
• Programación que perdura. Las flotas locales se ejecutan mediante el programador del sistema operativo (launchd, cron o temporizadores de systemd), que invoca un script de ejecución; las flotas en la nube son rutinas. Los loops vinculados a una sesión (/loop) son para el trabajo que supervisas en persona.

Esto concreta la idea de Cherny de que «mi trabajo es escribir loops»: el trabajo humano pasa a consistir en especificar comprobaciones, verificadores y presupuestos, y en leer los informes.

Los primeros dos loops que vale la pena crear

Si vas a iniciar una flota desde cero, hay dos loops que se amortizan de inmediato; ambos se han comprobado en el harness de este mismo sitio:

El gate loop — maker-checker para todo lo que publiques. Un evaluador nuevo (sin memoria de rondas anteriores) califica el artefacto según un criterio explícito; tú corriges todos los hallazgos señalados; un evaluador distinto vuelve a calificarlo; el loop se detiene cuando alcanza el criterio o el límite estricto de rondas. Dos observaciones prácticas tras ejecutarlo durante una serie de quince publicaciones: las correcciones pueden introducir defectos nuevos (la corrección de una ronda atribuyó erróneamente una cifra, algo que detectó el evaluador de la ronda siguiente) y los evaluadores se equivocan en ambas direcciones —uno «corrigió» con seguridad una afirmación verdadera—, por lo que las correcciones específicas se verifican en la fuente antes de aplicarlas. El checker no es la autoridad; la fuente sí.

El groundskeeper — el punto de entrada al nivel de acción. Una corrección pequeña y objetivamente verificable por ejecución, en una rama, con todas las pruebas aprobadas antes de abrir el PR; además, el loop nunca hace merge. Dos reglas mantienen su seguridad: todo lo ambiguo se marca, no se corrige (la primera ejecución supervisada rechazó correctamente un falso positivo del detector), y cualquier fallo preexistente en main se informa como tal, sin incorporarlo jamás al diff del loop.

Un detalle sobre la operación de flotas que vale la pena adoptar: asigna a los loops de modelos desatendidos un arrendamiento de sesión; es decir, pospón cualquier ejecución mientras haya una sesión interactiva activa en el mismo repositorio. Dos procesos de escritura sobre un mismo checkout acabarán intercalando commits; por diseño, el arrendamiento hace que el loop ceda el paso a la persona.

Preguntas frecuentes

¿Qué es la ingeniería de loops?

Es la práctica de hacer que los agentes de IA repitan ciclos de trabajo hasta que se cumpla una condición de parada, en lugar de darles instrucciones turno por turno. El trabajo de ingeniería deja de centrarse en escribir prompts y pasa a diseñar el loop: su regla de reactivación (una condición, una programación o un evento), el estado que conserva entre iteraciones, su verificador y su presupuesto. Anthropic dio nombre a la disciplina en junio de 2026; sus interfaces de Claude Code son /goal, /loop, el plugin Ralph, las rutinas y los workflows dinámicos.

¿Qué es un Ralph loop?

Es un patrón de autonomía por fuerza bruta al que Geoffrey Huntley dio nombre en julio de 2025: ejecutar Claude Code en un loop while del shell, proporcionándole el mismo prompt con un contexto nuevo en cada iteración, mientras los archivos de progreso y git conservan el estado entre pasadas y las pruebas ejercen contrapresión. Anthropic incluye un plugin oficial llamado ralph-wiggum que ejecuta el loop dentro de la sesión mediante un hook Stop, con --max-iterations como mecanismo de seguridad principal.

¿Cómo ejecuto Claude Code en un loop?

Elige el nivel más bajo que se ajuste a tus necesidades: /goal <condition> para iterar hasta que un evaluador independiente confirme una condición; /loop <interval> <prompt> para realizar ejecuciones periódicas mientras tu sesión permanezca abierta; /ralph-loop para iterar sobre una tarea hasta obtener una promesa de finalización; /schedule para crear una rutina en la nube que se ejecute mediante cron sin depender de tu computadora. En modo headless, la forma clásica es usar claude -p dentro de un loop del shell con una comprobación externa.

¿Los loops sustituyen a los prompts?

El prompt no desaparece, sino que cambia de lugar. Lo escribes una vez en la especificación del loop y este vuelve a ejecutarlo; cada vez con mayor frecuencia (en los workflows dinámicos y en la idea de Cherny de que «en realidad es otro Claude el que se encarga de generar los prompts»), un agente orquestador escribe los prompts de cada tarea. Lo que sustituye a la creación de prompts como oficio humano es el diseño de la verificación: establecer condiciones que una máquina o un modelo nuevo puedan comprobar.

¿Cuál es la diferencia entre un loop, una rutina y un workflow en Claude Code?

Un loop (/loop) vuelve a ejecutar un prompt según una programación dentro de tu sesión local y termina junto con ella. Una rutina aplica la misma idea, pero la empaqueta para ejecutarse en infraestructura en la nube: puede activarse mediante cron, API o un evento de GitHub, sin necesidad de una computadora portátil. Un workflow es el grafo de orquestación de una sola ejecución: un script de JavaScript que escribe Claude y que crea y coordina hasta 1.000 subagents, con los loops y las bifurcaciones definidos en el código en lugar del contexto.

¿Cuánto cuestan los loops de agentes?

La respuesta honesta abarca desde «nada» hasta «una cantidad ruinosa», y la variable decisiva es el diseño. Los observadores deterministas no cuestan nada: son scripts programados. Los loops de modelos se cobran por iteración: establece límites (--max-iterations, --max-budget-usd), haz que los resultados sean observables para que el loop pueda detenerse cuando los rendimientos disminuyan y trata cada límite como una regla de parada, no como un inconveniente. Los análisis posteriores de fallos —miles de dólares gastados durante la noche, 4M de tokens en cuestión de minutos— comparten una causa raíz: la ausencia de una condición de parada externa.

¿Cuándo debería un loop convertirse en un grafo?

Cuando el trabajo en paralelo genera dependencias: una tarea necesita el resultado de otra o dos agentes modificarían los mismos archivos. Los loops gestionan un repositorio y un objetivo; los grafos (workflows dinámicos, equipos de agentes y orquestadores externos) incorporan el orden de las dependencias, la asignación de archivos y la disciplina de merge. Adopta los grafos únicamente cuando las colisiones aparezcan de verdad, ya que la estructura adicional tiene un costo en observabilidad y configuración.

Registro de cambios