Primeros pasos con bucles en Claude Code

Hay mucha conversación actualmente sobre "diseñar bucles" en lugar de simplemente dar instrucciones a tu agente de codificación. Si pasas un tiempo en X tratando de definir qué es realmente un bucle, te encontrarás con múltiples respuestas diferentes.

En el equipo de Claude Code, definimos los bucles como agentes que repiten ciclos de trabajo hasta que se cumple una condición de parada. Categorizamos varios tipos de bucles según:

• Cómo se activan
• Cómo se detienen
• Qué primitiva de Claude Code se utiliza
• Qué tipo de tarea es más adecuada para cada uno.

Cubriremos los principales tipos de bucles, cuándo usar cada uno y cómo mantener la calidad del código mientras se gestiona el uso de tokens. No todas las tareas requieren bucles complejos; comienza con la solución más simple y usa estos patrones de forma selectiva.

Bucles basados en turnos

• Activado por: Una instrucción del usuario.
• Criterio de parada: Claude determina que ha completado la tarea o necesita contexto adicional.
• Mejor usado para: Tareas más cortas que no forman parte de un proceso o cronograma regular.
• Uso gestionado mediante: Escribir instrucciones específicas y mejorar la verificación usando habilidades para reducir el número de turnos.‍

Cada instrucción que envías inicia un bucle manual donde tú diriges cada turno. Claude reúne contexto, toma acción, verifica su trabajo, repite si es necesario y responde. A esto lo llamamos el bucle agéntico.

Por ejemplo, pídele a Claude que cree un botón de "Me gusta". Lee tu código, hace la edición, ejecuta las pruebas y te devuelve algo que cree que funciona. Luego, tú verificas manualmente el trabajo y escribes la siguiente instrucción.

Puedes mejorar el paso de verificación codificando tus pasos manuales como un archivo SKILL.md para que Claude pueda verificar más de su propio trabajo, de principio a fin. Esto debe incluir herramientas o conectores que permitan a Claude ver, medir o interactuar con el resultado. Cuanto más cuantitativas sean las verificaciones, más fácil será para Claude auto-verificarse.

Por ejemplo, en tu archivo SKILL.md podrías especificar:

1---
2name: verify-frontend-change
3description: Verifica cualquier cambio de UI de principio a fin antes de declararlo como completado.
4---
5
6# Verificando cambios de frontend
7Nunca reportes un cambio de UI como completado basándote solo en una edición exitosa. Verifícalo como lo haría un revisor humano:
8
91. Inicia el servidor de desarrollo y abre la página editada en el navegador.
10
112. Interactúa directamente con el cambio. Para un nuevo control (botón, campo de entrada, interruptor): haz clic en él, confirma el cambio de estado esperado y toma una captura de pantalla antes/después.
12
133. Revisa la consola del navegador: cero errores o advertencias nuevas.
14
154. Usa el MCP de Chrome Devtools, ejecuta un seguimiento de rendimiento y audita los Core Web Vitals.
16
17Si algún paso falla, corrige el problema y vuelve a ejecutar desde el paso 1 — no entregues trabajo parcialmente verificado.

Bucle basado en objetivos (/goal)

• Activado por: Una instrucción manual en tiempo real.
• Criterio de parada: Objetivo alcanzado O número máximo de turnos alcanzado.
• Mejor usado para: Tareas que tienen criterios de salida verificables.
• Uso gestionado mediante: Establecer criterios de finalización específicos y límites de turnos explícitos, "detente después de 5 intentos."

A veces, un solo turno no es suficiente, especialmente para tareas más complejas. Los agentes funcionan mejor cuando pueden iterar. Puedes extender cuánto tiempo sigue iterando Claude definiendo cómo se ve "completado" con /goal.

Cuando defines los criterios de éxito, Claude no tiene que determinar qué es "suficientemente bueno" y terminar el bucle antes de tiempo. Cada vez que Claude intenta detenerse, un modelo evaluador verifica tu condición y lo envía de vuelta a trabajar hasta que se cumpla el objetivo o se alcance el número de turnos que definiste.

Por eso los criterios deterministas, como la cantidad de pruebas aprobadas o superar un cierto umbral de puntuación, son tan efectivos.

Por ejemplo:

1/goal obtener una puntuación de Lighthouse en la página de inicio de 90 o más, detente después de 5 intentos.

Bucle basado en tiempo (/loop y /schedule)

• Activado por: Un intervalo de tiempo especificado.
• Criterio de parada: Tú lo cancelas, o el trabajo se completa (el PR se fusiona, la cola está vacía).
• Mejor usado para: Trabajo recurrente, o para interactuar con entornos/sistemas externos.
• Uso gestionado mediante: Establecer intervalos más largos o reaccionar basándose en eventos en lugar de tiempo.

Algunos trabajos agénticos son recurrentes: la tarea sigue siendo la misma y solo cambian las entradas. Por ejemplo, resumir mensajes de Slack cada mañana. Otros trabajos dependen de sistemas externos, y una forma sencilla de interactuar con uno es verificarlo en un intervalo y reaccionar a lo que cambió. Por ejemplo, un PR que puede recibir revisiones de código o fallar en CI.

Para estos casos, puedes activar la ejecución de Claude con \/loop`` que vuelve a ejecutar una instrucción en un intervalo. Por ejemplo:

