Ingeniería de bucles: curso acelerado

15 conceptos · De la programación con agentes a los sistemas que se dan instrucciones a sí mismos

Ya aprendiste a dirigir un agente de programación. Le das una instrucción, lee tus archivos, hace los cambios y tú compruebas el resultado. Un turno, luego otro y después otro. Tú manejas la herramienta en todo momento.

Ahora imagina que dejas de manejarla. En su lugar, construyes un sistema pequeño. Cada mañana se activa, revisa qué cambió durante la noche, decide qué vale la pena hacer, asigna cada tarea a un agente, comprueba el resultado y solo recurre a ti para las decisiones que realmente necesitan a una persona. Lo construyes una vez. A partir de entonces, se da instrucciones a sí mismo.

Eso es la ingeniería de bucles. La habilidad valiosa deja de ser la indicación que escribes y pasa a ser el bucle que diseñas. Este curso explica de qué se compone un bucle y cómo construirlo tanto en Claude Code como en OpenCode, dos herramientas que llegan al mismo lugar por caminos muy diferentes.

Requisito previo: Claude Code y OpenCode: curso acelerado. Ese curso te enseñó el modo de planificación, la gestión del contexto, el archivo de reglas, las habilidades, los subagentes y MCP. Aquí se da todo eso por conocido. Si esos términos son nuevos para ti, completa primero aquel curso. La ingeniería de bucles se apoya directamente en él. Lo ideal es que también hayas completado Desarrollo basado en especificaciones: la condición de parada de un bucle es, en realidad, una especificación, y en ese curso aprendiste a escribirla. Puedes continuar sin él, pero tus bucles solo serán tan buenos como las condiciones que puedas especificar.

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

• Modo de planificación: el agente lee tus archivos y propone un plan antes de cambiar nada; tú lo apruebas primero.
• Archivo de reglas (CLAUDE.md / AGENTS.md): notas breves y permanentes del proyecto que el agente lee al principio de cada sesión.
• Habilidades (SKILL.md): instrucciones guardadas y reutilizables que el agente carga solo cuando la tarea corresponde con ellas.
• Subagentes: ayudantes independientes con su propia ventana de contexto; realizan una tarea y devuelven solo 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 la conversación ligera; a medida que se llena, el modelo empeora 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 se apoya directamente en él.

De dónde surgió

A mediados de 2026, quienes construyen estas herramientas lo dijeron con claridad. Boris Cherny, creador de Claude Code, lo expresó así: "Ya no doy indicaciones a Claude. Tengo bucles en ejecución que le dan indicaciones a Claude... mi trabajo es escribir bucles". Peter Steinberger (OpenClaw) dijo que "deberías diseñar bucles que den indicaciones a tus agentes". Después, Addy Osmani dio nombre al patrón y enumeró sus partes. Ninguno afirma que el trabajo se haya vuelto más fácil. Dicen que la habilidad valiosa cambió de lugar. Esa es la idea sobre la que se construye todo este curso. (Todas las citas y afirmaciones del curso tienen su fuente en Fuentes y lecturas adicionales, al final.)

El cambio de mentalidad, en una imagen

Este curso presenta dos herramientas en paralelo por el mismo motivo que el anterior: si una técnica funciona en ambas, es una habilidad real y no un truco de una sola herramienta. Sin embargo, aquí las herramientas sí difieren, y esa diferencia también enseña algo. Claude Code ahora incluye las partes del bucle dentro del producto. OpenCode ofrece la capa inferior: un trabajador que inicias desde el sistema operativo. Verás ambos enfoques y comprobarás que la forma del bucle es la misma, aunque el cableado cambie.

Actualizado a junio de 2026. Ambas herramientas cambian con rapidez y varias funciones de bucles de Claude Code están en vista previa de investigación. Antes de cualquier sesión, ejecuta claude update u opencode upgrade. Consulta la documentación vigente (code.claude.com/docs, opencode.ai/docs) antes de depender de un límite o un indicador.

Primero, una nota sincera sobre dónde se pueden ejecutar los bucles

Un bucle real funciona sin supervisión: se da instrucciones por sí solo mientras estás ausente. Eso no puede ocurrir en el cuadro de chat normal de claude.ai, que siempre te espera; en el chat, tú eres la programación. Para ejecutar un bucle verdadero necesitas una herramienta capaz de actuar por sí sola según un temporizador: Claude Code, OpenCode o Cowork (consulta el curso acelerado de Cowork). La mayoría son funciones de pago y varias están actualmente en vista previa de investigación. Puedes aprender y diseñar un bucle en cualquier lugar. Para ejecutarlo sin supervisión, necesitas una de esas herramientas. Este curso presenta las dos orientadas a la programación.

"Pero completé todo el curso basado en especificaciones en claude.ai. ¿También puedo ejecutar allí un bucle?"

Es una pregunta razonable, porque "claude.ai" engloba en realidad dos cosas. La respuesta breve es que el cuadro de chat no puede ejecutar un bucle, pero Claude Code, que pertenece a la misma cuenta de claude.ai, sí puede.

• La conversación de chat te espera en cada turno y no puede activarse según un horario o un evento. Puedes volver a darle indicaciones de forma manual, pero entonces tú eres el latido, precisamente el trabajo que elimina un bucle.
• Claude Code está disponible con el mismo inicio de sesión. Sus Routines en la nube (creadas en claude.ai/code/routines) se ejecutan en los servidores de Anthropic aunque tu portátil esté cerrado y sin instalar nada de forma local. En ese sentido, sí puedes poner en marcha un bucle real y sin supervisión "desde claude.ai". Actualmente requiere un plan de pago y está en vista previa de investigación.
• OpenCode hace lo mismo con tu propio programador de tareas (cron o GitHub Actions).

