Ingeniería de bucles: curso acelerado

15 conceptos · De la programación con agentes a sistemas que se dan indicaciones solos, trabajan mientras duermes e incluso sueñan

Ya sabes usar un agente de programación. Le das una instrucción, lee tus archivos, los modifica y tú compruebas lo que hizo. Luego le das la siguiente instrucción y después otra. Tú controlas cada paso.

Ahora imagina que sueltas el control. En vez de guiarlo paso a paso, construyes un sistema pequeño. Cada mañana se inicia solo, revisa qué cambió durante la noche, decide qué hacer, asigna cada tarea a un agente y comprueba el resultado. Solo te consulta cuando una decisión de verdad necesita a una persona. Construyes el sistema una vez y, a partir de entonces, funciona por sí mismo.

Esto es ingeniería de bucles. La habilidad más importante cambia: antes era el prompt que escribías; ahora es el bucle que diseñas. Este curso enseña dos cosas: de qué se compone un bucle y cómo construir uno. Lo crearás tanto en Claude Code como en OpenCode. Ambas herramientas llegan al mismo resultado por caminos muy distintos.

Primero necesitas Claude Code y OpenCode: curso acelerado. Ese curso presentó el modo de planificación, la gestión del contexto, el archivo de reglas, las skills, los subagentes y MCP. Este curso da por sentado que conoces todo eso. Si esos términos son nuevos para ti, completa primero aquel curso. La ingeniería de bucles se apoya en esos fundamentos. También conviene hacer antes Desarrollo guiado por especificaciones. La condición de parada de un bucle es, en realidad, una especificación, y ese curso te enseña a escribirla. Puedes continuar sin él, pero tus bucles solo serán tan buenos como las condiciones que sepas definir.

¿Es tu primera vez aquí? Repaso de 2 minutos de lo que ya deberías saber

• Modo de planificación: el agente lee tus archivos y presenta un plan antes de cambiar nada. Tú lo apruebas primero.
• El archivo de reglas (CLAUDE.md / AGENTS.md): notas breves y permanentes que el agente lee al inicio de cada sesión.
• Skills (SKILL.md): instrucciones guardadas que el agente solo carga cuando la tarea coincide con ellas.
• Subagentes: asistentes separados, cada uno con su propia ventana de contexto. Hacen una tarea y devuelven únicamente el resultado.
• Conectores / MCP: la forma estándar de conectar un agente con herramientas externas, como GitHub, Slack o una base de datos.
• Gestión del contexto: mantén breve la conversación. A medida que se llena, el modelo rinde peor y cuesta más.

Si alguno de estos conceptos es nuevo para ti, completa primero el curso acelerado de programación con agentes. Este curso usa esas ideas directamente.

Palabras clave en lenguaje sencillo

Estas palabras aparecen a lo largo del curso. Lee la lista una vez y vuelve a ella cuando algún término no esté claro.

Término	Significado en lenguaje sencillo
Agente	Un sistema de IA capaz de usar herramientas y completar pasos, no solo de responder una pregunta.
Prompt	La instrucción que das al agente.
Bucle	Un sistema que inicia el trabajo, lo comprueba, registra el resultado y repite cuando hace falta.
Pulso	Una ejecución completa del bucle.
Latido	La programación, el evento o la condición que inicia un pulso.
Activar / disparar	Iniciar una ejecución. Por ejemplo, un evento de GitHub puede activar o «disparar» una Routine.
Sin supervisión	En ejecución sin que una persona observe cada paso.
Condición de parada	Una regla comprobable que indica al bucle cuándo terminó el trabajo.
Creador-revisor	Un agente crea el trabajo. Otro agente o comando distinto lo comprueba.
Worktree	Una carpeta de trabajo y rama separadas que evitan que agentes en paralelo cambien los mismos archivos.
Skill	Instrucciones guardadas del proyecto que un agente puede reutilizar.
Conector / MCP	Una conexión que permite al agente usar un sistema externo como GitHub, Slack o una base de datos.
Estado / memoria	Información guardada fuera del modelo para que una ejecución posterior sepa qué ocurrió antes.
Columna vertebral	Nombre que da este curso al estado guardado que conecta un pulso con el siguiente.
Puerta humana	Punto en el que una persona debe revisar o aprobar el trabajo antes de continuar con una acción arriesgada.
Routine	Automatización en la nube de Claude Code. Inicia una sesión nueva a partir de un prompt y un activador guardados.

En ocasiones, el curso usa metáforas corporales: el latido inicia el trabajo, el cuerpo lo realiza y la columna vertebral transporta la memoria entre ejecuciones. Cada metáfora siempre aparece junto con su significado técnico.

De dónde viene esta idea

En 2026, quienes construyen estas herramientas lo expresaron con claridad. Boris Cherny creó Claude Code. Dijo: «Ya no le doy prompts a Claude. Tengo bucles en ejecución que le dan prompts a Claude... mi trabajo es escribir bucles». Peter Steinberger, creador de OpenClaw, afirmó que «deberías diseñar bucles que den prompts a tus agentes». Después, Addy Osmani dio nombre al patrón y enumeró sus partes. Ninguno dice que el trabajo se haya vuelto más fácil. Dicen que la habilidad importante cambió de lugar. Esa es la idea sobre la que se construye todo este curso.

Algunas personas describen el diseño de bucles como la habilidad más importante para construir agentes en este momento. Otras dicen que solo es un nombre nuevo para un trabajo que las herramientas de agentes ya hacían. Ambas posturas tienen parte de razón. Los componentes no son nuevos, pero se han vuelto lo bastante económicos y fiables para el uso cotidiano. Por eso, la tarea principal consiste cada vez más en diseñar el bucle y no en guiar cada turno del agente. Un nombre se vuelve útil cuando la práctica pasa a formar parte del trabajo habitual. (Las citas, afirmaciones y precisiones técnicas principales aparecen al final, en Fuentes y lecturas adicionales.)

El cambio de mentalidad, en una imagen

Reproduce el cambio (30 segundos)

La imagen anterior, convertida en algo que puedes reproducir. Inicia por tu cuenta cada paso del lado izquierdo y compáralo con el lado derecho, donde el sistema inicia cada paso automáticamente. Volverás a encontrar cada intervención sustituida: la programación en la Parte 2, el revisor en el Concepto 11 y la puerta humana en la Parte 5.

Abrir ↗

Este curso enseña dos herramientas a la vez. Un método que funciona en ambas es una habilidad transferible, no un truco para un producto concreto. Cada herramienta proporciona los componentes de una forma distinta. Claude Code incluye muchas funciones de bucle dentro del producto. OpenCode aporta el agente trabajador, mientras que tú usas el sistema operativo o CI para iniciar cada ejecución. Los comandos cambian, pero la forma del bucle es la misma.

En pocas palabras

Claude Code te proporciona más funciones de bucle. OpenCode te da el trabajador y tú conectas el planificador y los demás componentes.

Información válida a mediados de julio de 2026. Ambas herramientas cambian con rapidez y varias funciones de bucle de Claude Code son versiones preliminares de investigación. Antes de cada sesión, ejecuta claude update u opencode upgrade. Consulta la documentación vigente (code.claude.com/docs, opencode.ai/docs) antes de confiar en un límite o una opción.

¿Dónde puede ejecutarse un bucle?

Un bucle real funciona sin supervisión. Se da prompts a sí mismo mientras estás ausente. Hasta julio de 2026, la web no podía hacer esto. En claude.ai y chatgpt.com encontrabas un cuadro de chat, y ese cuadro te esperaba en cada turno: tú eras la programación. Para ejecutar un bucle real había que salir del navegador y usar una herramienta capaz de activarse sola, es decir, Claude Code u OpenCode.

Eso cambió en julio de 2026. Ambos proveedores integraron sus productos de agentes en las mismas direcciones web. Claude Cowork ahora funciona en claude.ai; consulta el curso acelerado de Cowork. Sus sesiones remotas se ejecutan en los servidores de Anthropic, por lo que un bucle programado puede activarse desde una pestaña que cerraste hace mucho. ChatGPT Work hace lo mismo en chatgpt.com. Por tanto, ya no es cierto que «no se puede ejecutar un bucle en la web». La formulación precisa es otra: no puedes ejecutar un bucle en el cuadro de chat, pero sí en las superficies web que lo rodean. La mayoría son de pago y varias están en beta, con despliegues graduales. Puedes aprender y diseñar un bucle en cualquier lugar. Para ejecutarlo necesitas una de estas superficies. Este curso muestra las dos orientadas a programación.

«Pero hice todo el curso guiado por especificaciones en claude.ai. ¿También puedo ejecutar allí un bucle?»

Es una buena pregunta, y la respuesta cambió en julio de 2026. Veamos el antes y el después.

Antes de julio de 2026: claude.ai y chatgpt.com eran cuadros de chat. Un cuadro de chat te espera en cada turno. No puede iniciarse según una programación o un evento. Podías volver a darle un prompt manualmente, pero entonces tú eras el latido, justo la tarea que un bucle pretende eliminar. Por tanto, no podías ejecutar un bucle en la web. Lo diseñabas allí y después pasabas a Claude Code u OpenCode para ejecutarlo.

Después de julio de 2026: ambos proveedores incorporaron sus productos de agentes a esas mismas direcciones web. El cuadro de chat no cambió. Sigue esperándote y siempre lo hará. Lo que cambió es lo que aparece a su lado:

• Cowork en claude.ai (beta, primero en el plan Max y después en más planes). Inicia una sesión de Cowork en la misma pestaña del navegador donde conversas y se ejecutará como una sesión remota en los servidores de Anthropic. Las tareas programadas se activan sin ningún dispositivo conectado: portátil cerrado y teléfono en el bolsillo. Las sesiones y los archivos se guardan en tu cuenta, lo que te da una columna vertebral que no tuviste que construir. Cuando el bucle llega a una decisión que solo tú puedes tomar, la pregunta aparece en tu teléfono. Esa es la puerta humana integrada en el producto. Cowork es el equivalente no orientado a programación de una Routine.
• Claude Code Routines, con el mismo inicio de sesión de claude.ai y creadas en claude.ai/code/routines, ya ofrecían esto para tareas de programación: sesiones nuevas en la nube, en servidores de Anthropic, aunque el portátil esté cerrado. Requiere un plan de pago y es una versión preliminar de investigación.
• ChatGPT Work en chatgpt.com (OpenAI, 9 de julio de 2026). El mismo cambio del otro lado: un agente con tareas programadas, Codex integrado y sesiones sincronizadas en la nube, que funciona desde la web tanto en equipos de escritorio como en dispositivos móviles. Si lo interpretas con el vocabulario de este curso, aparecen las seis partes. Las tareas programadas son el latido, las apps conectadas son los conectores, el modo Goal de Codex es el bucle condicional que se ejecuta hasta terminar y las sesiones sincronizadas en la nube transportan el estado entre dispositivos.
• OpenCode sigue haciéndolo con tu propio planificador, como cron o GitHub Actions, sin necesitar la nube de un proveedor.

Dos proveedores, con pocos días de diferencia, llevaron el bucle al navegador. Es la evidencia más sólida hasta ahora de la afirmación central de este curso: la habilidad está en la forma, no en la herramienta.

Por tanto, la división del trabajo ahora es más precisa, no ha desaparecido. El cuadro de chat es donde diseñas y practicas un bucle: redactas la skill, escribes el prompt del revisor, defines la condición de parada y ejecutas un pulso a mano. La superficie de agente que aparece a su lado, ya sea Cowork, una Routine, ChatGPT Work u OpenCode, es donde lo ejecutas. Esa transición es el paso natural después del Desarrollo guiado por especificaciones.

Información válida a mediados de julio de 2026. Tanto Cowork en la web como ChatGPT Work apenas tienen unas semanas, sus despliegues avanzan por etapas según el plan y el uso se mide. Consulta las páginas vigentes de los productos antes de confiar en un límite o una función.

En pocas palabras

Usa el cuadro de chat para diseñar y practicar un bucle. Para ejecutarlo sin supervisión, usa una superficie que se active sola: Claude Code, OpenCode, Cowork o ChatGPT Work. Desde julio de 2026 ya no tienes que salir del navegador para hacerlo. Cowork funciona en claude.ai y ChatGPT Work en chatgpt.com.

Pruébalo mientras lees

A partir de aquí, casi todos los conceptos se pueden ejecutar en una sesión real, no solo leer. Mantén una terminal abierta junto a esta página (claude u opencode) y prueba cada idea al encontrarla. Empieza con un repositorio git pequeño y desechable para que un bucle no pueda dañar nada importante.

Qué cubre este curso

Parte	Tema	Qué aprenderás
1	El cambio	Qué es un bucle, cuáles son sus seis partes y las dos formas de construir uno
2	Qué inicia el bucle	Cómo hacer que algo se ejecute solo: en sesión, condicional (hasta terminar), programado o dirigido por eventos
3	Qué hace el bucle	Aislamiento, conocimiento, acción y separación entre creador y revisor
4	Memoria entre ejecuciones	Estado que sobrevive entre ejecuciones, la parte que suele olvidarse
5	Un bucle, dos veces	Un bucle completo, desde la revisión matutina hasta el PR, con archivos reales y construido en ambas herramientas
6	Mantener el control humano	Coste de tokens, comprobación del trabajo y trampas que aumentan a medida que mejoran los bucles
En vivo	Dogfooding: los bucles del propio libro	Los dos bucles que ejecutan este curso en producción y dónde sitúa cada uno a la persona
Práctica	Proyectos prácticos	Ocho bucles, de fáciles a difíciles, que construirás por tu cuenta
Apéndice	Routines de principio a fin	Guía completa de Routines: todos los campos del formulario, los tres activadores, secretos y problemas comunes, más tres ejercicios prácticos y un proyecto final

Tres bucles que puedes ejecutar hoy, no solo leer

La mayor parte de este curso presenta ideas. Estos tres casos son distintos. Tres de los cuatro latidos incluyen un proyecto pequeño que puedes clonar y activar en minutos. Cada proyecto aparece dentro del concepto que lo explica, justo cuando empieza a tener sentido.

Proyecto	Concepto	Qué ocurre
Observa la estación espacial	4, en sesión	Con una sola frase, la ISS real informa de su posición cada minuto mientras haces otra cosa. Si cierras la terminal, la observación termina, y ese es precisamente el concepto.
Construye tu portafolio	5, condicional	Añade tu CV, entrega a /goal una meta final y aléjate. Lee el PDF, diseña una página, comprueba su propio trabajo y vuelve a intentarlo hasta aprobar.
El timbre	7, dirigido por eventos	Abre un pull request y aparecerá una revisión que nadie solicitó, en un equipo que no es el tuyo, sin importar si tu portátil está abierto o cerrado.

La dificultad aumenta en el orden adecuado: el primero lleva cinco minutos y no requiere nada, el segundo ocupa una tarde de verdad y el tercero funciona por completo sin ti. El Concepto 6, las programaciones, aún no tiene proyecto: hace falta una noche para demostrar que funciona.

Los tres están en agentfactory-labs. Haz al menos el primero. Un latido que has visto activarse vale más que tres sobre los que solo has leído.

¿Quieres aprender haciendo? Lee primero la Parte 5 para ver un bucle completo de principio a fin. Después vuelve a sus componentes. Cuando las ideas estén claras, los proyectos prácticos te ofrecen ocho bucles para construir por tu cuenta.

Dos formas de leer este curso

¿Es tu primera vez? Sigue la ruta principal: las Partes 1 a 5 en orden. Omite todas las notas marcadas como «Para profundizar». Su contenido es válido, pero nada posterior depende de ellas. Déjalas para la segunda lectura. Completa los Proyectos 1 a 3 y detente. Esta ruta lleva unas dos horas, o tres si las ideas son nuevas. Al terminar podrás construir y ejecutar un bucle seguro.

Segunda lectura, después de que tu primer bucle se haya ejecutado de verdad: lee las notas avanzadas, toda la Parte 6, los Proyectos 4 a 8 y el apéndice de Routines, con sus tres ejercicios, cuando estés listo para construir una rutina real en la nube. El curso está diseñado para que esta segunda lectura resulte útil porque ya tienes un bucle en ejecución sobre el cual reflexionar.

Qué recordar y qué consultar

Dos capas recorren este curso y envejecen de formas muy distintas. Recuerda la primera. Consulta la segunda.

• La capa duradera. La forma de un bucle, con un latido, cuatro componentes de trabajo y una columna vertebral; la separación entre creador y revisor; y las dos cosas que un bucle nunca puede hacer por ti: la intención, expresar lo que quieres con suficiente claridad para comprobar el resultado, y la responsabilidad, hacerte cargo de lo que se publica. Esa es la habilidad. Sigue siendo válida aunque cambien todos los comandos que aparecen a continuación.
• La capa mecánica. Cada opción, ruta, nombre de modelo y comando. Estas herramientas se actualizan cada semana y varias funciones son versiones preliminares de investigación. Trata cada comando como una referencia a la documentación vigente, no como un dato que debas memorizar. Cuando el curso y la documentación actual no coincidan, la documentación tiene razón.

Si recuerdas la forma de seis partes y olvidas cada pulsación de teclas, habrás aprendido ingeniería de bucles. Si memorizas las pulsaciones y no entiendes la forma, solo habrás aprendido los comandos de este mes.

---

📚 Material didáctico

Abrir la presentación completa

Ver la presentación completa: Ingeniería de bucles: curso acelerado

---

Parte 1: el cambio

1. De los prompts a los bucles

Durante unos dos años, obtener trabajo de un agente de programación fue sencillo. Escribías un buen prompt, le dabas suficiente contexto, leías la respuesta y escribías lo siguiente. El agente era una herramienta que usabas paso a paso.

Un bucle es distinto. Sustituye a la persona que opera por un sistema. El sistema encuentra el trabajo, lo reparte, comprueba el resultado, registra lo que hizo y decide qué hacer después. Da prompts al agente por ti.

Entonces, ¿dónde queda tu valor? No desaparece. Se desplaza a las dos cosas que un bucle no puede hacer por ti. La primera es la intención: expresar lo que quieres con claridad suficiente para poder comprobar el resultado. La segunda es la responsabilidad: responder por el resultado. Tú eres responsable de lo que se publica. El bucle se ocupa de los pasos intermedios; los dos extremos siguen siendo tuyos. Te pagan por tu intención y tu criterio, no por ignorar cómo se hizo el trabajo.

El cambio no consiste en «un prompt más largo». Es una nueva forma de trabajar:

Dar prompts, lo que ya conoces	Diseñar bucles, lo que añade este curso
Tú inicias cada turno	Una programación o un evento inicia cada turno
Lees el resultado y decides qué sigue	Un revisor comprueba el resultado y el bucle decide qué sigue
Se detiene en cuanto dejas de escribir	Sigue en ejecución mientras duermes
Una tarea, una sesión y toda tu atención	Muchas ejecuciones pequeñas, casi siempre sin supervisión; solo intervienes en la puerta

Dos bucles comparten un nombre

Detalle técnico opcional que puedes omitir en la primera lectura.

La expresión «ingeniería de bucles» se usa para dos cosas diferentes. Este curso enseña el bucle grande, pero también escucharás la expresión aplicada a un bucle pequeño. Veamos qué significa cada uno para evitar confusiones.

El bucle pequeño, o bucle interno. Dentro de cada agente hay un ciclo diminuto de código. Funciona así: se envía el contexto al modelo, el modelo pide usar herramientas, se ejecutan las herramientas, se añaden los resultados al contexto y se repite. Cuando el modelo deja de pedir herramientas, el ciclo termina. En código, ocupa solo unas líneas:

while True:
    reply = model(context)
    if not reply.tool_calls:
        break                     # the model decided it is done
    context += run_tools(reply.tool_calls)

Observa la línea que contiene break. Es importante. El bucle pequeño se detiene cuando el propio modelo decide que terminó. Nada comprueba si el modelo tiene razón.

Esto plantea un problema: el modelo juzga su propio trabajo. Imagina un fallo habitual. El agente modifica un archivo, escribe con seguridad algo como «¡Listo! Todo corregido» y se detiene. Pero nunca ejecutó las pruebas. El turno terminó; la tarea no.

Por eso el curso enseña paradas externas. Una parada externa no depende de la opinión del propio modelo:

• una condición comprobada, que demuestra el trabajo con una prueba real
• un límite, es decir, un número máximo de intentos
• una comprobación de falta de progreso, para detenerse si nada mejora
• un revisor separado, un segundo proceso que evalúa el trabajo

Todas existen por la misma razón: la única parada que posee por sí solo el bucle pequeño es la opinión del modelo sobre su propio trabajo.

El bucle grande, o bucle externo, que enseña este curso. Imagina el bucle pequeño como un trabajador que realiza una tarea. El bucle grande es el responsable. Decide qué tarea asignar al trabajador, cuándo comenzar, cómo evaluar el resultado y qué recordar para mañana. Una ejecución completa del bucle pequeño es solo un pulso del bucle grande.

Cómo encajan las capas. Cada capa envuelve la anterior. Además, se convirtieron en el centro de atención del sector aproximadamente en este orden, con cerca de un año de diferencia entre ellas. Por eso cada una vivió un periodo de gran interés:

1. Ingeniería de prompts: las palabras que envías.
2. Ingeniería de contexto: todo lo que el modelo ve en un turno.
3. Ingeniería del arnés: el código que rodea al modelo, ejecuta herramientas y gestiona errores. Aquí vive el bucle pequeño.
4. Ingeniería de bucles: el tema de este curso. Es el ciclo externo: en qué trabaja el sistema completo, cuándo comienza y cómo sabe que terminó.

Por eso tu prompt importa menos que antes. Ahora es solo una entrada de un sistema mucho mayor.

Cada capa también detiene un tipo distinto de fallo, por eso ninguna puede sostener a las demás por sí sola. Un contexto sólido puede salvar un prompt débil, pero ningún prompt puede compensar un contexto ausente, un revisor inexistente o una programación que sigues haciendo tú. Por tanto, al construir conviene preguntarte: ¿cuáles de estas capas sigo realizando a mano?

Fortalecer el bucle pequeño con buenas condiciones de parada, un contexto limpio y herramientas bien elegidas exige trabajo real. Sin embargo, todo ocurre dentro de un pulso. Cuando el bucle pequeño sea relevante para el grande, este curso lo señalará. Consulta las condiciones de parada en el Concepto 5 y el diseño de conectores en el Concepto 10.

Esto no es magia. No significa «constrúyelo una vez y no vuelvas a mirarlo». Un bucle que funciona solo también puede equivocarse solo. Todo en este curso busca ayudarte a construir un bucle en el que puedas confiar cuando se ejecute sin ti. Eso es más difícil que dar prompts, no más fácil. La recompensa es el apalancamiento: construyes un buen bucle y repite una y otra vez el trabajo que, de otro modo, tendrías que iniciar a mano cada vez.

2. De qué se compone un bucle

Un bucle que de verdad funciona por sí solo tiene cinco componentes de trabajo y una capa de memoria guardada. Este curso llama columna vertebral a esa capa de memoria. Ya conociste cuatro de los cinco componentes de trabajo en el curso de programación con agentes. Aquí cumplen una función nueva.

1. Latido: una programación o un evento que inicia el bucle. Sin él tienes una ejecución, no un bucle. Aprende ahora una palabra porque el curso la usa constantemente: cada activación individual del bucle, es decir, un recorrido completo de sus pasos, se llama pulso. El latido produce los pulsos. Todo lo que aparece a continuación ocurre dentro de un pulso.
2. Worktree: aislamiento para que dos agentes que trabajan al mismo tiempo no sobrescriban los archivos del otro.
3. Skill: el conocimiento del proyecto escrito una sola vez, para que ninguna ejecución empiece desde cero.
4. Subagentes: la separación entre creador y revisor. El agente que escribe el código no es el que lo evalúa.
5. Conector (MCP): permite que el bucle actúe en tus herramientas reales, por ejemplo, que abra un PR o actualice un ticket, en vez de limitarse a sugerir.

Y la sexta parte, la que suelen omitir los principiantes:

6. Estado / memoria, la columna vertebral. Un archivo en disco, o un tablero como Linear, que registra lo que se hizo y lo que sigue. El modelo olvida todo entre ejecuciones. La columna vertebral permite que la ejecución de hoy sepa qué hizo la de ayer. Sin columna vertebral no hay bucle. Sin ella, el bucle repite eternamente su primer paso.

El resto del curso dedica una sección a cada parte y después presenta un ejemplo completo que las une.

¿Esto solo sirve para código?

No. Los ejemplos del curso usan código, es decir, repositorios, pruebas y PR, porque allí las herramientas son más eficaces. Sin embargo, a la forma del bucle no le importa cuál sea el trabajo. Un libro, un informe, un curso o un boletín pueden vivir en un repositorio lleno de archivos, y cada parte del bucle se aplica igual. Este libro, por ejemplo, es un repositorio de archivos Markdown. Una comprobación nocturna de enlaces, una revisión de estilo o una pasada que detecta nombres de modelos obsoletos son, en todos los casos, bucles de este capítulo.

Una cosa sí cambia: el revisor. El código cuenta con los revisores más honestos que existen, las pruebas y los linters, comandos que demuestran que algo está «terminado». La prosa no tiene una suite de pruebas. Por eso un bucle de escritura se apoya en dos comprobaciones más débiles: las mecánicas cuando existen, como enlaces rotos, figuras ausentes, palabras prohibidas o niveles de encabezado, y un agente revisor con una rúbrica escrita para todo lo demás. El peldaño mecánico es más amplio que las comprobaciones integradas. Las reglas que solo conoce tu proyecto, como «no usar fechas relativas en archivos de memoria» o «cada figura debe tener un texto alternativo de más de 40 palabras», también se convierten en comandos cuando las escribes. El interludio posterior al Concepto 11 muestra cómo hacerlo, y cada regla que bajas de la rúbrica a un comando transforma una afirmación en una prueba. Un truco permite usar la rúbrica como condición de parada: asígnale una puntuación y un umbral. «Evalúa este borrador con la rúbrica. No te detengas por debajo de 95» convierte un juicio flexible en algo sobre lo que el bucle puede actuar. Aun así, la puntuación de un modelo sigue siendo una afirmación, no una prueba, y es más débil que una prueba superada. Cuanto más débil sea el revisor, más trabajo deberá pasar por la puerta humana.

Hay otra cosa que no cambia: el menú de latidos. El dominio nunca elige el latido; lo hace la forma de la tarea. «Haz esto ahora, hasta que termine» es un bucle condicional y comienza de inmediato. «Haz esto cada noche» es una programación y empieza a la hora fijada. «Reacciona cuando llegue algo» es un evento. El menú es el mismo tanto si el repositorio contiene código como capítulos. Además, mientras escribes o programas activamente, por lo general no hay ningún bucle. Tú eres el latido, y los bucles se ocupan de los bloques acotados y del mantenimiento que te rodea.

Si trabajas con documentos en vez de código, lee este curso tal como está y después consulta el curso acelerado de Cowork y OpenWork para ver los mismos bucles con herramientas no orientadas a programación.

3. Dos formas de construir un bucle: herramientas integradas o conectadas por tu cuenta

Este es el único punto donde las herramientas difieren de verdad, y esa diferencia determina todo lo que sigue.

Claude Code incluye los componentes del bucle dentro del producto. El latido (/loop, /schedule y Routines en la nube), el bucle condicional que se ejecuta hasta terminar con un revisor integrado (/goal), el aislamiento (--worktree) y la recepción de eventos (Channels) son ahora funciones integradas. Hace un año tenías que escribir y mantener un montón de scripts de shell para conseguirlo. Hoy, principalmente, debes configurarlo.

La función principal es Routines: automatizaciones en la nube que se ejecutan en los servidores de Anthropic incluso cuando el portátil está cerrado. Pueden comenzar según una programación, una llamada de API o un evento de GitHub. A cambio, cada cuenta tiene un límite diario de ejecuciones. En el lanzamiento eran 5 ejecuciones al día en Pro, 15 en Max y 25 en Team/Enterprise. Puedes pagar por uso adicional tras superar el límite, y las ejecuciones programadas para una sola ocasión no cuentan. Sin embargo, la documentación ya no publica cifras fijas, así que considéralas ejemplos del lanzamiento, no una promesa. Routines es una versión preliminar de investigación y los límites pueden cambiar. La página de uso (claude.ai/settings/usage) es la única cifra en la que debes confiar.

OpenCode te proporciona el agente trabajador, pero no un planificador integrado en la nube. Tú inicias ese trabajador desde el sistema operativo o CI.

El comando clave es opencode run "<prompt>". Ejecuta un prompt sin la pantalla de chat, imprime el resultado y termina. Ese único comando constituye un pulso de un bucle. Lo conviertes en un bucle al envolverlo en algo que se activa con un temporizador: cron o launchd en macOS y Linux, Task Scheduler en Windows, o GitHub Actions con un activador de programación. Esto requiere más configuración, pero te da control total. Se ejecuta en las máquinas que ya tienes y no necesita la nube de ningún proveedor.

La habilidad es el bucle, no los comandos

Observa que las dos pestañas describen las mismas cinco partes. Un latido sigue siendo un latido, tanto si es una Routine gestionada como una línea de cron. La separación entre creador y revisor representa la misma idea, ya evalúe /goal el trabajo o lo haga un segundo opencode run. Aprende una vez la forma del bucle y podrás transferirla. Por eso enseñamos ambas herramientas.

El bucle completo que construirás

Antes de estudiar las partes, observa la meta. El bucle que construirás en la Parte 5 consta de seis pasos sencillos:

every weekday at 9am:                 # 1. Heartbeat
  read progress.md                    # 6. Spine (memory)
  find overnight CI failures + issues # what to work on
  for each one:
    draft a fix in its own checkout   # 2. Worktree
    using the project's triage skill  # 3. Skill
    have a separate reviewer grade it # 4. Subagents (maker/checker)
    if PASS: open a PR via GitHub      # 5. Connector (MCP)
    if risky: write it to progress.md and leave it for a human
  update progress.md                  # 6. Spine again

Mantén presente esta imagen. Cada concepto de las Partes 2 a 4 corresponde a una de sus líneas.

Comprueba lo aprendido

Un bucle se ejecuta cada mañana, pero cada ejecución comienza desde cero y nunca recuerda lo que hizo ayer. ¿Cuál de las seis partes falta y por qué rompe eso el bucle?

Mostrar respuesta

La columna vertebral, es decir, el estado o la memoria. El modelo olvida todo entre ejecuciones. Sin un archivo de estado en disco, el bucle repite eternamente su primer paso en vez de continuar a partir del trabajo de ayer.

---

Parte 2: qué inicia el bucle (el latido)

El latido es lo que inicia cada ejecución. Hay cuatro tipos. Van desde «repetir mientras esta sesión esté abierta» hasta «ejecutar sin que haya una persona presente». Apréndelos en orden. La mayoría de los sistemas desatendidos usan horarios o eventos.

Estos son los cuatro tipos en palabras sencillas, antes de entrar en detalles. Un bucle en sesión es como un temporizador de cocina. Solo suena mientras estás en la cocina. Un bucle condicional (ejecutar hasta terminar) significa «sigue cocinando hasta que quien prueba la comida diga que está lista». Un horario es como un despertador. Suena estés o no en casa. Y un evento es como un timbre. No sucede nada hasta que alguien lo pulsa. Entonces suena de inmediato. Conserva estas cuatro imágenes mentales. Cada comando que aparece abajo es simplemente una de ellas con un nombre.

Una idea sostiene los cuatro tipos: un bucle no es una sola acción. Es haz esto, espera y vuelve a hacerlo, una y otra vez, así que algo debe permanecer activo entre pulsos para disparar el siguiente. La única pregunta es dónde vive ese algo.

• Un bucle en sesión mantiene su temporizador en tu sesión abierta, el proceso que sigue funcionando mientras la terminal está abierta. Al cerrar la sesión, desaparece lo que sostenía el temporizador y el bucle se detiene.
• Una tarea programada o Routine (las construirás en el Concepto 6) mueve el temporizador fuera de la sesión, a un planificador que nunca duerme (cron en tu propio equipo o los servidores de Anthropic para una Routine en la nube). Con cada pulso, lanza una ejecución nueva y breve, deja que termine, la cierra y lanza otra nueva la próxima vez. Es el mismo bucle, pero nada tuyo tiene que permanecer abierto.

Latido	Dónde vive el temporizador	Qué permanece activo entre pulsos
/loop en sesión	dentro de la sesión	tu sesión abierta (tu equipo, con la terminal abierta)
Tarea programada o Routine	fuera, en un planificador	el planificador, que lanza una ejecución nueva con cada pulso

Conserva también esta imagen. Explica todos los límites que vienen: un bucle en sesión se detiene cuando lo hace su sesión, y uno que deba sobrevivir a un portátil cerrado necesita el tipo externo (Concepto 6).

4. Bucles en sesión (se repiten mientras observas)

Este es el latido más sencillo. Vuelves a ejecutar un prompt con un temporizador mientras la sesión está abierta. Sirve para «vigila esto hasta que termine»: un despliegue, una ejecución larga de pruebas o un trabajo de CI.

Prueba el bucle en sesión (30 segundos)

Dispara un pulso en cada intervalo mientras la sesión está abierta y detecta el despliegue porque te quedaste. Cierra la sesión y la vigilancia se detiene; por eso un bucle en sesión no puede ejecutarse mientras duermes (Concepto 6).

Abrir ↗

Usa la skill integrada /loop. Dale un intervalo de tiempo y un prompt:

/loop 5m check if the deployment finished and tell me what happened

Claude convierte el intervalo en un horario, asigna un ID al trabajo y ejecuta el prompt cada 5 minutos mientras la sesión permanezca abierta. Cuando termines, cancélalo y sigue adelante.

Cancelar un /loop. Cada bucle es una tarea programada con un ID, así que lo detienes del mismo modo en que lo iniciaste: con lenguaje natural.

show my running loops
cancel the deploy-check loop

Claude busca la tarea y la cancela. Si hay varios bucles en ejecución, preguntará cuál quieres detener; también puedes darle directamente el ID de la tarea. Cerrar la sesión también detiene un bucle de sesión simple, pero cancelarlo es la forma correcta: un bucle que pretendías detener no debería depender del cierre de la sesión. Los subcomandos exactos son la capa mecánica. Si alguna vez falla el lenguaje natural, consulta la documentación actual.

Ejecuta uno ahora: cinco minutos, un bucle real

Leer sobre un latido no es lo mismo que verlo dispararse. Hay un proyecto pequeño para este concepto que no hace nada más: observa cómo la Estación Espacial Internacional real vuela alrededor de la Tierra.

git clone https://github.com/panaversity/agentfactory-labs.git
cd agentfactory-labs/crash-course/loop-eng/iss-loop
claude

Responde yes cuando pregunte si confías en la carpeta. Eso activa el permiso incluido en el proyecto, para que el bucle nunca se detenga a pedirte confirmación. Después escribe una frase sencilla:

/loop show me the location of the ISS every minute

Eso es lo último que escribes. Cada minuto llega una posición nueva mientras te ocupas de otra cosa. Vale la pena observar dos detalles, porque juntos contienen todo el concepto:

• /loop interpretó «cada minuto» como el latido. No escribiste ningún horario, script ni URL. La carpeta del proyecto contiene todo eso, y por esa razón tu prompt pudo ser una sola frase.
• Ahora cierra la terminal. La vigilancia termina con ella. No es un error. Es la definición de un bucle en sesión y la razón de que existan los Conceptos 6 y 7.

Las instrucciones completas y dos prompts más difíciles para probar están en el README del proyecto.

Opcional: ¿qué sucede cuando se cierra la sesión?

Un límite que debes conocer: un /loop de sesión simple se ejecuta dentro de tu sesión a propósito. Cierra la terminal o deja que el portátil entre en suspensión y se detendrá. Es una función de seguridad, no un error. Un bucle informal en sesión no está pensado para sobrevivir a la sesión que lo inició. Dos cambios recientes flexibilizan esa regla:

• --resume recupera las tareas que todavía no han caducado. Una tarea recurrente sigue siendo válida durante siete días después de crearla.
• Mover la sesión a segundo plano lleva consigo tus tareas /loop, por lo que siguen disparándose aunque no haya una terminal abierta. La limitación: no reproducen los disparos que perdieron mientras el equipo estaba en suspensión.

Para un trabajo que deba seguir ejecutándose pase lo que pase, no dependas de /loop. Usa una tarea programada o una Routine (Concepto 6). Ahora la herramienta también se encarga de esto. En una sesión en la nube (una que se ejecuta en un servidor remoto, no en tu propio equipo), las versiones recientes ya no ofrecen /loop, porque esa sesión se cierra en cuanto termina tu solicitud. No queda nada en ejecución que mantenga el bucle activo.

Una opción intermedia: las sesiones en segundo plano.

Una sesión en segundo plano es el peldaño intermedio entre un /loop en sesión y una Routine. Mantiene una ejecución activa en tu propio equipo después de cerrar la ventana de la terminal. Se inicia con claude --bg.

Por sí sola, hace un trabajo y se detiene. No se repite con un temporizador. Su valor está en transportar un bucle. Inicia un /loop, envía esa sesión a segundo plano y el bucle seguirá con ella, disparándose incluso con la ventana cerrada. (claude agents la mostrará más tarde y /resume la volverá a abrir, marcada como bg).

Úsala cuando quieras cerrar la terminal pero mantener un bucle vigilando algo, como un despliegue o una ejecución larga de pruebas. Recuerda el costo de que siga «activo en tu propio equipo»: el equipo debe permanecer despierto. En cuanto el trabajo tenga que sobrevivir a un portátil cerrado, habrás entrado en el terreno de los planificadores y la herramienta correcta será una Routine (Concepto 6).

Los tres peldaños responden a una sola pregunta: ¿cuánto debe permanecer activo?

Peldaño	Opción	¿Sigue disparándose tras cerrar la terminal?	¿Sigue disparándose con el portátil suspendido o apagado?
Inferior	/loop en sesión	No	No
Intermedio	Sesión en segundo plano (--bg) que transporta un /loop	Sí	No (necesita que tu equipo esté despierto)
Superior	Tarea programada o Routine	Sí	Sí (una Routine en la nube se ejecuta en servidores de Anthropic)

OpenCode no tiene el comando /loop. Tú mismo construyes el temporizador con el shell. Como opencode run termina después de un prompt, un bucle while con un sleep hace el mismo trabajo:

while true; do
  opencode run "check if the deployment finished; if it did, say DONE"
  sleep 300   # 5 minutes
done

Es la misma idea que /loop, construida con componentes de nivel inferior. El shell es el latido y opencode run es el pulso. Para detener este bucle, pulsa Ctrl-C. Si se ejecuta en segundo plano, termina su proceso. Cada nuevo opencode run inicia primero todo el entorno de ejecución, es decir, la configuración, el modelo, los plugins y cualquier servidor MCP, antes de hacer una sola cosa. Para evitar pagar ese costo de inicio en cada pulso, inicia un servidor una vez y conéctate a él:

opencode serve --port 4096 &
# then, each beat:
opencode run --attach http://localhost:4096 "check the deploy status"

En términos sencillos

Usa un bucle en sesión cuando todavía estés observando el trabajo. Se detiene cuando lo hace la sesión o el equipo. Usa una Routine en la nube u otra programación desatendida cuando el trabajo deba continuar sin ti.

5. Bucle condicional o ejecutar hasta terminar (detenerse mediante una comprobación, no por el reloj)

Un bucle con temporizador fijo (Concepto 4) se repite en un intervalo elegido. Cada ejecución puede comprobar el trabajo, pero el resultado no detiene el temporizador. El bucle continúa hasta que lo canceles, termine la sesión o caduque la tarea.

Un bucle condicional, también llamado ejecutar hasta terminar, se detiene cuando una condición concreta se vuelve verdadera. Piensa: «Ejecuta hasta que pasen las pruebas», no «Ejecuta cada cinco minutos mientras observo».

La diferencia clave es sencilla: un bucle con temporizador fijo no sabe cuándo terminó el trabajo. Un bucle condicional se detiene porque el trabajo terminó. Un comando o verificador independiente debe decidirlo. El agente que hizo el trabajo no debería aprobar su propio resultado.

Prueba ejecutar hasta terminar (30 segundos)

El bucle sigue intentándolo y un verificador independiente decide cuándo está «terminado». Se detiene en cuanto se demuestra que se alcanzó el objetivo, sin temporizador y sin ti.

Abrir ↗

Usa /goal. Dale una condición de parada que Claude pueda demostrar en su propia salida, como «todas las pruebas de test/auth pasan». Claude sigue trabajando hasta que se cumple la condición.

Después de cada turno, otro modelo más pequeño, Haiku de forma predeterminada, lee la transcripción y pregunta: «¿Terminamos?». Así, el agente que escribió el código no califica su propio trabajo.

El verificador no puede ejecutar comandos. Solo puede leer la conversación. Por eso, el agente ejecutor debe ejecutar las pruebas y mostrar los resultados en su salida. Sin pruebas visibles, el verificador no puede confirmar que se alcanzó el objetivo.

/goal All tests in test/auth pass and `npm run lint` is clean.

Editará, ejecutará las pruebas, leerá los fallos, volverá a intentarlo y solo se detendrá cuando el verificador confirme que la condición se cumple de verdad, o cuando lo detengas con /goal clear. No existe una opción integrada de «rendirse después de N intentos». Si quieres un límite, escríbelo en la condición (…or stop after 20 turns). Escribe condiciones que un comando pueda demostrar: «las pruebas pasan y el lint está limpio», no «el código de autenticación es bueno». Aquí es donde la especificación del Desarrollo Basado en Especificaciones da fruto. Sus criterios de aceptación ya son condiciones que un comando puede demostrar, así que una buena especificación te ofrece gratis la condición de parada.

Opcional: configuración actual de reintentos de Claude Code

Una ejecución desatendida significa que el bucle trabaja sin que nadie lo observe, durante la noche o mientras estás lejos del teclado. No hay una persona que note si se atasca y lo detenga. Precisamente por eso los reintentos necesitan un límite aquí.

Un reintento ocurre cuando el bucle vuelve a probar un paso que falló (por ejemplo, una llamada a una API que agotó el tiempo de espera). Sin un tope, un bucle atascado podría reintentar indefinidamente mientras duermes y consumir tiempo y tokens. Por eso Claude Code ahora establece ese tope por ti:

• De forma predeterminada, los errores temporales se reintentan hasta 10 veces (CLAUDE_CODE_MAX_RETRIES), cifra que puedes elevar hasta un máximo de 15.
• Para sesiones desatendidas, como los trabajos de CI, establece CLAUDE_CODE_RETRY_WATCHDOG=1. Así se reintentan los errores temporales (como un problema breve de red) durante mucho más tiempo (hasta 300 veces al escribir esto, con unas tres horas de espera progresiva) y se elimina el tope de 15 cuando defines tu propio MAX_RETRIES.

Los nombres de las opciones y las cifras son la capa mecánica, así que consulta la documentación actual antes de confiar en ellos. La idea duradera es que incluso el proveedor asume ahora que una ejecución desatendida necesita un límite elegido de forma deliberada.

Construye algo real: tu propio portafolio

npm test es una condición de parada clara porque alguien ya escribió las pruebas. La mayoría del trabajo no es así. El proyecto Portafolio plantea una pregunta más difícil: ¿qué significa «terminado» para una página que verá una persona y puedes expresarlo con suficiente precisión para que un bucle lo alcance?

Coloca el PDF de tu CV o perfil de LinkedIn en la carpeta y dale a /goal una meta final:

/goal Build my portfolio in site/ from my-cv.pdf, following spec.md. Done when `python3 check.py site` prints 20/20 and the reviewer agent replies PASS on all six judgment promises — show me both. Stop after 15 check attempts or 3 review rounds and write what is still failing to progress.md.

Después aléjate. Lee tu PDF, decide un diseño, escribe el texto, construye la página, ejecuta el verificador, lee sus propios fallos y vuelve a intentarlo hasta que esa frase sea verdadera.

Cada cláusula pone a trabajar una idea de este concepto. Una condición que un comando puede demostrar: check.py ejecuta 20 comprobaciones que una máquina puede resolver, entre ellas la presencia de cinco secciones, las relaciones de contraste y que nada se salga de la pantalla de un teléfono. Pruebas visibles: show me both está ahí porque el verificador de /goal solo lee la transcripción y no puede confirmar un resultado que no se haya mostrado. Un tope: 15 intentos, porque /goal no tiene una forma integrada de rendirse y un bucle que persiga una condición imposible lo hará toda la noche. Y un verificador distinto del creador: un agente revisor independiente que la especificación hace obligatorio.

Ese último punto es donde el proyecto deja de ser un tutorial. 20/20 no significa que esté terminado. El revisor también debe aprobar seis aspectos que ningún comando puede medir: ¿el texto es fiel a tu CV?, ¿hay un diseño y no solo formato?, ¿esto podría haber sido simplemente un PDF? La especificación lo dice sin rodeos: «La Parte A es el trabajo de una mañana. La Parte B es el trabajo de verdad». Ya viste esta idea en la escala de verificadores del Concepto 2. Aquí la experimentarás.

Hay una regla que el proyecto no flexibiliza, y es la más incisiva: nunca edites check.py para conseguir que pase. Eso es exactamente lo que intentará un bucle que optimiza para obtener un resultado verde, y notar ese impulso es la lección.

OpenCode no tiene /goal, así que construyes la misma parada creador-verificador con el shell y códigos de salida. El patrón es sencillo. El agente hace el trabajo. Después, un comando real (no el agente) decide si debe detenerse.

for i in $(seq 1 8); do          # cap the tries — never loop forever
  opencode run "Make the tests in test/auth pass and fix any lint errors."
  if npm test -- test/auth && npm run lint; then
    echo "Condition met on try $i"; break
  fi
done

Aquí, el ejecutor de pruebas y el linter son el verificador. Son el verificador más honesto que existe, porque un comando no puede convencerse de que el trabajo está bien. Para una comprobación más inteligente, ejecuta un segundo opencode run con un agente revisor dedicado (Concepto 11) y haz que este imprima PASS o FAIL. Limita siempre los intentos. Un bucle que reintenta sin límite es la receta para que el gasto de tokens crezca sin control.

OpenCode también ha empezado a incorporar el límite. Cualquier agente acepta un límite steps en su configuración (el nombre anterior, maxSteps, está obsoleto). Cuando un agente alcanza el límite, recibe la instrucción de resumir lo que hizo y lo que queda, en lugar de seguir intentándolo. Los dos límites protegen cosas distintas. El tope del shell limita cuántos pulsos dispara el bucle. steps limita cuántos turnos emplea un agente dentro de un pulso. Establece ambos.

Da siempre al bucle una forma de detenerse

Todo bucle necesita tres paradas. Cada una evita una forma concreta de fallar:

Parada	Qué es	Si la omites...
Condición de éxito	cómo sabe el bucle que la tarea terminó	nada define «terminado», así que el bucle no puede detenerse a propósito ni evaluarse
Límite	un tope: máximo de intentos, minutos o gasto	un objetivo inalcanzable consume todo tu presupuesto de tokens
Comprobación de no progreso	detecta cuando el agente repite la misma acción con los mismos argumentos (está atascado y reintentar no lo arreglará)	consume todo el límite repitiendo un mismo error

Un nombre que encontrarás en internet: el bucle Ralph. Es el bucle sencillo más conocido de ejecutar hasta terminar. Ejecuta el mismo prompt una y otra vez; cada ejecución lee y actualiza un archivo de estado. Solo conserva dos de las tres paradas (una condición de éxito y un límite de tiempo), sin comprobación de atasco, skill ni verificador independiente. Esa sencillez extrema es precisamente lo que hace tan clara la lección. Un bucle Ralph con una condición vaga deambula hasta agotar el tiempo. El mismo bucle funciona bien con una condición que un comando pueda demostrar.

El bucle solo es tan bueno como su condición de parada.

Las ejecuciones largas empeoran con el tiempo

Un bucle de ejecutar hasta terminar que dura muchos turnos llena su propio contexto de basura: salidas antiguas de herramientas, callejones sin salida y razonamientos obsoletos. A medida que crece la acumulación, las respuestas del modelo empeoran. La comunidad llama al resultado doom loop: un contexto desordenado lleva a una decisión peor, que añade más desorden y hace que la siguiente decisión sea todavía peor. Las defensas son los mismos hábitos de contexto del curso de programación agéntica:

• Compacta las ejecuciones largas: de vez en cuando, sustituye el intercambio completo por un resumen breve de lo ocurrido para mantener pequeño el contexto.
• Mueve las salidas grandes a archivos: escribe los resultados extensos (registros, datos o texto generado) en un archivo y conserva solo una referencia en el contexto, en lugar de pegarlo todo.
• Entrega las subtareas desordenadas a un subagente: deja que un asistente haga la exploración ruidosa en su propio contexto y devuelva solo la respuesta limpia.

La idea que une las tres defensas es tratar el contexto como un presupuesto que gastas de forma deliberada, no como un cubo que sigues llenando. Un contexto más pequeño y limpio mantiene precisas las decisiones de una ejecución larga.

6. Horarios desatendidos (se ejecutan mientras duermes)

Este es el latido que da sentido a la ingeniería de bucles: una tarea que se ejecuta estés o no frente al equipo. «Todos los días laborables a las 9:00, revisa los fallos de CI de la noche». «Cada lunes, comprueba las dependencias y abre un PR con las correcciones seguras».

Prueba una Routine (40 segundos)

Configura una Routine en claude.ai, cierra el portátil y observa cómo los servidores de Anthropic la mantienen en ejecución según el horario, aunque tu portátil esté cerrado.

Abrir ↗

Primero, aclaremos los nombres. Un planificador es el concepto general: cualquier reloj siempre activo que inicia puntualmente una ejecución nueva (cron, GitHub Actions o un servicio en la nube). Una Routine es el planificador propio de Claude Code alojado en la nube, donde Anthropic proporciona tanto el reloj como el equipo, para que nada tuyo tenga que estar encendido. Toda Routine es un planificador. No todo planificador es una Routine.

Hay dos tipos, según necesites o no que el portátil esté encendido:

Routines en la nube (el portátil puede estar apagado). Son la opción moderna predeterminada y merecen una explicación pausada. Una Routine en la nube es una instrucción permanente que vive en los servidores de Anthropic, no en tu equipo. Escribes la instrucción una vez. Desde entonces se ejecuta por sí sola a la hora que fijaste, con el portátil abierto, suspendido o guardado en una bolsa. Imagínala como contratar a una persona que trabaja en la oficina de Anthropic, no en la tuya: le entregas una descripción escrita del trabajo y este se hace sin que tengas que alojarlo.

Mantén un ejemplo presente durante esta sección. Cada mañana dedicas 30 minutos al mismo triaje: leer los issues que llegaron durante la noche, etiquetarlos, marcar cualquier cosa que parezca un fallo grave y publicar un resumen en el Slack del equipo. Esa media hora es una Routine perfecta. Se repite, sigue reglas que puedes escribir y no te necesita a ti. Necesita tus instrucciones.

Las cuatro partes de toda Routine. Crear una significa completar cuatro espacios. Cada uno responde una pregunta.

1. El prompt: ¿qué debe hacer? Es la instrucción permanente, escrita como la especificación que aprendiste a redactar: un objetivo, reglas y una definición de «terminado». Es el mismo prompt en cada ejecución y no hay nadie presente para aclararlo, así que debe funcionar durante tu ausencia. Para el ejemplo de triaje:

Review all issues opened in the last 24 hours. Label each as bug,
feature-request, or question. If any issue describes a crash or data
loss, add the "urgent" label. Then post a summary to the #triage Slack
channel: total new issues, how many urgent, and one line per urgent
issue. If there are no new issues, post "No new issues overnight."
Do not close or comment on any issue.

Observa la anatomía de la especificación: un objetivo (clasificar y resumir), reglas (etiquetar de esas formas y considerar urgente un fallo grave o una pérdida de datos), un límite (no cerrar ni comentar nada) y una definición de «terminado» incluso para el caso vacío.

2. Los repositorios: ¿qué puede tocar? Indicas los repositorios en los que puede trabajar. Todo lo que no incluyas queda fuera de su alcance. Concede acceso a yourteam/product-app y solo a ese. Para esta Routine, tus demás repositorios, incluido el que contiene el código de facturación, no existen.

3. Los conectores: ¿a qué puede acceder? Slack, correo electrónico y calendarios. Son las manos de la Routine fuera del repositorio: la forma en que lee el mundo exterior y te informa. Adjunta el conector de Slack para que pueda publicar en #triage, y nada más. Los conectores son permisos, no sugerencias: sin un conector de correo electrónico, no podría enviar un mensaje aunque el prompt se lo pidiera.

4. El activador: ¿cuándo comienza? Es el latido. Hay tres tipos para tres formas de trabajo. Un horario: el reloj la inicia todos los días laborables a las 8:30, para que el resumen esté listo antes de que el equipo se siente a trabajar. Una llamada a la API: otro programa la inicia; por ejemplo, tu script de despliegue termina una versión y dispara una ejecución de «haz una prueba de humo de la versión e informa», de modo que la Routine se ejecuta justo cuando hay algo que comprobar, no según un reloj fijo. Un evento de GitHub: el evento del repositorio la inicia; así, un activador «pull request abierto» se ejecuta cero veces en un día tranquilo y nueve en uno ajetreado (el Concepto 7 explica esto).

Qué hacer, dónde puede actuar, a qué puede acceder y cuándo comienza. Toda Routine se compone de esas cuatro respuestas. El agente de triaje de issues ya está completamente especificado: el prompt anterior, un repositorio, un conector de Slack y los días laborables a las 8:30.

Una función, tres puertas. Puedes crear una Routine en claude.ai/code/routines, en la app de escritorio o con /schedule en la CLI. No son tres funciones distintas. Los tres métodos administran la misma función en la nube: toda Routine, sin importar desde qué puerta se cree, se guarda en la misma cuenta en la nube y aparece en los tres lugares. Por ejemplo, puedes crearla con /schedule en la terminal y editarla después en un navegador.

Qué sucede en una ejecución. El lunes a las 8:30, los servidores de Anthropic inician una sesión nueva de Claude, le entregan tu prompt y le dan exactamente el repositorio y los conectores que indicaste. Lee los issues del fin de semana, los etiqueta, publica en #triage («7 issues nuevos, 1 urgente: fallo de inicio de sesión en Android (#412)») y se apaga. La ejecución del martes comienza desde cero. La sesión del lunes ya no existe. Nada depende de tu equipo, y eso la convierte en un bucle verdadero en lugar de una sesión que debes vigilar. (También explica por qué la columna vertebral, el Concepto 12, debe vivir en el repositorio).

Opcional: límites actuales de las Routines y reglas de ramas

Dos reglas actuales del producto que debes comprobar antes de depender de él.

Regla uno: hay un límite diario. Cada cuenta recibe un número fijo de ejecuciones de Routines por día: en el lanzamiento, 5 para Pro, 15 para Max y 25 para Team y Enterprise. Un sistema desatendido que se ejecuta en servidores ajenos debe tener un presupuesto. Esto se cumple en todo servicio en la nube, y es una cifra en torno a la cual diseñas, no una sorpresa que descubres. Un cálculo rápido para un plan Pro: el triaje de issues (1 ejecución), más un resumen nocturno de commits (1 ejecución), más una Routine de revisión de PR en un día con 4 pull requests (4 ejecuciones), suman 6 ejecuciones, una por encima del límite. Tus opciones, en orden, son combinar los dos informes diarios en una Routine, comprar uso adicional para el revisor de PR en los días ajetreados o mejorar el plan. Haz este cálculo antes de que el bucle se detenga en silencio en la quinta ejecución. Tres detalles suavizan el límite: esas son cifras del lanzamiento, así que consulta claude.ai/settings/usage; las ejecuciones programadas de una sola vez no cuentan, y puedes pagar por uso adicional una vez superado el límite.

Regla dos: solo puede hacer push a ramas claude/ de forma predeterminada. Una Routine nueva no puede escribir en main. Toda rama a la que haga push debe comenzar por claude/.

Esto es positivo, no un obstáculo. Mantiene seguro el trabajo desatendido desde el primer día: la Routine puede hacer todo el trabajo que quiera, pero tú sigues decidiendo qué se fusiona.

Veamos un ejemplo. Configuras una segunda Routine para corregir pruebas inestables durante la noche. A las 3:00 hace push de la corrección a una rama claude/. Por la mañana lees el cambio, compruebas que parece correcto y lo fusionas tú mismo. La Routine hizo el trabajo mientras dormías. Tú hiciste la comprobación al despertar. Esa separación es el objetivo.

Más adelante, cuando un repositorio se haya ganado tu confianza tras muchas ejecuciones limpias, puedes desactivar la regla solo para ese repositorio mediante la opción Allow unrestricted branch pushes. Hazlo de forma deliberada, un repositorio a la vez, como si entregaras una llave a alguien.

Cuándo una Routine es la herramienta correcta: siempre que el trabajo no necesite tu equipo. Triaje de issues, un resumen de los viernes sobre «qué cambió esta semana» para las partes interesadas, vigilar el registro de cambios de un competidor o redactar respuestas a solicitudes rutinarias de soporte. Si te sorprendes pensando «esto debería suceder todos los días sin mí», esta es la herramienta. (Todos los campos del formulario, el entorno y los secretos se explican paso a paso en el apéndice de Routines. También hay una tercera opción nativa entre la nube y cron: las tareas programadas de escritorio, creadas en la app de escritorio. Se ejecutan localmente sobre tus archivos reales, incluso con cambios sin guardar, sin necesitar una sesión abierta, pero tu equipo debe estar encendido).

Opcional: administrar una Routine desde la terminal

Puedes administrar todo el ciclo de vida de una Routine desde la terminal, con lenguaje natural. Créala, enumera las que tienes, ejecuta una ahora o cambia su horario:

/schedule every weekday at 9am, run the daily-triage skill   # create it
/schedule list                                               # see what you have
/schedule run the triage routine now                         # fire one run, to test it
/schedule update the triage routine to every two hours       # change the timing

Tres detalles rápidos:

• Horarios personalizados. Las opciones preparadas cubren los casos habituales (cada día, cada hora o cada día laborable). Para un horario poco común, update también acepta una expresión cron: un código breve que expresa una hora exacta. Por ejemplo, 0 9 * * 1-5 significa «a las 9:00, de lunes a viernes».
• Práctica gratuita. Una ejecución única se realiza una sola vez en lugar de repetirse, como /schedule tomorrow at 9am, …. Las ejecuciones únicas no cuentan para tu límite diario, así que son una forma gratuita de probar un prompt una vez y comprobar que funciona antes de comprometerte a ejecutarlo todos los días.
• Solo basadas en el reloj. Desde la terminal solo puedes crear Routines que comiencen a una hora establecida. Para iniciar una desde otra fuente, como la llamada de otro programa (una llamada a la API) o un evento de GitHub (por ejemplo, la apertura de un pull request), abre la Routine en su página web y añade allí ese activador.

Si parece que /schedule no está en tu CLI, el apéndice de Routines explica qué debes comprobar.

Ejecuta un prompt desde tu propio cron (portátil encendido, sin la nube de Anthropic). claude -p ejecuta un solo prompt y después termina. Puedes colocarlo directamente en el crontab de tu equipo:

# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && claude -p "check the CI dashboard and summarize any failures" >> ~/claude-cron.log 2>&1

Cuando estés listo para construir tu primera Routine real (todos los campos del formulario, los tres activadores, los secretos y los problemas habituales), el apéndice de Routines al final del curso te guiará paso a paso.

Programa uno y vete a dormir: Sky Watch

Un horario es el único latido cuyo disparo no puedes observar, porque la medianoche llega cuando no estás mirando. Por eso existe un proyecto diseñado para dejarlo solo durante la noche: Sky Watch. Cada mañana consulta el canal de asteroides de la NASA y te deja una nota: qué pasará hoy cerca de la Tierra y si algo supone un peligro.

Clónalo y demuestra primero a mano que funciona:

what asteroids are coming this week?

Recibes un informe en lenguaje sencillo: «no hay nada de qué preocuparse; el objeto más cercano pasa a 23 veces la distancia de la Luna, todo despejado». Después conviértelo en un bucle con una sola línea:

/schedule every day at midnight, run the sky-watch skill for today and write me the forecast

Cierra el portátil. Por la mañana, el informe estará esperando, escrito mientras dormías por una máquina que nunca fue tuya. Adjunta un conector de correo electrónico y podrá llegar a tu bandeja de entrada como una tarjeta visual, con cada paso representado mediante una barra de proximidad. Observa que el prompt dice for today, no «la próxima semana»: una ejecución diaria debe informar sobre el día en que se dispara; de lo contrario, reenviará cada mañana el pronóstico de ayer. Haz coincidir la ventana con la cadencia.

Dos cosas hacen que esto sea un horario y no el timbre (Concepto 7). Mira hacia delante, no hacia atrás: advierte sobre el paso de mañana, no informa sobre el de ayer. Además, habla aunque no suceda nada. La mayoría de las mañanas solo dice «todo despejado», y ese informe tranquilo es la razón de ser de una vigilancia. Un bucle basado en eventos permanece en silencio en un día tranquilo. Un horario informa de todos modos. Para ensayar sin esperar a medianoche, dispara primero una ejecución única (/schedule in 2 minutes, run the sky-watch skill), porque estas no cuentan para tu límite diario. Es la regla de la Parte 6 hecha realidad: demuéstralo rápido y bajo observación antes de confiar en una ejecución lenta y desatendida.

El latido desatendido de OpenCode siempre es el sistema operativo o CI. Usa opencode run sin la pantalla de chat y deja que el planificador lo inicie.

Opcional: plugins de programación de la comunidad

Los plugins de la comunidad, como opencode-scheduler, pueden convertir una solicitud en lenguaje natural en un horario del sistema operativo. También pueden impedir que las ejecuciones se superpongan y rechazar prompts que quedarían esperando una respuesta humana. Estos plugins son software de terceros, así que comprueba que se mantengan activamente antes de depender de ellos.

Tu propio equipo, con cron:

# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && opencode run "check the CI dashboard and summarize any failures" >> ~/opencode-cron.log 2>&1

La nube, con GitHub Actions (ningún equipo tuyo debe estar encendido). La cadena model de abajo es solo un ejemplo. Ejecuta opencode models para obtener los ID exactos que reconoce tu instalación:

name: Scheduled OpenCode Task
on:
  schedule:
    - cron: "0 9 * * 1-5"   # weekdays at 9am UTC
jobs:
  opencode:
    runs-on: ubuntu-latest
    permissions: { contents: write, pull-requests: write, issues: write }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
        with:
          model: anthropic/claude-sonnet-5   # confirm with `opencode models`
          prompt: |
            Review the codebase for TODO comments and summarize them.
            If any are worth acting on, open an issue to track them.

Para los eventos programados, prompt es obligatorio porque no hay un comentario del que leerlo. Además, debes conceder contents: write y pull-requests: write si el bucle debe abrir ramas o PR.

En términos sencillos

Una Routine de Claude Code se ejecuta en los servidores de Anthropic. Un horario de OpenCode se ejecuta mediante tu sistema operativo o GitHub Actions. Ambos inician trabajo nuevo a una hora elegida, así que ambos necesitan estado guardado fuera del modelo.

Una nota sobre los nombres de la acción y el modelo anteriores

Detalle técnico opcional que puedes omitir en una primera lectura.

La documentación oficial actual escribe la GitHub Action de OpenCode como anomalyco/opencode/github@latest. Algunas guías antiguas todavía muestran sst/opencode/github@latest. Ambas apuntan al mismo proyecto. Usa la que genere opencode github install. En cuanto a los modelos, Claude Sonnet 5 es ahora el nivel Sonnet actual (su ID de API es claude-sonnet-5, porque las versiones mayores omiten el número menor). Sustituye directamente a Sonnet 4.6, que sigue siendo un ID fijado válido. Quien construye bucles debe saber dos cosas: el pensamiento adaptativo está activado de forma predeterminada y un nuevo tokenizador genera alrededor de un 30 % más de tokens para el mismo texto, así que los presupuestos de tokens medidos con 4.6 no se trasladan sin cambios. Los ID sin fecha llegaron con la generación 4.6, donde la cadena sin fecha es la instantánea fijada. Los modelos anteriores de la generación 4.5, como Haiku 4.5, tienen un ID canónico con fecha (claude-haiku-4-5-20251001) y un alias sin fecha, claude-haiku-4-5. Los ejemplos de abajo fijan el ID con fecha de Haiku para que los resultados sean reproducibles. Las generaciones de modelos avanzan más rápido que este libro. Ejecuta opencode models (actualiza su lista de modelos si falta una versión nueva) para conocer las cadenas exactas que reconoce tu instalación antes de fijar nada.

7. Basado en eventos (reacciona cuando sucede algo)

Un horario pide «comprueba cada hora». Un evento pide «reacciona en cuanto suceda X». Se abre un PR, se registra un issue o llega un mensaje, y el bucle se ejecuta en respuesta.

Prueba el timbre (30 segundos)

Permanece inactivo, sin reloj y sin que nadie observe. Entonces sucede algo: un PR, un mensaje o una alerta. El bucle reacciona en cuanto llega, cada elemento por su propia ruta, y después vuelve a quedarse en silencio.

Abrir ↗

La estructura de esta sección

Esta sección trata sobre los eventos. Un evento es simplemente algo que sucede. Cada tipo tiene un receptor, una herramienta que reacciona a él, y no todos los receptores son iguales. Una Routine captura los eventos de GitHub y los de «todo lo demás». Un Channel captura los mensajes de chat. Por tanto, dos de los tres receptores son Routines y uno, el Channel, no lo es. La única debilidad del Channel, que necesita tu equipo encendido, aparece claramente en la tabla de abajo.

Con Claude Code, el origen del evento determina qué herramienta debes usar. Hay tres rutas:

1. Desde GitHub, usa una Routine. Una Routine no tiene que ejecutarse según un reloj. Su activador también puede ser un evento de GitHub. Funcionan dos tipos: el cambio de un pull request (se abre, actualiza o fusiona) y la publicación de una versión. Por ejemplo: «cuando se abra un PR, revísalo y comenta» o «cuando se publique una versión, redacta el registro de cambios».

Hay tres cosas que debes saber antes de construir una:

• Configuración. La Claude GitHub App debe estar instalada en el repositorio. Ten cuidado: /web-setup solo concede acceso para clonar y no instala la app. Esto hace que fallen muchos primeros intentos.
• No hay activador de push. No existe un evento «on push». Sin embargo, si alguien hace push de commits a una rama que ya tiene un PR abierto, GitHub lo considera una actualización del PR (el evento synchronized), por lo que la Routine se dispara. Haz push a una rama sin PR y no sucederá nada.
• Filtros. Puedes limitar qué eventos la disparan: por autor, título, etiquetas, rama, estado de borrador y otros criterios. La lista completa de campos, los límites por hora y los detalles difíciles están en el apéndice de Routines (A3).

2. Desde una app de chat, usa un Channel. Un Channel lleva un mensaje de una app externa directamente a una sesión que ya está en ejecución. Telegram, Discord e iMessage funcionan de inmediato. Para cualquier otra fuente, configuras un webhook. Este es el timbre de la Parte 2: no sucede nada hasta que llega un mensaje y entonces la sesión reacciona al instante.

Por ejemplo, mientras estás lejos de tu escritorio, puedes preguntar por Telegram: «¿Terminó el despliegue?». La sesión existente lo comprueba y responde con su contexto, skills e historial actuales. Un bucle también puede devolver informes mediante el mismo Channel.

Dos precauciones:

• Necesita una sesión activa. La sesión ya debe estar en ejecución (una terminal abierta o una sesión en segundo plano), por lo que un Channel no funciona con el equipo apagado.
• Es una puerta abierta. Cualquiera que pueda enviar mensajes desde esa fuente puede dirigir tu sesión, así que conecta solo fuentes bajo tu control.

Configuración: code.claude.com/docs/en/channels.

3. Desde cualquier otra fuente, usa una Routine con un activador de API. Algunos eventos no vienen de GitHub ni de una app de chat: se dispara una alerta en tu herramienta de supervisión, termina un despliegue o se envía un formulario. Dale a la Routine un activador de API y cualquier sistema capaz de enviar una solicitud web autenticada (una solicitud que demuestra su identidad) podrá dispararla con el portátil cerrado. Esa solicitud incluso puede llevar los detalles del evento: un campo opcional text pasa a la Routine el contexto específico de la ejecución (el mensaje de alerta o el registro que falla) junto con el prompt guardado. El endpoint, el token y una advertencia sobre reintentos están en el apéndice de Routines (A3).

Cómo elegir entre las cuatro opciones:

El evento viene de...	Usa	El trabajo se ejecuta en...	¿Funciona con el portátil cerrado?
GitHub (un PR, una versión)	una Routine, activador de GitHub	una sesión nueva en la nube por evento	sí
GitHub, sin una Routine	la Claude Code GitHub Action en CI	un ejecutor nuevo de CI por evento	sí
un mensaje de chat (Telegram, Discord, iMessage)	un Channel	la sesión que ya tienes en ejecución	no, necesita un equipo
cualquier fuente que envíe una solicitud web	una Routine, activador de API	una sesión nueva en la nube por llamada	sí

La segunda fila importa más de lo que parece. Una Routine no es la única forma de seguir trabajando con el portátil cerrado. anthropics/claude-code-action@v1 en un flujo de GitHub Actions hace el mismo trabajo y no necesita acceso a la versión preliminar de investigación ni tiene un límite diario de ejecuciones. Basta con un plan Pro o Max: claude setup-token te da una credencial que puede usar el ejecutor, así que tampoco hace falta una clave de API. Es la puerta más económica al trabajo desatendido.

Esto señala la regla que sostiene las cuatro filas. La pregunta nunca es «¿es una Routine?», sino «¿en qué equipo se ejecuta el trabajo?» Tu propio equipo deja de funcionar cuando lo cierras. Los servidores de Anthropic y los ejecutores de GitHub no, porque nunca fueron tuyos. También por eso esas filas necesitan un token y /loop no: tu portátil ya sabía quién eras, pero una máquina ajena alquilada no. Necesitar credenciales y sobrevivir a una tapa cerrada son el mismo hecho visto desde dos lados.

Observa el patrón en todas las filas salvo la del Channel: cada evento inicia una sesión nueva, así que dos eventos no saben nada el uno del otro. Dos pushes al mismo PR son dos sesiones separadas. La columna vertebral (Concepto 12) es la forma de compartir estado.

Haz sonar uno tú mismo: el timbre

El párrafo anterior contiene el tipo de afirmación que no significa nada hasta que la ves ocurrir. Hay un proyecto pequeño para este concepto, The Doorbell, que hace exactamente una cosa: revisa un pull request sin que nadie se lo pida.

Copia su kit en un repositorio propio, genera un token con claude setup-token, añádelo como secreto y abre un pull request que contenga un bug. Aproximadamente un minuto después aparecerá una revisión. No escribiste ningún prompt. Nadie estaba observando.

Después haz la parte que fija la idea: cierra el portátil y pide a otra persona que abra un PR. La revisión sigue apareciendo. Esa acción muestra la diferencia con el Concepto 4. El bucle de la ISS muere cuando cierras la terminal porque se ejecutaba en tu equipo. Este nunca estuvo allí. Cuando suena el timbre, GitHub alquila un equipo, ejecuta el trabajo en él y luego desecha la máquina.

Eso también explica el token. Tu portátil ya sabía quién eras. Una máquina ajena alquilada no. Todo bucle desatendido paga este precio.

Hay algo que debes esperar, porque nos costó una hora: una marca de verificación verde no significa que haya funcionado. Si omites una opción, la ejecución tiene éxito, hace la revisión y no publica nada. El README del proyecto indica la opción y el síntoma. (Usa la Claude Code GitHub Action en lugar de una Routine: el mismo timbre, sin necesitar acceso preliminar ni tener límite diario).

Y el final demuestra el párrafo anterior. Haz push por segunda vez y la nueva revisión citará correctamente tus commits anteriores por su hash, aunque se ejecute en una máquina recién creada que no recuerda nada. No recordó. Leyó el repositorio. Esa es la columna vertebral, que conocerás bien en la Parte 4.

Instala una vez el agente de GitHub con opencode github install. Esto añade .github/workflows/opencode.yml. Después, OpenCode reacciona a los eventos del repositorio (pull_request, issues y comentarios /oc o /opencode) dentro de tus ejecutores de GitHub Actions:

name: opencode-review
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions: { contents: read, pull-requests: read }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          model: anthropic/claude-sonnet-5
          use_github_token: true
          prompt: |
            Review this pull request for bugs, quality issues, and security risks.

Para un evento pull_request sin prompt, OpenCode revisa el PR de forma predeterminada.

En términos sencillos

Usa un horario cuando el tiempo inicie el trabajo. Usa un evento cuando lo inicie una acción externa, como abrir un pull request o enviar un mensaje.

Comprueba lo aprendido

Quieres que un bucle siga corrigiendo una prueba fallida hasta que pase y después se detenga por sí solo. ¿Qué latido eliges y quién decide que está «terminado»?

Mostrar la respuesta

Un bucle condicional (ejecutar hasta terminar), es decir, /goal en Claude Code o un bucle de shell limitado en OpenCode. Un comando (el ejecutor de pruebas) decide cuándo está «terminado», nunca el agente que escribió la corrección. Y aun así necesita un límite para que no pueda reintentar indefinidamente.

Elige el bucle más ligero que encaje

Ya conoces los cuatro latidos. No elijas el más grande por defecto. Dos decisiones definen cada bucle: qué lo inicia y qué lo detiene. Antes de construir nada, hazte una pregunta sobre la tarea: ¿termina o se repite?

• La tarea termina y un comando puede demostrar el final → un bucle condicional. Inícialo ahora y deja que se ejecute hasta terminar.
• La tarea se repite → un horario o un evento.
• La tarea sucede una sola vez → ningún bucle. Una sesión normal, un turno a la vez, es la herramienta correcta. Sigue siendo la herramienta adecuada para la mayoría del trabajo.

Una regla más: cuando un bucle repetitivo sea nuevo, observa sus primeras ejecuciones reales antes de confiar en él sin supervisión. La Parte 6 lo convierte en regla: demuestra que el bucle funciona antes de usarlo durante la noche.

Una última nota sobre los nombres. En internet se usan estas palabras con poca precisión, así que esta es la equivalencia. «Turn-based» es una sesión normal. «Goal-based» es nuestro bucle condicional. «Time-based» mezcla dos de nuestros tipos, en sesión y programado, que ya sabes que son distintos. «Proactive» es un bucle compuesto por completo, como el de la Parte 5. Etiquetas distintas, las mismas piezas.

Práctica: elige un latido y construye uno

Ya conoces los cuatro latidos, y este es el mejor momento para usar uno mientras las cuatro imágenes siguen frescas. Hay dos pasos. Primero demuestra que puedes elegir el latido correcto. Después inicia uno.

Paso uno: elegir (2 minutos, nada que instalar). Indica el latido de cada tarea siguiente. Una de ellas es una trampa.

1. Cada viernes, redactar para el equipo un resumen de los pull requests fusionados durante la semana.
2. Seguir trabajando en esta compilación fallida hasta que pase y después detenerse.
3. Alguien abre un pull request y debe revisarse.
4. Hay una migración de 40 minutos en ejecución y quieres saber el momento en que termina.
5. Cambiar el nombre de una variable en todo el repositorio.

Mostrar las respuestas

1. Programado. Se repite según el reloj y nadie necesita estar presente. Una Routine o una línea de cron (Concepto 6).
2. Condicional, o ejecutar hasta terminar. La tarea termina y un comando puede demostrar el final. /goal o un bucle de shell limitado (Concepto 5).
3. Basado en eventos. Una acción externa lo inicia, así que se dispara cero veces en un día tranquilo (Concepto 7).
4. En sesión. Sigues observando y puede detenerse cuando cierres la sesión. /loop o un bucle while con un sleep (Concepto 4).
5. Ningún bucle. La tarea sucede una vez, así que una sesión normal es la herramienta correcta. Si elegiste un bucle para esta, vuelve a leer el consejo anterior. La mayor parte del trabajo todavía pertenece a esta fila y seguirá siendo así después del curso.

Paso dos: construir uno. Cada latido tiene un proyecto esperando al final del curso. No hagas los cuatro ahora. Dos están listos para ti y otros dos se adelantan a propósito a partes que todavía no has leído:

Latido	Concepto	Constrúyelo en	¿Está listo ahora?
En sesión	4	Proyecto 1, un bucle de vigilancia	Sí
Condicional	5	Proyecto 2, hacer pasar las pruebas y detenerse	Sí
Programado	6	Proyecto 3, el informe matutino con memoria	Después de la Parte 4; necesita la columna vertebral
Basado en eventos	7	Proyecto 6, el bucle de timbre	Después de la Parte 3; necesita conectores

La última columna merece una pausa. Un horario sin memoria no es más que el mismo primer paso repetido cada mañana, y un bucle basado en eventos que no puede abrir un PR solo puede hablar. Por eso, los dos latidos que se ejecutan sin ti son precisamente los dos que primero necesitan el resto del curso. No es relleno. Es la forma del sistema.

El Proyecto 1 es el comienzo más económico posible: unos 15 minutos, ningún horario que configurar y nada que pueda ejecutarse mientras estás ausente. Si solo haces una cosa antes de la Parte 3, que sea esta.

---

Parte 3: qué hace el bucle en cada ejecución (el cuerpo)

El latido inicia el bucle. Estas cuatro partes son lo que el bucle hace en cada pulso. Las conociste en el curso de programación agéntica como complementos útiles. En un bucle importan de verdad, porque ninguna persona observa cada paso.

8. Aislamiento: worktrees

En cuanto un bucle ejecuta más de un agente a la vez, empiezan a sobrescribir los archivos de los demás. Es como dos personas que editan las mismas líneas sin avisarse. Un worktree de Git resuelve el problema. Es una carpeta de trabajo independiente, en su propia rama, que comparte el mismo historial del repositorio. Las ediciones de un agente no pueden tocar el checkout de otro.

Está integrado. Usa la opción --worktree para abrir una sesión en su propio checkout. También puedes establecer isolation: worktree en un subagente, de modo que cada asistente reciba un checkout nuevo que se limpie solo al terminar. Una tarea programada puede activar el aislamiento mediante worktrees en cada ejecución, para que las ejecuciones paralelas nunca entren en conflicto con tu trabajo manual.

No hay una sola opción. Usas los worktrees propios de Git y diriges una ejecución a cada uno. Es el mismo aislamiento, construido de forma explícita:

git worktree add ../wt-feature-a feature-a
git worktree add ../wt-feature-b feature-b
( cd ../wt-feature-a && opencode run "implement feature A" ) &
( cd ../wt-feature-b && opencode run "implement feature B" ) &
wait

Si haces esto con frecuencia, los ejecutores de la comunidad, administradores de worktrees construidos alrededor de OpenCode, pueden encargarse de la gestión por ti.

9. Conocimiento: skills para que ninguna ejecución empiece de cero

Un bucle comienza cada vez como una sesión nueva, sin memoria de los hábitos de tu proyecto. Sin ayuda, deduce (o adivina) toda la configuración en cada pulso. Eso desperdicia tokens y favorece los errores. Una skill es ese conocimiento escrito una vez en un archivo SKILL.md, que el agente lee en cada ejecución.

Funciona igual en ambas herramientas: una carpeta con un archivo SKILL.md que contiene instrucciones y metadatos, además de scripts y referencias opcionales. En un bucle, la regla es sencilla. Todo lo que de otro modo tendrías que volver a explicar en cada ejecución pertenece a una skill. Los pasos del triaje, los hábitos del proyecto y el «no lo hacemos así por aquel incidente» viven en la skill. Así, el bucle construye sobre lo anterior en lugar de empezar de nuevo. (La explicación completa está en el curso intensivo de Skills y conectores).

Una skill mantiene breves los prompts del bucle

No pegues un bloque largo de instrucciones en un horario que nadie mantendrá actualizado. En su lugar, el prompt programado se convierte en una línea, «ejecuta la skill daily-triage», y la skill contiene los detalles. Un prompt breve para el bucle, lógica fácil de actualizar y menor costo de tokens en cada pulso.

10. Acción: conectores (el bucle actúa, no solo sugiere)

Un bucle que solo puede leer tus archivos es un bucle que solo puede hablar. Los conectores, construidos sobre MCP, le permiten actuar: abrir un PR, actualizar un ticket de Linear, publicar en Slack, consultar una base de datos o llamar a una API de preproducción. Es la diferencia entre un bucle que dice «aquí está la corrección» y otro que abre el PR, enlaza el ticket y publica en el canal cuando CI está en verde.

Ambas herramientas hablan MCP, por lo que el protocolo se transfiere entre ellas. Sin embargo, el empaquetado y la autenticación (local o alojada, OAuth y permisos) suelen necesitar una configuración específica de cada herramienta.

Añade servidores MCP a tu configuración e inclúyelos en la lista de conectores de una Routine para que la ejecución desatendida pueda acceder a ellos. Los mismos conectores que usas a mano están disponibles para las ejecuciones programadas y en la nube.

Declara los servidores en la sección mcp de opencode.json. Los servidores locales inician un subproceso. Los remotos acceden a un endpoint HTTPS con OAuth automático. En un opencode run programado, inicia opencode serve una vez y conéctate mediante --attach, para no pagar el costo de inicio de MCP en cada pulso.

Tres cosas que necesita un conector porque está en un bucle

Un bucle reintenta y elige herramientas sin supervisión. Eso cambia la composición de un buen conjunto de herramientas:

• Unas pocas herramientas específicas superan a muchas que se solapan. Elegir una herramienta es una decisión que el modelo toma en cada pulso, sin que nadie observe. Dale cien herramientas que se solapen y perderá de vista cuál corresponde. Quienes trabajan con estos sistemas han comprobado que reducir las herramientas disponibles para un agente aumenta su tasa de éxito. La regla práctica de Anthropic dice que, si una persona con experiencia en ingeniería no puede afirmar con certeza qué herramienta corresponde al trabajo, el agente tampoco podrá. A mano, una mala elección te cuesta un momento. En un bucle, cuesta un pulso cada vez que ocurre, para siempre. Reduce la lista de conectores a lo que el bucle realmente necesita. (El apéndice de Routines pide lo mismo por razones de seguridad. Ambas razones coinciden).
• Las escrituras deben poder repetirse sin riesgo. Un bucle que reintenta un paso fallido volverá a realizar la misma escritura. Si reintentar «crear cliente» crea un segundo cliente, deja registros duplicados y cobros dobles. Prefiere operaciones seguras al repetirlas (actualizar o crear, un PR por rama) frente a creaciones ciegas.
• Los errores deben indicar qué hacer después. En un bucle, el mensaje de error es la entrada del siguiente pulso. «Permiso denegado: solicita el ámbito repo» permite corregir el problema en el siguiente intento. «Error 403» desperdicia un pulso.

Cuando trabajas a mano, absorbes los tres problemas sin notarlo. Eliges la herramienta correcta, evitas el duplicado y buscas el error. En una ejecución desatendida, no hay nadie que los absorba.

11. Creador-verificador: subagentes

Esta es la decisión más importante en un bucle: el agente que produce el trabajo no debe ser quien lo apruebe. Un modelo que comprueba su propia salida suele aprobarla con demasiada facilidad. Un segundo agente usa instrucciones distintas y puede usar otro modelo. Puede detectar problemas que el primero pasó por alto. Esta separación hace más seguro un bucle desatendido. También encontrarás este patrón con el nombre LLM como juez: un modelo independiente califica el trabajo en lugar de que el creador se califique a sí mismo.

Define subagentes en .claude/agents/ y reúnelos en equipos de agentes: uno explora, otro implementa y otro comprueba el resultado frente a la especificación y las pruebas. «La especificación» es la que aprendiste a escribir en el Desarrollo Basado en Especificaciones. Sus criterios de aceptación son exactamente aquello contra lo que evalúa un verificador fiable. Una especificación vaga produce un veredicto vago. Esto también es lo que hace /goal por dentro: un modelo nuevo decide si el bucle terminó, en lugar de que el agente ejecutor se califique a sí mismo.

OpenCode incluye los agentes principales Build y Plan. También incluye tres subagentes: general, explore y scout. Scout es de solo lectura y se usa para investigar documentación externa y dependencias. Puedes definir agentes adicionales en opencode.json o como archivos Markdown en la carpeta de agentes.

Dale al verificador su propio modelo, que a menudo puede ser más económico y de solo lectura. El creador puede llamarlo mediante una mención @ o la herramienta Task. Un diseño habitual usa un modelo potente para explorar e implementar, y después uno especializado para comprobar el resultado.

Dos opciones son especialmente importantes en un bucle: un límite steps para cada agente (Concepto 5) y reglas permission.task que impidan a un subagente iniciar más subagentes. Sin estos límites, los agentes pueden delegar trabajo en círculos y consumir tokens innecesarios.

---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons.
---

You are a strict code reviewer. You do not make changes.
Check the diff against the spec and the test results, then reply PASS or FAIL with the reasons.

Los subagentes cuestan más, así que úsalos donde importan

Cada subagente ejecuta su propio modelo y sus propias herramientas, por lo que la separación creador-verificador consume realmente más tokens. Es el precio de un verificador en el que puedes confiar. Págalo donde importe una segunda opinión: cualquier cosa que el bucle vaya a confirmar mientras estás ausente. Omítelo para tareas desechables y de solo lectura.

Interludio: codificar el cuerpo con flujos de trabajo dinámicos

Hasta ahora, el cuerpo de un pulso (encontrar el trabajo, preparar cada corrección en su propio checkout y hacer que un agente independiente la califique) es algo que el agente compone turno a turno. Claude Code ahora te permite escribir toda esa orquestación como un script que puedes volver a ejecutar, llamado flujo de trabajo dinámico. Describes la tarea, Claude escribe un script que reparte el trabajo entre muchos subagentes y un entorno de ejecución lo ejecuta en segundo plano mientras tu sesión queda libre. Es la separación creador-verificador (Concepto 11) y la separación mediante worktrees (Concepto 8), empaquetadas en una unidad repetible. También puede aplicar un patrón de calidad real, no solo ejecutar más agentes: revisores independientes pueden comprobar los hallazgos de los demás antes de que se informe de nada.

Pide uno con palabras sencillas («usa un flujo de trabajo para...»), inícialo con la palabra clave ultracode (la palabra activadora anterior, workflow, se retiró a mediados de 2026, y describir lo que quieres sigue funcionando) o ejecuta /deep-research, que viene integrado. Cuando una ejecución haga lo que quieres, pulsa s en la vista /workflows para guardar su script como un /command que podrás volver a ejecutar en cada rama. Las salvaguardas mantienen el control. Los agentes tienen un límite (unos 16 a la vez y 1000 por ejecución), por lo que un script desbocado no puede crecer en espiral. Los subagentes que siguen fallando la validación se detienen tras unos intentos en lugar de entrar en un bucle infinito. Además, la memoria de una ejecución vive solo dentro de esa ejecución: puedes reanudarla en la misma sesión, pero una sesión nueva comienza desde cero.

No existe el comando /workflows. El script que ya escribes es el flujo de trabajo. El bucle for limitado del Concepto 5 y la distribución con &/wait del Concepto 8 son una versión artesanal de la misma idea. Tu shell contiene el plan, cada opencode run es un agente y los códigos de salida son el verificador. Obtienes control total y ningún límite de agentes, a cambio de escribir y mantener tú mismo la orquestación.

Un flujo de trabajo es el cuerpo de un pulso, no el bucle

Este es el error más fácil de cometer cuando los flujos de trabajo empiezan a parecer potentes. Un flujo de trabajo dinámico se ejecuta una vez, cuando tú (o la opción ultracode) lo inicias, y olvida todo al terminar. No tiene latido ni columna vertebral. Por tanto, es el cuerpo de un solo pulso, no un bucle. El bucle es la combinación: un latido (una Routine, /loop o cron) dispara el pulso, el flujo de trabajo es el cuerpo que se ejecuta sobre él y un archivo de progreso que escriben sus agentes es la columna vertebral que lee el siguiente disparo. En términos literales: el flujo de trabajo realiza una ejecución, el activador inicia ejecuciones posteriores y el archivo de progreso almacena información entre ellas.

Como ayuda para recordarlo: el flujo de trabajo es el motor, la Routine gira la llave y progress.md lleva información al siguiente viaje.

Comprueba lo aprendido

Tu bucle ejecuta dos agentes al mismo tiempo y también quieres confiar en los commits que hace mientras estás ausente. Son dos problemas distintos. ¿Qué parte del cuerpo resuelve cada uno?

Mostrar la respuesta

Los worktrees resuelven el problema del paralelismo: cada agente recibe su propio checkout, así que sus ediciones no pueden chocar. El patrón creador-verificador resuelve el problema de la confianza: un agente independiente califica el trabajo, de modo que «terminado» significa algo aunque no estés observando. Es habitual confundirlos. El aislamiento evita que los agentes se estorben. El verificador evita que el trabajo defectuoso entre en tu repositorio. Necesitas ambos por motivos distintos.

Interludio: codificar el verificador con skills de verificación

El interludio anterior codificó el cuerpo de un pulso. Este codifica el verificador. En julio de 2026, el equipo de Claude Code de Anthropic publicó sus propias recomendaciones sobre este tema y lo llamó bucle de verificación: el agente comprueba su trabajo e intenta corregirlo una y otra vez hasta que la comprobación pasa. Ya conoces este bucle con el nombre que usa el libro. Es el ciclo Intentar → Comprobar → Corregir → Repetir del curso de programación agéntica, al que Boris Cherny llama el consejo más importante para usar la herramienta.

Primero, una nota sobre los nombres para que la palabra «bucle» no te confunda. Un bucle de verificación se ejecuta dentro de un pulso. No tiene un latido propio ni columna vertebral. Cuando termina el pulso, termina también el bucle. En el vocabulario de este curso, es la maquinaria del bucle pequeño. Lo que justifica su lugar en este capítulo es lo que sucede después: la misma comprobación, escrita una vez, se convierte en el verificador de un bucle grande en cuanto un latido la dispara. El agente revisor de la Parte 5 califica el trabajo precisamente frente a este tipo de comprobación escrita. Por tanto, esta sección trata en realidad de un solo movimiento: tomar una comprobación que vive en tu cabeza y darle un archivo.

Qué comprobaciones debes escribir. La prueba es sencilla: vale la pena escribir como comprobación todo aquello que sigues corrigiendo a mano cada vez que termina el agente. El recorrido manual de clics después de cada cambio del frontend. La revisión para comprobar si eliminaste el cuerpo de la solicitud de los registros de errores. La migración que siempre vuelves a leer antes de aprobarla. Escribe el procedimiento en lenguaje sencillo, como se lo entregarías a una persona nueva del equipo en su primer día. Si no puedes expresarlo con claridad, pide primero al agente la versión estándar de buenas prácticas y después edítala. Tu versión diferirá en algunos puntos concretos, y esas diferencias son exactamente lo que debes escribir. El modelo ya conoce la parte estándar. La parte específica de tu proyecto es la valiosa.

La comprobación no tiene que depender del criterio para merecer un archivo. «Rechaza toda migración que elimine una columna sin un paso de rellenado previo» es una regla fija que un comando podría demostrar y que ningún linter de propósito general incluirá jamás, porque es tuya. Es un peldaño fácil de pasar por alto en la escala de verificadores del Concepto 2: entre las comprobaciones mecánicas que ya incluyen las herramientas y la rúbrica con la que califica un revisor, existe una capa de comprobaciones mecánicas que solo tú puedes escribir. Cada regla que bajes de la rúbrica a este peldaño convierte una afirmación en una prueba.

El contenedor es una skill. Ya conoces el contenedor del Concepto 9: un archivo SKILL.md que el agente carga cuando la tarea coincide. Una skill de verificación es el mismo contenedor, pero alberga una comprobación en lugar de un procedimiento. Una completa cabe en una pantalla:

# .claude/skills/verify-log-hygiene/SKILL.md  (or .opencode/skills/…)
---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
  include the request body. Use when the diff touches error handling
  or logging.
allowed-tools: [Read, Edit, Grep]
---

Read the error-handling paths in the current diff.

For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied
payload.

Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.

Observa la línea allowed-tools: esta comprobación puede leer, editar y buscar, y nada más. Es la idea de permisos permanentes del Concepto 14 aplicada a una comprobación. (Al igual que la línea tools del revisor en la Parte 5, acepta nombres de herramientas, no comandos individuales. Restringir una comprobación a comandos específicos corresponde a la capa de cumplimiento, que vive en el curso siguiente, Ingeniería de arneses).

Dónde se ejecuta la comprobación. Esta parte de las recomendaciones de Anthropic añade algo realmente nuevo al curso: una comprobación tiene cuatro hogares posibles, y cada hogar corresponde a un latido distinto.

1. Independiente. La invocas de forma deliberada después de que existe el trabajo. En el vocabulario del curso, tú sigues siendo el latido. Es el hogar adecuado para comprobaciones que se aplican a muchos tipos de trabajo, pero no a todos los cambios: un análisis de seguridad previo al commit, una revisión de encabezados de licencia o una auditoría de accesibilidad previa al PR. El costo es que cada invocación supone un turno que debes recordar realizar.
2. Integrada. La comprobación se añade al final de la skill productora, por lo que el flujo de trabajo la ejecuta sin que se lo pidan. La versión más sencilla es añadir una línea: «Después de crear el componente, ejecuta eslint sobre él y corrige cualquier error antes de informar que terminaste». Verifica que la integración se dispare de verdad: invoca la skill en una tarea nueva y confirma que la comprobación se ejecuta como parte de la salida. Si no sucede, las instrucciones anteriores de la skill no la están cargando. Hay un límite estricto: la integración solo funciona con skills que puedes editar. Las skills integradas y las administradas por plugins se sobrescriben al actualizarse, por lo que una comprobación añadida desaparece en silencio. En esos casos, encadena.
3. Encadenada. Una skill llama a otra al terminar, de modo que varias entregas verificadas se ejecutan de principio a fin. El propio equipo de Claude Code de Anthropic lo hace a diario: /code-review busca bugs, /simplify limpia el diff, /verify confirma el comportamiento de extremo a extremo y una skill /design personalizada comprueba los cambios de interfaz frente a un archivo DESIGN.md. Encadenar también permite añadir verificación a una skill que no puedes modificar: escribe una skill envolvente ligera que invoque la original y después tu comprobación. La frase que debes recordar es: lo que empezó como un hábito («siempre ejecuto la comprobación después») se convierte en un contrato (la skill siempre la ejecuta al terminar). Sin embargo, el costo es real. Encadenar reduce la flexibilidad, porque ya no puedes ejecutar con facilidad un paso aislado, y cada eslabón añadido consume tokens en cada ejecución (Concepto 13). Omítelo cuando los pasos sean lo bastante independientes como para que a veces quieras ejecutar solo uno.
4. En cada PR. Cuando la cadena sea sólida para tus propios cambios, las mismas skills se ejecutarán en cada pull request mediante el latido de evento que construiste en el Concepto 7, es decir, Doorbell, con tu comprobación como prompt. El cambio de otra persona del equipo pasará ahora por las mismas puertas que el tuyo, recuerde o no invocar algo. Este es el momento en que la verificación deja de ser infraestructura personal y se convierte en infraestructura del equipo: la comprobación que escribiste para ahorrarte dos minutos a la semana ahora ahorra dos minutos a todo el mundo, en cada cambio.

La regla de graduación. No empieces en el cuarto hogar. La señal de que una comprobación está lista para abandonar el hogar independiente es que te descubres ejecutándola después de cada cambio. En ese momento se ha ganado un hogar permanente, así que intégrala o encadénala. Espera antes de añadir una puerta para todos los PR mientras la cadena siga cambiando, porque cuando la comprobación proteja los PR del equipo, cada cambio que hagas en ella será visible para todo el equipo. Vuelve a leer esas dos reglas y las reconocerás: es la regla de la Parte 6, demuéstralo rápido y bajo observación antes de confiar en una ejecución lenta y desatendida, aplicada al propio verificador. Una comprobación sube por la misma escala de confianza que un bucle.

Tres atajos, todos vigentes a finales de julio de 2026:

• Empieza con lo que ya viene incluido. Una skill /verify integrada construye, ejecuta y observa los cambios en tu aplicación. Pruébala antes de escribir la tuya. La misma guía recomienda además un pequeño hábito para CLAUDE.md: enumera en el archivo de reglas los comandos exactos de compilación y pruebas, para que ninguna ejecución tenga que adivinarlos. (El Concepto 12 ya te enseñó por qué: un comando que el agente adivina es una suposición que el bucle repite para siempre, mientras que un comando escrito es un hecho que puede leer).
• Deja que el agente te entreviste. La forma más rápida de escribir una skill de verificación es el plugin skill-creator: /skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow. El agente pregunta, tú respondes y el archivo aparece. Escribirla a mano en .claude/skills/ funciona exactamente como en el Concepto 9.
• El cuarto hogar administrado. Code Review (versión preliminar de investigación) es el cuarto hogar convertido en producto: un servicio multiagente administrado que ejecuta una revisión automatizada de los PR en los repositorios que habilites. Corriges un hallazgo y haces push, o respondes con un comentario @claude en el hallazgo si configuraste la GitHub Action del Concepto 7. Tiene la misma forma que tu cadena artesanal, pero Anthropic aloja el latido y a los revisores.

No hay nada nuevo que instalar, y esa es la idea. El archivo SKILL.md anterior funciona sin cambios desde .opencode/skills/, y los cuatro hogares se corresponden con piezas que ya construiste:

• Independiente es opencode run "run the verify-log-hygiene skill on the current diff".
• Integrada es la misma línea añadida al cuerpo de tu propia skill productora.
• Encadenada es tu script, es decir, el patrón del Concepto 5, donde el estado de salida de cada skill decide si se dispara el siguiente opencode run. Tu shell contiene el contrato.
• En cada PR es la GitHub Action del Concepto 7 con la comprobación como prompt. La revisión predeterminada de PR sin prompt que ya viste es la idea /code-review de Anthropic, construida con piezas de OpenCode. Un prompt que apunte a tu skill de verificación hace que se apliquen tus normas en lugar de unas genéricas.

En términos sencillos

Una skill de verificación es una comprobación manual que ya hacías, escrita una vez para que el agente la ejecute y corrija lo que encuentre. Empieza invocándola tú mismo. Cuando notes que la ejecutas siempre, adjúntala al flujo de trabajo. Cuando toda la cadena funcione para ti, colócala en cada PR, y solo entonces.

Dónde retoman esto los cursos vecinos

Dos temas se dejan a propósito para los cursos vecinos. El cumplimiento, es decir, hacer que una comprobación no pueda hacer nada más que comprobar, comando por comando, corresponde al curso de Ingeniería de arneses. allowed-tools reduce la caja de herramientas, pero los bloqueos reales viven en ese curso. La calificación, es decir, cuándo la comprobación es una rúbrica en lugar de una prueba y hasta qué punto confiar en la puntuación de un modelo, corresponde al curso Confiar en el verificador. Una nota de producto pertenece a ese segundo curso: Rubrics in Claude Managed Agents (beta) es la rúbrica con umbral del Concepto 2 de este curso, ofrecida como servicio administrado. Un agente calificador independiente verifica los resultados frente a una rúbrica, y el trabajo fallido vuelve automáticamente para otro intento. La forma que aprendiste a construir a mano es ahora una pieza básica de la plataforma. Como siempre, esa es la capa mecánica: consulta la documentación actual.

Comprueba lo aprendido

Escribiste una gran comprobación de accesibilidad y quieres que, desde hoy, todos los PR de tu equipo la pasen. La comprobación se ha ejecutado dos veces, ambas invocadas por ti a mano. ¿Qué dice la regla de graduación y qué dos hogares te estás saltando?