1/loop 5m revisa mi PR, atiende los comentarios de la revisión y corrige el CI que falla

\/loop` se ejecuta en tu computadora, por lo que si la apagas, se detiene. Puedes mover el bucle a la nube creando una rutina con \/schedule\`.

Bucles proactivos

• Activado por: Un evento o cronograma, sin intervención humana en tiempo real.
• Criterio de parada: Cada tarea finaliza cuando se cumple su objetivo. La rutina en sí se ejecuta hasta que la desactives.
• Mejor usado para: Flujos recurrentes de trabajo bien definido: informes de errores, triaje de incidencias, migraciones, actualizaciones de dependencias, etc.
• Uso gestionado mediante: Enrutar rutinas a modelos más pequeños y rápidos y usar el modelo más capaz para decisiones críticas.

Las primitivas anteriores, junto con otras características de Claude Code como el modo automático y los flujos de trabajo dinámicos (vista previa de investigación) se pueden combinar en un bucle para trabajos de larga duración.

Por ejemplo, para manejar comentarios entrantes, puedes usar:

1. `/schedule` (vista previa de investigación) para ejecutar una rutina que verifique si hay nuevos informes
2. `/goal` para definir cómo se ve "completado" y habilidades para documentar cómo verificarlo
3. Flujos de trabajo dinámicos para orquestar agentes que trien cada informe, lo corrijan y revisen la corrección
4. Modo automático para que la rutina se ejecute sin detenerse a pedir permiso

Uniendo todo, una instrucción podría verse así:

1/schedule cada hora: revisa el canal de comentarios del proyecto en busca de informes de errores. /goal: no te detengas hasta que cada informe encontrado en esta ejecución esté triado, solucionado y respondido. Al corregir un error, usa un flujo de trabajo para explorar tres soluciones en árboles de trabajo paralelos y haz que un juez las revise de manera adversarial.

Manteniendo la calidad del código

La calidad del resultado de un bucle depende del sistema que lo rodea. Al diseñar el sistema:

• Mantén la base de código limpia: Claude sigue los patrones y convenciones que ya existen en tu base de código.
• Dale a Claude una forma de verificar su propio trabajo: Codifica cómo se ve "bien" para ti y tu equipo con habilidades.
• Haz que la documentación sea fácil de alcanzar: Las guías de frameworks y bibliotecas tienen las mejores prácticas actualizadas.
• Usa un segundo agente para revisiones de código: Un revisor con contexto nuevo es menos sesgado y no está influenciado por el razonamiento del agente principal. Puedes usar la habilidad incorporada \/code-review`` o Code Review para Github.

Cuando un resultado individual no cumple con el estándar, no te limites a corregir el problema individual, intenta codificarlo para mejorar el sistema para todas las iteraciones futuras.

Gestionando el uso de tokens

Para gestionar el uso de tokens, los bucles deben tener límites claros:

• Elige la primitiva y el modelo adecuados para el trabajo: Las tareas más pequeñas no necesitan múltiples agentes o bucles. Algunas tareas pueden usar modelos más baratos y rápidos.
• Define criterios claros de éxito y parada: Sé específico sobre cómo se ve "completado" para que Claude pueda llegar a la solución antes (pero no demasiado pronto).
• Prueba antes de una ejecución grande: Los flujos de trabajo dinámicos pueden generar cientos de agentes. Mide el uso en una porción más pequeña del trabajo primero.
• Usa scripts para trabajo determinista: Ejecutar un script es más barato que razonar a través de los pasos. Por ejemplo, una habilidad de PDF puede incluir un script de llenado de formularios que Claude ejecuta cada vez, en lugar de volver a derivar el código.
• No ejecutes rutinas con más frecuencia de la necesaria: Ajusta el intervalo a la frecuencia con la que cambia lo que estás monitoreando.
• Revisa el uso: El comando \/usage` desglosa el uso reciente por habilidades, subagentes y MCPs, \/goal\ sin argumentos muestra el número de turnos y el uso de tokens hasta el momento, \/workflows\` muestra el uso de tokens de cada agente y puedes detener un agente en cualquier momento.

Cómo empezar

Para resumir:

Bucle

Delegas

Úsalo cuando

Recurre a

Basado en turnos

La verificación

Estás explorando o decidiendo

Habilidades de verificación personalizadas

Basado en objetivos

La condición de parada

Sabes cómo se ve "completado"

/goal

Basado en tiempo

El disparador

El trabajo ocurre fuera de tu proyecto en un cronograma

/loop

,

/schedule

Proactivo

La instrucción

El trabajo es recurrente y está bien definido

Todo lo anterior, y flujos de trabajo dinámicos

Para empezar con los bucles, observa el trabajo que ya haces. Elige una tarea donde seas el cuello de botella y pregúntate qué parte podrías delegar: ¿puedes escribir la verificación? ¿El objetivo es lo suficientemente claro? ¿El trabajo llega en un cronograma?

Una vez que tengas una idea, ejecuta el bucle, observa los resultados, como dónde se estanca o se excede, y no tengas miedo de iterar sobre él.

Para obtener más información, lee la documentación de Claude Code sobre ejecutar agentes en paralelo, así como las páginas de bucle, cronograma, objetivo y flujos de trabajo dinámicos.

Este artículo fue escrito por @delba_oliveira