Por tanto, el chat es donde diseñas y ensayas un bucle: redactas la habilidad, escribes la indicación del revisor, fijas la condición de parada y ejecutas un latido a mano. Claude Code u OpenCode es donde lo ejecutas. Ese traspaso es el paso natural después del desarrollo basado en especificaciones.

Pruébalo mientras lees

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

Qué cubre este curso​

Parte	Tema	Qué aprenderás
1	El cambio	Qué es un bucle, sus seis partes y los dos caminos para construirlo
2	El latido	Hacer que algo se ejecute solo: en sesión, hasta terminar, programado o por eventos
3	El cuerpo	Aislamiento, conocimiento, acción y separación entre creador y revisor
4	La columna vertebral	El estado que sobrevive entre ejecuciones, la parte que suele olvidarse
5	Un bucle, dos veces	Un bucle completo de triaje matutino a PR, con archivos reales, en ambas herramientas
6	Seguir siendo quien diseña	Coste de tokens, revisión del trabajo y trampas que crecen cuando mejora el bucle
Práctica	Proyectos prácticos	Cinco bucles, de fáciles a difíciles, para construir por tu cuenta

¿Prefieres aprender haciendo? Lee primero la Parte 5 para ver un bucle completo de principio a fin y luego vuelve a estudiar sus partes. Cuando los conceptos encajen, los proyectos prácticos te ofrecen cinco bucles para construir por tu cuenta.

Reserva unas dos horas para leer todo. Construir la Parte 5 y los proyectos prácticos lleva más tiempo; de eso se trata: estás construyendo bucles, no leyéndolos por encima.

Qué debes conservar y qué debes consultar

Dos capas recorren este curso y envejecen de forma muy distinta. Interioriza la primera; consulta la segunda.

• La capa duradera. La forma de un bucle (un latido, cuatro partes de trabajo y una columna vertebral), la separación entre creador y revisor y los dos extremos que un bucle nunca puede automatizar: la intención (expresar lo que quieres con suficiente precisión para comprobar el resultado) y la responsabilidad (responder por lo que se publica). Esta es la habilidad. Seguirá siendo válida cuando hayan cambiado todos los comandos siguientes.
• La capa mecánica. Cada indicador, ruta, identificador de modelo y nombre de comando. Estas herramientas publican actualizaciones cada semana y varias funciones están en vista previa de investigación. Trata cada comando concreto como una referencia a la documentación vigente, no como un dato para memorizar. Si el curso y la documentación actual discrepan, prevalece la documentación.

Recuerda la forma de seis partes aunque olvides cada tecla y habrás aprendido ingeniería de bucles. Memoriza las teclas pero pierde de vista la forma y solo habrás aprendido la CLI 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 dar indicaciones a diseñar bucles​

Durante unos dos años, obtener trabajo de un agente de programación era sencillo. Escribías una buena indicación, le dabas suficiente contexto, leías la respuesta y escribías lo siguiente. El agente era una herramienta que utilizabas turno a turno.

Un bucle te sustituye como operador por un sistema. El sistema encuentra el trabajo, lo distribuye, lo comprueba, registra lo que hizo y decide qué sigue. Da indicaciones al agente para que tú no tengas que hacerlo.

Entonces, ¿dónde queda el valor? No desaparece. Se divide entre los dos extremos que un bucle no puede automatizar: la intención, expresar con precisión lo que quieres para que el resultado pueda comprobarse, y la responsabilidad, responder por lo que sale. El bucle automatiza la parte intermedia, es decir, los pasos; los extremos siguen siendo tuyos. Se te valora por la intención y el criterio, no por ignorar cómo se produjo el trabajo.

La diferencia no es "una indicación más grande". Es otra forma de trabajar:

Indicaciones (lo que ya conoces)	Bucles (lo que añade este curso)
Tú inicias cada turno	Un horario 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 ejecutándose mientras duermes
Una tarea, una sesión y toda tu atención	Muchas ejecuciones pequeñas, casi siempre sin supervisión, y tu atención solo en la puerta de control

Esto no es magia ni consiste en "configurarlo y olvidarse". Un bucle que funciona por sí solo también comete errores por sí solo. Todo este curso busca ayudarte a construir un bucle en el que realmente puedas confiar para que se ejecute sin ti. Eso es más difícil que dar indicaciones, no más fácil. La recompensa es el apalancamiento: un buen bucle trabaja para ti una y otra vez en tareas que, de otro modo, tendrías que iniciar a mano cada vez.

2. De qué se compone un bucle​

Un bucle que realmente funciona por sí solo tiene cinco partes y una columna vertebral. Ya conociste cuatro de esas cinco partes en el curso de programación con agentes. Aquí asumen una función nueva.

1. Latido: un horario (o un evento) que inicia el bucle. Sin él, tienes una sola ejecución, no un bucle.
2. Worktree: aislamiento para que dos agentes que trabajan al mismo tiempo no sobrescriban sus archivos.
3. Habilidad: el conocimiento del proyecto escrito una sola vez, para que cada ejecución no empiece desde cero.
4. Subagentes: la separación entre creador y revisor; el agente que escribe el código no es quien lo evalúa.
5. Conector (MCP): permite que el bucle actúe en tus herramientas reales (abrir una PR o actualizar un ticket), en lugar de limitarse a sugerir.

Y la sexta, que suele ser la que omiten los principiantes:

6. Estado / memoria: la columna vertebral. Un archivo en disco (o un tablero como Linear) que conserva lo terminado y lo siguiente. El modelo olvida todo entre ejecuciones. Gracias a la columna vertebral, la ejecución de hoy sabe qué hizo la de ayer. Sin columna vertebral no hay bucle: solo el mismo primer paso repetido para siempre.

