/goal, /loop o rutinas: deja de vigilar a tu agente de programación

Si todavía escribes un prompt, esperas, lees la respuesta y escribes el siguiente, tu agente de programación es exactamente igual de rápido que tú. Claude Code tiene ya tres formas de dejarle seguir solo: /goal trabaja hasta que se cumple una condición, /loop repite un prompt cada cierto tiempo mientras tu sesión está abierta y las tareas programadas en la nube, que casi todo el mundo sigue llamando rutinas, se ejecutan con el portátil cerrado. Parecen similares, pero resuelven problemas distintos. Si eliges mal, la tarea se para demasiado pronto, no termina nunca o gasta más de tu plan de lo que ahorra. Así elijo entre ellas en proyectos con clientes y así configuro cada una para revisar resultados en lugar de cada paso.

Dominik Heinrich

7 de noviembre de 202610 min de lectura

1. Por qué el ping-pong es el verdadero cuello de botella

En una sesión normal el agente se detiene después de cada respuesta y te espera. Para una pregunta está bien, pero una tarea de ingeniería real, como migrar un módulo a una API nueva, necesita decenas de turnos: ejecutar los tests, leer el fallo, corregir, volver a ejecutar. Si cada turno espera a una persona, pasas la tarde pulsando Enter y el agente pasa casi todo el tiempo parado. La documentación de Claude Code ordena las tres opciones con una pregunta: ¿qué inicia el siguiente turno y qué detiene el trabajo? Con /goal el siguiente turno empieza en cuanto termina el anterior y se detiene cuando un modelo confirma tu condición o la considera imposible. Con /loop el siguiente turno empieza cuando pasa un intervalo. Con una rutina, un horario, una llamada a la API o un evento de GitHub inicia una sesión nueva en la nube. Pensado así, la elección es casi mecánica y dejas de usar una ventana de chat como planificador de trabajos.

2. /goal: trabajar hasta que se cumpla una condición

Escribes /goal seguido de la condición y el turno empieza de inmediato; no hace falta enviar otro prompt. Según la documentación, /goal es por dentro un Stop hook basado en prompt y limitado a la sesión: después de cada turno, Claude Code envía la condición y la conversación a tu modelo pequeño y rápido configurado, que responde «aún no» (Claude sigue y usa el motivo como guía), «cumplida» (el objetivo se borra) o «imposible» (se borra con una entrada de fallo). La consecuencia importante es que el evaluador no ejecuta comandos ni lee archivos. Solo juzga lo que Claude ya ha mostrado en la transcripción, así que «npm test termina con 0» funciona porque la salida de los tests aparece en la conversación, mientras que «el código está limpio» no. La condición puede tener hasta 4.000 caracteres, /goal a secas muestra la condición, el tiempo, los turnos, el gasto de tokens y el último motivo, y /goal clear lo detiene. También funciona sin interfaz con claude -p, que es como ejecuto migraciones largas en entornos tipo CI.

text

/goal all tests in test/billing pass (npm test -- test/billing exits 0),
npm run lint exits 0, no test is skipped or deleted,
no file outside src/billing and test/billing is modified,
and git status shows the work committed on the current branch.
Print the last 20 lines of the test output as proof.
Or stop after 25 turns and list what is still failing and why.

Consejo práctico

/goal no cambia tu modo de permisos. Para turnos sin supervisión ejecútalo en auto mode; en modo manual Claude sigue preguntando antes de cada llamada a herramientas que tu configuración no permita ya, y el objetivo te espera.

3. Escribir una condición que aguante 25 turnos

La documentación recomienda tres ingredientes y, por experiencia, hacen falta los tres. Primero, un estado final medible: un resultado de tests, un código de salida del build, un número de archivos, una cola vacía. Segundo, una comprobación explícita, para que Claude sepa cómo demostrarlo, por ejemplo «npm test termina con 0» o «git status está limpio». Tercero, las restricciones que importan por el camino, como «no se modifica ningún otro archivo de tests», porque un agente bajo presión hace pasar un test debilitándolo sin pestañear. Añade una cláusula de turnos o de tiempo como «o para tras 25 turnos», que el evaluador juzga a partir de la conversación, para que un objetivo no corra toda la noche. Dos trampas que veo a menudo: condiciones que dependen de algo que el evaluador no ve, como un panel o un archivo que Claude nunca imprimió, y trabajo que mantiene ocupado a un subagente o una shell en segundo plano. En ese caso Claude Code se salta la evaluación hasta que un turno termina sin nada en marcha y, a los 30 minutos, empieza a hacer comprobaciones. Y si Claude deja de usar herramientas durante varios turnos, el bucle se detiene y te devuelve el control con el objetivo aún activo.

