` | Refactorización mecánica en paralelo | v2.1.63+ | Cada unidad tiene su propio git worktree |
`/goal` es el comando que más se parece a Ralph Loop. En segundo plano, un modelo evaluador (Haiku por defecto) comprueba en cada turno si se ha alcanzado el objetivo. Si no es así, la siguiente iteración incluye una indicación sobre qué hay que corregir exactamente. Si sí, se detiene. Expliqué `/goal` en detalle en la guía sobre [cómo ejecutar Claude Code de forma autónoma durante la noche con /goal](https://ailoot.ai/blog/es/goal-mode-claude-code-codex/), que incluye escenarios listos para usar en 14 horas de trabajo.
`/batch` es un comando poco habitual, pero potente. Cuando necesitas aplicar el mismo cambio a más de 100 archivos (migración de API, sustitución de componentes, cambio de nombres), `/batch` envía cada archivo a un subagente distinto en su propio git worktree. Los cambios no entran en conflicto: cada agente trabaja en una copia aislada. Para saber más sobre los subagentes, consulta la guía sobre [subagentes anidados](https://ailoot.ai/blog/es/claude-code-nested-subagents/).
En la descripción del autor, este enfoque se resume así:
Límites estrictos de `/loop` y `/goal`:
- Una tarea se ejecuta mientras Claude Code esté abierto. Cierra el terminal y el bucle se detiene. Para un ciclo nocturno serio, usa un servidor remoto o tu propio wrapper de shell.
- La duración máxima de una tarea recurrente es de **7 días** (después se elimina automáticamente para evitar que sigan activos los bucles olvidados).
- Hasta **50 tareas simultáneas** en una sesión.
¿Quieres crear una configuración que haga que Claude sea fiable? Ralph Loop es solo una parte. Conviene tener en cuenta los tres componentes: **clon de IA + Second Brain + Context Engineering**. Esta combinación transforma Claude de un «asistente que alucina» en una herramienta a la que puedes asignar una tarea y luego seguir con tus asuntos.
## Cómo iniciar tu primer bucle autónomo en 5 minutos
Ideas clave
La forma más rápida de empezar es usar el comando integrado `/goal`. Abre Claude Code e introduce un comando con un objetivo y una condición de parada verificable; después, sigue con tus asuntos. Claude genera código, ejecuta pruebas, lee los errores, los corrige y vuelve a ejecutar las pruebas hasta que pasan.
5 pasos:
1. ### Abre el proyecto en Claude Code
Entra en la raíz del proyecto desde el terminal y ejecuta `claude`. Espera a que Claude lea `CLAUDE.md` e indexe el repositorio.
2. ### Define un objetivo y una condición de parada
El objetivo indica qué hay que hacer. La condición de parada indica cómo sabrá Claude que ha terminado. Lo ideal es que sea un comando que devuelva 0 o 1. Ejemplo: «Objetivo: deben pasar las 23 pruebas de `tests/api/*.test.ts`. Detente cuando `pnpm test` devuelva el código de salida 0».
3. ### Ejecuta /goal
Comando:
```
/goal Deben pasar todas las pruebas de tests/api/*.test.ts. Ejecuta pnpm test, lee los errores, corrígelos y vuelve a ejecutar el comando. Detente cuando el código de salida = 0. Máximo 20 iteraciones.
```
Claude inicia el bucle: ejecuta las pruebas, detecta un fallo, abre el archivo, lo corrige y vuelve a ejecutar las pruebas.
4. ### Establece un límite de presupuesto
En una pestaña en segundo plano, usa `/usage` para controlar el consumo. Establece un límite diario de tokens o dinero para no gastar todo tu saldo en un solo bucle. Encontrarás más detalles en la guía sobre [cómo no agotar los límites de Claude Code](https://ailoot.ai/blog/es/claude-code-token-limits-saving/).
5. ### Sigue con tus asuntos
Vuelve dentro de 30 minutos. Si la tarea es sencilla, ya aparecerá «DONE, todas las pruebas pasan». Si es más compleja, lee el informe: «detenido en la iteración 20, motivo X». Corrige a mano lo que el bucle no haya podido resolver y luego vuelve a iniciarlo.
En segundo plano, hay un bucle bien construido que incorpora un patrón de verificador.
## Patrón de verificador: cómo Claude comprueba su propio trabajo en un bucle
Ideas clave
Claude siempre debe tener una forma de comprobar su trabajo. Sin una comprobación, un agente en bucle empieza a alucinar: decide que la tarea está terminada cuando en realidad todo está roto. Un verificador es un comando (pruebas, lint, modelo evaluador, comprobación personalizada) que devuelve un resultado inequívoco: «terminado/no terminado».
Hay tres tipos de verificadores:
**1. Técnico (código de salida)**: el más fiable. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. Devuelven 0 o 1, sin necesidad de interpretación. `/goal` también funciona así: en segundo plano utiliza el modelo evaluador Haiku, que comprueba en cada turno si se ha cumplido la condición (hasta 4000 caracteres).
**2. Modelo evaluador**: un segundo modelo examina el resultado del primero y lo evalúa según una rúbrica. Es útil para tareas sin una comprobación formal («¿Es bueno el estilo de escritura?», «¿El diseño encaja con la marca?»). En Anthropic, esto se llama `Claude Code Review`: un modo en el que un agente revisor independiente busca errores lógicos, casos límite y problemas de seguridad en el trabajo del agente principal. Según los datos internos de Anthropic, detecta **el 84 % de los problemas** en PR grandes (frente al 16 % con el enfoque de referencia).
**3. Comprobación personalizada**: un script de shell que escribes tú. «Si los logs no contienen la palabra ERROR, está terminado». «Si existe el archivo `output.json` y se puede analizar, está terminado». «Si la página `/pricing` devuelve el estado 200, está terminado».
Aquí tienes una plantilla de prompt que puedes poner en `CLAUDE.md` o en un comando:
```
Encuentra 10 razones por las que este proyecto podría haber salido muy mal.
Ponte en la situación de que algo ha salido mal.
Puedo repasar esta historia muchas veces,
antes de publicarla.
```
El error más común de los principiantes es **iniciar un bucle sin un verificador**. El agente da vueltas en círculo: escribe código, no lo comprueba, cree que ha terminado, pasa a la siguiente iteración y vuelve a escribir lo que ya había hecho. Tres horas después, todo es un desastre y la factura asciende a 200 $.
La mejor regla: **escribe primero el verificador y luego inicia el bucle**. Si no puedes expresar la condición de parada en una línea, la tarea aún no está lista para ser autónoma.
## Cómo no gastar miles de dólares durante la noche: límites de presupuesto y condiciones de parada
Ideas clave
Un bucle sin límite presupuestario, condición de parada por coste ni verificador puede generar una factura elevada antes de que alguien se dé cuenta. Tres medidas de protección pueden evitarlo: un límite de iteraciones, un límite de tokens o dinero y un detector de estancamiento.
Tres frenos esenciales para cualquier bucle nocturno:
**1. Límite de iteraciones.** `--max-iterations 20`. El bucle no puede ejecutarse más de N veces, aunque el verificador no se active. Si no ha alcanzado la condición de parada después de 20 iteraciones, la tarea está atascada y necesita intervención humana.
**2. Límite de tokens o dinero.** `/usage limit 50`: no más de 50 $ al día. Al acercarse al límite, el bucle se detiene solo y envía una alerta. Esto protege frente a una situación descontrolada.
**3. Comprobación de progreso con un contrato explícito.** La comparación de `HEAD` siguiente detecta commits nuevos, no todos los cambios de código. Úsala solo en un worktree aislado donde cada iteración que cambie código registre antes un commit local de control. Las ediciones útiles sin commit no cambian `HEAD`; sin ese contrato, un hash igual puede ser una falsa señal de estancamiento. Conserva también el resultado del verificador: un commit nuevo demuestra un cambio registrado, no que la tarea haya mejorado o superado las pruebas.
Estructura ilustrativa de wrapper con estas tres comprobaciones. Las líneas de costes e invocación del agente son ejemplos específicos del ejecutor, no una receta de CLI verificada; confirma esas interfaces en la versión instalada antes de adaptarlo. Para comprobar progreso por commits, exige un commit local de control en cada iteración que cambie código. Si deja ediciones sin commit, detente para revisarlas en vez de etiquetarlas como «sin progreso».
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# Money limit
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: budget cap $MAX_COST_USD reached"
break
fi
# Run
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Completion check
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Solo progreso por commits: cada iteración que cambie código debe guardar un commit.
# HEAD no detecta ediciones útiles que permanezcan sin commit.
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: stagnation 3 iterations"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
Valida el control de progreso antes de ampliar este esquema: una edición sin commit es trabajo sin registrar; un commit de control cambia `HEAD`; solo el verificador separado puede demostrar éxito. Tres comparaciones sin commits nuevos indican ausencia de cambios registrados bajo ese contrato, no que todos los archivos hayan permanecido intactos. Después puedes añadir una alerta de Slack cuando se detenga, un informe automático por Telegram por la mañana o una notificación push cuando el presupuesto llegue al 80 %. El principio es el mismo: un bucle necesita **frenos**, no solo un acelerador.
## 5 escenarios de bucles nocturnos listos para usar
Ideas clave
No todas las tareas son adecuadas para un bucle autónomo. Las buenas candidatas son las tareas iterativas con un verificador inequívoco: pruebas, refactorización, monitorización, pipelines de artículos e importaciones de datos. Las malas candidatas son las tareas sin comprobaciones formales o con varios criterios subjetivos.
**Escenario 1: Hacer que pasen las pruebas que fallan**
```
/goal Hay 47 pruebas fallidas en el directorio tests/. Objetivo: hacer que pasen todas.
Ejecuta pnpm test, lee stderr, abre el archivo que contiene el error, corrígelo y vuelve a ejecutar pnpm test.
Detente cuando el código de salida sea 0. Máximo 30 iteraciones.
```
**Escenario 2: Refactorización amplia en 200 archivos**
```
/batch Sustituye el cliente API antiguo apiV1 por el nuevo apiV2 en todos los archivos bajo src/**/*.ts.
Cada archivo tiene su propio worktree. Después de la sustitución, ejecuta tsc --noEmit y corrige los errores que aparezcan.
Fusiona los worktrees al final.
```
**Escenario 3: Monitorización de producción durante la noche**
```
/loop 30m Cada 30 minutos, comprueba https://your-app.example.com/api/health.
Si no devuelve 200, lee los logs, encuentra la causa, corrígela y vuelve a desplegar.
Registra cada iteración en /tmp/night-monitor.log.
```
**Escenario 4: Importar un conjunto de datos grande con deduplicación**
```
/goal Importa el archivo CSV /tmp/import.csv (12,000 filas) en la tabla clients.
Para cada fila, comprueba si hay un duplicado por correo electrónico; si no lo hay, insértala; si existe, actualízalo.
Registra los conflictos en /tmp/conflicts.log. Detente cuando se haya procesado la última fila.
```
**Escenario 5: Pipeline de artículos (configuración habitual)**
Para un servicio en línea o una agencia que necesita artículos SEO con regularidad, el escenario es el siguiente:
```
/loop 8h Cada 8 horas: abre el archivo de backlog con los temas cuyo estado sea 'queued'.
Si hay un tema disponible, ejecuta la habilidad para redactar una guía.
Publica en dev. Cambia el estado a 'review'. Avisa por Telegram a la persona responsable.
```
## Qué proporcionar en cada iteración: CLAUDE.md y Second Brain como estado
Ideas clave
Sin memoria, Claude empieza desde cero en cada iteración: vuelve a abrir el proyecto, lee archivos y olvida las decisiones de la iteración anterior. Sin `CLAUDE.md`, no conoce la arquitectura; sin `business/` (el Second Brain), no conoce el contexto del producto; sin habilidades, no recuerda tus reglas ni tu estilo. El estado entre iteraciones se conserva en estas tres capas de archivos. Sin ellas, el bucle se deteriora a partir de la iteración 5.
Tres capas de «memoria» del proyecto convierten un prompt puntual en un bucle controlado:
**1. CLAUDE.md**: la constitución del proyecto. Qué es el producto, cuál es la stack, qué reglas hay y qué cosas nunca deben hacerse. Claude lee este archivo al iniciar cada sesión y cada iteración del bucle. Sin él, tiene que «reabrir» el proyecto cada vez, lo que consume contexto y aumenta el riesgo de alucinaciones. Encontrarás una plantilla lista para usar y 6 reglas en la guía de [CLAUDE.md](https://ailoot.ai/blog/es/claude-md-template/).
**2. Second Brain**: una carpeta de conocimientos del negocio: producto, público, objetivos, economía y marketing. No es código, sino significado. Cuando el bucle redacta un artículo o busca una respuesta para soporte, consulta Second Brain y responde con el contexto del proyecto, en lugar de hacerlo desde cero.
**3. Context Engineering**: qué le proporcionas exactamente a Claude en cada iteración. No toda la carpeta Second Brain ni el repositorio completo: solo lo relevante. Plan Mode ayuda: Claude determina qué archivos necesita para la tarea y solo lee esos. Encontrarás más detalles en la guía de [Plan Mode](https://ailoot.ai/blog/es/claude-code-plan-mode/).
El principal principio operativo que tuve que aprender a base de errores:
Estas tres capas forman los **tres pilares** de la metodología: clon de IA (has enseñado a Claude tu estilo y tus reglas mediante las habilidades y CLAUDE.md), Second Brain (el significado del negocio en archivos) y Context Engineering (lo que proporcionas en cada solicitud). Sin los tres, el bucle se convierte en un ciclo infinito con una factura cada vez mayor.
Ideas clave
En un portátil se pueden mantener 5 pestañas numeradas del terminal, cada una con su propio git checkout. Además, se pueden usar entre 5 y 10 sesiones en la aplicación Claude mediante Remote Control en el teléfono: entre 10 y 15 sesiones paralelas en total. Cada una tiene su propia tarea, verificador y bucle.
¿Qué hay en cada sesión? Tareas distintas: un bucle corrige errores, otro escribe nuevas funciones, un tercero revisa las PR del equipo, un cuarto optimiza el rendimiento y un quinto prepara documentación. No es un único agente generalista enorme. Son decenas de agentes especializados, cada uno con su propia habilidad, objetivo y verificador.
El cambio de perspectiva clave:
Para un empresario sin programadores, esto tiene una aplicación concreta. Tienes una cuenta de Claude por 200 $/mes y un portátil normal. Puedes iniciar **5 bucles en paralelo**: soporte, artículos, métricas, pruebas de un producto nuevo y monitorización de la competencia. Cada uno funciona en su propia pestaña de Claude Code. Por la mañana lees el resumen. Esto ya es la norma de trabajo en el verano de 2026.
## Cuatro fallos habituales de los bucles autónomos
Ideas clave
La mayoría de los fallos de los bucles autónomos encajan en cuatro patrones: no hay verificador y el agente decide por sí mismo que ha terminado; no hay límite presupuestario y el bucle gasta el presupuesto durante la noche; no hay estado entre iteraciones y las decisiones se contradicen; la condición de parada es vaga y el bucle no sabe cuándo detenerse.
**Fallo 1: «bucle de alucinaciones»**
El agente decide que ha terminado aunque el verificador no se haya activado. O no hay verificador. Tres horas más tarde, Claude dice: «¡Todo listo!», pero las pruebas fallan, la página no se abre y nada funciona. Ya has gastado 80 $ en iteraciones inútiles.
**Solución:** un verificador estricto (el `exit code` del comando), no una comprobación verbal.
**Fallo 2: «se agotó el presupuesto durante la noche»**
Sin un límite presupuestario, un bucle es una granada sin pasador.
**Solución:** `/usage limit` o un script externo que use `claude usage --json` para detener el bucle cuando alcance un umbral.
**Fallo 3: «el bucle perdió el contexto entre iteraciones»**
En la iteración 1, Claude tomó una decisión arquitectónica. Para la iteración 7, la había olvidado y tomó la decisión contraria. Después de 15 iteraciones, el código es un caos.
**Solución:** una capa de estado mediante `CLAUDE.md` y la carpeta Second Brain. El bucle **escribe** cada decisión arquitectónica en un archivo que lee en la iteración siguiente.
**Fallo 4: «la condición de parada es imprecisa y el bucle se ejecuta para siempre»**
`/goal "Haz que la página sea bonita"`: ¿qué significa «bonita»? Si no hay una métrica inequívoca, el bucle nunca se detendrá. Seguirá funcionando hasta alcanzar el límite de iteraciones o de presupuesto.
**Solución:** la condición de parada siempre debe ser **medible**. No «bonita», sino «Lighthouse Performance ≥ 90, Accessibility ≥ 95». No «funciona», sino «pasan las pruebas de `tests/pricing.test.ts`».
## Cuándo no hace falta la ingeniería de bucles
Ideas clave
La ingeniería de bucles sirve para tareas repetitivas y verificables. No hace falta para tareas creativas puntuales, tareas sin un verificador formal o tareas que requieren una evaluación subjetiva. Conocer los límites importa más que conocer la técnica.
No conviene usar un bucle autónomo para:
- **Una tarea creativa puntual.** Un sitio web para un producto nuevo, un logotipo o un memorando estratégico. En estos casos, un bucle es excesivo; es más fácil escribir un prompt y perfeccionar el resultado a mano.
- **Una tarea sin verificador.** Si no puedes expresar la condición de parada como un código de salida o una señal inequívoca, no inicies el bucle; de lo contrario, será una hoguera interminable.
- **Una tarea que requiera evaluación subjetiva.** «Haz que suene mejor», «mejora la UX para que resulte más agradable»: para esto te necesita a ti, no a un bucle.
- **Un ámbito nuevo y desconocido.** Si ni tú sabes qué aspecto debe tener el resultado terminado, no ejecutes Claude en un bucle. Primero entiéndelo y luego automatízalo.
Y la regla principal que aprendí a base de errores:
La pregunta principal antes de iniciar un bucle es: **¿Puedo describir en una línea cómo sabré que Claude ha terminado?** Si la respuesta es sí, el bucle puede ayudar. Si no, define primero una condición verificable y luego inícialo.
### Fuentes
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - plugin oficial
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - código fuente
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - avance de investigación sobre revisión de PR con varios agentes, tasa de detección del 84 %
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - documentación oficial del comando
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - documentación oficial
La ingeniería de bucles es una capa que se añade a todo lo que ya sabes sobre Claude Code. Primero necesitas los tres pilares: clon de IA + Second Brain + Context Engineering. Sin ellos, el bucle se deteriora a partir de la iteración 5. Sigue explorando Ailoot en [ailoot.ai](https://ailoot.ai/).
## Preguntas sobre Claude Code
### ¿Por qué un HEAD sin cambios puede sugerir falsamente que un bucle no avanzó?
HEAD identifica un commit. Las ediciones útiles del árbol de trabajo no lo cambian hasta confirmarlas. Por eso el detector exige un commit local de control tras cada iteración que cambie código; sin ese contrato, pausa e inspecciona lo que está sin commit en lugar de llamarlo estancamiento.
### ¿Un commit nuevo demuestra que el bucle mejoró el resultado?
No. Solo demuestra que se registró un cambio. Conserva el resultado del verificador junto al punto de control y detente según la condición real de aceptación. Antes de usar el wrapper, valida sus interfaces de invocación y costes específicas del ejecutor.
## Ailoot · La empresa y su cartera de proyectos
Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI.
La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes.
Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.