El resto del curso dedica una sección a cada parte y termina con un ejemplo completo que las une.

3. Dos caminos: componentes incluidos frente a la capa inferior

Este es el punto en el que las herramientas realmente difieren, y esa diferencia da forma a todo lo que sigue.

Claude Code incluye las partes del bucle dentro del producto. El latido (/loop, /schedule y las Routines en la nube), la ejecución hasta terminar con un revisor integrado (/goal), el aislamiento (--worktree) y la entrada de eventos (Channels) son ahora comandos incorporados. Hace un año habrías tenido que escribir y mantener muchos scripts de shell para conseguirlo. Hoy, en gran medida, basta con configurarlo.

La función principal es Routines: automatizaciones en la nube que se ejecutan en los servidores de Anthropic incluso cuando tu portátil está cerrado y se activan mediante un horario, una llamada a la API o un evento de GitHub. Esa facilidad tiene un precio: límites diarios de ejecución por cuenta (consulta el límite actual en la interfaz de uso de Routines en vez de confiar en una cifra fija) y el hecho de que Routines sigue siendo una vista previa de investigación sujeta a cambios.

OpenCode te ofrece la capa inferior. No incorpora un programador en la nube. OpenCode es el trabajador al que llamas y tú aportas el latido desde el sistema operativo o desde CI.

El comando clave es opencode run "<prompt>". Ejecuta una indicación sin mostrar la pantalla de chat, imprime el resultado y termina. Ese comando representa un latido de un bucle. Para convertirlo en un bucle, lo envuelves en algo que se active con un temporizador: cron o launchd (macOS y Linux), el Programador de tareas (Windows) o GitHub Actions con un desencadenador programado. Requiere más cableado, pero obtienes control total, se ejecuta en equipos que ya tienes y no necesita la nube de un proveedor.

La habilidad es el bucle, no la combinación de teclas

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

Hacia dónde vamos (el bucle completo desde el principio)

Antes de estudiar las partes, este es el punto de llegada. 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. Sub-agents (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

Conserva esta imagen en mente. Cada concepto de las Partes 2 a 4 corresponde a una de sus líneas.

Comprueba lo que sabes

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

Mostrar la respuesta

La columna vertebral (estado / memoria). El modelo olvida todo entre ejecuciones, así que, sin un archivo de estado en disco, el bucle repite su primer paso para siempre en vez de continuar el trabajo del día anterior.

---

Parte 2: El latido​

El latido es lo que convierte una ejecución en un bucle. Hay cuatro tipos, desde "permanece en esta sesión" hasta "se ejecuta por completo sin ti". Apréndelos en orden; la mayoría de los bucles reales usan los dos últimos.

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

El latido más sencillo consiste en volver a ejecutar una indicación según un temporizador mientras la sesión está abierta. Es adecuado para "vigilar esto hasta que termine": un despliegue, una ejecución larga de pruebas o un trabajo de CI.

Usa la habilidad /loop incluida. Proporciónale un intervalo y una indicación:

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

Claude convierte el intervalo en un horario, asigna un identificador al trabajo y ejecuta la indicación cada 5 minutos mientras la sesión permanezca abierta. Cuando termines, cancélalo y continúa.

Un límite que debes conocer: /loop permanece dentro de la sesión a propósito. Si cierras la terminal o el portátil entra en suspensión, se detiene. Es una función de seguridad, no un error: un bucle informal en sesión no debe sobrevivir a la sesión. Para algo que siga ejecutándose, usa una tarea programada o una Routine (Concepto 6).

OpenCode no tiene un comando /loop. Tú construyes el temporizador con el shell. Como opencode run termina después de una indicación, un bucle while con sleep realiza 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, una capa más abajo: el shell es el latido y opencode run es cada pulsación. Cada nuevo opencode run inicia primero todo el entorno de ejecución, incluida la configuración, el modelo, los plugins y cualquier servidor MCP, antes de hacer nada. Para evitar ese coste de inicio en cada latido, 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"

5. Ejecutar hasta terminar (el bucle decide cuándo detenerse)

Un bucle con temporizador fijo es deliberadamente sencillo: se activa N veces pase lo que pase. A menudo, lo que realmente quieres es "seguir hasta que esto sea cierto". Aquí aparece por primera vez la idea de creador-revisor: el bucle no debe permitir que el agente que hizo el trabajo decida si ya está terminado.

Usa /goal. Le das una condición de parada que Claude pueda demostrar en su propio resultado, por ejemplo, algo que pruebe al ejecutar un comando y mostrar el resultado, como "todas las pruebas de test/auth pasan". Seguirá trabajando turno tras turno hasta que se cumpla la condición. Lo importante es que después de cada turno, un modelo independiente y más pequeño (Haiku de forma predeterminada) lee la transcripción y decide si ya terminamos. Así, el agente que escribió el código no es quien lo evalúa. Hay un detalle importante: el revisor no ejecuta comandos por sí mismo, sino que juzga lo que Claude ya mostró. Por tanto, la condición debe ser algo que el resultado de Claude pueda demostrar, no un dato privado que solo revele un comando.

/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 revisor confirme que la condición se cumple de verdad, o cuando tú lo detengas con /goal clear. No existe una opción integrada de "abandonar tras N intentos". Si quieres un límite, inclúyelo en la condición (…or stop after 20 turns). Escribe condiciones que pueda demostrar un comando: "las pruebas pasan y el lint no presenta errores", no "el código de autenticación es bueno". Aquí resulta rentable la especificación del desarrollo basado en especificaciones: sus criterios de aceptación ya son condiciones demostrables por un comando, así que una buena especificación te proporciona la condición de parada.

OpenCode no tiene /goal, así que construyes la misma parada de creador-revisor con el shell y códigos de salida. El patrón es el siguiente: el agente hace el trabajo y, 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 revisor, el más honesto que existe, porque un comando no puede convencerse a sí mismo de que el trabajo está bien. Para una revisió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; los bucles que reintentan sin límite son la causa de facturas de tokens fuera de control.

Da siempre al bucle una forma de detenerse

Incluye siempre dos paradas: una condición de éxito (el trabajo está terminado) y un límite (máximo de intentos, minutos o gasto). Un bucle con condición de éxito pero sin límite gastará todo tu presupuesto de tokens intentando alcanzar un objetivo imposible.

6. Programaciones sin supervisión (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. "Cada día laborable a las 9:00, revisa los fallos nocturnos de CI". "Cada lunes, comprueba las dependencias y abre una PR con las correcciones seguras".

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

Routines en la nube (el portátil puede estar apagado). Es la opción moderna predeterminada. Crea una en claude.ai/code/routines, en la aplicación de escritorio o con /schedule en la CLI; las tres escriben en la misma cuenta en la nube. Una Routine agrupa una indicación, los repositorios que puede modificar, sus conectores y un desencadenador (horario, API o evento de GitHub), y se ejecuta en los servidores de Anthropic. Ten en cuenta los límites diarios de ejecución por cuenta y que, de forma predeterminada, una Routine solo puede enviar cambios a ramas que empiecen por claude/. Es una protección deliberada que puedes desactivar por repositorio mediante la opción Allow unrestricted branch pushes.

Ejecución única sin interfaz en tu propio cron (portátil encendido, sin la nube de Anthropic). claude -p ejecuta una indicación y termina; colócalo directamente en crontab:

# 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

Para una explicación completa, consulta Tareas programadas: la habilidad Loop y las herramientas cron en el libro.

El latido sin supervisión de OpenCode siempre procede del sistema operativo o de CI; este es el camino de OpenCode. Usa opencode run sin la pantalla de chat y deja que el programador lo active.

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 (ninguno de tus equipos tiene que estar encendido). La cadena model siguiente es solo ilustrativa; ejecuta opencode models para ver los identificadores 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-4-6   # 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.

En los eventos programados, prompt es obligatorio (no hay ningún comentario del que leerlo), y debes conceder contents: write / pull-requests: write si el bucle debe abrir ramas o PR.

Nota sobre los nombres de la acción y los modelos anteriores

La documentación oficial actual hace referencia a la acción de GitHub 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. Para los modelos, anthropic/claude-sonnet-4-6 es el identificador actual de Sonnet. Los identificadores sin fecha llegaron con la generación 4.6, en la que la cadena sin fecha es la instantánea fijada. Los modelos anteriores de la generación 4.5, como Haiku 4.5, tienen un identificador canónico con fecha (claude-haiku-4-5-20251001) y un alias sin fecha, claude-haiku-4-5, que apunta a la instantánea más reciente. Para facilitar la reproducción, los ejemplos siguientes fijan el identificador de Haiku con fecha. Ejecuta opencode models para ver las cadenas exactas que reconoce tu instalación.

7. Dirigidos por eventos (reaccionan cuando ocurre algo)​

Un horario pide "comprobar cada hora". Un evento pide "reaccionar en cuanto ocurra X". Se abre una PR, se registra una incidencia o llega un mensaje, y el bucle se ejecuta como respuesta.

Hay dos caminos. Routines admite un desencadenador de webhook de GitHub, por lo que una Routine puede ejecutarse al enviar cambios o al abrir una PR, no solo según un reloj. Para eventos de tipo chat, Channels envía mensajes de fuentes externas directamente a una sesión en ejecución (Telegram, Discord e iMessage están integrados; tú conectas el receptor de webhook). Es la contraparte dirigida por eventos de la programación. Consulta code.claude.com/docs/en/channels.

Instala una vez el agente de GitHub con opencode github install, que añade .github/workflows/opencode.yml. A partir de entonces, OpenCode reacciona a eventos del repositorio, como pull_request, issues y comentarios /oc o /opencode, y se ejecuta dentro de tus runners 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-4-6
          use_github_token: true
          prompt: |
            Review this pull request for bugs, quality issues, and security risks.

Ante un evento pull_request sin indicación, OpenCode revisa la PR de forma predeterminada.

Comprueba lo que sabes

Quieres que un bucle siga corrigiendo una prueba fallida hasta que pase y que luego se detenga solo. ¿Qué latido eliges y quién decide que el trabajo está terminado?

Mostrar la respuesta

Ejecutar hasta terminar: /goal en Claude Code o un bucle de shell con límite en OpenCode. Un comando (el ejecutor de pruebas) decide cuándo está terminado, nunca el agente que escribió la corrección. Además, necesita un límite para no reintentar indefinidamente.

---

Parte 3: El cuerpo​

El latido inicia el bucle. Estas cuatro partes definen lo que el bucle hace en cada latido. En el curso de programación con agentes las conociste como complementos prácticos. En un bucle son esenciales porque ninguna persona observa cada paso.

8. Aislamiento: worktrees​

En cuanto un bucle ejecuta más de un agente al mismo tiempo, empiezan a sobrescribir sus archivos, igual que dos personas que editan las mismas líneas sin coordinarse. Un git worktree resuelve el problema: es una carpeta de trabajo independiente, en su propia rama, que comparte el historial del repositorio. Los cambios de un agente no pueden afectar el checkout de otro.

Está integrado. Usa el indicador --worktree para abrir una sesión en su propio checkout o configura isolation: worktree en un subagente para que cada ayudante reciba un checkout nuevo que se elimine después. Una tarea programada puede activar el aislamiento por worktree en cada ejecución, de modo que las ejecuciones paralelas nunca choquen con tu trabajo manual.

No existe un único indicador. Usas los worktrees propios de git y diriges una ejecución a cada uno. Es el mismo aislamiento 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 lo haces con frecuencia, los runners de la comunidad (administradores de worktrees creados alrededor de OpenCode) pueden encargarse de la gestión.

9. Conocimiento: habilidades para que ninguna ejecución sea el "primer día"​

Un bucle empieza en frío cada vez: una sesión nueva sin memoria de las costumbres de tu proyecto. Sin ayuda, reconstruye (o adivina) toda la configuración en cada latido, desperdicia tokens y favorece los errores. Una habilidad es ese conocimiento escrito una sola vez en un archivo SKILL.md, que el agente lee en cada ejecución.

Funciona igual en ambas herramientas: una carpeta con un 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 habilidad. Los pasos de triaje, las costumbres del proyecto y el "no lo hacemos así por aquel incidente" viven en la habilidad. De este modo, el bucle acumula conocimiento en lugar de reiniciarse. (Consulta el tratamiento completo en el curso acelerado de habilidades y conectores.)

Una habilidad mantiene breves las indicaciones del bucle

En vez de pegar un muro de instrucciones en una programación que nadie mantendrá actualizada, la indicación programada se convierte en una sola línea, "ejecuta la habilidad daily-triage", y la habilidad contiene los detalles. Obtienes una indicación breve, lógica fácil de actualizar y un menor coste de tokens en cada latido.

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

Un bucle que solo puede leer tus archivos también solo puede hablar. Los conectores, creados sobre MCP, le permiten actuar: abrir una 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 la PR, enlaza el ticket y publica en el canal cuando CI está en verde.

Ambas herramientas hablan MCP, por lo que el protocolo se traslada de una a otra. Sin embargo, el empaquetado y la autenticación (local frente a alojado, OAuth y permisos) suelen requerir un cableado específico para 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 sin supervisión pueda acceder a ellos. Los mismos conectores que usas manualmente están disponibles para ejecuciones programadas y en la nube.

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

11. Creador-revisor: subagentes​

La decisión más importante de un bucle es esta: el agente que escribe el trabajo no debe aprobarlo. Un modelo que evalúa su propio resultado es demasiado indulgente consigo mismo. Un segundo agente, con instrucciones distintas y a menudo con otro modelo (a veces más potente), detecta lo que el primero pasó por alto porque estaba convencido de tener razón. Esta es la única razón por la que puedes dejar solo a un bucle en ejecución.

Define subagentes en .claude/agents/ y reúnelos en equipos de agentes: uno explora, otro implementa y un tercero comprueba el resultado frente a la especificación y las pruebas. "La especificación" es la que aprendiste a escribir en Desarrollo basado en especificaciones. Sus criterios de aceptación son exactamente lo que evalúa un revisor fiable; una especificación vaga produce un veredicto vago. Esto también es lo que hace /goal internamente: un modelo nuevo decide si el bucle terminó en vez de dejar que el trabajador se evalúe a sí mismo.

OpenCode incluye agentes principales integrados (Build y Plan) y un subagente general también integrado (además de explore y, en las versiones actuales, scout tras un indicador experimental). Puedes definir los tuyos en opencode.json o como archivos Markdown en tu carpeta de agentes. Asigna al revisor su propio modelo, a menudo más barato y de solo lectura, y haz que el creador lo llame mediante una mención @ o la herramienta Task. Una separación habitual usa un modelo potente para explorar e implementar y uno enfocado para comprobar.

---
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: úsalos donde importan

Cada subagente ejecuta su propio modelo y sus propias herramientas, así que la separación entre creador y revisor realmente consume más tokens. Es el precio de un revisor en el que puedes confiar. Págalo cuando una segunda opinión sea importante (todo lo que el bucle vaya a confirmar mientras estás ausente); omítelo en tareas desechables y de solo lectura.

11b. Codificar el cuerpo: flujos de trabajo dinámicos​

Hasta ahora, el agente ensambla turno a turno el cuerpo de cada latido: encontrar el trabajo, redactar cada corrección en su propio checkout y hacer que otro agente la evalúe. Claude Code ahora te permite codificar toda esa orquestación como un script que puede volver a ejecutarse, denominado flujo de trabajo dinámico. Describes la tarea, Claude escribe un script que distribuye el trabajo entre muchos subagentes y un entorno lo ejecuta en segundo plano mientras tu sesión queda libre. Empaqueta la separación entre creador y revisor (Concepto 11) y la separación por worktrees (Concepto 8) en una unidad repetible. Además, puede aplicar un patrón real de calidad, no solo ejecutar más agentes: revisores independientes pueden cuestionar entre sí sus hallazgos antes de comunicar nada.

Pide uno con palabras sencillas ("usa un flujo de trabajo para…"), actívalo con la palabra clave ultracode o ejecuta el comando incluido /deep-research. 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. Dos límites lo mantienen bajo control: el número de agentes está limitado (unos 16 simultáneos y 1000 por ejecución) para impedir que un script desbocado crezca sin control, y la memoria de una ejecución existe solo dentro de esa ejecución. Puedes reanudarla en la misma sesión, pero una sesión nueva empieza 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 manual de la misma idea. El shell contiene el plan, cada opencode run es un agente y los códigos de salida actúan como revisor. 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 latido, 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 latido, no un bucle. El bucle es la composición: un latido (una Routine, /loop o cron) activa cada ejecución; el flujo de trabajo es el cuerpo que se ejecuta; y un archivo de progreso que escriben sus agentes es la columna vertebral que leerá la siguiente ejecución. El flujo de trabajo es el motor, la Routine gira la llave y progress.md es el combustible que perdura entre viajes.

---

Parte 4: La columna vertebral​

12. Estado que sobrevive entre ejecuciones​

Esta es la parte que omiten los principiantes y también la que convierte un bucle en un bucle. El modelo olvida todo entre ejecuciones. Si cada latido comienza desde cero, no tienes un bucle, sino el mismo primer paso repetido para siempre. La solución es poco vistosa pero potente: conservar el estado fuera del modelo, en disco.

Dos capas de estado 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é. Un archivo de reglas inflado se paga en cada latido.)
• Un archivo de progreso: un archivo Markdown sencillo (o un tablero de Linear mediante MCP) que registra qué se intentó, qué pasó y qué sigue pendiente. Esta es la verdadera columna vertebral. La ejecución de mañana a las 9:00 lo abre y continúa donde se detuvo la de hoy.

El hábito es este: cada ejecución lee el archivo de progreso al principio y lo actualiza al final. Cuando el bucle sigue cometiendo el mismo error, la solución no es una indicación más ingeniosa. Haz que el bucle escriba la lección en el archivo de reglas para que la corrección perdure en todas las ejecuciones futuras.

<!-- 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 texto dentro del repositorio, también registra lo que hizo el bucle mientras estabas ausente. Cuando llegues a la puerta de control humana, lee la columna vertebral, no la transcripción completa de cada ejecución.

Comprueba lo que sabes

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

Mostrar la respuesta

En disco: en un archivo de progreso (además del archivo de reglas) o en un tablero como Linear. La memoria del modelo se borra entre ejecuciones, así que todo lo que deba perdurar debe vivir fuera de él. El repositorio recuerda; el modelo no.

---

Parte 5: Un bucle completo, dos veces​

Lista de verificación mínima para un bucle seguro

Antes de permitir que un bucle se ejecute solo, necesita estos siete elementos. El bucle que vas a construir los incluye todos:

• Condición de éxito: cómo sabe que el trabajo terminó (Concepto 5).
• Límite: máximo de intentos, minutos o gasto para que no se ejecute indefinidamente (Concepto 13).
• Rama o worktree aislado: evita que el trabajo paralelo choque (Concepto 8).
• Revisor de solo lectura: un agente independiente que evalúa pero no puede editar (Concepto 11).
• Archivo de estado: la columna vertebral que permite recordar entre ejecuciones (Concepto 12).
• Puerta de control humana: el trabajo arriesgado o fallido se envía 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 solo bucle: un bucle de mantenimiento matutino que clasifica los fallos nocturnos de CI, redacta correcciones seguras, las somete a revisión, abre PR para las que pasan y marca el resto. Lo construirás una vez en cada herramienta. Los archivos siguientes son reales; puedes copiarlos a un repositorio y ejecutarlos.

La forma del bucle (igual en ambas):

1. Latido: cada día laborable a las 9:00.
2. Habilidad: una habilidad daily-triage contiene los pasos para que la indicación ocupe una sola línea.
3. Columna vertebral: leer progress.md al principio y actualizarlo al final.
4. Worktree: redactar cada corrección en su propio checkout.
5. Creador-revisor: un implementador redacta y otro revisor independiente responde PASS o FAIL.
6. Conector: abrir una PR ante PASS; ante FAIL o cualquier riesgo, escribirlo en "necesita intervención humana" y detenerse.

La habilidad compartida​

Este archivo funciona en ambas herramientas. Guárdalo como .claude/skills/daily-triage/SKILL.md (Claude Code) o .opencode/skills/daily-triage/SKILL.md (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 (quien comprueba)​

El revisor lleva a la práctica la separación entre creador y revisor. Necesitas ambos archivos; no tienes que elegir uno u otro. El formato cambia ligeramente según la herramienta, por lo que ambos se muestran completos.

Claude Code: guarda 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(npm test*), Bash(npm run lint*), Bash(git diff*)
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.

OpenCode: guarda 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.

Conectar el latido​

Crea una Routine en claude.ai/code/routines con un horario de las 9:00 en días laborables, tu repositorio y tus conectores de GitHub y Slack. Dirige su indicación a la habilidad para que la definición de la Routine se mantenga breve:

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 habilidad contiene los pasos. .claude/agents/reviewer.md es el revisor. isolation: worktree mantiene separadas las correcciones paralelas. El conector de GitHub abre las PR. Como se trata de una Routine en la nube, se ejecuta a las 9:00 tanto si tu portátil está abierto como si no, dentro del límite diario de ejecuciones de tu plan.

Constrúyelo como un flujo de trabajo de GitHub Actions para que se ejecute en la nube sin mantener encendido ninguno de tus equipos. La Action es el latido, opencode run es el trabajador y tu repositorio contiene la habilidad, 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-4-6   # 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 (en un modelo más barato y de solo lectura) es quien comprueba. Las ramas nuevas cumplen la función de aislamiento de los worktrees en CI. La aplicación de GitHub de OpenCode abre las PR. ¿Prefieres ejecutarlo en tu propio equipo en vez del de GitHub? La misma indicación 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, del tipo que encontrarías al despertar (la ejecución siguiente ilustra 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.

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

Comprueba lo que sabes

En el bucle de triaje matutino, ¿qué impide que una corrección incorrecta se fusione mientras duermes?

Mostrar la respuesta

Tres elementos juntos: el subagente revisor debe devolver PASS (creador-revisor), solo los cambios de bajo riesgo pueden abrir una PR y la puerta de control humana envía cualquier elemento arriesgado o fallido a una nota de "necesita intervención humana" en vez de a main. Además, cada ejecución tiene límites y queda registrada.

---

Parte 6: Seguir siendo quien diseña​

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

13. El coste de los tokens es el límite real, no la combinación de teclas​

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

• Limita cada bucle: máximo de intentos, minutos o gasto. Siempre (Concepto 5).
• Adapta el modelo al trabajo: uno potente para planificar y comprobar, y uno barato para hacer el trabajo. Es la mayor fuente de ahorro y ya la aprendiste en el curso anterior.
• Mantén breves la indicación del bucle y el archivo de reglas: pagas por ellos en cada latido. Traslada los detalles a habilidades 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 es unas doce veces más barato.

Una referencia rápida de las cifras (ilustrativas). Supongamos que un latido, creador más revisor, lee unos 40.000 tokens y escribe unos 6.000. Con los precios de Sonnet 4.6 de 3 USD / 15 USD por millón, son aproximadamente 0,20 USD por latido. Cinco latidos al día durante un mes de 20 días cuestan unos 20 USD: barato. El mismo bucle, activado cada cinco minutos durante todo el día, produce más de cien veces esa cantidad de latidos y supera con holgura los 1.000 USD al mes sin aportar valor adicional. El dinero se va en la cadencia, no en la combinación de teclas.

El modelo es una segunda palanca en el camino de OpenCode. Esas cifras presuponen Sonnet 4.6. Los comandos de bucle de Claude Code ejecutan Claude, pero OpenCode te permite elegir el modelo, y uno barato reduce mucho el coste por latido: DeepSeek V4 Flash (unos 0,14 USD / 0,28 USD por millón) ejecuta ese mismo latido por unos 0,007 USD, alrededor de 30 veces menos, convirtiendo un bucle de 20 USD al mes en uno que cuesta bastante menos de un dólar. Hay dos advertencias sinceras. Primero, creador barato, revisor fiable: un modelo más débil escribe peores correcciones, puede consumir más latidos o fallar la revisión con mayor frecuencia, y los reintentos se comen el ahorro. Usa el modelo barato como creador mecánico sobre una especificación clara y conserva un revisor en el que confíes (el ejecutor de pruebas y el linter son los revisores más baratos y honestos). Segundo, la cadencia sigue dominando: un modelo 30 veces más barato que se activa cada cinco minutos puede costar más que Sonnet ejecutándose cada hora. El modelo reduce la factura; la frecuencia de ejecuciones y reintentos sigue determinándola.

Un bucle sin límite de gasto puede costar mucho

El fallo habitual es siempre el mismo: un bucle que se ejecuta solo, con una condición de parada imposible de cumplir y que reintenta durante toda la noche. Establece un límite antes de iniciarlo. Observa las primeras ejecuciones reales. Después deja que funcione solo.

14. Comprobar el trabajo sigue siendo tu responsabilidad​

Un bucle que se ejecuta solo también comete errores solo. La separación entre creador y revisor hace que la afirmación "terminado" del bucle signifique algo, pero sigue siendo una afirmación, no una prueba. Tu trabajo no desapareció; cambió de lugar. Ya no escribes cada paso, pero sigues siendo quien confirma que el bucle entregó código que realmente funciona. Lee los diffs que abrió el bucle. Confía en él para hacer el trabajo, pero comprueba el trabajo antes de darlo por válido.

15. No dejes de comprender tu propio proyecto​

Cuanto más rápido entregue el 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 y te permite dejar de pensar cuando lo haces para evitar el trabajo. La misma acción produce el resultado opuesto. El bucle no puede distinguirlos. 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 comprender el trabajo. Construye el bucle, pero hazlo como alguien que piensa seguir siendo quien diseña, no solo quien pulsa iniciar.

Este es el hilo conductor de todo el curso. Cada año, las herramientas absorben más mecanismos del bucle: la orquestación, el revisor y la programación ahora están integrados (flujos de trabajo dinámicos, /goal y Routines), cuando hace un año eran tus propios scripts de shell. Lo que las herramientas no pueden absorber son los dos extremos que conociste en el Concepto 1: la intención, especificada con suficiente precisión para poder comprobarla, y la responsabilidad por lo que se entrega. Por eso esto es ingeniería y no pulsar botones, y es la parte de la habilidad que no caduca. Deja que las herramientas se vuelvan más potentes y apóyate en ellas, pero mantén ambos extremos en tus propias manos.

Cuando un bucle falla mientras duermes

Un bucle sin supervisión también falla sin supervisión. Antes de confiarle una noche, haz que pueda observarse:

• Envía el resultado a un lugar donde lo veas: un archivo de registro, un mensaje de Slack o Discord (Claude Code Channels) o la bandeja de Triage. No a la terminal que ya cerraste.
• Escribe una línea en cada ejecución, incluso si falla: cada latido añade a progress.md (o a un registro) una nota con fecha y hora que indica qué intentó, qué pasó y qué falló. Un fallo silencioso es el peor tipo.
• Mantén reproducibles las ejecuciones: en OpenCode, opencode run --format json, opencode export <id> y opencode session list proporcionan el registro completo. En Claude Code, una Routine conserva su historial de ejecuciones en la interfaz web.
• Haz que el fallo sea visible al alcanzar el límite: cuando el bucle llegue a su límite o encuentre un error, debe dejar una nota clara de "necesita intervención humana", no limitarse a detenerse.
• Gánate la ejecución nocturna: ejecútalo cada hora y bajo observación durante unos días antes de dejarlo trabajar de noche sin supervisión. Cuando algo parezca incorrecto, lee primero la columna vertebral; te indicará qué hizo la última ejecución correcta.

No puedes confiar en un bucle que no puedes depurar.

---

🚀 Proyectos

Leer sobre bucles no es lo mismo que construir uno. Aquí tienes cinco proyectos, de menor a mayor dificultad. Hazlos con cualquiera de las dos herramientas; la forma del bucle es la misma, así que usa el comando del concepto correspondiente (/loop y /goal en Claude Code; 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 hacia un trabajo que te importe.
• Establece primero un límite. Máximo de intentos, minutos o gasto antes de dejar que algo se ejecute solo (Concepto 13).

👀Project 115-30 minUn bucle de vigilanciaHaz que un bucle vigile 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 espere un rato y después escriba un archivo). Configura un bucle en sesión que compruebe cada minuto si la tarea terminó y te avise en ese momento.

Está terminado cuando el bucle detecta que la tarea terminó, lo anuncia una sola vez y puedes detenerlo limpiamente sin haber permanecido mirando la terminal.

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

Dificultad: fácil a media · Usa: Concepto 5 (ejecutar hasta terminar), Concepto 11 (creador-revisor).

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

Está terminado cuando el bucle se detiene porque las pruebas realmente pasaron, no porque alcanzó el límite. Si sigue alcanzándolo, debes mejorar la condición de parada o la indicación. Esa es la lección.

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

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

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

Está terminado cuando lo ejecutas dos veces y la segunda ejecución continúa claramente la primera sin repetir lo ya registrado. Eso demuestra que tu columna vertebral funciona. Si la segunda ejecución empieza desde cero, tu bucle todavía no tiene memoria.

🔍Project 41-2 hUn bucle de corrección con un revisor realUn implementador redacta, un revisor independiente evalúa y solo PASS abre una PR.

Dificultad: media a difícil · Usa: Concepto 8 (worktree), Concepto 9 (habilidad), Concepto 11 (creador-revisor).

Construye. Crea una versión más pequeña del bucle de la Parte 5. Escribe una habilidad breve con tus pasos de corrección y un agente revisor que responda PASS o FAIL. Elige un error real, pide al implementador que redacte una corrección en su propio checkout (worktree o rama) y deja que el revisor la evalúe. Abre una PR solo ante PASS.

Está terminado cuando se cumplen dos condiciones: una buena corrección obtiene PASS y una PR, y una corrección deliberadamente mala que introduzcas obtiene FAIL con motivos. Si el revisor aprueba la corrección mala, es demasiado indulgente; endurece sus criterios. Un revisor que aprueba todo no es un revisor.

🔁Project 52-4 hTu propio bucle diarioEl bucle completo de seis partes aplicado a una tarea real y ejecutado una semana sin supervisión: 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, habilidad, creador-revisor, conector y columna vertebral. Añade protecciones de presupuesto y déjalo ejecutar.

Está terminado cuando se ha ejecutado una semana sin supervisión y confías en lo que entrega porque lo lees, no porque dejaste de leer. Después, responde con sinceridad al Concepto 15: ¿tu comprensión del proyecto siguió el ritmo de los cambios del bucle? Si no fue así, reduce la velocidad hasta conseguirlo. (Cuando falle durante la noche, porque ocurrirá, sigue Cuando un bucle falla mientras duermes antes de culpar al modelo.)

---

Where to go next​

• Just want the schedule details? The reference page Scheduled Tasks: The Loop Skill and Cron Tools covers /loop, claude -p, opencode run, and OS schedulers in depth.
• Building loops for non-coding work? The Cowork & OpenWork crash course shows the same heartbeat idea for professionals, with scheduled tasks instead of cron.
• The spec you wrote in Spec-Driven Development is your loop's stopping condition: its acceptance criteria are what the checker grades against and what /goal proves before it stops. When a loop feels unsafe to leave running, the fix is almost always a sharper spec — not more automation.

Sources & further reading

This course rests on a small set of primary sources. The framing and the quotes come from these; the technical details come from the official docs.

The origin of "loop engineering"

• Addy Osmani, Loop Engineering — the essay that named the pattern and set out the five-parts-plus-spine model. https://addyosmani.com/blog/loop-engineering/
• The New Stack, "The Anthropic leader who built Claude Code says he ditched prompting — now he just writes loops." https://thenewstack.io/loop-engineering/
• Boris Cherny's "my job is to write loops" remark is from a CNBC interview, as reported by Business Insider. Peter Steinberger's "design loops that prompt your agents" line is from his post on X.

Claude Code (official docs)

• Routines — cloud scheduled automations, triggers, and run caps: https://code.claude.com/docs/en/routines
• Channels — event-driven input into a running session: https://code.claude.com/docs/en/channels
• This book's own reference page, Scheduled Tasks: The Loop Skill and Cron Tools, goes deeper on /loop, /goal, and claude -p.

OpenCode (official docs)

• CLI — opencode run, serve, and --attach: https://opencode.ai/docs/cli/
• Agents and subagents — primary agents, subagents, and per-agent models: https://opencode.ai/docs/agents/
• GitHub integration — the Action, schedule/PR/issue triggers, and opencode github install: https://opencode.ai/docs/github/

Model identifiers

• Anthropic, Introducing Claude Sonnet 4.6 — source for the claude-sonnet-4-6 model string: https://www.anthropic.com/news/claude-sonnet-4-6
• Anthropic, Model IDs and versioning — why dateless IDs (claude-sonnet-4-6) are the pinned snapshot from the 4.6 generation onward, while 4.5-generation models like Haiku 4.5 keep a dated canonical ID (claude-haiku-4-5-20251001) plus a dateless alias: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions

All links current as of June 2026. These tools update often, so confirm any specific limit, flag, or model string against the live docs before you rely on it.

---

The one-line summary

Stop prompting your agent turn by turn. Design the loop that prompts it for you — a heartbeat, four working parts, and a spine that remembers — and stay the engineer who reads what it ships.

Flashcards Study Aid

---

Test Your Understanding

Checking access...