La criatura que vacía tu backlog mientras duermes: cómo diseñar loops con metas y workflows en Claude Code

Loop engineering sin humo: la anatomía de un bucle autónomo, cómo monto el mío con un tablero de GitHub y subagentes, y las piezas de Claude Code que lo hacen posible.

Durante dos años el oficio consistió en escribir el prompt perfecto. La frase exacta, el ejemplo justo, el tono adecuado. Funcionaba. Pero había un detalle incómodo: el bucle eras tú. Tú leías la respuesta, tú juzgabas si servía, tú decidías el siguiente paso y volvías a teclear. Eras el sistema nervioso disparando cada señal a mano, neurona a neurona, durante horas.

En 2026 el oficio cambió de nombre. Addy Osmani lo llamó loop engineering y Peter Steinberger lo resumió sin anestesia: deberías dejar de promptear a tus agentes y empezar a diseñar los bucles que los promptean. El prompt dejó de ser la unidad de trabajo. Ahora la unidad es el bucle.

Diseñar un bucle es, básicamente, construir un arco reflejo que se dispara solo. Y sí, hay algo ligeramente inquietante en la imagen: una criatura tranquila que metaboliza tu backlog mientras tú duermes, ticket a ticket, sin pedir permiso ni cansarse. Vamos a abrirla en canal para ver cómo está hecha por dentro.

1. La anatomía de un bucle

Quita el envoltorio de moda y un agente hace siempre lo mismo, en tres tiempos: reúne contexto, actúa con una herramienta y verifica el resultado. Luego repite. La propia documentación de Claude Code describe ese latido como el «agentic loop»: Claude evalúa, llama a una herramienta, recibe el resultado y vuelve a evaluar, turno tras turno, hasta que ya no necesita más herramientas.

Si te suena a biología, es porque lo es. Tu cuerpo lleva toda la vida sosteniendo 37 grados con exactamente el mismo circuito: un sensor mide, un controlador compara contra un valor deseado, un efector corrige y la corrección se vuelve a medir. Eso es la homeostasis, y es el bucle más antiguo y más fiable que existe. Un loop de agentes no inventa nada nuevo: le pone GPU a un truco que la naturaleza tiene patentado desde hace millones de años.

Dentro de ese latido hay dos papeles que conviene no confundir: un hacedor, que produce, y un verificador, que decide si lo producido sirve. La trampa es pensar que el difícil es el hacedor. No: el hacedor (el modelo) ya es bueno. El que decide si todo el invento funciona es el verificador, y ahí está casi todo el arte.

Si no puedes decir qué significa «hecho», no tienes un bucle. Tienes un deseo.

Esa frase —que circula mucho estos meses entre quien construye loops— es la versión cruda de algo que en mi flujo tiene nombre formal: la Definition of Done. Sin un check claro, el agente no sabe cuándo parar, igual que un termostato sin termómetro: calienta para siempre.

2. Mi loop, hoy

Te enseño las tripas del que uso a diario, porque es más fácil entender un bucle viéndolo correr que leyendo teoría.

El tablero como aparato digestivo

Todo arranca en un tablero de GitHub. Ahí dejo las tareas en columnas, y la única que le importa al sistema es Ready for implement. El tablero hace dos cosas a la vez: es la cola de trabajo y es la memoria externa del loop —el cuaderno que vive fuera de la conversación y recuerda qué está hecho y qué falta—. Pienso en él como en un intestino: las tareas entran por un extremo y avanzan por peristalsis, una a una, hasta salir digeridas por «Closed».

El orquestador reparte; los subagentes ejecutan

Un orquestador principal va sacando tickets de Ready for implement y se los pasa a un subagente de ejecución. Esto es, calcado, el patrón orquestador-trabajadores que Anthropic describe en su guía de agentes: un cerebro que descompone y delega, y unas manos que hacen. El cerebro no toca el código; las manos no deciden la estrategia.

Sobrecarga de skills: la enzima justa para cada sustrato

Aquí viene mi parte favorita. Según la tarea, el orquestador le dice al ejecutor qué skills cargar —una «sobrecarga» deliberada de capacidades—. Una célula no fabrica todas sus enzimas a la vez: expresa la que necesita para el sustrato que tiene delante. Igual el subagente: si toca tocar SQL, carga las skills de datos; si toca front, otras. Contexto limpio, herramientas mínimas, cero ruido.

El revisor y el QA: el bucle dentro del bucle

Cuando el ejecutor termina, el trabajo pasa a un revisor y a un QA. El QA corre los tests y, lo más interesante, propone mejoras: se abre un pequeño bucle entre QA y ejecutor que itera hasta que la cosa pasa. Eso tiene nombre en la literatura: el patrón evaluador-optimizador, un modelo que genera y otro que evalúa, en lazo, hasta que el resultado cumple. Es exactamente la regla de oro de los loops: nadie corrige su propia tarea. El que cocina no es el que prueba la sal.

