Qué es el modo loop
Imagínalo así: Tienes un asistente que sabe: intenta, si falla, corrige e inténtalo de nuevo. No necesitas repetirle «ahora inténtalo de nuevo». Lo hace solo hasta que funciona.
Loop mode es cuando Claude ejecuta, verifica el resultado y, si no funcionó, corrige y vuelve a intentarlo automáticamente. En vez de aprobar cada paso, defines el objetivo y el criterio de éxito, y Claude itera por su cuenta hasta alcanzarlo.
En la práctica, activas loop mode con flags como --dangerously-skip-permissions o configurando allowedTools en settings. Claude recibe permiso para ejecutar herramientas sin pedir aprobación en cada paso. Es potente, pero requiere medidas de seguridad (tema 3).
En 1 frase: loop mode = Claude ejecuta, prueba y corrige por su cuenta hasta alcanzar el criterio de éxito.
Cuándo usarlo frente al modo interactivo
Imagínalo así: No dejas solo al pasante el primer día en una cirugía. Pero después de meses, le permites hacer curaciones sin supervisión. El modo loop es la curación; las tareas críticas son la cirugía.
Usa el modo loop cuando: (1) el criterio de éxito es claro y automatizable (las pruebas pasan, el linter no reporta errores, la compilación funciona), (2) las acciones son reversibles (puedes hacer git reset) y (3) el alcance es limitado (no es todo el sistema). Usa el modo interactivo cuando las decisiones requieren criterio humano o el riesgo de error es alto.
Una buena heurística: si confiarías en que un junior competente lo hiciera por su cuenta, puede ser un loop. Si revisarías el trabajo de un senior antes de hacer merge, hazlo de forma interactiva. El loop mode no es pereza. Es delegar de forma inteligente tareas que tienen feedback automático.
En 1 frase: loop para tareas con criterios automatizables y de bajo riesgo; interactivo para decisiones que requieren criterio.
Guardas de seguridad
Imagínalo así: Un auto autónomo tiene sensores, freno de emergencia y límites de velocidad. El loop mode necesita lo mismo: herramientas permitidas, límite de iteraciones y aislamiento.
Los tres controles esenciales: (1) allowedTools en settings.json limita qué herramientas puede usar Claude sin pedir permiso; (2) máximo de turnos define cuántas iteraciones hacer antes de parar; (3) git worktree aísla los cambios en un branch separado para no contaminar main.
Configura todo antes de ejecutar, no después. Un loop sin protecciones puede ejecutarse indefinidamente, consumir tokens y hacer cambios no deseados. Lo mínimo: allowedTools restringido a read/write/bash, worktree activo y un commit de checkpoint antes de empezar.
En 1 frase: configura allowedTools, max turns y worktree ANTES de ejecutar el loop. Nunca después.
El ciclo del loop mode: ejecuta, prueba, decide y repite hasta cumplir el criterio de éxito.
Cuidado: loop sin guardas
Un loop sin allowedTools restringidas puede: eliminar archivos importantes, ejecutar comandos destructivos o gastar cientos de dólares en tokens. Configura las protecciones ANTES de iniciar el loop.
Monitoreo en tiempo real
Imagínalo así: No pones la comida en el horno y te vas a dormir. La revisas de vez en cuando. Con el modo loop, supervisar significa mirar la terminal mientras se ejecuta.
Mientras el bucle se ejecuta, mantén visible el terminal. Claude muestra lo que está haciendo en cada iteración: qué archivos leyó, qué editó, qué comando ejecutó y cuál fue el resultado. Si ves algo extraño (edita el archivo equivocado, repite el mismo error en bucle), interrúmpelo con Ctrl+C.
Para loops largos, usa git diff --stat entre iteraciones para ver el tamaño de los cambios. Si el diff crece demasiado, puede ser señal de que el loop está divergiendo en lugar de converger. Otra señal: si el número de errores no disminuye en cada iteración, algo está mal.
En 1 frase: mantén la terminal visible e interrumpe si el diff crece o los errores no disminuyen.
Detenerse en el momento adecuado
Imagínalo así: Un escultor se detiene cuando la estatua está lista. Si sigue, la estropea. El loop mode es igual: un criterio claro para detenerse es tan importante como el criterio para empezar.
Define criterios de parada explícitos en el prompt: "detente cuando pasen todas las pruebas", "detente cuando el linter devuelva cero errores", "detente cuando el build termine correctamente". Sin un criterio claro, el loop puede seguir intentando "mejorar" algo que ya está bien y gastar tokens sin avanzar.
Ten cuidado con los rendimientos decrecientes: si el loop ya resolvió el 95% y se atasca con el 5% restante, puede ser más eficiente detenerse y resolver el resto manualmente. Una buena señal de convergencia es que cada iteración haga menos cambios que la anterior.
En 1 frase: criterio de parada explícito en el prompt. Sin él, el loop consume tokens sin parar.
Loop mode vs. background agents
Imagínalo así: Loop mode es como tener un asistente en tu oficina trabajando mientras tomas café. Los background agents son asistentes en una oficina remota que ni siquiera ves. Cada uno tiene sus ventajas y desventajas.
Loop mode se ejecuta localmente, en tu terminal, con acceso a tu sistema de archivos. Los background agents (como los de GitHub Actions o Devin) se ejecutan en servidores remotos. Loop mode es más rápido de configurar, más barato por iteración y puedes verlo todo en tiempo real. Los background agents escalan mejor y se ejecutan mientras duermes.
En la práctica, el loop mode es ideal para tareas de sesión (una tarde de trabajo). Los agentes en segundo plano son mejores para tareas de larga duración (ejecutar una suite de pruebas de 2 horas, procesar 500 PRs). La mayoría de los desarrolladores empieza con loop mode y escala a agentes en segundo plano según lo necesite.
En 1 frase: loop mode = local, rápido y visible; background agents = remoto, escalable y asíncrono.
¿Cuál es el requisito previo para usar el modo loop de forma segura?
Resumen del módulo
Siguiente módulo:
2-4 — Patterns de loop en la práctica: recetas reales de bucles para copiar y ejecutar.