Mostrar la respuesta

Todavía no. Tras dos invocaciones manuales, la comprobación sigue en su hogar independiente y aún no ha mostrado el patrón que merece un ascenso: que la ejecutes después de cada cambio. Saltar directamente a cada PR omite los hogares integrado y encadenado, donde la comprobación debe demostrar primero su valor sobre tu trabajo. Además, cuando controle los PR del equipo, cada corrección que hagas en ella será visible para todos. Es la misma escala de la Parte 6: bajo observación antes que desatendido, personal antes que equipo.

---

Parte 4: memoria entre ejecuciones (la columna vertebral)

12. Estado que sobrevive entre ejecuciones

Esta es la parte que suelen omitir los principiantes, aunque es la que convierte un bucle en un bucle. El modelo olvida todo entre ejecuciones. Si cada pulso comienza desde cero, no tienes un bucle: tienes el mismo primer paso repitiéndose para siempre. La solución es poco llamativa, pero potente: conservar el estado fuera del modelo, en disco.

Reproduce el archivo de guardado (40 segundos)

Sin un archivo de guardado, el agente choca con los mismos obstáculos en cada ejecución. Después guarda, y tú controlas el interruptor. Si está encendido, lee su archivo y termina. Si está apagado, olvida y empieza de nuevo.

Abrir ↗

Ese juego representa exactamente este concepto. El agente olvida todo entre ejecuciones, así que conserva un archivo de guardado en disco: esa es la columna vertebral. Reaparecer en el punto de control en vez de en el inicio equivale a tu archivo de progreso (progress.md), que registra lo terminado y lo que sigue abierto para que la próxima ejecución continúe en vez de empezar desde cero. La nota guardada de «obstáculos más adelante» equivale a tu archivo de reglas (CLAUDE.md / AGENTS.md): una lección aprendida una vez para dejar de repetir el mismo error. Por eso importa el interruptor. Con los archivos, el bucle avanza de una ejecución a otra. Sin ellos, siempre es un desconocido en la línea de salida. Cada ejecución lee estos archivos primero y los actualiza al final, porque el repositorio recuerda lo que el modelo no puede.

Hay dos capas de estado que trabajan juntas:

• El archivo de reglas (CLAUDE.md / AGENTS.md): los hábitos estables que el bucle lee en cada ejecución. Mantenlo breve. En el curso anterior aprendiste por qué: pagas el coste de un archivo de reglas inflado en cada pulso.
• Un archivo de progreso: un archivo Markdown sencillo, o un tablero de Linear mediante MCP, que registra qué se intentó, qué se aprobó y qué sigue abierto. Esta es la verdadera columna vertebral. La ejecución de mañana a las 9:00 lo abre y continúa donde terminó la de hoy.

El hábito es este: cada ejecución lee el archivo de progreso al comienzo y lo actualiza al final. Cuando el bucle repite el mismo error, la solución no es un prompt más ingenioso. Haz que el bucle escriba la lección en el archivo de reglas para conservar la corrección en todas las ejecuciones futuras.

El diario del practicante

Si las dos capas de estado parecen abstractas, imagina lo siguiente. Estás formando a un practicante nuevo. Defines una vez su contexto: el flujo de trabajo, el tablero de tickets, qué tareas puede tomar y cuándo debe consultarte. Después le entregas un diario y dos instrucciones permanentes. Primera: cada vez que recibas comentarios, escribe la lección al principio del diario y vuelve a leerla cada mañana. Por ejemplo: «no uses ese patrón de diseño», «este equipo combina los commits» o «ejecuta siempre el linter antes de mostrarme algo». Segunda: antes de irte a casa, escribe al final lo que terminaste y dónde te detuviste, para que mañana comience donde terminó hoy y no desde cero. El principio del diario es tu archivo de reglas: lecciones duraderas que se leen en cada ejecución. El final es tu archivo de progreso: puntos de control que se actualizan en cada ejecución. Sin el diario, por inteligente que sea, el practicante vuelve a aprender las mismas correcciones y repite eternamente el trabajo de ayer. A un bucle le ocurre lo mismo, porque la memoria del modelo se borra por completo entre ejecuciones, mientras que la del practicante al menos se desvanece despacio. Para ninguno de los dos el diario es opcional. Es la diferencia entre una persona empleada y un desconocido que aparece cada día.

<!-- progress.md — the loop's memory between runs -->

## Done

- 2026-06-22: fixed flaky test in test/auth (retry on token refresh)

## In progress

- Dependency audit: 3 of 7 advisories patched; lodash bump blocked by an API change

## Open / needs a human

- CVE-2026-xxxx in image lib — the fix changes the output format, escalating to a maintainer

La columna vertebral también es tu registro

Como el archivo de progreso es solo texto dentro del repositorio, también registra lo que hizo el bucle mientras estabas ausente. Cuando llegas a la puerta humana, lees la columna vertebral, no la transcripción completa de cada ejecución.

Observa cómo un bucle olvida y después recuerda: Paper Watch

Resulta difícil creer en la columna vertebral hasta que ves olvidar a un bucle. Por eso existe un proyecto que lo hace visible: Paper Watch. Cada día muestra los artículos de investigación más recientes sobre el tema que elijas, pero solo aquellos que aún no has visto. No necesitas instalar nada ni usar una clave: Claude los obtiene directamente de arXiv.

Clónalo, abre la carpeta en tu agente y pide:

show me what's new on arXiv about "LLM agents"

Recibirás los artículos más recientes, empezando por el más nuevo. Ahora pide exactamente lo mismo otra vez y responderá «nada nuevo desde la última ejecución ✓». El bucle recordó: escribió en progress.md cada artículo que acababa de mostrarte y volvió a leer el archivo antes de responder. Ese archivo es la columna vertebral. Para demostrarlo, elimina la memoria y vuelve a preguntar:

rm progress.md
show me what's new on arXiv about "LLM agents"

Todos los artículos vuelven a aparecer como «nuevos». Acabas de hacer que el bucle olvide todo: sin columna vertebral no hay bucle, con un solo comando. Para convertirlo en un vigilante real, dale un latido diario, como viste en el Concepto 6: /schedule every weekday at 9am, run the paper-watch skill and show me what's new. arXiv se actualiza aproximadamente una vez al día, así que una ejecución diaria tiene el ritmo adecuado.

Compáralo ahora con Sky Watch, del Concepto 6, y la idea completa quedará clara. Ambos son Routines diarios. Sin embargo, Sky Watch vuelve a mostrar los asteroides de hoy en cada ejecución y no necesita memoria, mientras que Paper Watch solo muestra las novedades y no puede funcionar sin la columna vertebral. El mismo latido, pero necesidades de memoria opuestas. Ese contraste muestra exactamente cuándo la necesita un bucle.

El sector convergió en los archivos

Contexto opcional que puedes omitir en la primera lectura.

La columna vertebral de este curso consiste en archivos Markdown sencillos en disco. No es una simplificación para principiantes. Es el resultado al que llegó el trabajo de memoria de Anthropic después de un año probando alternativas. Su regla declarada es «haz lo sencillo que funciona», y vale la pena conocer el camino que describen:

1. Un archivo de reglas (CLAUDE.md) llegó primero: un archivo Markdown que se inyecta al comienzo de cada sesión. Funcionó mucho mejor de lo esperado, pero crece, y el coste de un archivo inflado se paga en cada ejecución.
2. Las herramientas de memoria en sesión llegaron después: permiten que el agente decida cuándo leer y escribir recuerdos durante una tarea. La autonomía funcionó; las herramientas imponían demasiadas decisiones.
3. Las skills resolvieron el problema del crecimiento: el agente solo lee la descripción breve de cada skill y carga el contenido completo cuando lo necesita.
4. La práctica recomendada actual es la más sencilla: representar la memoria como un sistema de archivos normal. Archivos Markdown dentro de carpetas. El agente los busca con herramientas comunes que ya conoce, como grep y comandos de shell, en lugar de usar una API de memoria especial. El almacén puede crecer mucho siempre que siga siendo fácil de buscar.

Observa en qué consiste ese último paso. Es la columna vertebral tal como la enseña este curso: archivos en el repositorio, leídos al inicio, actualizados al final y consultados con herramientas normales. Cuando la solución de producción de un laboratorio de frontera y el primer bucle de un principiante usan el mismo diseño, significa que el diseño es fundamental y no una versión simplificada de algo más sofisticado.

El bucle que mejora el bucle

Detalle técnico opcional que puedes omitir en la primera lectura.

El hábito anterior del archivo de reglas es más importante de lo que parece. Cuando tu bucle escribe una lección en CLAUDE.md para que todas las ejecuciones futuras se comporten mejor, haces manualmente algo que tiene nombre: un bucle de ascenso de colina. Su resultado no es trabajo, sino mejoras al sistema que realiza el trabajo.

La versión automática funciona así. Cada ejecución deja una traza. Un paso lee las trazas y busca errores recurrentes. Después, los hallazgos modifican el prompt, las herramientas o las reglas del revisor. En resumen, el bucle se edita a sí mismo.

(LangChain describe cuatro bucles apilados: el ciclo de herramientas del agente, un bucle de comprobación, otro dirigido por eventos y, encima, este bucle de mejora. swyx llama loopcraft a la práctica de apilar bucles. Observa que los tres primeros son el bucle interno, el creador-revisor y el latido de este curso con otros nombres. El sector sigue llegando a la misma forma. Es una prueba sólida de que la habilidad está en la forma, no en la herramienta.)

Una distinción mantiene la honestidad de todo esto: nada de ello significa que el modelo esté aprendiendo. Ningún modelo público actual modifica sus propios pesos a partir de tus sesiones. El modelo que se ejecute mañana será exactamente el mismo que se ejecutó hoy. Lo que mejora es todo lo que lo rodea: el archivo de reglas, las skills, la rúbrica del revisor y el prompt. Algunas personas llaman autoaprendizaje a lo primero y automejora a lo segundo. Todos los bucles de este curso pertenecen al segundo tipo, y funcionan gracias a la columna vertebral: la lección sobrevive en disco porque no puede sobrevivir dentro del modelo. La misma diferencia aparece después de una ejecución decepcionante. El reflejo del principiante consiste en escribir mañana un prompt mejor y volver a empezar desde cero, así que nada se conserva. El reflejo del bucle es otro: ejecutar, registrar, extraer la lección, escribirla en el sistema y volver a ejecutar. La memoria crece, el sistema se afina y las mejoras se acumulan ejecución tras ejecución.

No necesitas una plataforma especial para empezar. Lee una semana de entradas de progress.md y formula una pregunta: «¿qué debería decir el archivo de reglas para que este tipo de error deje de ocurrir?». Es la misma idea a velocidad humana. Ten presente la misma advertencia que aparece en toda la Parte 6: un bucle de mejora que nunca lees reescribe sus propias reglas sin que nadie lo observe. Los cambios al propio bucle también merecen pasar por la puerta humana.

Dreaming: el bucle de mejora como producto y construido por ti

Detalle técnico opcional que puedes omitir en la primera lectura.

El bucle de ascenso de colina anterior existe ahora como función gestionada. El equipo de IA aplicada de Anthropic lo describe en una conferencia de 2026 y lo llama dreaming, o sueño. El nombre encaja: es un proceso que se ejecuta mientras descansan los agentes de trabajo y ordena lo que aprendieron.

Primero, su vocabulario. El trabajo de memoria en banda ocurre dentro de una sesión activa: el agente pausa la tarea para escribir una lección en disco. Es lo que enseñó el Concepto 12 y funciona, pero tiene dos límites inherentes. El agente debe dividir su atención entre la tarea que le diste y el trabajo de memoria que ayuda a ejecuciones futuras. Además, solo puede ver su propia sesión, así que nunca detecta un error que se repite a lo largo de diez sesiones o diez agentes.

Dreaming es la respuesta fuera de banda. Es un bucle separado con su propio latido y su propio presupuesto de tokens. Un pulso funciona así:

1. Reunir el almacén de memoria, es decir, los archivos de reglas y progreso que mantienen tus bucles, y un lote de transcripciones de ejecuciones recientes, incluidas las llamadas a herramientas y no solo la conversación.
2. Un orquestador entrega las transcripciones a un grupo de subagentes y cada uno analiza una parte.
3. El orquestador busca patrones que se repitan entre sesiones: la misma llamada a herramienta que falla, el mismo conocimiento ausente o el mismo error de estilo.
4. Propone cambios al almacén de memoria y adjunta pruebas: transcripciones de ejemplo donde apareció el patrón y su frecuencia.
5. Una persona acepta o rechaza cada cambio antes de que entre en vigor.

Vuelve a leer la lista con el vocabulario del curso. La programación por lotes es un latido. El almacén de memoria es la columna vertebral. Quienes analizan las transcripciones son subagentes. El paso que presenta una propuesta con pruebas para que una persona decida es la separación entre creador y revisor, con una puerta humana encima. Dreaming no tiene una forma nueva: es el bucle de seis partes dirigido a la memoria del propio bucle en vez de a tu código. La charla lo representa como una escuela: los estudiantes, los agentes de trabajo, hacen las tareas; un docente principal, la pasada de dreaming, lee todos los trabajos corregidos, detecta que todas las clases fallaron la misma pregunta y corrige el plan de estudios. Así, cada estudiante mejora al día siguiente sin haber dedicado tiempo de clase a ello.

Dos advertencias de la misma charla se aplican directamente a tus bucles. Los recuerdos se vuelven obsoletos: una lección escrita hace seis meses puede ser incorrecta hoy, así que algo debe revisarlos y podarlos. Esa es la mitad de la finalidad de dreaming. Además, cuando muchos agentes comparten un almacén de memoria, este necesita salvaguardas de producción. Se explican donde corresponde, en la nota del Concepto 14 sobre memoria compartida.

Comprueba primero tus propias herramientas, porque ya se distribuye una versión de esto. Claude Code tiene una función preliminar de investigación llamada Auto Dream. Mientras trabajas, Claude Code escribe discretamente sus propias notas sobre tu proyecto. Después de muchas sesiones, esas notas se desordenan: se acumulan duplicados y los datos antiguos conviven con otros nuevos que los contradicen. Auto Dream se encarga de limpiarlas. Se ejecuta en segundo plano entre sesiones, combina duplicados, elimina notas que el trabajo más reciente demostró incorrectas y solo puede escribir en archivos de memoria, nunca en tu código. Para comprobar si lo tienes, ejecuta /memory en una sesión y busca el interruptor Auto-dream. Para ejecutar una pasada manual, basta con decir «consolidate my memory files». OpenClaw incluye un sistema opcional parecido, /dreaming, y los usuarios de OpenCode encontrarán equivalentes comunitarios. Como siempre, esta es la capa mecánica: consulta la documentación vigente.

Una advertencia antes de confiar en esta función: el limpiador da prioridad a las pruebas nuevas frente a las notas antiguas, así que puede reescribir o eliminar una nota aunque la hayas escrito a mano. Conserva esta regla: cualquier norma que nunca quieras modificar debe ir en CLAUDE.md, el archivo que solo tú controlas. Las notas gestionadas automáticamente son el cuaderno de Claude. CLAUDE.md es tuyo.

Mantén clara otra distinción, porque las dos tareas se parecen. Auto Dream se ocupa de la higiene: mantiene limpias las notas. El bucle siguiente se ocupa de la mejora: encuentra errores que tus bucles siguen repitiendo y propone reglas nuevas para detenerlos. Uno limpia y el otro entrena. Misma forma, distinto trabajo. Vale la pena construir por tu cuenta el entrenador, porque ya conoces cada componente:

1. Latido semanal, no diario. Dreaming busca patrones entre ejecuciones, así que necesita observar un lote. Una Routine semanal en la nube, o una programación semanal de cron o GitHub Actions, tiene la cadencia correcta. Una ejecución diaria es demasiado frecuente para detectar patrones y además multiplica el coste sin aportar nada, como explica el Concepto 13.
2. Entrada: haz que tus bucles dejen transcripciones legibles. Este es el único requisito previo. Tus bucles de trabajo deben registrar lo ocurrido siguiendo el hábito de observabilidad que ya tienes: una entrada fechada por pulso en progress.md, además de registros de ejecución conservados en el repositorio. En OpenCode, opencode run --format json y opencode export proporcionan el registro completo. En Claude Code, haz que cada Routine añada su resultado a un archivo de registro y haga commit. Sin registros no hay nada con lo que soñar.
3. Cuerpo: un orquestador y subagentes analistas. El prompt de dreaming lee el lote de registros acumulado desde la última ejecución. Si el lote es grande, reparte fragmentos entre subagentes y cada uno responde una pregunta: ¿qué falló y apareció el mismo fallo más de una vez? Un error es ruido. El mismo error tres veces indica una lección ausente.
4. Creador-revisor por partida doble. Los analistas proponen y el orquestador solo conserva los patrones respaldados por pruebas suficientes. Después interviene el revisor real: el bucle nunca edita directamente el archivo de reglas ni una skill. Redacta el cambio en una rama claude/ y abre un PR cuya descripción incluye las pruebas: qué ejecuciones mostraron el patrón, con qué frecuencia y por qué esa línea lo detendría.
5. Puerta humana: tú fusionas o cierras. Un cambio en CLAUDE.md o en una skill es la escritura con mayor influencia de todo el sistema, porque la leen todas las ejecuciones futuras de todos los bucles. Es justo donde el curso sitúa la puerta: una decisión costosa y difícil de revertir que debe tomar una persona.
6. La propia columna vertebral del bucle de dreaming. Un archivo de estado pequeño, por ejemplo dreaming-state.md, registra la fecha del último lote revisado. Así, la semana siguiente solo lee los registros nuevos en vez de volver a soñar con todo el historial.

Observa lo que este diseño te ofrece sin coste adicional. El almacén vive en git, así que el control de versiones y la reversión no cuestan nada. Todos los cambios de reglas llegan como PR, por lo que los permisos se reducen a «nadie fusiona salvo tú». La obsolescencia también encuentra un lugar natural: indica al prompt de dreaming que proponga eliminaciones, como reglas que ninguna ejecución reciente necesitó y lecciones que contradicen los registros actuales. Un almacén de memoria que solo crece se convierte en un archivo de reglas cuyo coste pagas en cada pulso y en el que confías menos cada mes.

Dos formas en que puede fallar un bucle de dreaming

Puede blanquear un ataque. Las transcripciones que lee una pasada de dreaming contienen texto escrito por personas externas: cuerpos de issues, descripciones de PR y páginas obtenidas por un bucle. Los investigadores de seguridad llaman envenenamiento de memoria a este riesgo: una instrucción insertada en la entrada de una ejecución se guarda en la memoria y dirige todas las ejecuciones posteriores mucho después de desaparecer el ataque original. Una pasada de dreaming es precisamente la máquina capaz de convertir una inyección puntual en una regla permanente. No es una razón para descartar dreaming, sino el motivo de dos reglas que ya incorpora el diseño. Siempre debe haber pruebas: una propuesta debe citar las ejecuciones de las que procede para que puedas leer la fuente antes de confiar en la lección. Y siempre debe existir la puerta humana: un cambio de reglas que evita la revisión es justo la escritura que más desea un atacante. La misma pasada también te beneficia, porque una lectura semanal del archivo de reglas es tu mejor oportunidad de detectar una línea que nunca aprobaste.

Puede erosionar lo que mantiene. Los investigadores que estudiaron la reescritura repetida de memoria encontraron dos patrones de fallo. El sesgo hacia la brevedad conserva la idea general y elimina los detalles: «comprueba la carga útil de la respuesta, no el código de estado» se convierte en «gestiona los errores». El colapso del contexto hace que cada reescritura completa sea una copia con pérdidas de la anterior, hasta degradar un manual detallado en un párrafo vago. La defensa es la que ya usa este bucle: proponer diferencias pequeñas, nunca reescrituras completas. Como el almacén vive en git, un archivo de reglas que se reduce aparece en el diff y puedes rechazarlo. Un hábito pequeño evita toda una clase de deterioro: un archivo de memoria nunca debe contener una fecha relativa. «Ayer elegimos Redis» carecerá de sentido dentro de seis semanas. Cada pasada de consolidación convierte «ayer» en la fecha real, y tus bucles deberían escribir fechas absolutas desde el principio.

Otro límite importante: un sueño necesita material. Un bucle con un historial de tres ejecuciones, o un proyecto desechable, no contiene patrones que encontrar; la pasada producirá lecciones plausibles a partir del ruido. Aplica dreaming a bucles con experiencia real y comprueba el resultado de la forma más económica: una lección que funcionó se refleja en un fallo que deja de aparecer en los registros de la semana siguiente.

Recuerda la advertencia de la nota anterior sobre el bucle de mejora: este bucle reescribe las reglas que dirigen a todos los demás. De todos los bucles que posees, es el último que debería ejecutarse sin su puerta.

Anthropic distribuye la versión gestionada como parte de las herramientas de memoria de Managed Agents. Como en todo el curso, esa es la capa mecánica: consulta la documentación vigente de la plataforma antes de confiar en cualquier detalle del producto. La capa duradera es la forma, y tú mismo la construiste dos párrafos atrás.

Comprueba lo aprendido

¿Dónde debe guardar un bucle lo que ha hecho hasta ahora y por qué no debe hacerlo en la conversación?

Mostrar respuesta

En disco, dentro de un archivo de progreso, junto con el archivo de reglas, o en un tablero como Linear. La memoria del modelo se borra entre ejecuciones, así que todo lo que deba sobrevivir vive fuera del modelo. El repositorio recuerda; el modelo no.

---

Parte 5: un bucle completo, dos veces

Lista mínima para un bucle seguro

Antes de permitir que un bucle funcione por sí solo, necesita estos siete elementos. El bucle que vas a construir los incluye todos:

• Condición de éxito: cómo sabe que terminó el trabajo, Concepto 5.
• Límite: número máximo de intentos, minutos o gasto para impedir que se ejecute eternamente, Concepto 13.
• Rama o worktree aislado: evita colisiones entre trabajos en paralelo, Concepto 8.
• Revisor de solo lectura: un agente separado que evalúa, pero no puede editar, Concepto 11.
• Archivo de estado: la columna vertebral que permite recordar entre ejecuciones, Concepto 12.
• Puerta humana: el trabajo arriesgado o fallido llega a una persona, nunca directamente a main, Parte 5.
• Registro o notificación: hace visible un fallo nocturno en vez de dejarlo en silencio, Parte 6.

Si falta uno, el bucle será inseguro, olvidadizo o invisible.

Ahora une las partes. Este es un bucle: un bucle de mantenimiento matutino que clasifica los fallos de CI ocurridos durante la noche, redacta correcciones seguras, hace que se revisen, abre PR para las que aprueban y marca las demás. Lo construiremos una vez en cada herramienta. Los archivos siguientes son reales: puedes copiarlos en un repositorio y ejecutarlos.

La forma del bucle, idéntica en ambas herramientas:

1. Latido: cada día laborable a las 9:00.
2. Skill: una skill daily-triage contiene los pasos para que el prompt se mantenga en una sola línea.
3. Columna vertebral: leer progress.md al inicio y actualizarlo al final.
4. Worktree: redactar cada corrección en su propio checkout.
5. Creador-revisor: una persona implementadora redacta y un revisor separado responde PASS o FAIL.
6. Conector: abrir un PR si el resultado es PASS. Si es FAIL o existe algún riesgo, escribirlo en «necesita una persona» y detenerse.

La skill compartida

Este único archivo funciona en ambas herramientas. Guárdalo como .claude/skills/daily-triage/SKILL.md en Claude Code o .opencode/skills/daily-triage/SKILL.md en OpenCode.

---
name: daily-triage
description: >-
  Runs the morning maintenance pass. Reads the progress file, gathers overnight
  CI failures, open issues, and new audit advisories, drafts safe fixes (each
  one checked by a separate reviewer agent), opens pull requests for what passes,
  and writes anything risky to the progress file for a human. Use this for the
  scheduled morning maintenance loop.
---

# Daily triage

You are the morning maintenance loop. Work through these steps in order.
Do not skip the progress file. It is your only memory between runs.

## 1. Read your memory first

- Open `progress.md`. Read the "In progress" and "Open / needs a human" sections.
- Do not redo anything already listed under "Done".

## 2. Find the work

Gather candidates in this order, and stop once you have at most 5:

1. CI runs that failed since the last entry in `progress.md`.
2. Open issues labelled `bug` or `maintenance`.
3. New advisories from `npm audit` (or this project's audit command).

## 3. Work each candidate

- Create an isolated checkout: a git worktree, or a fresh branch named
  `claude/<short-slug>`.
- Draft the smallest fix that solves the one problem. Do not bundle changes.
- Send the diff to the reviewer agent. Wait for its verdict before going on.

## 4. Decide from the verdict

- PASS, and the change is low risk (no public API change, no data migration,
  no file deletion): open a pull request. Title it `fix: <one short line>` and
  link the issue.
- FAIL, or the change touches anything risky: do NOT open a pull request. Add a
  short entry to the "Open / needs a human" section of `progress.md`. Say what
  you tried and why you stopped.

## 5. Update your memory last

- Move finished items to "Done" with today's date.
- Save `progress.md`. This is the file tomorrow's run will read.

## Rules

- Never open more than 5 pull requests in one run.
- Never change `main` directly. Only `claude/*` branches.
- When in doubt, escalate. A flagged item a human checks is always safer than a
  wrong fix shipped while no one was watching.

El revisor

El revisor lleva a la práctica la separación entre creador y revisor. Necesitas ambos archivos; no debes elegir uno u otro según la herramienta. El formato cambia un poco, por eso ambos aparecen completos a continuación.

Claude Code, guardado como .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews a diff against the spec and the test results. Replies PASS or FAIL with reasons. Makes no changes.
tools: Read, Bash
model: claude-haiku-4-5-20251001
---

You are a strict, read-only code reviewer. You never edit files.

1. Run the tests and the linter. Read the output yourself. Do not trust a claim
   that they pass.
2. Check the change against the project conventions in `CLAUDE.md` and the
   relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
   behaviour.

Then reply with exactly one of:

- `PASS` — followed by one line saying what you verified.
- `FAIL` — followed by the specific reasons, one per line.

A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.

Una aclaración importante sobre la línea tools: solo acepta nombres de herramientas (Read, Bash), por lo que no puede limitar al revisor únicamente a los comandos de pruebas, lint y diff. Por ahora, las instrucciones numeradas establecen ese límite. El siguiente curso, Ingeniería del arnés, añade la regla que lo aplica. Además, las comprobaciones que evalúa este revisor no tienen que residir en su prompt. El interludio sobre skills de verificación muestra cómo escribir cada comprobación como una skill propia, de modo que el revisor y el revisor de /goal evalúen el mismo archivo.

OpenCode, guardado como .opencode/agents/reviewer.md:

---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons. Read-only.
permission:
  edit: deny
  bash:
    "*": deny
    "npm test*": allow
    "npm run lint*": allow
    "git diff*": allow
---

You are a strict, read-only code reviewer. You never edit files.

1. Run the tests and the linter. Read the output yourself. Do not trust a claim
   that they pass.
2. Check the change against the project conventions in `AGENTS.md` and the
   relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
   behaviour.

Reply with exactly one of:

- PASS — followed by one line saying what you verified.
- FAIL — followed by the specific reasons, one per line.

A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.

Iniciar el bucle según una programación

Crea una Routine en claude.ai/code/routines con una programación para las 9:00 de los días laborables, tu repositorio y tus conectores de GitHub y Slack. Haz que el prompt apunte a la skill para mantener muy breve la definición de la rutina:

Run the daily-triage skill.
Start by reading progress.md; finish by updating it.
For each fix: draft it in an isolated worktree, have the reviewer subagent grade it,
open a PR only on PASS, and append anything risky to the "needs a human" section.

La skill contiene los pasos. .claude/agents/reviewer.md es el revisor. isolation: worktree mantiene separadas las correcciones en paralelo. El conector de GitHub abre los PR. Como es una Routine en la nube, se ejecuta a las 9:00 tanto si el portátil está abierto como si no. También cabe dentro del límite diario de ejecuciones de tu plan: una programación a las 9:00 en días laborables supone 5 ejecuciones semanales, así que incluso un límite Pro de 5 al día deja margen suficiente. Una Routine que se active cada pocas horas no lo dejaría. El apéndice de Routines explica campo por campo cómo configurar una por primera vez, incluidos el entorno, el alcance de los conectores y el panel de secretos.

Constrúyelo como un flujo de trabajo de GitHub Actions para que se ejecute en la nube sin que ninguna de tus máquinas permanezca activa. La Action es el latido. opencode run es el trabajador. Tu repositorio contiene la skill, los agentes y progress.md.

name: morning-maintenance
on:
  schedule:
    - cron: "0 9 * * 1-5"
jobs:
  triage:
    runs-on: ubuntu-latest
    permissions: { contents: write, pull-requests: write, issues: write }
    steps:
      - uses: actions/checkout@v6
        with: { persist-credentials: false }
      - uses: anomalyco/opencode/github@latest
        env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
        with:
          model: anthropic/claude-sonnet-5   # confirm with `opencode models`
          prompt: |
            Run the daily-triage skill.
            Read progress.md first; update it last.
            For each candidate fix: draft it on a new branch, then invoke the
            @reviewer subagent to grade it. Open a PR only when the reviewer
            replies PASS. Append anything risky to the "needs a human" section
            of progress.md and leave it for the maintainer.

El agente reviewer, ejecutado con un modelo de solo lectura más económico, es el revisor. Las ramas nuevas cumplen la función del aislamiento mediante worktrees en CI. La app de GitHub de OpenCode abre los PR. ¿Prefieres ejecutarlo en tu propia máquina en vez de la de GitHub? El mismo prompt se ejecuta desde una línea de cron que llama a opencode run; solo cambia el latido.

Cómo es una mañana real

Diseñaste una sola vez todo lo anterior. Esta es una ejecución individual, como la que encontrarías al despertar. La ejecución siguiente muestra la forma, no es una grabación:

[09:00] daily-triage fires
  → reads progress.md: 1 item still "in progress" (lodash bump), nothing new flagged
  → finds: 2 CI failures overnight, 1 new npm-audit advisory
  → CI failure #1 (flaky auth test):
        drafts fix on branch claude/fix-auth-retry
        reviewer → PASS (tests green; retries on token refresh; no API change)
        → opens PR #142, links the issue
  → CI failure #2 (type error in report.ts):
        drafts fix on branch claude/fix-report-types
        reviewer → PASS → opens PR #143
  → advisory (image library):
        the safe fix changes the output format
        reviewer → FAIL (public behaviour change)
        → writes it to "Open / needs a human" in progress.md, opens no PR
  → updates progress.md, exits
[you, 09:30] two PRs to review, one flagged item to decide on. You typed nothing.

Reproduce el bucle completo, unos 40 segundos

La ejecución anterior, animada: se activa, encuentra el trabajo, redacta cada corrección y un revisor separado evalúa cada una como PASS o FAIL. Publica las dos seguras como PR y rechaza la arriesgada. Después te entrega la puerta humana. Tú tomas la única decisión que necesita a una persona.

Abrir ↗

Observa lo que ocurrió. El bucle encontró el trabajo, lo redactó, lo comprobó, publicó la parte segura y solo te entregó la decisión que necesitaba a una persona. Eso es la ingeniería de bucles en la práctica. Observa también que la única diferencia real entre ambas herramientas fue el latido y el lugar de ejecución. Todo lo intermedio, la skill, la columna vertebral, el worktree, el creador-revisor y el conector, compartía el mismo diseño.

Comprueba lo aprendido

En el bucle de revisión matutina, ¿qué impide que una corrección equivocada se fusione mientras duermes?

Mostrar respuesta

Tres elementos combinados: el subagente revisor debe devolver PASS, separación entre creador y revisor; solo los cambios de bajo riesgo pueden abrir un PR; y la puerta humana envía todo lo arriesgado o fallido a una nota de «necesita una persona» en vez de a main. Además, cada ejecución tiene un límite y queda registrada.

---

Parte 6: mantener el control humano

Un bucle cambia el trabajo, pero no te aparta de él. Hay tres problemas que se vuelven mayores a medida que mejoran tus bucles, no menores. Esta es la parte más importante del curso.

Tu bucle es uno de tres ciclos de retroalimentación

Acabas de construir un bucle de seis partes. Una vez iniciado, funciona por sí solo: el agente escribe código, lo prueba, lo corrige y vuelve a intentarlo sin ti.

Ese es un bucle, el más rápido. Completa un ciclo en minutos, pero no trabaja solo. Es el menor de tres bucles y tú debes dirigir los otros dos.

La forma más sencilla de entenderlos es mediante un ejemplo. Supón que pides a un agente que construya un pequeño juego de mecanografía para un niño.

• El bucle de programación completa un ciclo en minutos. El agente escribe el juego, lo prueba y corrige errores hasta que coincide con tus instrucciones. Es el bucle que acabas de construir.
• El bucle de retroalimentación completa un ciclo en horas. Abres el juego, lo pruebas y decides qué cambiar: agrandar los botones, añadir disfraces de gato que el niño pueda desbloquear o incorporar un inicio de sesión para que ayude una persona adulta. Después actualizas las instrucciones y el agente vuelve a construir.
• El bucle externo completa un ciclo en días. Personas reales usan el juego. Un amigo lo prueba. Un niño juega con él. Sus acciones te muestran qué corregir después.

Los bucles no están uno al lado del otro, sino uno dentro de otro. Ocurren muchos bucles de programación mientras diriges un bucle de retroalimentación. Ocurren muchos bucles de retroalimentación mientras el mundo exterior devuelve una ronda de comentarios. El bucle rápido funciona solo; los lentos te necesitan.

Debes conocer dos palabras. Una spec es la descripción escrita de lo que se debe construir. Las evaluaciones son un conjunto pequeño de pruebas que comprueban si el agente acertó. Juntas se sitúan entre los dos primeros bucles y llevan tus decisiones al código.

Llegamos a la idea principal, de Andrew Ng. ¿Por qué no puede el agente dirigir por sí solo los tres bucles? Porque tú sabes cosas que él desconoce: quién usará el producto, qué necesita en realidad y cómo se siente un buen resultado. Mientras poseas información que el agente no tiene, permanecerás en el bucle para comunicársela. Ng llama a esto tu ventaja de contexto.

Es la misma lección con la que termina este curso. La máquina dirige el bucle rápido. Tú conservas las dos cosas que nunca puede asumir: qué construir y quién responde por ello.

Aunque nunca construyas un producto, conserva este mapa. Muestra dónde se sitúa la persona en el trabajo de cualquier agente. Para afinar la spec que une los dos primeros bucles, consulta Desarrollo guiado por especificaciones. Para ver cómo crece tu función a lo largo de los bucles externos, consulta Los roles para los que te prepara este libro.

13. El coste de los tokens es el límite real, no los comandos

Esta es, con diferencia, la forma más habitual en que fallan los bucles. Un bucle se ejecuta una y otra vez. A menudo inicia subagentes y cada uno ejecuta su propio modelo y herramientas. El coste crece más rápido de lo que casi nadie espera. Las soluciones son sencillas:

• Limita cada bucle: número máximo de intentos, minutos o gasto. Siempre, como vimos en el Concepto 5.
• Ajusta el modelo a la tarea: usa un modelo potente para planificar y comprobar, y uno económico para hacer el trabajo. Es el mayor ahorro posible y ya lo aprendiste en el curso anterior. En Claude Code también debes ajustar el nivel de esfuerzo al pulso (/effort, o CLAUDE_CODE_EFFORT_LEVEL para ejecuciones sin interfaz). El valor predeterminado basta para una revisión rutinaria. Los niveles superiores son para pulsos que de verdad requieren razonamiento profundo. Pagar el máximo esfuerzo en cada activación de un bucle programado es el mismo error que ejecutar un modelo de frontera para una tarea mecánica.
• Mantén breves el prompt del bucle y el archivo de reglas: pagas por ellos en cada pulso. Lleva los detalles a skills que solo se carguen cuando se usen.
• Ejecútalo con menos frecuencia: una vez por hora, en vez de cada cinco minutos, suele bastar y cuesta unas doce veces menos.

Una referencia rápida de las cifras, a modo de ejemplo. Supón que un pulso, creador más revisor, lee unos 40.000 tokens y escribe unos 6.000. Con el precio estándar de Sonnet de 3 USD por millón de tokens de entrada y 15 USD por millón de tokens de salida, son unos 0,20 USD por pulso. Cinco pulsos diarios durante un mes de 20 días cuestan alrededor de 20 USD.

El mismo bucle ejecutado cada cinco minutos, durante todo el día y toda la noche, realiza más de cien veces esa cantidad de pulsos. Su coste mensual puede superar con facilidad los 1.000 USD, aunque cada pulso haga el mismo trabajo. La frecuencia, no el nombre del comando, impulsa el aumento.

Detalle opcional sobre el modelo actual: Sonnet 5 se lanzó con precios promocionales hasta agosto de 2026 y su tokenizador puede producir más tokens para el mismo texto que modelos anteriores. Mide los tokens utilizados por tu bucle real, multiplícalos por el precio vigente del modelo y después por el número de ejecuciones programadas.

El modelo es una segunda palanca de costes en OpenCode. El ejemplo anterior presupone un modelo de la clase Sonnet con el precio estándar. Los comandos de bucle de Claude Code usan Claude, mientras que OpenCode permite elegir otro modelo. Un modelo más económico puede reducir mucho el precio de cada pulso.

Sin embargo, un creador más débil puede producir más intentos fallidos y eliminar el ahorro. Un patrón práctico es creador económico y revisor fiable: usa el modelo más barato para trabajos claros y mecánicos, y conserva las pruebas, los linters o un revisor de confianza para comprobarlos.

La frecuencia sigue siendo lo más importante. Un modelo treinta veces más barato que se ejecuta cada cinco minutos puede costar más que Sonnet una vez por hora. El modelo cambia el coste por pulso; la programación y la tasa de reintentos determinan cuántos pulsos pagas.

Un bucle sin límite de gasto puede costar mucho

El fallo habitual siempre es el mismo: un bucle funciona solo con una condición de parada que nunca puede cumplir y vuelve a intentarlo durante toda la noche. Establece un límite antes de iniciarlo. Observa las primeras ejecuciones reales. Después permite que funcione solo.

Una buena columna vertebral también reduce costes

La columna vertebral suele enseñarse como una función de corrección: sin memoria no hay bucle. Sin embargo, Anthropic informa de un segundo efecto en flotas de producción. Un agente con un almacén de memoria bien mantenido realiza mejor la tarea la segunda vez, porque la lección del primer intento ya está en disco. Mejores primeros intentos significan menos reintentos, y menos reintentos significan menos tokens. Así, el bucle se vuelve más preciso y económico al mismo tiempo. Esta es también la respuesta honesta a «¿por qué gastar tokens en una pasada de dreaming?»: la pasada consume tokens una vez y los recupera en cada pulso futuro que tiene éxito al primer intento en vez de repetir.

14. Comprobar el trabajo sigue siendo tu responsabilidad

Un bucle que funciona por sí solo también comete errores por sí solo. La separación entre creador y revisor hace que el «terminado» del bucle signifique algo. Aun así, «terminado» sigue siendo una afirmación, no una prueba. Tu trabajo no desapareció, sino que cambió de lugar. Ya no escribes cada paso, pero sigues siendo quien confirma que el bucle publicó código que funciona de verdad. Lee los diffs que abrió el bucle. Confía en que haga el trabajo y compruébalo antes de darlo por válido.

Cuando ejecutas muchos bucles

Detalle técnico opcional que puedes omitir en la primera lectura.

Tres aspectos que este curso enseña para un bucle se convierten en problemas de organización en cuanto tienes muchos. El mundo de las plataformas empresariales ya empieza a documentar los tres.

Primero, las matemáticas del fallo cuando nadie observa. Los pasos del modelo son fiables, pero no seguros. Encadena cinco pasos, cada uno correcto el 95 % de las veces, y solo unas tres de cada cuatro ejecuciones terminarán sin problemas. Además, empeora: los errores de un bucle sin supervisión se acumulan dentro de la columna vertebral. Una línea incorrecta en progress.md esta noche será un punto de partida incorrecto mañana. Por eso importa tanto separar al creador del revisor. El revisor impide que un paso equivocado se vuelva permanente.

Segundo, limita lo que el bucle puede hacer, no solo lo que revisas. Tu revisor evalúa el trabajo que se le mostró, es decir, el diff. Esa revisión no demuestra que el bucle no hiciera nada más. Podría haber cambiado un valor de configuración, activado una opción o llamado a un sistema externo mediante un conector que tenía disponible. La solución no es un revisor más inteligente, sino un bucle más limitado. Considera cada parte del bucle como un permiso permanente. Una programación autoriza actuar mientras duermes. Un conector proporciona acceso permanente a un sistema real. Un subagente actúa con una identidad prestada. Por tanto, concede a cada bucle únicamente lo que necesita para su tarea. El prefijo claude/, la lista breve de conectores y el revisor de solo lectura expresan esta misma idea.

Tercero, la cuestión del recuento. Cuando cinco colegas copien tu bucle, alguien acabará formulando preguntas difíciles. ¿Cuántos bucles ejecuta este equipo? ¿Qué puede tocar cada uno? ¿Con la identidad de quién actúa? ¿Quién los aprobó? Eso ya no es ingeniería de bucles, sino gestión de personal. Es justo donde retoman el tema el material sobre equipos de personas y agentes y la idea del Digital-FTE. Un bucle que se gana la confianza por sí solo todavía debe ganarse un lugar en un equipo.

Cuando muchos bucles comparten una memoria

Detalle técnico opcional que puedes omitir en la primera lectura.

Un bucle que escribe en su propio progress.md no necesita nada de lo siguiente. Sin embargo, cuando varios bucles, o una flota completa, leen y escriben un almacén de memoria compartido, aparecen nuevos modos de fallo: dos agentes escriben el mismo archivo al mismo tiempo; uno «corrige» las reglas de toda la organización que leen los demás; y lecciones correctas en enero ya son falsas en junio. El equipo de Anthropic, que ejecuta precisamente estas flotas en producción, identifica cuatro salvaguardas. Cada una es una práctica antigua de software aplicada de nuevo a la memoria de los agentes:

• Control de versiones. Se registra cada cambio al almacén: qué cambió, qué ejecución lo provocó y quién o qué lo hizo. Una actualización incorrecta se puede revertir en vez de envenenar silenciosamente todas las ejecuciones futuras. Una columna vertebral bajo seguimiento de git lo ofrece sin coste, otro motivo para conservarla en el repositorio.
• Comprobación de conflictos antes de escribir. Antes de confirmar una edición, el agente comprueba si el archivo cambió mientras redactaba. Si cambió, vuelve a leerlo y lo intenta de nuevo, en vez de sobrescribir la actualización de otra persona. Las bases de datos llevan décadas haciéndolo y la memoria de agentes también lo necesita.
• Permisos por nivel. Un agente puede escribir libremente en su propio espacio temporal. Las reglas de toda la organización que leen todos los agentes deben ser de solo lectura para los agentes normales, y los cambios deben pasar por revisión. Una línea incorrecta en el nivel superior se extiende a toda la flota.
• Portabilidad. La memoria seleccionada es un activo que querrás usar en más de un producto. Consérvala en un formato sencillo y abierto, detrás de una interfaz clara, para poder trasladarla contigo.

El hilo común es este: una memoria de la que depende una flota constituye datos de producción y merece disciplina de producción. En particular, la pasada de dreaming de la nota del Concepto 12 existe para limpiar el problema de la memoria obsoleta.

Dentro, sobre o fuera del bucle: los nombres del sector para la puerta

Este curso habla de «la puerta humana». En el mundo más amplio, como los artículos sobre seguridad de IA, la Ley de IA de la UE, los equipos de cumplimiento bancario y las compras empresariales, se usan tres términos anteriores para la misma idea. Apréndelos una vez. Los compradores y reguladores los utilizarán, y corresponden exactamente a lo que ya construiste.

Término	Qué significa	Dónde lo construiste en este curso
Persona dentro del bucle	Una persona debe aprobar cada acción antes de que surta efecto. Mayor control, menor velocidad.	Prompts turno a turno. Modo de planificación. Fusión en la puerta humana. Puerta de dos Routines, A4.
Persona sobre el bucle	El sistema actúa solo; una persona observa y puede intervenir. Más rápido y autónomo.	Una Routine que sube a ramas claude/ mientras revisas cada mañana. Lectura de la columna vertebral a las 9:30.
Persona fuera del bucle	Nadie observa y no hay forma de intervenir.	En ninguna parte, de forma deliberada. En este curso no es una tercera opción, sino el modo de fallo.

De la tabla se desprenden tres ideas.

Primero, el cambio de mentalidad del Concepto 1 ya tiene nombre. Dar prompts sitúa a la persona dentro del bucle: tú eres el latido, el revisor y la memoria, y nada ocurre sin tu turno. La ingeniería de bucles te coloca sobre el bucle: el sistema se ejecuta y tu atención espera en la puerta. Es todo el cambio del curso expresado con las palabras del sector.

Segundo, un buen bucle no elige una opción u otra, sino que las combina para cada acción. El bucle de revisión matutina sitúa a la persona sobre el bucle para las correcciones seguras y vuelve a colocarla dentro ante cualquier riesgo: un FAIL del revisor, un cambio de comportamiento público o la propia fusión. La regla de ramas claude/ expresa exactamente esto: trabajo sin supervisión con un paso obligatorio dentro del bucle antes de main. La escalera de revisores del Concepto 2 indica cómo ajustar la mezcla: cuanto más débil sea el revisor, más acciones deben volver de «sobre el bucle» a «dentro del bucle». Una prueba superada gana autonomía; una puntuación de rúbrica no.

Tercero, la gravedad de la IA tira hacia «fuera del bucle». Nadie diseña a propósito un sistema con la persona fuera del bucle. Ocurre por deriva. Deja de leer los diffs, confía en las marcas verdes y omite la revisión semanal de lo publicado: un bucle diseñado con la persona sobre él se convierte silenciosamente en uno sin persona, sin cambiar nada del diseño. La regla de dogfooding es la defensa: sitúa a la persona allí donde un movimiento automático equivocado resulte costoso y difícil de revertir, y comprueba que de verdad siga allí. El hábito semanal del Concepto 15 es esa comprobación.

Cuando vendas un Digital FTE en un sector regulado, espera esta pregunta exacta: «¿La persona está dentro o sobre el bucle?» Ahora puedes responder con precisión, acción por acción, y señalar la puerta.

En pocas palabras

Dentro del bucle: una persona aprueba cada acción. Sobre el bucle: el sistema actúa y una persona observa y puede detenerlo. Fuera del bucle: nadie observa, algo nunca aceptable para escrituras. Todos los bucles de este curso sitúan de forma predeterminada a la persona sobre el bucle, con puertas dentro del bucle en los pasos arriesgados.

Comprueba lo aprendido

El bucle What's New de la sección de dogfooding publica sin ningún paso de aprobación. ¿La persona está dentro, sobre o fuera del bucle, y por qué es aceptable en este caso?

Mostrar respuesta

Sobre el bucle. Nadie aprueba cada ejecución, pero el resultado es público, queda registrado, se corrige con una sola reversión y el equipo lee las transcripciones. Solo quedaría fuera del bucle si nadie leyera nunca lo que publica. El coste de un movimiento equivocado determina el ajuste, y revertir una línea torpe del registro de cambios es barato.

15. No dejes de entender tu propio proyecto

Cuanto más rápido publique un bucle código que no escribiste, mayor será la distancia entre lo que contiene tu proyecto y lo que realmente entiendes. Esa distancia tiene un coste real y un bucle fluido la amplía en silencio. La cura y la trampa son el mismo acto. Diseñar el bucle te mantiene implicado cuando lo haces con cuidado. Te permite dejar de pensar cuando lo haces para evitar el trabajo. La misma acción produce resultados opuestos. El bucle no distingue la diferencia; tú sí.

Dos personas pueden construir exactamente el mismo bucle y obtener resultados opuestos. Una lo usa para avanzar más rápido en un trabajo que comprende a fondo. La otra lo usa para evitar entender el trabajo. Construye el bucle, pero hazlo como alguien que piensa seguir ejerciendo la ingeniería, no solo como quien pulsa el botón de inicio.

Ambas personas están sometidas a la misma fuerza, y tiene un nombre. Eric So, de MIT Sloan, la llama gravedad de la IA: la atracción constante a dejar que la IA realice cada vez más de tu pensamiento. Un bucle intensifica esa fuerza porque se ejecuta mientras duermes. Así, la distancia entre lo publicado y lo que entiendes puede crecer incluso los días en que no tocas nada. Si no se controla, la atracción debilita los dos extremos que este curso reserva para ti. La intención pasa de una condición precisa y comprobable a «haz que siga funcionando». La responsabilidad pasa de leer los diffs a confiar en las marcas verdes. El bucle continúa de cualquier forma; no puede saber si sigues ejerciendo la ingeniería. El hábito semanal del Concepto 15 contrarresta esa fuerza: lee lo publicado y comprueba que tu comprensión avanzó al mismo ritmo que los cambios del bucle.

Esta es la idea principal de todo el curso. Cada año, las herramientas se ocupan de una parte mayor de la mecánica del bucle. Funciones como los flujos de trabajo dinámicos, /goal, Routines, los límites de reintentos, los límites de steps por agente y las sesiones en segundo plano sustituyen ahora tareas que antes requerían scripts personalizados.

Las herramientas siguen sin poder asumir los dos extremos presentados en el Concepto 1: una intención expresada con precisión suficiente para comprobarla y la responsabilidad por lo publicado. Esas responsabilidades convierten esto en ingeniería y no en limitarse a pulsar botones. Usa herramientas más potentes, pero mantén la intención y la responsabilidad bajo control humano.

Cuando falla un bucle sin supervisión

Un bucle sin supervisión también falla sin supervisión. Antes de confiarle la noche, hazlo observable:

• Envía el resultado a un lugar donde lo verás: un archivo de registro, un mensaje de Slack o Discord mediante Channels de Claude Code, o la bandeja de entrada de Triage. No a la terminal que ya cerraste.
• Escribe una línea en cada ejecución, incluso si falla: cada pulso añade una nota con marca de tiempo a progress.md, o a un registro, que indica qué intentó, qué aprobó y qué se rompió. Un fallo silencioso es el peor de todos.
• Conserva ejecuciones reproducibles: en OpenCode, opencode run --format json, opencode export <id> y opencode session list proporcionan el registro completo. En Claude Code, una Routine conserva el historial de ejecuciones en la interfaz web y las sesiones en segundo plano aparecen en --resume junto a las interactivas.
• Falla de forma visible al alcanzar el límite: cuando el bucle llega al límite o encuentra un error, debe dejar una nota clara de «necesita una persona», no limitarse a detenerse.
• Demuestra el bucle antes de usarlo durante la noche: hazlo crecer en dos ejes a la vez. Cadencia: ejecútalo cada hora y bajo observación durante unos días antes de permitir una ejecución nocturna sin supervisión. Capacidad: comienza en modo solo informe, donde el bucle puede describir problemas pero no corregirlos; después permite correcciones detrás de la puerta humana y solo entonces acciones sin supervisión. Un bucle gana cada nivel al demostrar que acierta en el nivel anterior. Cuando algo parezca incorrecto, lee primero la columna vertebral. Te dirá qué hizo la última ejecución correcta.

No puedes confiar en un bucle que no puedes depurar.

---

Después de los bucles: ingeniería de grafos

Este curso deja deliberadamente un hilo abierto. El 18 de julio de 2026, Peter Steinberger, la voz que al principio del curso pidió «diseñar bucles que den prompts a tus agentes», publicó después de medianoche una pregunta de doce palabras: «¿Seguimos hablando de bucles o ya pasamos a los grafos?» El público la convirtió en un lema, «la ingeniería de bucles ha muerto, larga vida a la ingeniería de grafos», pero detrás del ruido hay una pregunta real que este curso no puede responder por sí solo: cuando ejecutas más de un bucle, los bucles necesitan conexiones, es decir, quién alimenta a quién, quién revisa a quién, dónde reside su memoria compartida y qué mediciones ningún bucle puede discutir.

Esa pregunta tiene su propio curso completo dos pasos más adelante en esta serie: Ingeniería de grafos, después de Ingeniería del arnés. Cubre ambas mitades de la expresión: los grafos de memoria que comparten tus bucles, el DAG de commits del trabajo y el grafo de conocimiento de hechos, mediante autoresearch de Karpathy y Knowledge Graph Cookbook de Anthropic; y el grafo de gobernanza que mantiene honestos a muchos bucles, mediante los cuatro fallos del bucle único de Carlos E. Perez, incluido por qué el lema es incorrecto. Por ahora conserva solo la versión honesta del lema, porque todo lo demás depende de ella: un grafo está compuesto por bucles. Si eliminas los bucles, el grafo queda reducido a cajas vacías. Cada condición de parada, revisor, columna vertebral y puerta que construiste aquí es algo que la ingeniería de grafos da por sabido. Construye tu primer bucle tal como enseña este curso. En cuanto construyas el segundo, el curso de grafos te estará esperando.

Información válida a finales de julio de 2026. El término puede permanecer o desaparecer, pero el patrón que señala es estable.

---

Uso de estos bucles en el libro (dogfooding)

La forma ya debería resultarte familiar. Un bucle es un sistema que encuentra el trabajo, lo realiza, comprueba su propio resultado, registra lo que hizo y decide qué sigue. Un latido inicia todo y una columna vertebral lo mantiene unido. Lo has construido dos veces sobre el papel. Aquí deja de ser solo papel.

Antes de que una herramienta te pida confianza, conviene formular una pregunta justa: ¿quienes la construyeron la usan por su cuenta? En software esto se llama dogfooding: usar tu propio producto en producción de verdad, no solo en una demostración. La respuesta es clara. Dos bucles mantienen este libro en funcionamiento cada día, y son los mismos que acaba de enseñarte el curso. El libro hace consigo mismo exactamente lo que te enseña a hacer por tu cuenta. Se ejecutan en dos pilas distintas, una aplicación real del Concepto 3: aprende el bucle una vez y podrás trasladarlo entre herramientas.

Bucle 1: el bucle de comentarios, que mantiene correcto el libro. El cuadro de comentarios al final de cada lección, incluida esta, es la puerta de entrada de un bucle.

• Latido: dos Routines en la nube. Una clasifica los comentarios nuevos varias veces por semana y otra redacta correcciones semanalmente.
• Columna vertebral: una base de datos activa de cada nota que deja un lector, junto con los issues de GitHub que abre a partir de ellas. Cada ejecución lee lo que ya hicieron las anteriores, así que nunca se trabaja dos veces la misma nota.
• Un pulso: leer y clasificar los comentarios nuevos. La mayoría, como valoraciones, agradecimientos, duplicados y cualquier asunto ya resuelto, se cierra automáticamente para que ninguna persona tenga que tocarla. El resto se convierte en issues bajo seguimiento y, para los pequeños y seguros, el bucle redacta un pull request con la corrección real.
• La puerta humana: solo los pocos casos esenciales llegan a una persona: un lector bloqueado, alguien que ofrece una contribución o un error genuino de contenido. Una persona también aprueba cada corrección redactada antes de publicarla. Todo lo menor se gestiona y cierra sin intervención. Las personas participan donde se las necesita, no para cerrar una valoración de cinco estrellas.
• Lo que ha hecho: en sus primeras ejecuciones eliminó una acumulación de miles de notas que ninguna persona tenía tiempo de leer, y solo escaló las pocas que de verdad requerían una decisión.

Bucle 2: el bucle What's New, que mantiene informados a los lectores. La página What's New que puedes abrir ahora mismo la escribe un bucle, no una persona.

• Latido: una programación de GitHub Actions, una vez al día. Su trabajador es OpenCode, no Claude Code, es decir, la otra herramienta que enseña el curso.
• Columna vertebral: un archivo de estado pequeño que recuerda el último cambio descrito para no repetir ni omitir entradas.
• Un pulso: revisar todo lo que cambió en el libro desde la última vez, decidir qué interesa de verdad al lector, escribir una frase sencilla por cambio, comprobar sus propios enlaces para que ninguno se rompa y publicar.
• La puerta humana: ninguna. Nadie lo aprueba antes de que aparezca en vivo.

Observa ahora el único punto en el que discrepan ambos bucles, porque es lo más útil de esta página. El bucle de comentarios se detiene ante una persona antes de publicar nada. El bucle What's New no se detiene ante nadie. El factor decisivo no es cuál importa más, sino el coste de un movimiento equivocado. Una mala edición de una lección resulta costosa y difícil de deshacer. Una línea torpe del registro de cambios se corrige con una sola reversión. La regla que puedes llevar a tus bucles es breve: sitúa a la persona donde un movimiento automático incorrecto sea costoso y difícil de revertir; déjala fuera en todos los demás lugares. Es la idea del Concepto 1, la intención y la responsabilidad siguen siendo tuyas, convertida en un control que ajustas por separado para cada bucle. En los términos del sector explicados en la Parte 6: dentro del bucle cuando sea costoso, sobre el bucle en los demás casos.

Y ahora la parte honesta, ya que las páginas anteriores hablaban de seguir ejerciendo la ingeniería: ninguno de los bucles se deja solo. Leemos las transcripciones de ejecución porque una ejecución verde no es necesariamente correcta, como explica el Apéndice A5. Una persona sigue decidiendo qué comentarios merecen una corrección. Los bucles realizan incansablemente el trabajo intermedio y nosotros conservamos ambos extremos. No es una limitación por la que debamos disculparnos, sino el diseño.

Ya has visto desde fuera un bucle terminado y en ejecución en producción. En los proyectos siguientes construirás el primero.

---

🚀 Proyectos

Leer sobre bucles no equivale a construir uno. Aquí tienes ocho proyectos, de fácil a difícil. Hazlos con cualquiera de las herramientas. La forma del bucle es la misma, así que usa el comando del concepto correspondiente: /loop y /goal en Claude Code, o opencode run con un temporizador de shell en OpenCode.

Dos reglas antes de empezar, siempre:

• Usa un repositorio git desechable. Un bucle edita archivos por sí solo. No dirijas tus primeros bucles a trabajo que te importe.
• Establece primero un límite. Número máximo de intentos, minutos o gasto antes de permitir que algo funcione solo, como viste en el Concepto 13.

👀Project 115-30 minUn bucle vigilanteHaz que un bucle observe una tarea larga y te avise en cuanto termine.

Dificultad: fácil · Usa: Concepto 4, bucle en sesión.

Construye. Inicia una tarea larga en tu repositorio, por ejemplo, un script que espera un rato y después escribe un archivo. Configura un bucle en sesión que compruebe cada minuto si la tarea terminó y te avise en cuanto lo haga.

Terminado cuando el bucle detecta que la tarea acabó, lo comunica una sola vez, puedes detenerlo de forma limpia y no tuviste que sentarte a observar la terminal.

✅Project 230-45 minHaz que las pruebas pasen y detenteRepite hasta que un comando, no el agente, decida que terminó el trabajo.

Dificultad: fácil a media · Usa: Concepto 5, bucle condicional, y Concepto 11, creador-revisor.

Construye. Añade a tu repositorio 2 o 3 pruebas pequeñas que fallen. Construye un bucle que siga trabajando hasta que las pruebas pasen, pero deja que un comando, el ejecutor de pruebas, y no el agente, decida cuándo terminó. Limítalo, por ejemplo, a 6 intentos.

Terminado cuando el bucle se detiene porque las pruebas realmente pasaron, no porque alcanzó el límite. Si sigue llegando al límite, debes mejorar la condición de parada o el prompt. Esa es la lección.

🧠Project 345-60 minEl informe matutino con memoriaUn bucle programado cuya segunda ejecución continúa claramente a partir de la primera.

Dificultad: media · Usa: Concepto 6, programación sin supervisión, y Concepto 12, la columna vertebral.

Construye. Crea un bucle programado que se ejecute una vez, lea progress.md, reúna algo sencillo del repositorio, como comentarios TODO abiertos o los commits del último día, escriba un resumen breve y actualice progress.md con lo encontrado y la fecha.

Terminado cuando lo ejecutas dos veces y la segunda ejecución continúa claramente a partir de la primera, sin repetir lo que ya registró. Eso demuestra que la columna vertebral funciona. Si la segunda ejecución comienza desde cero, tu bucle aún no tiene memoria.

🔍Project 41-2 hUn bucle de corrección con un revisor realUna persona implementadora redacta, un revisor separado evalúa y solo PASS abre un PR.

Dificultad: media a difícil · Usa: Concepto 8, worktree; Concepto 9, skill; y Concepto 11, creador-revisor.

Construye. Crea una versión más pequeña del bucle de la Parte 5. Escribe una skill breve con los pasos de corrección y un agente revisor que responda PASS o FAIL. Toma un error real, haz que la persona implementadora redacte una corrección en su propio checkout, worktree o rama, y permite que el revisor la evalúe. Abre un PR solo con PASS.

Terminado cuando se cumplen dos condiciones: una buena corrección recibe PASS y un PR, y una corrección deliberadamente mala que introduces recibe FAIL con motivos. Si el revisor aprueba la mala corrección, es demasiado permisivo y debes endurecerlo. Un revisor que aprueba todo no es un revisor.

🧩Project 51-1,5 hCodifica el cuerpoConvierte la orquestación del Proyecto 4 en una unidad que se pueda volver a ejecutar y demuestra que no es un bucle.

Dificultad: media a difícil · Usa: el interludio sobre flujos de trabajo dinámicos y los Conceptos 8 y 11.

Construye. Toma el bucle de corrección que construiste en el Proyecto 4 y codifica su cuerpo. En el enfoque de Claude Code, descríbelo con palabras sencillas: «usa un flujo de trabajo para redactar correcciones de estos tres issues en worktrees paralelos y haz que un revisor evalúe cada una». Deja que el entorno de ejecución escriba y ejecute el script. Cuando una ejecución haga lo que quieres, guárdala desde la vista /workflows como un /command. En el enfoque de OpenCode, escribe lo mismo como script de shell: un bucle for sobre los candidatos, &/wait para distribuirlos en paralelo y el código de salida del revisor como comprobación. Ejecútalo dos veces.

Terminado cuando se cumplen dos condiciones. Primera: un comando, o un script, ejecuta todo el cuerpo de redacción y revisión, con varios candidatos, checkouts aislados y un veredicto para cada uno, sin que tú des prompts paso a paso. Segunda: has demostrado en tu propia máquina la advertencia del interludio. Inicia una sesión nueva, o un shell nuevo, y confirma que el flujo no recuerda nada de la última ejecución. Después nombra lo que necesitaría para convertirse en un bucle: un latido que lo active y un archivo de progreso en el que escriban sus agentes. Si puedes nombrar ambos, entiendes la diferencia entre un motor y un bucle. Los flujos de trabajo dinámicos son una versión preliminar de investigación; cuando este proyecto y la documentación vigente discrepen, la documentación tiene razón.

🔔Project 645-60 minEl bucle del timbreUn bucle que reacciona a un pull request sin que escribas ningún prompt.

Dificultad: media · Usa: Concepto 7, dirigido por eventos, y Concepto 10, conectores.

Construye. Haz que tu repositorio desechable revise sus propios pull requests. En el enfoque de OpenCode, ejecuta opencode github install y acepta el flujo que genera. En el de Claude Code, crea una Routine con un activador de pull requests de GitHub; el apéndice explica los filtros. Después abre un PR que contenga un error introducido a propósito, como un desfase de uno o una comprobación de null eliminada, y espera.

Terminado cuando el PR recibe una revisión que nunca solicitaste y esta detecta el error introducido. Si no lo encuentra, endurece el prompt y vuelve a hacer push. El push activa de nuevo el bucle mediante el evento de sincronización; esa nueva activación demuestra que funciona el latido de evento. Junto con los Proyectos 1 a 3, esto completa los cuatro latidos: en sesión, condicional, programado y dirigido por eventos.

🔦Project 745-60 minRómpelo a propósitoSabotea tu propio bucle y después diagnostícalo usando solo la columna vertebral.

Dificultad: media · Usa: observabilidad, Concepto 13, coste, y Concepto 14.

Construye. Toma el bucle del Proyecto 3. Primero mide un pulso: anota aproximadamente cuántos tokens lee y escribe una ejecución y multiplícalos por la cadencia para obtener el coste mensual. Es el cálculo del Concepto 13 aplicado a tu bucle. Después sabótéalo: dirige el prompt a un archivo inexistente o dale una condición de éxito imposible de cumplir, con un límite establecido. Deja que se active según la programación y falle. Ahora diagnostica el fallo usando únicamente lo que dejó el bucle, es decir, la línea de registro y progress.md, sin reproducir toda la ejecución.

Terminado cuando se cumplen tres condiciones. Puedes determinar qué falló y cuándo usando solo la columna vertebral. El bucle dejó una nota clara de «necesita una persona» en vez de fallar en silencio. Y conoces el coste mensual del bucle con su cadencia actual. Si falló en silencio, corrige eso antes que nada añadiendo la línea de registro. Estás ensayando ahora el fallo nocturno, cuando es barato y estás observando.

🔁Project 82-4 hTu propio bucle diarioEl bucle completo de seis partes aplicado a una tarea real y ejecutado sin supervisión durante una semana: el proyecto final.

Dificultad: proyecto final · Usa: las seis partes.

Construye. Elige una tarea real, aburrida y recurrente de un proyecto en el que trabajes: una auditoría de dependencias, una comprobación de vigencia de la documentación, un borrador del registro de cambios o una pasada de lint. Construye el bucle completo: latido, worktree, skill, creador-revisor, conector y columna vertebral. Añade límites de presupuesto y deja que se ejecute.

Terminado cuando se ha ejecutado sin supervisión durante una semana y confías en lo que publica porque lo leíste, no porque dejaste de leer. Después responde con honestidad al Concepto 15: ¿tu comprensión del proyecto avanzó al mismo ritmo que los cambios del bucle? Si no, reduce la velocidad del bucle hasta que lo haga. Cuando falle durante la noche, y ocurrirá, sigue Cuando falla un bucle sin supervisión antes de culpar al modelo.

---

Apéndice: Routines de principio a fin

Referencia avanzada, no necesaria en la primera lectura

Este apéndice contiene ajustes del producto, límites, detalles de autenticación y casos de fallo. Léelo cuando estés listo para configurar una Routine real en la nube. No necesitas memorizarlo para entender la ingeniería de bucles.

El curso principal presenta una Routine como un tipo de latido y continúa. Este apéndice es la guía de campo: todos los campos del formulario, los tres activadores, dónde se guardan los secretos y los modos de fallo que cuestan horas reales. Es la sección más mecánica del curso. Routines es una versión preliminar de investigación, así que espera cambios y da siempre prioridad a la página oficial cuando exista una discrepancia. Léelo cuando vayas a construir tu primera rutina real, no antes.

Primero, una frase para orientarte. Una rutina es una configuración guardada de Claude Code: un prompt, uno o más repositorios, un entorno en la nube y un conjunto de conectores, empaquetados una vez y ejecutados automáticamente en los servidores de Anthropic. Es el latido del Concepto 6 convertido en producto. Tú aportas el diseño del bucle; la plataforma aporta el planificador, la máquina y las conexiones.

Para quienes leen por encima, todo el apéndice cabe en una tabla. Las secciones posteriores explican cada fila:

Valor predeterminado / comportamiento	Riesgo	Solución
Opción «Local» en el diálogo New routine	Construyes una tarea de Desktop creyendo que es una Routine	Remote es una rutina en la nube; Local es una tarea programada de Desktop, A1
Todos los conectores incluidos, escrituras permitidas, sin preguntas	El agente sin supervisión puede actuar en todas las herramientas conectadas	Elimina cada conector que no necesite la tarea, A2
.env está ignorado por git y nunca llega al clon en la nube	La Routine no encuentra credenciales y falla o improvisa	Guarda los secretos en el panel de variables de entorno e indícalo en el prompt, A4
Clon y entorno nuevos en cada ejecución	El bucle repite eternamente su primer paso	Archivo de contexto o progreso confirmado, o tablero externo, A4
La programación mínima es de 1 hora	El diseño supone activaciones cada 15 minutos	Activador de API más tu propio planificador para una frecuencia mayor, A3
El token bearer de API se muestra una vez y el endpoint no deduplica	Token perdido y ejecuciones duplicadas por reintentos de webhooks	Guarda el token de inmediato y escribe un prompt seguro al repetirse, A3
Eventos de GitHub limitados por hora y exceso descartado	Un bucle con muchos eventos pierde trabajo en silencio	Pasada nocturna de conciliación con un activador programado, A3
matches regex evalúa todo el campo	hotfix nunca coincide con «urgent hotfix for auth»	Usa .*hotfix.* o simplemente contains, A3
Las ejecuciones usan tu identidad sin aprobación intermedia	Las acciones externas se publican como tú y sin revisar	Puerta de dos rutinas: borrador, aprobación humana y ejecutor activado por API, A4
El estado verde significa que no hubo error de infraestructura	Las tareas fallidas parecen correctas	Lee siempre la transcripción de la ejecución, A5

A1. Una sesión local no es una Routine en la nube

El botón New routine de la app de Desktop te permite elegir entre Remote y Local, y esos nombres confunden a muchos tutoriales de internet. Remote crea una rutina en la nube, el tema de este apéndice. Local crea una tarea programada de Desktop, una función distinta que se ejecuta en tu máquina, usa tus archivos reales, incluidos los cambios sin guardar, y solo funciona mientras el equipo está encendido. Se aplica la regla del Concepto 6. Si necesitas archivos locales, usa una tarea de Desktop. Si necesitas la garantía de funcionar con el portátil cerrado, conectores o activadores de API y GitHub, usa una rutina en la nube. Un buen primer paso es demostrar el prompt como tarea de Desktop o ejecución puntual y, cuando se comporte bien, trasladarlo a una rutina programada en la nube.

A2. El formulario de creación, campo por campo

Crea una rutina en claude.ai/code/routines, en la app de Desktop mediante Routines → New routine → Remote, o en lenguaje natural desde la CLI con /schedule. Las tres opciones escriben en la misma cuenta, y una rutina creada en un lugar aparece en los demás. La CLI solo crea rutinas activadas por programación. Los activadores de API y GitHub se añaden después en la web. /schedule list, /schedule update y /schedule run gestionan las existentes.

Nombre y prompt. El prompt es toda la descripción de la tarea y debe ser autocontenido. Una rutina funciona como una sesión autónoma completa en la nube, sin solicitudes de permiso ni nadie a quien preguntar durante la ejecución. Por tanto, todo lo que Claude necesita, qué leer, qué hacer, cómo se reconoce el éxito y qué no tocar, debe estar en el prompt o en archivos accesibles para la ejecución. Aquí se combinan los consejos del curso: dirige el prompt a una skill confirmada en el repositorio, Concepto 9, y limita el texto de la rutina a unas pocas líneas. El cuadro del prompt incluye un selector de modelo. La rutina usa ese modelo en cada ejecución, así que ajústalo a la tarea, Concepto 13.

Repositorios. Cada repositorio que añadas se clona de nuevo en cada ejecución, empezando por la rama predeterminada. De forma predeterminada, Claude solo puede hacer push a ramas cuyos nombres comienzan por claude/. El interruptor Allow unrestricted branch pushes, dentro de Permissions, elimina ese límite para cada repositorio. Mantén los pushes sin restricciones desactivados, salvo que exista un motivo concreto y revisado para permitirlos. Evitar que un agente sin supervisión haga push a main durante una mala ejecución es justo la razón de la puerta humana.

Entorno. Cada rutina se ejecuta dentro de un entorno en la nube que controla tres cosas: acceso a la red, variables de entorno y un script de configuración, usado para instalar dependencias y cuyo resultado se guarda en caché para no repetirlo en cada sesión. El entorno Default incluye acceso de red Trusted: una lista fija de registros de paquetes, API de proveedores de nube, registros de contenedores y dominios de desarrollo habituales. Cualquier otro acceso falla con un 403 y x-deny-reason: host_not_allowed. Si la rutina debe acceder a tu propio servicio, cambia el entorno a Custom y permite solo ese dominio, además de conservar la lista predeterminada. Existe el acceso Full, pero concede más de lo que necesitan la mayoría de los bucles. Amplíalo con cuidado.

Conectores. Este es el valor predeterminado que conviene cambiar siempre. Todos tus conectores vinculados en claude.ai se incluyen de forma predeterminada. Claude puede usar todas sus herramientas, incluidas las de escritura, sin preguntar. Elimina todo lo que la rutina no necesite antes de guardar. Ten en cuenta otros dos detalles. El tráfico de los conectores pasa por los servidores de Anthropic, así que funcionan sin modificar la lista de acceso a la red. Además, los servidores MCP añadidos localmente con claude mcp add residen en tu máquina, no en tu cuenta, por lo que una rutina no puede verlos. Añádelos como conectores en claude.ai/customize/connectors o decláralos en un .mcp.json confirmado para que viajen con el clon.

A3. Los tres activadores

Programación. Los valores predefinidos son cada hora, a diario, en días laborables o semanalmente. Introduces las horas en tu zona horaria local y el sistema las convierte. Las ejecuciones pueden comenzar unos minutos después de la hora debido a una separación deliberada; el desplazamiento es siempre el mismo para cada rutina. Una hora es el mínimo y se rechazan las expresiones cron más frecuentes. Si necesitas mayor frecuencia, usa el activador de API y aporta tu propio planificador. Para crear intervalos personalizados, como cada dos horas o el primer día del mes, elige el valor predefinido más cercano y después ejecuta /schedule update en la CLI con una expresión cron. Una programación puntual se activa una vez a una hora establecida y después se desactiva sola. Además, las ejecuciones programadas puntuales no cuentan para el límite diario de rutinas, por lo que son una forma económica de ensayar un prompt antes de comprometerlo a una programación. La CLI las acepta en lenguaje natural: /schedule tomorrow at 9am, summarize yesterday's merged PRs.

API. Un activador de API proporciona a la rutina su propio endpoint /fire y un token bearer. El token se muestra una sola vez al generarlo y no se puede recuperar después, así que guárdalo de inmediato en el almacén de secretos de tu herramienta de alertas. La misma ventana permite Regenerate o Revoke. Cualquier sistema capaz de enviar un POST autenticado puede activar la rutina: un webhook de alertas, un pipeline de despliegue, un controlador de formulario o una tarea cron en tu propia máquina. El cuerpo de la solicitud acepta un campo opcional text para aportar contexto específico de la ejecución, como el cuerpo de una alerta o un registro fallido. Se envía a la rutina junto con su prompt guardado como texto libre sin analizar. La respuesta devuelve el ID y la URL de la sesión nueva para que quien llama pueda enlazar directamente a la ejecución.

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<routine-id>/fire \
  -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": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

El encabezado beta con fecha es obligatorio y cambiará a medida que evolucione la versión preliminar. La documentación promete mantener en funcionamiento las dos versiones anteriores más recientes para dar tiempo a migrar.

Un webhook que reintenta es un latido fuera de control

El endpoint /fire no incluye deduplicación y los emisores de webhooks vuelven a intentarlo de forma predeterminada. Por tanto, una alerta reintentada genera una ejecución duplicada, y una alerta mal configurada que reintenta toda la noche crea un bucle que nunca diseñaste. El aspecto económico es más grave de lo que parece. Las ejecuciones activadas por API cuentan para el límite diario de rutinas, así que una tormenta de reintentos consume todo el límite antes de que despiertes. Si está activado el uso adicional medido, el límite deja de ser un techo y se convierte en una factura. La regla del Concepto 13 se aplica a los activadores, no solo a los bucles. Deduplica o limita la frecuencia en el emisor. Escribe también un prompt seguro al repetirse, por ejemplo, que compruebe si ya existe la rama de corrección antes de redactarla. Es exactamente lo que enseñaron las reglas de conectores del Concepto 10.

Eventos de GitHub. Un activador de GitHub inicia una sesión nueva cuando llega un evento coincidente a un repositorio conectado. Se admiten dos tipos: pull request, abierto, cerrado, etiquetado, sincronizado, etc., y release. Cada uno puede activarse con una acción concreta o con todas. Requiere instalar la Claude GitHub App en el repositorio. Ten presente que /web-setup concede acceso para clonar, pero no instala la app, una diferencia que ha confundido muchos primeros intentos. Los filtros limitan qué PR activan la rutina: autor, título, cuerpo, rama base, rama de origen, etiquetas, estado de borrador y estado de fusión, con operadores como contains, is one of y matches regex. Un detalle importante: matches regex evalúa el campo completo, no una parte. Por eso hotfix solo coincide con un título que sea exactamente hotfix. Escribe .*hotfix.* o usa contains. Otros dos hechos importan para el diseño. Primero, durante la versión preliminar, los eventos de GitHub tienen límites horarios por rutina y por cuenta, y los eventos que superan el límite se descartan hasta que se reinicia el periodo. Se descartan, no se ponen en cola. Por eso un diseño con muchos eventos necesita una pasada de conciliación: una ejecución nocturna programada que recupere lo que hayan omitido los eventos. Segundo, cada evento coincidente inicia su propia sesión separada. Dos pushes al mismo PR son dos sesiones que no saben nada una de otra. Es la lección de la columna vertebral del Concepto 12 aplicada a GitHub.

A4. Secretos, estado e identidad

Los secretos van en el panel de variables de entorno, nunca en un archivo .env. El motivo es mecánico: git ignora .env, los archivos ignorados nunca llegan a GitHub y, por tanto, el clon en la nube no los contiene. La rutina se activa, no encuentra nada y falla o, peor aún, improvisa. Coloca cada clave en el panel de variables del entorno y añade una línea clara al prompt: «las credenciales están disponibles como variables de entorno; no busques un archivo .env». Sin ella, Claude puede intentar por costumbre la ruta de .env.

Cada ejecución comienza desde cero. Clon nuevo, entorno nuevo, sin árbol de trabajo, cookies ni restos. Todo lo que deba recordar la rutina tiene que salir de la máquina antes de terminar: mediante push al repositorio, escritura en un sistema externo a través de un conector o envío por la API de un tablero. No es una limitación que debas evitar. Es la regla de la columna vertebral del Concepto 12 aplicada por la infraestructura. El patrón correspondiente merece un nombre: archivos de contexto en el repositorio. Un clients.txt, progress.md o triage-rules.md confirmado en el repositorio se puede leer en cada ejecución y actualizar sin tocar el prompt. Cuando cambia la lista de clientes, editas el archivo y el texto de la rutina permanece intacto.

Las Routines actúan como tú. Pertenecen a tu cuenta individual, cuentan para tu límite diario y todo lo que hacen, commits, PR, publicaciones en Slack, tickets de Linear y borradores de correo, lleva tu identidad. Una rutina que responde a clientes seguirá respondiendo como tú mientras estés de vacaciones. Antes de programar algo visible externamente, analiza sus implicaciones de identidad.

No hay aprobación a mitad de la ejecución. Una rutina ejecuta su prompt de principio a fin; no puede detenerse para preguntarte. Cuando una decisión de verdad necesita a una persona, como un pago, un correo externo o un despliegue, construye la puerta entre rutinas, no dentro de una. Funciona en tres pasos. La Routine A redacta el trabajo y lo publica en un lugar donde puedas revisarlo: una rama claude/, un mensaje de Slack o un borrador de correo. Una persona lo lee y aprueba. Esa aprobación activa la Routine B mediante su activador de API, y la Routine B realiza la acción. Es la puerta humana de la Parte 5 escrita como dos rutinas y un webhook.

A5. Leer las ejecuciones

Cada ejecución aparece como una sesión completa en la página de detalles de la rutina. La transcripción muestra cada llamada a herramienta, decisión y cambio. Puedes continuar la conversación manualmente o convertir el resultado en un PR. La documentación formula con claridad una advertencia que confirma la experiencia: un estado verde significa que la sesión terminó sin errores de infraestructura. No significa que tu tarea tuviera éxito. Las solicitudes de red bloqueadas, las herramientas de conectores ausentes y los fallos normales de la tarea aparecen en la transcripción, no en la columna de estado. Abre la ejecución y léela. El Concepto 14 sigue siendo válido aunque el planificador esté gestionado.

En pocas palabras: verde significa que la plataforma completó la sesión. No demuestra que el trabajo solicitado tuviera éxito.

Run now inicia de inmediato una ejecución de prueba. El interruptor de pausa en la sección Repeats detiene la programación sin eliminar la configuración. En cuanto al coste, las ejecuciones consumen el uso de tu suscripción y cuentan para el límite diario de rutinas. Cuando superas el límite, el uso adicional se factura con tarifas medidas si lo activaste. Ambos valores aparecen en claude.ai/settings/usage. Si /schedule parece haber desaparecido de tu CLI, las causas habituales son la autenticación mediante clave de API o proveedor de nube, ya que necesita un inicio de sesión de claude.ai, variables de entorno que desactivan la telemetría o una CLI obsoleta. La interfaz web funciona en cualquier caso.

El mismo apéndice con el enfoque de OpenCode

Cada fila anterior tiene un equivalente en GitHub Actions porque el enfoque de OpenCode resolvió estos problemas años antes con componentes más sencillos. El panel de variables de entorno corresponde a los secretos del repositorio (secrets.ANTHROPIC_API_KEY). La lista de conectores es la sección mcp de un opencode.json confirmado. Los activadores de programación y PR son on: schedule y on: pull_request. La ausencia de estado es la misma, porque los ejecutores de CI también comienzan nuevos en cada ejecución, así que el patrón del archivo de contexto confirmado se conserva sin cambios. La cuestión de identidad se resuelve con la GitHub App o un token de bot en vez de tu cuenta personal. La salvaguarda de ramas son las reglas de protección de ramas que configuras por tu cuenta. Cambian los nombres y la configuración, pero los problemas subyacentes son iguales. Ese es el argumento central del curso.

A6. La versión de la lista para Routines

La lista mínima para un bucle seguro se traslada directamente.

La condición de éxito y el límite viven en el prompt; la plataforma limita las ejecuciones diarias, no el daño de cada una. El aislamiento es el prefijo de rama claude/, así que déjalo activado. El revisor de solo lectura es un subagente definido en el repositorio clonado. El archivo de estado es un archivo de contexto confirmado, porque el clon siempre es nuevo. La puerta humana es el patrón anterior de dos rutinas o, simplemente, «solo redacta PR, nunca fusiones». El registro es la transcripción de ejecución más una publicación mediante conector en un lugar que realmente consultes, recordando que verde no significa terminado.

Antes de guardar una Routine en la nube

Repasa esta lista siempre. Lleva un minuto y marca la diferencia entre un apéndice que leíste y un bucle en el que confías:

• Repositorios: solo el repositorio correcto, con los pushes de rama sin restricciones desactivados.
• Prompt: autocontenido, con la condición de éxito y el límite incluidos.
• Conectores: elimina todos los que no necesite la tarea.
• Entorno: secretos en el panel de variables, no en .env, y acceso de red tan limitado como permita la tarea.
• Activador: programación, API o GitHub elegido a propósito, sin activaciones accidentales de alta frecuencia y con gestión segura de repeticiones si puede reintentar.
• Estado: archivo de progreso o contexto confirmado, o tablero externo, elegido antes de la primera ejecución.
• Puerta humana: solo borradores de PR, ramas o mensajes; nunca fusión, despliegue, pago o envío a clientes de forma directa.
• Ejecución de prueba: actívala una vez con una programación puntual o Run now y después lee la transcripción, no el color del estado.

Práctica: tres ejercicios de Routines

Leer una guía de campo no equivale a recorrer el formulario. Estos tres ejercicios reproducen deliberadamente los casos de fallo más importantes del apéndice en un repositorio desechable. Así puedes experimentar cada problema con poco coste y riesgo. También respetan el límite diario de ejecuciones. El primer ejercicio usa ejecuciones puntuales, que no cuentan para el límite. Los otros dos requieren unas cinco ejecuciones en total, el límite de un día en Pro. Siguen vigentes las dos reglas de los proyectos principales: usa un repositorio desechable y establece primero los límites.

(El Proyecto 12, al final de esta sección, no es un ejercicio. Es un segundo proyecto final basado en los Proyectos 3 u 8 y se ejecuta semanalmente, así que planifica sus ejecuciones por separado.)

🧪Project 920-30 minEnsaya gratis una rutinaDemuestra un prompt con ejecuciones puntuales antes de comprometerlo a una programación.

Dificultad: fácil · Usa: A1, A3, programaciones puntuales, y A5, lectura de ejecuciones.

Construye. En un repositorio desechable, crea una rutina cuyo prompt realice una tarea pequeña y comprobable, como resumir los commits de ayer en una rama claude/summary. No la pongas en una programación repetida. Actívala con una ejecución puntual, /schedule tomorrow at 9am, … o Run now, y lee la transcripción completa, no la columna de estado. Después modifica el prompt para obligar a fallar la tarea, por ejemplo, indicándole que lea un archivo inexistente, y vuelve a activarla.

Terminado cuando hayas visto dos ejecuciones verdes: una cuya transcripción demuestre éxito y otra cuya transcripción muestre un fallo. Debes poder explicar en una frase por qué la columna de estado no permite distinguirlas. Esa frase es la lección de A5: verde significa que la sesión terminó sin errores de infraestructura, nada más.

🔑Project 1030-45 minEl ejercicio de los secretosFalla una vez a propósito por usar .env para no hacerlo nunca por accidente.

Dificultad: fácil a media · Usa: A4, secretos, y A2, el entorno.

Construye. Escribe un prompt que necesite un secreto. Puedes usar un token ficticio, porque el ejercicio trata sobre dónde reside el valor, no sobre lo que desbloquea. Primera ejecución: coloca el token en un archivo .env ignorado por git y activa la rutina. Observa cómo no encuentra el valor y lee la transcripción para ver qué intentó Claude en su lugar. Segunda ejecución: mueve el token al panel de variables de entorno y añade la línea que recomienda el apéndice: «las credenciales están disponibles como variables de entorno; no busques un archivo .env».

Terminado cuando la segunda ejecución lee el token del entorno y puedes explicar el motivo mecánico por el que la primera no pudo: los archivos ignorados por git nunca llegan a GitHub, así que el clon nuevo en la nube no los contiene.

🚪Project 111-2 hConstruye la puerta de dos rutinasA redacta, tú decides y solo tu decisión activa B.

Dificultad: media a difícil · Usa: A3, activador de API; A4, la puerta; y A6, la lista.

Construye. La Routine A, con una programación puntual, redacta algo revisable: una rama claude/ o un resumen breve publicado mediante un conector. La Routine B tiene un activador de API y realiza una pequeña acción posterior. Guarda el token bearer de B en cuanto aparezca, porque solo se muestra una vez. Revisa por tu cuenta el borrador de A. Después apruébalo activando B con la llamada curl de A3.

Terminado cuando se cumplen tres condiciones: B solo se ejecutó porque tú la activaste; la transcripción de B demuestra que la acción ocurrió de verdad; y aplicaste la lista de A6 a ambas rutinas, con los conectores innecesarios eliminados, los pushes sin restricciones desactivados y un archivo de estado elegido. Esta es la puerta humana de la Parte 5, ahora construida con componentes reales.

🌙Project 122-3 hConstruye un bucle de dreamingUn bucle semanal que lee los registros de tus otros bucles y propone cambios de reglas como PR.

Dificultad: proyecto final · Usa: Concepto 12, columna vertebral y bucle de mejora; Concepto 11, creador-revisor; Concepto 6, programación; y Parte 5, puerta humana.

Construye. Necesitas un bucle que ya se haya ejecutado durante una semana y haya dejado entradas fechadas en progress.md; el Proyecto 3 o el Proyecto 8 te proporciona uno. Construye ahora un segundo bucle sobre él. Con una programación semanal, lee todas las entradas de registro posteriores a la fecha de su propio dreaming-state.md, busca cualquier fallo o corrección que aparezca más de una vez y redacta el cambio mínimo al archivo de reglas o a una skill que lo impediría. Debe hacerlo como PR en una rama claude/, nunca como commit directo. La descripción del PR debe citar sus pruebas: qué ejecuciones, con qué frecuencia y por qué esa línea lo detiene. Haz que también proponga una eliminación: una regla que ninguna ejecución reciente necesitó. Termina actualizando dreaming-state.md.

Terminado cuando se cumplen tres condiciones. El cambio propuesto en el PR se remonta a entradas reales y citadas del registro, no a una suposición plausible. Un fallo repetido que introduzcas deliberadamente en los registros, añadido a mano, se detecta y convierte en propuesta. Y nada cambia en tu archivo de reglas sin que tú lo fusiones. Si el bucle propone cambios sin pruebas adjuntas, endurece el prompt: un bucle de mejora que adivina es peor que no tenerlo, porque sus suposiciones dirigen todas las ejecuciones futuras.

---

Próximos pasos

• ¿Ejecutas más de un bucle? En cuanto dos bucles intercambian trabajo o comparten estado, necesitas las conexiones y la memoria compartida. Ingeniería de grafos, dos pasos más adelante en esta serie, aborda ambos temas.
• ¿Creas bucles para trabajo que no es programación? El curso intensivo sobre Cowork y OpenWork muestra la misma idea del latido para profesionales, con tareas programadas en lugar de cron.
• ¿Ejecutas bucles desde la API en vez de una terminal? Los Managed Agents de Claude Platform ya admiten despliegues programados (beta pública): asigna a un agente una programación cron y cada activación inicia una sesión nueva en la infraestructura de Anthropic, sin que tengas que crear ni alojar un planificador. Es la idea de Routines ofrecida como primitiva de plataforma y conserva la misma forma. La programación es el latido, tu instrucción es el pulso y tú sigues aportando la columna vertebral.
• ¿Quieres que administren por ti el bucle de mejora? La misma plataforma Managed Agents incluye herramientas de memoria y sueño, es decir, ofrece como producto el paso de mejora fuera de banda de la nota del Concepto 12. La forma no cambia: el trabajo por lotes es el latido, el almacén de memoria es la columna vertebral y el paso de aprobación es la compuerta humana.
• ¿También quieres que administren el verificador? Dos avances de investigación convierten el interludio sobre habilidades de verificación en productos. Code Review ejecuta una revisión multiagente administrada en cada PR de los repositorios que habilites (el cuarto lugar como servicio), y Rubrics in Claude Managed Agents (beta) ofrece como primitiva de plataforma la rúbrica con umbral del Concepto 2: un agente evaluador independiente verifica los resultados y devuelve el trabajo fallido para otro intento. El curso Confiar en el verificador explica hasta qué punto confiar en la calificación de un modelo.
• ¿Ajustas los reintentos de ejecuciones desatendidas? La referencia de errores de Claude Code documenta la configuración de reintentos automáticos, incluidas CLAUDE_CODE_MAX_RETRIES y el modo CLAUDE_CODE_RETRY_WATCHDOG para sesiones desatendidas al estilo de CI.
• ¿Quieres puntos de partida listos para clonar y ejecutar? El repositorio comunitario cobusgreyling/loop-engineering (MIT) reúne patrones de bucles de producción (clasificación diaria, supervisión de PR, verificación de CI y dependencias, y redacción de registros de cambios) como kits iniciales con una lista de preparación, adaptados a varias CLI de agentes. Es joven y de terceros, así que comprueba que siga mantenido. Sin embargo, su tabla de primitivas presenta las seis partes de este curso con otros nombres, lo que ofrece una segunda explicación útil. Para seguir las lecturas, la colección comunitaria awesome-loop-engineering en Hugging Face reúne los artículos principales.
• La especificación que escribiste en Desarrollo guiado por especificaciones es la condición de parada de tu bucle: sus criterios de aceptación son aquello que evalúa el verificador y que /goal demuestra antes de detenerse. Cuando parece inseguro dejar un bucle ejecutándose, casi siempre hace falta una especificación más precisa, no más automatización.

Fuentes y lecturas adicionales

Este curso se apoya en un pequeño conjunto de fuentes primarias. De ellas proceden el enfoque y las citas. Los detalles técnicos provienen de la documentación oficial.

El origen de la «ingeniería de bucles»

• Addy Osmani, Loop Engineering: el ensayo que dio nombre al patrón y presentó el modelo de cinco partes más una columna vertebral. https://addyosmani.com/blog/loop-engineering/
• Avi Chawla, Loop Engineering, Clearly Explained: la anatomía del bucle interno, las cuatro capas anidadas de ingeniería (instrucción → contexto → arnés → bucle), el enfoque del bucle fatal y las reglas de diseño de herramientas para bucles. https://www.dailydoseofds.com/p/loop-engineering-clearly-explained/
• Data Science Dojo, The 4 Layers of AI Engineering: el enfoque de un modo de fallo por capa y la autoevaluación «qué capa sigues realizando a mano», parafraseada en la nota del Concepto 1. https://www.facebook.com/share/p/1HCxfwo5aC/
• Rakesh Gohel, How to Actually Use Fable 5 (infografía): la distinción entre autoaprendizaje y automejora, y el contraste entre esforzarse más con la instrucción y volver a empezar frente a ejecutar, registrar, destilar y repetir, parafraseado en la nota del Concepto 12. https://rakeshgohel.substack.com
• Sydney Runkle (LangChain), The Art of Loop Engineering: la pila de cuatro bucles (agente, verificación, orientado a eventos y ascenso de colinas), el bucle de mejora guiado por trazas y la referencia al enfoque «loopcraft» de swyx para apilar bucles. https://www.langchain.com/blog/the-art-of-loop-engineering
• Lamis (Anthropic, Applied AI), Context Engineering: Memory and Dreaming (charla de AI DevCon 2026): la separación entre memoria dentro y fuera de banda, el proceso de consolidación durante el sueño, las medidas de protección para almacenes de memoria compartida en producción parafraseadas en la nota del Concepto 14 y la analogía de la escuela y la dirección parafraseada en la nota del Concepto 12. https://www.youtube.com/watch?v=tQ41RxfZZVg
• Letta (Charles Packer, Sarah Wooders y otros), Sleep-time Compute (artículo y blog de abril de 2025): la primera versión convertida en producto de la idea del sueño, un agente en segundo plano que reescribe la memoria de un agente principal durante el tiempo de inactividad, procedente del linaje de MemGPT, junto con la salvedad de que la consolidación sin conexión solo compensa cuando las tareas futuras se parecen a las anteriores. https://www.letta.com/blog/sleep-time-compute/
• Stanford / SambaNova / UC Berkeley, Agentic Context Engineering (ACE): denomina los dos modos de fallo de la reescritura reiterada de memoria, el sesgo hacia la brevedad y el colapso del contexto, y propone la solución parafraseada en la nota sobre el sueño: actualizaciones delta incrementales en lugar de reescrituras monolíticas. https://arxiv.org/abs/2510.04618
• OWASP, Top 10 for Agentic Applications (2026): define el envenenamiento de memoria y contexto como una amenaza específica de los agentes, en la que el contenido inyectado persiste en la memoria e influye en el comportamiento después de desaparecer el ataque original. Es la base de la advertencia sobre envenenamiento de la nota del sueño.
• Simon Willison, Designing agentic loops (septiembre de 2025): la primera afirmación clara de que la habilidad consiste en diseñar el bucle, no en dirigir al agente. Es anterior al término. https://simonwillison.net/
• TrueFoundry, Loop Engineering at Enterprise Grade: las matemáticas de la acumulación de fallos, el enfoque de las partes del bucle como permisos permanentes y el problema del inventario a escala de equipo. Representa los análisis de gobernanza citados en la nota del Concepto 14. https://www.truefoundry.com/blog/loop-engineering-enterprise-agent-runtime
• The New Stack, «El responsable de Anthropic que creó Claude Code afirma que abandonó las instrucciones y ahora solo escribe bucles». https://thenewstack.io/loop-engineering/
• La afirmación de Boris Cherny «mi trabajo es escribir bucles» procede de una entrevista de CNBC, según informó Business Insider. La frase de Peter Steinberger «diseña bucles que den instrucciones a tus agentes» procede de su publicación en X.
• Andrew Ng: los tres bucles de desarrollo de productos (programación en minutos, comentarios de desarrolladores en horas y comentarios externos en días) y la reformulación del «gusto» como la ventaja de contexto de la persona. De su publicación en X. https://x.com/AndrewYNg/status/2071988145667928442
• Andrej Karpathy: «No le digas qué hacer; dale criterios de éxito y observa cómo avanza», y el proyecto AutoResearch, un agente que ajusta un script de entrenamiento, mide el resultado y conserva lo que funciona, sin edición humana entre rondas. De sus publicaciones en X.

Claude Code (documentación oficial)

• Routines: automatizaciones programadas en la nube, desencadenadores, límites de ejecución y el anuncio de lanzamiento con límites diarios por plan: https://code.claude.com/docs/en/routines y https://claude.com/blog/introducing-routines-in-claude-code
• Channels: entrada orientada a eventos en una sesión activa: https://code.claude.com/docs/en/channels
• Tareas programadas: /loop, las herramientas cron, las tareas de Desktop y la regla de continuidad de sesiones en segundo plano: https://code.claude.com/docs/en/scheduled-tasks
• Registro de cambios: donde se actualizan primero las sesiones en segundo plano, el supervisor de reintentos, el cambio de nombre de ultracode y todos los demás detalles mecánicos de este capítulo: https://code.claude.com/docs/en/changelog
• Memoria: CLAUDE.md, memoria automática y el paso de consolidación tras el avance de investigación Auto Dream: https://code.claude.com/docs/en/memory
• Delba de Oliveira (Anthropic, equipo de Claude Code), Building verification loops in Claude Code with skills (22 de julio de 2026): fuente del interludio sobre habilidades de verificación, que abarca verificaciones empaquetadas como habilidades, los cuatro lugares de despliegue (independiente, integrado, encadenado y en cada PR), las señales de madurez, el patrón de habilidad envolvente para habilidades que no puedes editar, la cadena interna de Anthropic /code-review → /simplify → /verify → /design y las referencias a /verify, Code Review y Rubrics in Managed Agents: https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
• Code Review y Rubrics in Managed Agents son avances de investigación o están en beta al momento de escribir este texto. Consulta la documentación actual antes de depender de su disponibilidad o comportamiento.

OpenCode (documentación oficial)

• CLI: opencode run, serve y --attach: https://opencode.ai/docs/cli/
• Agentes y subagentes: agentes principales, subagentes y modelos por agente: https://opencode.ai/docs/agents/
• Integración con GitHub: la Action, la programación, los desencadenadores de PR e incidencias y opencode github install: https://opencode.ai/docs/github/

Identificadores de modelos

• Anthropic, What's new in Claude Sonnet 5: fuente de la cadena de modelo claude-sonnet-5, la migración directa desde Sonnet 4.6, el pensamiento adaptativo predeterminado y el nuevo tokenizador: https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5
• Anthropic, Model IDs and versioning: los ID sin fecha son la instantánea fijada desde la generación 4.6, las versiones principales como Sonnet 5 omiten el segmento menor y los modelos de la generación 4.5, como Haiku 4.5, conservan un ID canónico con fecha (claude-haiku-4-5-20251001) además de un alias sin fecha: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions
• Anthropic, Introducing Claude Fable 5 and Mythos 5: la generación insignia superior a Opus, publicada a mediados de 2026, y un recordatorio de que los ejemplos de modelos de este capítulo son ilustraciones, no la frontera: https://www.anthropic.com/news/claude-fable-5-mythos-5

Todos los enlaces estaban vigentes a principios de julio de 2026. Estas herramientas se actualizan con frecuencia, así que confirma cualquier límite, opción o cadena de modelo en la documentación actual antes de depender de ello.

---

Resumen en una línea

Una instrucción dice qué hacer. Un bucle dice cuándo detenerse. Deja de dar instrucciones a tu agente turno a turno. Diseña el bucle que se las dé por ti, con un latido, cuatro partes operativas y una columna vertebral que recuerde, y sigue siendo quien revisa lo que entrega.

Ayuda de estudio con tarjetas

---

Comprueba tu comprensión

Checking access...