La Definition of Done abre la última puerta

Cerrado el lazo interno, el ticket vuelve al orquestador, que comprueba contra la Definition of Done. Solo si la cumple, el ticket se mueve a «Closed». Y vuelta a empezar con el siguiente, hasta vaciar el backlog. Dos lazos encajados: el grande, que drena la cola; el pequeño, que pule cada pieza.

3. Las piezas de Claude Code que lo hacen posible

Lo bueno: casi nada de esto hay que montarlo a mano. Claude Code ya trae las piezas; el truco está en saber cuál enciende cada función del bucle.

• Subagentes — trabajadores con su propia ventana de contexto, sus herramientas y sus permisos. Hacen el trabajo sucio en su rincón y solo te devuelven el resumen. Son el hacedor, el revisor y el QA de mi pipeline.
• Skills — instrucciones reutilizables que el agente carga solo cuando hacen falta. La enzima a demanda. La base de mi «sobrecarga de skills».
• Hooks — scripts que disparan en momentos fijos del ciclo (antes de una herramienta, al terminar, al cerrar). No le piden nada al modelo: lo hacen. Un hook Stop que corre los tests es un verificador determinista, sin discusión posible.
• /goal y /loop — el verificador de fábrica. Con /goal le das una meta comprobable y el agente itera solo hasta cumplirla; un modelo pequeño y rápido revisa tras cada vuelta si ya está. Clave: pon siempre un tope («para tras N turnos»).
• Dynamic workflows — cuando una tarea necesita más agentes de los que cabe coordinar en una conversación, Claude escribe un script (lo invocas con ultracode) que sostiene el plan, las ramas y los resultados intermedios. Hasta 16 agentes en paralelo y un tope duro para que no se desboque.
• Agent SDK — el mismo bucle, pero embebido en tu código, con max_turns, max_budget_usd y modos de permiso. Es el paso de «juguete en mi terminal» a «proceso en producción».

4. Patrones que vale la pena robar

De la investigación reciente saqué algunas ideas que ya he metido (o estoy metiendo) en mi loop:

• Verificador independiente, siempre. El que revisa no es el que ejecuta. Parece obvio y casi nadie lo respeta.
• Pon un tope, o la criatura no para de comer. max_turns, presupuesto en dólares, «para tras 30 turnos». Un bucle sin freno no es autonomía: es un coche sin pedal.
• Empieza en solo-lectura. Deja que el loop resuma y proponga unos días antes de dejarle tocar nada. Confianza ganada, no concedida.
• Worktrees separados. Dos agentes en paralelo sobre el mismo árbol se pisan. Dales celdas distintas, como cultivos que no se contaminan.
• Memoria fuera del chat. Un fichero (o un tablero, como el mío) que recuerde el estado aunque la conversación se reinicie. El contexto es volátil; la cola, no.

Ese último peldaño merece un párrafo. Una routine es el temporizador que lanza el bucle por su cuenta, en la nube, a las 8 de la mañana, sin que tú aprietes nada. Meta comprobable + temporizador = tu primer agente verdaderamente autónomo. Aquí es donde la metáfora se pone distópica: la criatura ya no espera a que la despiertes.

5. LoopMaker: el bucle que construye el bucle

El siguiente salto no es escribir loops, sino que un asistente los monte por ti. Y Claude Code ya hace una versión de esto: con ultracode no ejecutas la tarea a mano, sino que Claude te escribe el workflow; el creador de routines es un wizard sin código. El plan deja de estar en tu cabeza y pasa a ser algo que la máquina redacta.

Yo estoy empezando a usar un wizard de este tipo —lo llamo LoopMaker— que convierte todo el montaje en un par de preguntas guiadas: qué cola, qué Definition of Done, qué tope. Es, literalmente, un bucle creando un bucle. La célula que fabrica el ribosoma que fabrica la célula. La máquina que diseña la máquina. Suena a ciencia ficción y, sin embargo, es martes.

---

Al final, todo se reduce a una fórmula tonta de enunciar y difícil de cumplir: tu palanca = habilidad × claridad. La habilidad es revisar el trabajo y mejorar el lazo. La claridad es saber decir, con exactitud, qué significa «hecho». El reflejo nunca será mejor que su receptor.

Así que sí: deja que la criatura te vacíe el backlog mientras duermes. Pero asegúrate de ser tú quien define qué es «terminar». Porque si no se lo dices tú, lo decidirá ella.

---

Fuentes

• Claude Code Docs — How the agent loop works
• Claude Code Docs — Create custom subagents
• Claude Code Docs — Extend Claude with skills
• Claude Code Docs — Orchestrate subagents at scale with dynamic workflows
• Anthropic — Building Effective Agents
• Addy Osmani — Loop Engineering
• Sabrina Ramonov — AI Loop Engineering: Claude Code /goal + Routines