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 o la juzga imposible), /loop (ejecuciones locales recurrentes), el plugin oficial Ralph (itera hasta cumplir una promesa), tareas programadas en la nube (antes 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.312 (octubre 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 scheduled task (formerly a 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.¹¹)

Una opción local se sitúa entre los peldaños 3 y 5: las tareas programadas de Desktop se ejecutan en tu máquina sin una sesión abierta, con intervalos mínimos de 1 minuto cuando las configura Claude (1 hora en los formularios), y la documentación las recomienda «cuando necesitas acceso a archivos y herramientas locales».¹²

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 tarea programada en la nube.

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 comprueba si se cumple la condición. Si el modelo juzga que aún no se cumple, Claude inicia otro turno en lugar de devolverte el control».⁹ Internamente, «/goal es un envoltorio de un Stop hook basado en prompts y limitado a la sesión», por lo que no está disponible allí donde los hooks estén desactivados (disableAllHooks, o allowManagedHooksOnly en la configuración administrada). El evaluador es el modelo pequeño y rápido que tengas configurado, y devuelve uno de tres veredictos, cada uno con una breve razón:⁹

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.¹¹ La documentación expone el límite sin rodeos: el evaluador «no ejecuta comandos ni lee archivos por su cuenta, así que redacta la condición como algo que la propia salida de Claude pueda demostrar».⁹ Incluye también la regla de parada dentro de la condición: una cláusula como or stop after 20 turns se evalúa igual que el resto, y una condición puede tener hasta 4.000 caracteres. Si Claude sigue respondiendo al evaluador sin usar herramientas durante varios turnos seguidos, Claude Code detiene el loop y te devuelve el control con el goal todavía activo.⁹

El manejo de fallos, reforzado por primera vez en la v2.1.234,³⁴ ahora cubre todas las formas en que puede fallar un turno:

Cuando un host como la aplicación de escritorio o una sesión en la nube administra las credenciales, un fallo de autenticación deja el goal activo, porque el propio host restablece el acceso. Y cuando el trabajo en segundo plano mantiene un goal en espera, Claude consulta su estado a los 30 minutos, de nuevo 1 hora después y luego cada 2 horas, con un máximo de tres consultas sin actividad entre tus prompts (CLAUDE_CODE_GOAL_CHECKIN_MINUTES define el primer intervalo; 0 desactiva las consultas y los reintentos automáticos).⁹

/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, de entre un minuto y una hora, 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».¹³ Para reemplazar el prompt de mantenimiento integrado, escribe un loop.md (.claude/loop.md en el proyecto, que tiene prioridad, o ~/.claude/loop.md); «Los cambios en loop.md se aplican en la siguiente iteración», y el contenido que supere los 25.000 bytes se trunca.¹²

La limitación importante: /loop vive dentro de un proceso de Claude Code en ejecución. «Las tareas solo se activan mientras Claude Code está en ejecución e inactivo». Si sales, dejan de activarse; si pasas la sesión a segundo plano, el loop sigue ejecutándose sin terminal; si la reanudas con --resume o --continue, las tareas programadas con CronCreate vuelven, pero un /loop con ritmo autogestionado no, así que tendrás que ejecutarlo de nuevo.¹² Para el trabajo que debe sobrevivir a la sesión, la documentación compara tres superficies:¹²

Para el trabajo que debe ejecutarse con tu máquina apagada existen las tareas programadas en la nube.

El plugin Ralph: iterar hasta cumplir la promesa

El plugin oficial ralph-loop de Anthropic convierte en producto el patrón de fuerza bruta favorito de la comunidad. Se llama ralph-loop en el repositorio anthropics/claude-plugins-official desde el 6 de enero de 2026, cuando Anthropic le cambió el nombre de ralph-wiggum «por recomendación legal». El 26 de octubre de 2026, el repositorio claude-code eliminó su propia copia desactualizada de ralph-wiggum, y su marketplace ahora instala ralph-loop desde el repositorio oficial, de modo que «los identificadores de plugin existentes siguen funcionando».¹⁴ El mecanismo: 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.¹⁴ Un límite del harness se aplica a todo loop basado en Stop hooks: «Si el hook bloquea ocho detenciones seguidas sin ninguna llamada a herramientas entre ellas, Claude Code anula el siguiente bloqueo y finaliza el turno» (CLAUDE_CODE_STOP_HOOK_BLOCK_CAP eleva ese límite).²⁹ Eso termina un loop que dejó de avanzar; no termina un loop Ralph que sigue llamando a herramientas, así que el límite de iteraciones sigue siendo importante.

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, dices «use a workflow» o incluyes la palabra clave ultracode; Claude escribe un script de orquestación de JavaScript en el que agent() genera un subagent con salidas opcionales basadas en el esquema de JSON, pipeline() ejecuta uno por cada elemento de una lista, parallel() ejecuta un conjunto a la vez, y await, los loops y los condicionales convencionales controlan el flujo; un runtime lo ejecuta en segundo plano. /effort ultracode va más allá: Claude «planifica un workflow para cada tarea sustancial de la sesión», y una sesión así «alcanza un límite de sesión o semanal antes que el mismo trabajo con la opción desactivada».¹⁶ «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, según la documentación:¹⁶

Los scripts guardados en .claude/workflows/ se convierten en comandos slash reutilizables. Una ejecución se reanuda a partir de los resultados de agentes guardados cuando Claude la vuelve a lanzar, pero un agente que falló «se ejecuta de nuevo, al igual que todos los agentes que el script inicia después de él, incluso los que ya habían terminado», y una ejecución que pasas a segundo plano o de la que sales a mitad de camino «no continúa por sí sola».¹⁶

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. Anthropic ahora incluye una instancia de esta topología: el workflow integrado /deep-research «distribuye búsquedas web sobre una pregunta desde varios ángulos, obtiene y contrasta las fuentes que encuentra, vota cada afirmación y devuelve un informe con citas del que se eliminan las afirmaciones que no resistieron el contraste», y cuando sus verificadores no pueden comprobar una afirmación, «el informe la incluye como no verificada en lugar de contarla como refutada».¹⁶ 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 (añadido como versión preliminar de investigación en v2.1.32, febrero de 2026; la documentación ahora dice «Los agent teams son experimentales y están desactivados de forma predeterminada»): 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í». Eso forma 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 interponen comprobaciones automatizadas entre un compañero y el estado «terminado»: TaskCompleted con código de salida 2 bloquea la finalización, y TeammateIdle con código de salida 2 mantiene trabajando a un compañero.¹⁷ Dos comportamientos que conviene conocer antes de activarlo: mientras los agent teams están habilitados, «un subagent al que Claude le pone nombre se inicia como compañero, por lo que pueden formarse equipos aunque no lo hayas pedido», y «Un compañero no puede aprobar una solicitud de permiso ni dar su consentimiento en tu nombre».¹⁷

Routines: loops que sobreviven a tu laptop

Una tarea programada en la nube (antes 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», que se ejecuta en la infraestructura en la nube administrada por Anthropic o en el entorno self-hosted de tu organización.¹⁸ El nombre anterior se mantiene donde cambiarlo rompería algo: la dirección web (claude.ai/code/routines), el alias /routines de /schedule y la ruta de API /fire. Hay tres tipos de activadores que pueden combinarse: un horario (mínimo de 1 hora para una cadencia recurrente, o una ejecución única en una fecha y hora fijas), activación mediante API (POST .../routines/{id}/fire) y eventos de GitHub. Se crean mediante /schedule, la aplicación Desktop o claude.ai/code/routines. La sesión de una ejecución se inicia en modo automático, salvo que el modo automático no esté disponible; un clasificador permite o bloquea cada acción, y la ejecución se detiene a esperar en casos como una acción que pide confirmación incluso en modo automático (una regla ask) o bloqueos repetidos. Precisamente por eso la advertencia de la documentación resulta fundamental: el resultado de una ejecución indica «cómo terminó la sesión, no si Claude completó el trabajo que describe tu prompt, así que abre la ejecución y lee su transcripción para ver qué pasó».¹⁸ Dos correcciones desde septiembre demuestran que la brecha es real: hasta la v2.1.286, las ejecuciones cuya sesión en la nube nunca llegó a iniciarse aparecían como Succeeded, y hasta la v2.1.302, las ejecuciones aparecían «como Completed después de que su sesión en la nube se detuviera inesperadamente».³⁶ Esa misma versión evitó que una ejecución que falló a mitad de camino se volviera a ejecutar desde el principio, «lo que podía repetir trabajo, como publicar el mismo informe dos veces», una razón para que el trabajo que se activa sea idempotente.³⁶

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».¹⁹ Desde una sesión conectada a Remote Control, también llega a tus sesiones en otras máquinas (v2.1.225+) y en la nube. Para las esperas entre loops, la entrada notify_when_idle (v2.1.236+)³⁶ le pide a una sesión de esta máquina un único aviso cuando vuelva a quedar inactiva o se cierre, y Claude Code se suscribe «sin iniciar un turno ni gastar tokens en la sesión observada».¹⁹ Los runners self-hosted (v2.1.224, Team/Enterprise) ejecutan sesiones en la nube y tareas programadas en la nube (antes 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 con el nombre del personaje de Los Simpson: Ralph es, literalmente,

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

—su comando de una línea, exactamente como lo publicó—: un repositorio, una tarea por iteración, contexto nuevo en cada pasada, con especificaciones y archivos de progreso en el sistema de archivos que mantienen el estado entre iteraciones, y pruebas y verificaciones de lint que actúan como «contrapresión».²¹ La versión moderna sin interfaz de este mismo esquema es claude -p "$(cat PROMPT.md)" dentro de un bucle de shell, que es básicamente lo que ejecutó el propio harness de Anthropic para su compilador de C.²³ Los resultados que afirmó haber obtenido (MVP de un contrato de $50K por $297 en tokens; seis repositorios en una noche durante un hackatón) venían acompañados de límites igual de claros: solo proyectos desde cero, implementaciones de relleno y duplicadas como fallas recurrentes, y «los LLM son un reflejo de la habilidad de quien los opera».

Anthropic nunca usa ese nombre en su material de ingeniería, pero el patrón ya es doctrina oficial por partida doble: el ensayo de noviembre de 2025 sobre agentes de larga duración prescribe exactamente este esquema —un agente inicializador que crea listas de funciones y archivos de progreso, seguido de agentes de programación nuevos en 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 mete a Claude en un bucle simple», como lo describe Nicholas Carlini— con bloqueos de tareas basados en archivos y git como capa de sincronización, lo que produjo unas 100.000 líneas de Rust a lo largo de unas 2.000 sesiones por unos $20K.²³ La frase del ensayo sobre 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 funciona mejor que una sola sesión larga: la eficacia disminuye a medida que se llena el contexto de una sesión —el consenso entre profesionales sitúa el umbral de desvío alrededor de los 100.000 tokens— y los resúmenes de compactación son paráfrasis que pierden información y convierten los errores en afirmaciones que suenan seguras.²⁴ El diseño de Ralph, que combina agentes nuevos con archivos, evita ambos problemas. (Los bucles dentro de una misma sesión del plugin oficial sacrifican parte de estas ventajas por comodidad; para ejecuciones largas, la versión sin interfaz con estado externo sigue siendo el patrón más sólido).

El caso que sirve de advertencia sobre este patrón también deja una lección: alguien ejecutó el plugin con un prompt vago y max_iterations: 0 —que significa infinito, no desactivado— y Claude se hizo la misma pregunta aclaratoria 1.966 veces, mientras el hook Stop tomaba el control de cada mensaje posterior.²⁵ Los límites de iteraciones no son opcionales.

Cuando los bucles se convierten en grafos

Un bucle único presupone que sus iteraciones son independientes o estrictamente secuenciales. En cuanto el trabajo en paralelo tiene dependencias —la tarea B necesita el resultado de A, dos agentes editarían el mismo archivo—, los bucles sin estructura entran en conflicto y necesitas una estructura explícita: una lista de tareas con arreglos de dependencias, asignación de archivos y disciplina al fusionar cambios. Ese es el verdadero fondo del debate entre bucles y grafos: bucles para un repositorio y un objetivo; grafos cuando el trabajo en paralelo necesita un orden.²⁶

Las opciones de grafos, de menor a mayor infraestructura:

1. Flujos de trabajo dinámicos — dependencias expresadas en el flujo de control de JavaScript; barreras solo donde una etapa realmente necesita todos los resultados anteriores. Las topologías que enumera Anthropic: distribuir y sintetizar, verificación adversarial, generar y filtrar, torneo («Crea N agentes que intenten realizar la misma tarea con enfoques distintos», y luego compara sus resultados de a pares) y repetir hasta terminar.¹⁵
2. Equipos de agentes — una lista de tareas compartida con seguimiento de dependencias; un compañero creado mientras el líder está en modo de planificación envía su plan para que se apruebe, y Claude Code lo aprueba automáticamente; el líder solo lo revisa si pasas a modo de planificación a un compañero en proceso que ya está en ejecución (Shift+Tab); el grafo son datos, no código.¹⁷ Un valor predeterminado cambió en este patrón, por primera vez en la v2.1.233:³⁴ las herramientas de seguimiento de tareas (TaskCreate, TaskGet, TaskUpdate, TaskList, TodoWrite) ahora están «disponibles de forma predeterminada solo en Opus 4.7, Sonnet 4.6, Haiku 4.5 y modelos anteriores», un conjunto predeterminado que se aplica a partir de la v2.1.268.³⁸ Los agentes sin ellas «se coordinan mediante mensajes en lugar de usar la lista de tareas compartida»,¹⁷ de modo que, con un modelo actual en una sesión local normal, la lista de tareas no está disponible a menos que la actives; las sesiones en segundo plano y en la nube reciben las herramientas con todos los modelos.³⁸ Actívalas con CLAUDE_CODE_ENABLE_TODO_TOOLS=1, --allowedTools TaskCreate o una lista --tools que las incluya. Una variable exportada no llega a un compañero de panel dividido, así que, para darle las herramientas, inicia el líder con claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'.³⁸
3. Orquestadores externos — la expansión de la comunidad: Gas Town, de Steve Yegge, ejecuta entre 20 y 30 instancias de Claude Code sobre DAG de «beads» respaldados por git (75.000 líneas de Go en 17 días; según él mismo cuenta, también es «una máquina de gastar dinero» que exige mucha habilidad de quien la opera);²⁷ claude-flow/Ruflo (unas 31.000 estrellas) organiza enjambres en una jerarquía de reina y trabajadores; los motores al estilo de LangGraph añaden una máquina de estados tipada con Claude Code dentro de los nodos.

Cherny formaliza esta trayectoria con la escala de Etapas de adopción de la IA, publicada a través de Anthropic en julio de 2026: Con aprobación previa (0 agentes) → Asistida (~1) → En paralelo (~10) → Autonomía supervisada (~100, donde «la mayoría de los agentes son iniciados por Claude, no por humanos») → Nativa de IA (1.000+). Su consejo al respecto: «en cada etapa… necesitas identificar y eliminar los siguientes cuellos de botella, y establecer las siguientes medidas de protección».²⁸

Ingeniería de verificación

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

La escala de Anthropic para aumentar el rigor, según la documentación actual de buenas prácticas, parte de un consejo: «Dale a Claude algo que pueda ejecutar y que devuelva un resultado de aprobación o fallo. Una vez que lo tiene, puede seguir trabajando por su cuenta sin que tengas que vigilarlo». Los peldaños van luego de lo que decide Claude a lo que impone el harness: una línea en el prompt (run the auth tests after, and keep going until they pass) → una condición /goal que «un modelo independiente comprueba contra la conversación después de cada turno», lo cual «importa en las ejecuciones largas en segundo plano, en las que Claude a veces termina un turno con un resumen del progreso mientras aún quedan elementos pendientes» → un hook Stop, «impuesto por Claude Code (el harness), de modo que el turno no termina hasta que pasa la comprobación de tipos o se alcanza el límite de bloqueos» → una revisión «Por alguien que no escribió el código», en la que /code-review «revisa el diff en un subagent nuevo que nunca vio tu conversación. No se deja influir por el razonamiento que produjo el código».²⁹ La norma de evidencia que lo acompaña: «pídele a Claude evidencia: el comando que ejecutó y su salida, o la captura de pantalla», porque «En una sesión que no estabas observando, también es la única evidencia que tienes».²⁹ La refutación adversarial, el peldaño con el que antes terminaba esta escala, ahora está en la documentación de flujos de trabajo, cuyo prompt de ejemplo le pide a un flujo de trabajo «verificar de forma adversarial cada hallazgo antes de informarlo».¹⁶

La misma documentación clasifica cada instrucción según lo que decide Claude y lo que impone Claude Code. Tres de sus filas son las reglas de parada, presupuesto e integración de un bucle:²⁹

Un bucle sin supervisión necesita una entrada de la columna derecha en cada fila; la columna izquierda es todo lo que tiene un bucle cuando nadie escribió esa entrada. La documentación también descarta un hábito al escribir prompts: frases como «sigue adelante, repite hasta terminar, no seas perezoso» tienen «más probabilidades de provocar trabajo excesivo que de resolver un estancamiento», y «en las ejecuciones que nadie está observando, /goal o un hook Stop lo imponen».²⁹

Las tres clases de retroalimentación, según el ensayo Agent SDK: retroalimentación basada en reglas («reglas claramente definidas para un resultado, seguidas de una explicación de cuáles se incumplieron y por qué», la mejor opción), retroalimentación visual (capturas de pantalla, diferencias de píxeles) y LLM como juez (rúbricas imprecisas; en palabras de Anthropic, «por lo general, un método poco robusto»).⁷ Dales preferencia en ese orden; una comprobación determinista que existe vale más que un juez que opina.

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. Su experimento instrumentado deja una cifra que conviene recordar: el 67% del gasto en tokens del bucle no produjo ninguna mejora, porque nada le indicó al bucle que las mejoras habían pasado a crecer de forma logarítmica.³⁰ Los topes de presupuesto no son solo un control de costos; son una regla de detención de último recurso.

Integridad de las pruebas. Según la doctrina de Anthropic sobre agentes de larga duración: «Es inaceptable eliminar o editar pruebas, porque esto podría dar lugar a funciones ausentes o defectuosas».²² Los bucles encuentran cómo aprovechar las especificaciones —pasan las pruebas visibles sin cumplir la intención implícita—, por lo que el propio verificador necesita protección frente al agente que evalúa.

Evalúa los resultados, no los caminos. Según el ensayo sobre evaluaciones: «Evalúa lo que produjo el agente, no el camino que siguió»; usa evaluadores basados en código cuando los criterios sean objetivos y evaluadores basados en modelos para las rúbricas, y calíbralos: «No sabrás si tus evaluadores funcionan bien a menos que leas las transcripciones y las calificaciones de muchos ensayos».³¹

Otra distinción que se le escapa a buena parte del debate: cuando todas las comprobaciones de un bucle son deterministas, ningún modelo tiene lugar en ese bucle. Un monitor de desviaciones que compara marcas de tiempo, un verificador de enlaces, un monitor de compilaciones: son scripts de shell con ejecución programada, sin consumo de tokens, con ejecuciones de segundos y perfectamente repetibles. Reserva los bucles impulsados por modelos para las iteraciones que necesitan criterio. El bucle más barato es el que nunca llama a un modelo.

Disciplina de costos y seguridad

La objeción más frecuente de la comunidad a la ingeniería de bucles es el costo, y los análisis de incidentes la respaldan: un error al crear subagents que consumió 4 millones de tokens en cinco minutos; bucles nocturnos que gastaron miles de dólares; límites de uso alcanzados «mucho antes de lo esperado».³² Una de esas barreras ya cambió: desde la v2.1.234, una sesión continúa automáticamente cuando se restablece un límite de uso de claude.ai (la configuración autoContinueAtUsageLimit; puedes desactivarla en /config → «Continue automatically at usage limit»).³⁴³⁷ El alcance es limitado. «La continuación automática está activada de forma predeterminada en las sesiones interactivas iniciadas con una suscripción de claude.ai»; Claude Code no inicia la espera por su cuenta ante «Un restablecimiento a más de 24 horas», como un límite semanal; salir de Claude Code termina la espera; y Claude Code «no ofrece la espera en absoluto» en «Las sesiones en segundo plano y las ejecuciones con -p», lo que abarca Ralph sin interfaz y claude -p "/goal ...".³⁷ Dentro de una sesión que cumple los requisitos, los bucles siguen esa regla: un /goal en pausa se reanuda con el restablecimiento,⁹ y desde la v2.1.271 una ejecución de flujo de trabajo espera a que pase el límite en lugar de hacer fallar a sus agentes, como máximo dos veces por ejecución.¹⁶ Un bucle nocturno que permanece en una sesión interactiva abierta ahora puede superar el límite; uno que se ejecuta sin interfaz o en una sesión en segundo plano sigue deteniéndose en él. Eso vuelve aún más importantes los controles de presupuesto que aparecen a continuación. De ahí surgió esta disciplina, en la que cada medida corresponde a un control ya disponible:

La última fila merece su propio párrafo, porque así es como quienes llevan esta práctica más lejos mantienen la seguridad: limita el alcance del impacto a la solicitud de cambios (PR). Los agentes permanentes de Cherny en segundo plano —uno que mejora continuamente la arquitectura y otro que busca abstracciones duplicadas— envían PR sin que una persona los active;² nada se integra sin revisión. Un bucle siempre activo cuyo peor resultado posible es «una rama sin integrar» puede trabajar a plena capacidad; uno que escribe en main, no. Las tareas programadas en la nube incorporan esto como comportamiento predeterminado: «Claude envía su trabajo a una rama con el prefijo claude/, a menos que tu prompt le indique enviarlo a otra rama», y la protección de ramas o los rulesets de GitHub deciden a dónde puede hacer push una ejecución.¹⁸ Amplía gradualmente las facultades de los bucles: empieza con observación únicamente (informes, sin escrituras), deja que se ganen la confianza mediante ejecuciones sin incidentes y luego permite que propongan cambios, con la prueba del orden de ejecución («la purga solo se ejecuta después de que la verificación devuelve el nuevo marcador») y una declaración exhaustiva del alcance del impacto documentadas antes de configurar la programación. La economía de esta progresión es el tema de Los bucles ganan donde verificar cuesta poco: el costo de verificación, no la construcción del bucle, determina qué puede ejecutarse sin supervisión.

Ninguna entrada de un bucle cuenta como consentimiento. Cuatro reglas documentadas coinciden: un mensaje de otra sesión «nunca cuenta como tu consentimiento»;¹⁹ un compañero «no puede aprobar una solicitud de permiso ni dar su consentimiento en tu nombre»;¹⁷ el prompt activado de una tarea programada en la nube «no puede actuar como aprobación o consentimiento para acciones durante la ejecución», y el texto enviado con una activación mediante API «llega envuelto en un bloque <routine-fire-payload> que lo marca como datos no confiables»;¹⁸ y, en modo automático, el prompt que un script de flujo de trabajo pasa a agent() «no cuenta como una solicitud tuya» porque «Claude Code lo marca como texto que calculó el script».¹⁶ Copia la regla en tus propios bucles: el texto que produce una máquina son datos, y la aprobación viene de una persona.

La objeción de fondo no es el costo, sino la capacidad de revisión: los bucles producen código más rápido de lo que las personas pueden revisarlo a conciencia.³³ No hay una respuesta ingeniosa; solo queda delimitar el alcance con honestidad: los bucles sin supervisión corresponden exactamente a los casos en que la verificación puede automatizarse, y a ningún otro. Si no puedes verificarlo, no lo publiques.

Qué dice un estudio controlado sobre los componentes del harness

La mayoría de los consejos sobre harness, incluidos los de esta guía, provienen de profesionales que cambian una cosa a la vez en producción. Un estudio de septiembre de 2026 de UMass Amherst, Emory, UNC Charlotte y Zoom lo hizo en condiciones controladas: un harness creado específicamente para el estudio, «cuyo bucle de ejecución se mantiene fijo mientras se varían tres componentes: planificación, espacio de acciones y gestión del contexto», evaluado en «176 configuraciones emparejadas que abarcan cinco estrategias de gestión del contexto, cuatro presupuestos de ventana de contexto y ablaciones específicas de planificación y espacio de acciones» en SWE-Bench Verified y Terminal-Bench 2.1, con cuatro modelos de pesos abiertos: tres tamaños de Nemotron-3 y Mistral-Medium-3.5-128B.³⁵ Sus cuatro hallazgos, en palabras de los autores:

• «La gestión del contexto se vuelve cada vez más valiosa a medida que se reduce el presupuesto de la ventana de contexto; la mayor parte de su beneficio proviene de prevenir fallas por desbordamiento del contexto».
• «Aplicar una omisión basada en reglas antes de resumir mediante LLM ofrece la mayor eficiencia general entre las estrategias de gestión del contexto, mientras que permitir recuperar el contenido omitido añade mecanismos que los modelos rara vez usan y no mejora la precisión».
• «La planificación pasa de servir como apoyo a la precisión en modelos más débiles a reducir costos en modelos más potentes, con pocos cambios en la precisión».
• «Las herramientas predefinidas mejoran el rendimiento de los modelos con menor dominio de bash, mientras que los modelos que dominan bash pueden operar eficazmente con una interfaz basada solo en bash y lograr un costo considerablemente menor, en especial en tareas centradas en la línea de comandos».

A mi juicio, tres de esos hallazgos se aplican directamente a la ingeniería de bucles. La gestión del contexto protege contra el desbordamiento: un bucle de larga duración debe administrar el presupuesto de su ventana y omitir las salidas voluminosas de las herramientas antes de resumir cualquier cosa; además, puede prescindir de mecanismos de recuperación que el modelo no va a usar. Para un modelo capaz, la planificación sirve para ajustar el costo más que para mejorar la precisión, algo que conviene saber antes de añadir una fase de planificación a un bucle que utiliza un modelo potente. Y el resultado de usar solo bash es la separación entre ejecución y modelo un nivel más arriba: cuando quien actúa tiene la capacidad necesaria, menos acciones de mayor alcance cuestan menos. Las salvedades son las del propio estudio: cuatro modelos, dos pruebas de referencia y un harness creado para el experimento, en lugar de un agente disponible en el mercado, de modo que los resultados sirven como orientaciones, no como configuraciones para copiar.³⁵

Operar una flota

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

• Especificaciones como archivos. Cada bucle es una especificación bajo control de versiones —nombre, nivel, programación, objetivo, verificador, herramientas permitidas, presupuesto y tiempo de espera máximo— que reside en el repositorio al que sirve. Si has escrito la misma comprobación manual tres veces, se convierte en una especificación. Anthropic incluye una versión reducida de la idea: un archivo loop.md reemplaza el prompt integrado de /loop sin argumentos, y los cambios que le hagas se aplican en la siguiente iteración.¹²
• Dos niveles y ascensos que se ganan. Los bucles de observación pueden leer cualquier cosa, escriben solo en su propio directorio de informes y se programan de inmediato. Los bucles de acción modifican el entorno y requieren la prueba del orden de ejecución, la declaración del alcance del impacto y un verificador distinto de quien produce el resultado, todo documentado antes de que exista la programación. Los bucles empiezan como observadores y se ganan el ascenso.
• La separación entre ejecución y modelo. Las comprobaciones deterministas se ejecutan como scripts (cero tokens, 1–2 segundos); los bucles con modelos se reservan para tareas que requieren criterio. La comprobación diaria del estado de una flota puede no costar nada.
• Contratos de informes. Una línea por comprobación, PASS|FAIL <check>: <reason>, añadida a un archivo de informe con fecha. Si no puedes definir una línea PASS que se entienda de un vistazo, el bucle no está listo. Un bucle de resumen lee los informes de la flota para que la persona lea una página, no treinta.
• Referencias que se mantienen solas. Los mejores monitores de desviaciones derivan sus expectativas del artefacto que vigilan —las marcas de tiempo registradas en la propia guía, los hashes del propio archivo de bloqueo—, de modo que actualizar el artefacto actualiza el monitor y no queda una segunda fuente de verdad que puedas olvidar.
• Programación que perdura. Las flotas locales se ejecutan mediante el programador del sistema operativo (launchd, cron, temporizadores de systemd), que invoca un script de ejecución, o mediante las tareas programadas de Desktop cuando la máquina permanece encendida; las flotas en la nube son tareas programadas en la nube (antes rutinas). Los bucles ligados a una sesión (/loop) sirven para el trabajo en el que estás presente o para una sesión en segundo plano.¹²

Esto concreta la frase de Cherny «mi trabajo es escribir bucles»: el trabajo humano pasa a ser especificar comprobaciones, verificadores y presupuestos, y leer los informes.

Los primeros dos bucles que vale la pena construir

Si empiezas una flota desde cero, dos bucles compensan su costo de inmediato; ambos están probados en el harness de este sitio:

El bucle de control: un esquema de creador y revisor para cualquier cosa que publiques. Un evaluador nuevo (sin memoria de rondas anteriores) puntúa el artefacto frente a un umbral explícito; aplicas cada observación señalada; otro evaluador vuelve a puntuar; el bucle se detiene al alcanzar el umbral o un límite estricto de rondas. Dos observaciones de su uso en una tanda de quince publicaciones: las reparaciones pueden introducir nuevos defectos (la corrección de una ronda atribuyó erróneamente una cifra, algo que detectó el evaluador de la siguiente), y los evaluadores se equivocan en ambas direcciones: uno «corrigió» con total seguridad una afirmación verdadera, por lo que las correcciones concretas se verifican en la fuente antes de aplicarlas. La autoridad no es el revisor, sino la fuente.

El encargado de mantenimiento: el punto de entrada al nivel de acción. Una corrección pequeña y objetivamente verificable por ejecución, en una rama, con las pruebas aprobadas antes de abrir la PR y sin que el bucle integre nunca los cambios. Dos reglas lo mantienen seguro: todo lo ambiguo se señala, no se corrige (la primera ejecución supervisada acertó al descartar un falso positivo del detector), y una falla preexistente en main se informa como tal, sin incorporarla nunca al diff del bucle.

Un detalle operativo de la flota que vale la pena adoptar: asigna a los bucles con modelos sin supervisión una reserva de sesión; pospón cualquier ejecución mientras haya una sesión interactiva activa en el mismo repositorio. Dos procesos que escriben en una misma copia de trabajo terminarán intercalando commits; la reserva hace que el bucle ceda el paso a la persona por diseño.

Preguntas frecuentes

¿Qué es la ingeniería de bucles?

La práctica de hacer que los agentes de IA repitan ciclos de trabajo hasta cumplir una condición de parada, en lugar de darles instrucciones turno a turno. El trabajo de ingeniería pasa de escribir prompts a diseñar el bucle: su regla de reactivación (una condición, una programación, un evento), su estado entre iteraciones, su verificador y su presupuesto. Anthropic dio nombre a la disciplina en junio de 2026; en Claude Code se materializa mediante /goal, /loop, el plugin Ralph, las tareas programadas en la nube (antes rutinas) y los flujos de trabajo dinámicos.

¿Qué es un bucle Ralph?

Un patrón de autonomía por fuerza bruta al que Geoffrey Huntley dio nombre en julio de 2025: ejecutar Claude Code dentro de un bucle while de 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 actúan como freno. Anthropic ofrece un plugin oficial, ralph-loop (que se llamaba ralph-wiggum hasta enero de 2026), que ejecuta el bucle dentro de la sesión mediante un hook Stop, con --max-iterations como mecanismo de seguridad principal.

¿Cómo ejecuto Claude Code en un bucle?

Elige el nivel más bajo que se ajuste a lo que necesitas: /goal <condition> para iterar hasta que un evaluador independiente confirme una condición; /loop <interval> <prompt> para ejecuciones recurrentes mientras una sesión de Claude Code esté en ejecución; /ralph-loop para iterar sobre una tarea hasta cumplir una promesa de finalización; /schedule para crear una tarea programada en la nube que se ejecute mediante cron sin depender de tu computadora. Sin interfaz interactiva, la forma clásica es claude -p dentro de un bucle de shell con una comprobación externa.

¿Los bucles reemplazan la escritura de prompts?

El prompt no desaparece: cambia de lugar. Lo escribes una vez en la especificación del bucle y este vuelve a ejecutarlo; cada vez más —con los flujos de trabajo dinámicos y la idea de Cherny de que «en realidad es otro Claude quien escribe los prompts»—, un agente orquestador redacta los prompts de cada tarea. El diseño de la verificación reemplaza la elaboración de prompts como labor humana: formular condiciones que una máquina o un modelo con contexto nuevo puedan comprobar.

¿Cuál es la diferencia entre un bucle, una rutina y un flujo de trabajo en Claude Code?

Un bucle (/loop) vuelve a ejecutar un prompt según una programación dentro de una sesión local de Claude Code y deja de activarse cuando ese proceso termina; una sesión en segundo plano lo mantiene en marcha. Una tarea programada en la nube (antes una rutina) es la misma idea preparada para ejecutarse en infraestructura en la nube: se activa mediante cron, API o eventos de GitHub, sin necesidad de una computadora portátil. Un flujo de trabajo 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 bucles y las bifurcaciones definidos en el código en lugar del contexto.

¿Cuánto cuestan los bucles de agentes?

La respuesta honesta va «de cero a la ruina», y la variable es el diseño. Los monitores deterministas no cuestan nada: son scripts programados. El consumo de los bucles con modelos se mide por iteración: ponles límites (--max-iterations, --max-budget-usd), haz que los resultados sean observables para que el bucle pueda detenerse cuando disminuya el beneficio de seguir iterando y trata cada límite como una regla de parada, no como una molestia. Los análisis de fallas —miles de dólares en una noche, 4 millones de tokens en minutos— comparten una causa raíz: la ausencia de una condición de parada externa.

¿Cuándo debe convertirse un bucle en un grafo?

Cuando surgen dependencias entre trabajos paralelos: una tarea necesita la salida de otra, o dos agentes modificarían los mismos archivos. Los bucles gestionan un repositorio y un objetivo; los grafos (flujos de trabajo dinámicos, equipos de agentes, orquestadores externos) añaden orden de ejecución según las dependencias, reserva de archivos y disciplina de integración. Pasa a los grafos solo cuando aparezcan colisiones reales: la estructura adicional exige más trabajo de observabilidad y configuración.

Historial de cambios