Consejo práctico

Pide al agente que imprima sus pruebas (códigos de salida, recuentos, las últimas líneas de los tests) al final de cada turno. El evaluador solo puede aprobar lo que puede leer.

How auto mode works with Claude Code, Claude (YouTube). Se carga desde YouTube solo cuando haces clic.

4. /loop: repetir un prompt mientras trabajas

/loop es la herramienta adecuada cuando no hay meta pero algo fuera de la sesión no deja de cambiar: un pull request que recibe comentarios, un pipeline, un despliegue. «/loop 10m revisa la CI de mi PR» se ejecuta con un ritmo fijo; la documentación admite s, m, h y d como unidades y redondea los intervalos raros a un paso de cron limpio, con un minuto como mínimo. Si omites el intervalo, Claude elige tras cada iteración una espera de entre un minuto y una hora, corta mientras termina un build y larga cuando no pasa nada. Un /loop a secas ejecuta el prompt de mantenimiento integrado, que continúa el trabajo pendiente, atiende el pull request de la rama actual y hace pasadas de limpieza, o tu propio .claude/loop.md si existe. Tres límites importan: la sesión y la máquina deben seguir encendidas, las tareas recurrentes caducan solas a los siete días y Esc no detiene un bucle de intervalo fijo. Pídele a Claude que lo cancele, por ejemplo «cancela el bucle de la CI».

text

/loop 10m check the CI status and review comments on my open PR.
If a check failed, read the log, fix the cause on this branch, push and say what you changed.
If a reviewer asked for something, address it or reply why not.
When all checks are green and no comment is open, tell me and stop the loop.

5. Rutinas: se ejecutan con el portátil cerrado

Una rutina, que la documentación llama ahora tarea programada en la nube, es una configuración guardada: un prompt, uno o varios repositorios y un conjunto de conectores, ejecutada en infraestructura gestionada por Anthropic como una sesión completa de Claude Code. Puede tener varios disparadores a la vez. Un horario se ejecuta cada hora, cada noche, cada semana o una sola vez, con una hora como intervalo mínimo. Un disparador de API le da a la tarea su propio endpoint: envías un POST con un bearer token y puedes pasar un campo «text», como el cuerpo de una alerta. Un disparador de GitHub reacciona a eventos como pull_request.opened o una release, con filtros por ramas y etiquetas. Cada ejecución clona los repositorios de cero y sube los cambios a ramas con el prefijo claude/, salvo que el prompt diga otra cosa. Se ejecuta como tú: los commits llevan tu usuario de GitHub y las ejecuciones cuentan contra los límites de tu plan. Se crean en claude.ai/code/routines o con /schedule en la CLI, que solo crea disparadores de horario; los de API solo se crean en la web. Siguen en research preview, están disponibles en Pro, Max, Ultra, Team y Enterprise, y los owners de Team y Enterprise pueden desactivarlas para toda la organización.

bash

# Fire a cloud scheduled task (routine) from an alerting hook.
# URL and token come from the task's API trigger panel on claude.ai/code/routines.
curl -X POST "$ROUTINE_FIRE_URL" \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error rate above 2% on checkout since 14:05 UTC. Stack trace attached."}'

Consejo práctico

El texto enviado al endpoint de la API llega envuelto como datos no confiables, y Claude no sigue instrucciones que contenga salvo que el prompt guardado lo diga. Escribe el prompt nombrando el payload de forma explícita y guarda el token en el almacén de secretos de tu herramienta de alertas.

Diagrama de flujo: /goal ejecuta turnos hasta que un modelo evaluador confirma la condición; /loop repite un prompt cada cierto tiempo en tu sesión; las rutinas inician sesiones en la nube por horario, llamada a la API o evento de GitHub. Las tres terminan en un pull request en una rama y una revisión humana antes del merge. — Tres formas de mantener a Claude Code trabajando: una meta, un temporizador y un disparador en la nube. Todos los caminos acaban en la misma puerta humana.

6. Cuál y cuándo

Mi decisión cabe en tres preguntas. ¿La tarea tiene un estado final que tests o comandos pueden demostrar? Entonces es un /goal, ya sea «poner el build en verde», actualizar un framework o dividir un archivo grande hasta que cada módulo quede por debajo de un tamaño. ¿Tiene que ejecutarse sin ti, según una hora o un evento? Entonces es una rutina en la nube, o una tarea programada de Desktop si necesita archivos que solo están en tu máquina. ¿No tiene fin y solo la necesitas mientras trabajas de todas formas? Entonces es /loop. En mis proyectos eso significa /goal para migraciones y builds en rojo, /loop para acompañar una release o un pull request durante la revisión, y rutinas para la actualización nocturna de dependencias, la comprobación semanal de documentación desfasada y una primera revisión de cada pull request nuevo. Prueba el asistente de decisión de abajo con una tarea de tu propio backlog.

Interactivo

¿Qué modo encaja con tu tarea?

Responde tres preguntas sobre la tarea que quieres que el agente te quite de encima.

1.¿Tiene una meta que una máquina pueda comprobar (tests en verde, archivo creado, métrica alcanzada)?
2.¿Debe repetirse cada cierto tiempo o vigilar algo?
3.¿Debe funcionar con tu portátil apagado, o arrancar por horario, llamada a una API o evento de GitHub?

Todas las calculadoras y checklists

7. Salvaguardas antes de que nada se ejecute sin supervisión

La autonomía solo sale barata si un error sale barato. Mi base con cada cliente: los agentes trabajan en ramas, nunca en main, y la protección de ramas o los rulesets lo imponen, que es también lo que recomienda la documentación de rutinas para controlar dónde pueden subir cambios. Cada objetivo lleva un límite de turnos. El auto mode funciona con reglas explícitas de denegación para secretos como los archivos .env y las carpetas de credenciales, y nadie usa el modo bypass en una máquina que llega a producción. Las rutinas reciben solo los repositorios y conectores que necesitan, porque todo lo que hacen aparece con tu nombre. Vigila también el coste: /usage muestra el coste de la sesión y el consumo del plan, y un objetivo se pausa solo cuando alcanzas un límite de uso en lugar de fallar en silencio. Por último, una persona revisa y hace el merge. En la práctica reviso un pull request terminado con un resumen claro en lugar de treinta pasos intermedios, y ahí está el ahorro de tiempo.

Consejo práctico

Empieza durante dos semanas con rutinas que solo leen e informan (triaje, resúmenes, comentarios de revisión). Cuando su resultado sea útil de forma constante, permite las que suben código.

8. Qué cambia para el equipo

El mayor cambio no es técnico. Cuando los agentes iteran solos, la habilidad escasa pasa a ser definir «terminado» con precisión y revisar bien. Los buenos equipos escriben objetivos como escriben criterios de aceptación, mantienen en el repositorio una pequeña biblioteca de condiciones y prompts de rutinas probados, y tratan sus cambios como código, con revisión. También miden: el tiempo desde el ticket hasta el cambio fusionado, con qué frecuencia el pull request de un agente necesita retrabajo y cuánto cuesta cada cambio fusionado en consumo del plan. En mis propios proyectos, así es como un equipo pequeño entrega miles de pull requests revisados al año sin que nadie vigile una ventana de chat. Las herramientas seguirán cambiando de nombre, como acaban de hacer las rutinas. El patrón se queda: una meta clara, un disparador automático, un lugar seguro donde trabajar y una puerta humana al final.

Conclusión
Define «terminado» una vez, deja que el agente itere en un lugar seguro y dedica tu atención a la revisión en lugar de a cada paso: de ahí sale la velocidad de verdad.

Proyectos reales relacionados

Pruébalo tú mismo

/goal, /loop o rutina

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos