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.
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 updateuopencode upgrade. Consulta la documentación vigente (code.claude.com/docs, opencode.ai/docs) antes de depender de un límite o un indicador.
Un bucle real funciona sin supervisión: se da instrucciones a sí mismo mientras estás ausente. El cuadro de chat normal de claude.ai no puede hacerlo: te espera en cada turno, así que en el chat tú eres la programación. Para ejecutar un bucle real necesitas una herramienta capaz de activarse por sí sola: Claude Code, OpenCode o Cowork (consulta el curso acelerado de Cowork). La mayoría son de pago y varias están hoy en vista previa de investigación. Puedes aprender y diseñar un bucle en cualquier lugar; para ejecutarlo necesitas una de esas herramientas. Este curso presenta las dos orientadas a la programación. 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. 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."Pero completé todo el curso basado en especificaciones en claude.ai. ¿También puedo ejecutar allí un bucle?"
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.
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.
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
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.
- Latido: un horario (o un evento) que inicia el bucle. Sin él, tienes una sola ejecución, no un bucle.
- Worktree: aislamiento para que dos agentes que trabajan al mismo tiempo no sobrescriban sus archivos.
- Habilidad: el conocimiento del proyecto escrito una sola vez, para que cada ejecución no empiece desde cero.
- Subagentes: la separación entre creador y revisor; el agente que escribe el código no es quien lo evalúa.
- 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:
- 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.
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.
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? 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.Mostrar la respuesta
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.
Una misma idea sostiene los cuatro tipos: un bucle no es una sola acción. Es haz esto, espera, hazlo de nuevo, una y otra vez, así que algo tiene que permanecer despierto entre pulsaciones para disparar la siguiente. La única pregunta es dónde vive ese algo.
- Un bucle en sesión conserva su temporizador en tu sesión abierta, el proceso que sigue en marcha mientras tu terminal está abierta. Cierra la sesión y lo que sostiene el temporizador desaparece, así que el bucle se detiene.
- Una tarea programada o una Routine (las construyes en el Concepto 6) traslada el temporizador fuera de la sesión, a un programador que nunca duerme (cron en tu propia máquina, o los servidores de Anthropic para una Routine en la nube). En cada pulsación lanza una ejecución nueva y efímera, deja que termine y la apaga; luego lanza otra distinta la próxima vez. El mismo bucle, pero nada tuyo tiene que quedar abierto.
| Latido | Dónde vive el temporizador | Qué permanece despierto entre pulsaciones |
|---|---|---|
/loop en sesión | dentro de la sesión | tu sesión abierta (tu máquina, con la terminal abierta) |
| Tarea programada / Routine | fuera, en un programador | el programador, que lanza una ejecución nueva en cada pulsación |
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 un bucle que debe sobrevivir a un portátil cerrado necesita el tipo externo (Concepto 6).
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: un Para un trabajo que deba seguir ejecutándose pase lo que pase, no dependas de Una opción intermedia: las sesiones en segundo plano. Una sesión en segundo plano es el peldaño intermedio entre un Por sí sola solo hace un trabajo y se detiene; no se repite según un temporizador. Su valor está en transportar un bucle. Inicia un Recurre a ella cuando quieras cerrar la terminal pero mantener un bucle vigilando algo, como un despliegue o una ejecución larga de pruebas. Solo recuerda el coste de "viva en tu propia máquina": el equipo tiene que permanecer encendido. En cuanto el trabajo deba sobrevivir a un portátil cerrado, has cruzado al territorio del programador y la herramienta adecuada es una Routine (Concepto 6). Los tres peldaños se alinean en una sola pregunta: ¿cuánto tiene que permanecer despierto?Opcional: ¿qué ocurre cuando se cierra la sesión?
/loop de sesión normal se ejecuta dentro de tu 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 está pensado para sobrevivir a la sesión que lo inició. Dos cambios recientes suavizan esa regla:
--resume recupera las tareas que no han caducado. Una tarea recurrente sigue siendo válida durante siete días después de crearla./loop, de modo que siguen disparándose aunque no haya ninguna terminal abierta. La salvedad: no recuperan las ejecuciones que se perdieron mientras la máquina estaba en suspensión./loop: usa una tarea programada o una Routine (Concepto 6). La herramienta también se encarga de esto por ti. En una sesión en la nube (una que se ejecuta en un servidor remoto, no en tu propia máquina), las versiones recientes ya no ofrecen /loop en absoluto, porque esa sesión se apaga en cuanto termina tu solicitud. No queda nada en marcha para mantener el bucle./loop en sesión y una Routine: mantiene una ejecución viva en tu propia máquina después de que cierres la ventana de la terminal. Inicias una con claude --bg./loop, envía esa sesión a segundo plano y el bucle viaja con ella, disparándose aún con la ventana cerrada. (claude agents la lista después y /resume la vuelve a abrir, marcada como bg).Peldaño Opción ¿Sigue disparándose tras cerrar la terminal? ¿Sigue disparándose con el portátil en suspensión o apagado? Inferior /loop en sesiónNo No Intermedio Sesión en segundo plano ( --bg) que transporta un /loopSí No (necesita tu máquina encendida) Superior Tarea programada / Routine Sí Sí (una Routine en la nube se ejecuta en los servidores de Anthropic)
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"
Cancelar un /loop. Cada bucle es una tarea programada con un ID, así que se detiene igual que se inició: 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 deseas cancelar, o puedes indicar directamente el ID de la tarea. Cerrar la sesión también detiene un bucle de sesión normal, pero cancelarlo es la forma correcta: un bucle que querías detener no debe depender del cierre de la sesión. Los subcomandos exactos son la capa mecánica; si el lenguaje natural falla, consulta la documentación actual en code.claude.com/docs/en/scheduled-tasks.
Para OpenCode, detenga un bucle de primer plano con Ctrl-C; si se ejecuta en segundo plano, finalice su proceso. Para /objetivo, el verificador separado solo puede leer la conversación: Claude debe ejecutar la prueba y mostrar el resultado, o el verificador no puede probar que se cumplió el objetivo. Un bucle Ralph repite un mensaje y actualiza un archivo de estado; sin una condición de éxito verificable por comando, deambula hasta que finaliza su límite de tiempo.
5. Ejecutar hasta terminar (el bucle decide cuándo detenerse)
Un bucle con temporizador fijo se ejecuta una y otra vez según el reloj hasta que lo cancelas o termina la sesión. Cada ejecución puede comprobar un resultado, pero nada lee ese resultado para detener el bucle. Un bucle condicional de ejecutar hasta terminar se detiene cuando una comprobación independiente demuestra que el trabajo terminó. La diferencia no es el número de intentos: el primero no sabe cuándo acabó el trabajo; el segundo se detiene porque acabó.
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 Una ejecución sin supervisión significa que el bucle trabaja sin que nadie observe, de noche o mientras estás lejos del teclado. No hay ninguna persona que note si se atasca y lo detenga. Por eso mismo los reintentos necesitan aquí un límite. Un reintento es el bucle volviendo a intentar un paso que falló (por ejemplo, una llamada a la API que agotó su tiempo). Sin un tope, un bucle atascado podría reintentar para siempre mientras duermes, gastando tiempo y tokens. Así que Claude Code ahora fija ese tope por ti: Los nombres de los indicadores y las cifras son la capa mecánica, así que consulta la documentación vigente antes de fiarte de ellos. Lo que perdura: incluso el proveedor asume ahora que una ejecución sin supervisión necesita un límite que alguien haya elegido a propósito./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.Opcional: configuración actual de reintentos de Claude Code
CLAUDE_CODE_MAX_RETRIES), y puedes subirlo hasta un tope de 15.CLAUDE_CODE_RETRY_WATCHDOG=1. Reintenta los errores temporales (como un corte breve de red) durante mucho más tiempo (hasta 300 en el momento de escribir esto, unas tres horas de espera progresiva) y elimina el tope de 15 en cuanto defines tu propio MAX_RETRIES.
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.
Todo bucle necesita tres formas de detenerse. Cada una evita una manera concreta de fallar:
| Parada | Qué es | Si la omites… |
|---|---|---|
| Condición de éxito | cómo sabe el bucle que la tarea está terminada | nada define "terminado", así que el bucle no puede detenerse a propósito ni evaluarse |
| Límite | un tope: máximo de intentos, de minutos o de gasto | un objetivo que no puede alcanzar consume todo tu presupuesto de tokens |
| Comprobación de no progreso | detecta cuándo el agente repite la misma acción con los mismos argumentos (está atascado; reintentar no lo arreglará) | gasta todo el límite repitiendo un mismo error |
Un nombre que encontrarás en internet: el bucle Ralph. El bucle de ejecutar hasta terminar más conocido y sencillo: ejecuta la misma indicación una y otra vez, y en cada ejecución lee y actualiza un único archivo de estado. Conserva solo dos de las tres paradas (una condición de éxito y un tope de tiempo), sin comprobación de atasco, sin habilidad y sin un revisor aparte. Esa desnudez es justo lo que enseña la lección con tanta claridad. Un bucle Ralph con una condición vaga deambula hasta que se agota el tope de tiempo; el mismo bucle con una condición que un comando pueda demostrar funciona bien.
Un bucle solo es tan bueno como su condición de parada.
Un bucle de ejecutar hasta terminar que corre muchos turnos llena su propio contexto de basura: salidas de herramientas antiguas, callejones sin salida y razonamientos obsoletos. A medida que crece el montón, las respuestas del modelo empeoran. La comunidad llama al resultado un bucle fatal (doom loop): un contexto desordenado lleva a una peor decisión, que añade más desorden, que empeora aún más la siguiente decisión. Las defensas son los mismos hábitos de contexto del curso de programación con agentes:
- Compacta las ejecuciones largas: cada cierto tiempo, sustituye el ida y vuelta en bruto por un resumen breve de lo ocurrido, para que el contexto se mantenga pequeño.
- Mueve las salidas grandes a archivos: escribe los resultados voluminosos (registros, datos, texto generado) en un archivo y conserva solo un puntero en el contexto, en lugar de pegarlo todo.
- Delega las subtareas desordenadas a un subagente: deja que un ayudante haga la exploración ruidosa en su propio contexto y devuelva solo la respuesta limpia.
La única idea detrás de las tres: trata el contexto como un presupuesto que gastas a propósito, no como un cubo en el que sigues vertiendo. Un contexto más pequeño y limpio es lo que mantiene afiladas las decisiones de una ejecución larga.
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".
Primero, una nota sobre los nombres. Un programador (scheduler) es lo general: cualquier reloj siempre activo que lanza una ejecución nueva a su hora (cron, GitHub Actions o un servicio en la nube). Una Routine es el programador alojado en la nube propio de Claude Code, donde Anthropic aporta el reloj y la máquina, así que nada tuyo tiene que estar encendido. Toda Routine es un programador; no todo programador es una Routine.
Hay tres formas de ejecutar Claude según una programación. Una pregunta elige entre ellas: ¿dónde se ejecuta el trabajo? En los servidores de Anthropic, en su máquina a través de la aplicación de escritorio o en su máquina a través de su propio programador. Tómelos en ese orden; el primero es el que la mayoría de la gente debería aprender bien.
1. Rutinas en la nube: la computadora portátil puede estar apagada
Comience con la idea simple. Una rutina en la nube es una instrucción permanente que reside en los servidores de Anthropic, no en su computadora. Escribes la instrucción una vez. A partir de ese momento, se ejecuta por sí solo, en el momento que usted establezca, ya sea que su computadora portátil esté abierta, inactiva o en un bolso. Piense en ello como contratar a un trabajador que se sienta en la oficina de Anthropic, no en la suya: usted entrega una descripción escrita del trabajo y el trabajo se realiza sin que usted lo organice.
Un ejemplo concreto al que aferrarse. Suponga que mantiene un producto pequeño con un repositorio de GitHub y cada mañana dedica 30 minutos a realizar la misma clasificación: lea los nuevos problemas que llegaron durante la noche, etiquételos, marque todo lo que parezca un bloqueo y publique un resumen en el Slack del equipo. Esa media hora es una rutina perfecta: se repite, sigue reglas que puedes escribir y nada de eso te necesita a ti, necesita tus instrucciones. Construiremos exactamente esta rutina a continuación.
Las cuatro partes de cada Rutina
Cuando creas una rutina, estás completando cuatro espacios en blanco. Cada uno responde una pregunta; aquí están, con nuestro ejemplo de clasificación matutina completado:
-
El mensaje: ¿qué debería hacer? La instrucción permanente en sí, escrita de la manera que aprendió en la lección de especificaciones: el objetivo, las reglas, cómo se ve "hecho". Es el mismo mensaje en cada ejecución, por lo que debe sobrevivir a su ausencia; usted no estará allí para aclararlo.
Ejemplo de mensaje: "Revise todos los problemas abiertos en las últimas 24 horas. Etiquételos como
bug,feature-requestoquestion. Si algún problema describe una falla o pérdida de datos, agregue la etiquetaurgent. Luego publique un resumen en el canal #triage de Slack: total de problemas nuevos, cuántos urgentes y una línea por problema urgente. Si no hay problemas nuevos, publique "No hay problemas nuevos durante la noche". No cerrar ni comentar ningún tema."Observe la anatomía de las especificaciones en funcionamiento: un objetivo (clasificar y resumir), reglas (etiquetar estas formas, urgente significa falla/pérdida de datos), un límite (no cerrar ni comentar) y un "hecho" definido incluso para el caso vacío.
-
Los repositorios: ¿qué puede tocar? Usted nombra los repositorios en los que la Rutina puede trabajar. Todo lo que no enumere está fuera de su alcance.
Ejemplo: otorgas
yourteam/product-app— y solo eso. Sus otros cinco repositorios, incluido el que tiene el código de facturación, simplemente no existen en lo que respecta a esta Rutina. -
Los conectores: ¿a qué puede llegar? Slack, correo electrónico, calendarios: las manos de la rutina más allá del repositorio: cómo lee el mundo exterior y cómo le informa.
Ejemplo: conectas el conector de Slack para que pueda publicarse en #triage. No hay ningún conector de correo electrónico adjunto, por lo que no podría enviar correos electrónicos incluso si el mensaje así lo solicita. Los conectores son permisos, no sugerencias.
-
El desencadenante: ¿cuándo se despierta? El latido del corazón. Tres tipos, y cada uno se adapta a una forma diferente de trabajo:
- Un horario: el reloj lo despierta. Nuestro ejemplo: todos los días laborables a las 8:30 a. m., por lo que el resumen espera en Slack antes de que el equipo se siente.
- Una llamada API: otro programa lo activa. Ejemplo: su secuencia de comandos de implementación finaliza una versión, luego llama al punto final API de la rutina para activar una ejecución de "verificación de humo de la versión e informe"; la rutina se activa exactamente cuando hay algo que verificar, no en un temporizador tonto.
- Un evento de GitHub: el repositorio lo reactiva. Ejemplo: una rutina activada por una "solicitud de extracción abierta" que compara cada nuevo RP con la lista de verificación de su equipo y deja un comentario estructurado; se ejecuta cero veces en un día tranquilo y nueve veces en uno ocupado.
Aviso, repositorios, conectores, disparador. Qué hacer, dónde puede actuar, a qué puede llegar, cuándo despierta. Cada rutina son esas cuatro respuestas, y nuestro trabajador de clasificación matutina ahora está completamente especificado: el mensaje anterior, un repositorio, un conector de Slack, de lunes a viernes a las 8:30.
Una característica, tres puertas
Puede crear una rutina en tres lugares: en claude.ai/code/routines en el navegador, en la aplicación de escritorio o con el comando /schedule en la CLI. Éstas no son tres características diferentes: las tres puertas se abren a la misma habitación. Cada rutina que realices, desde cualquier puerta, se guarda en la misma cuenta en la nube y aparece en los tres lugares.
Ejemplo de por qué esto es importante: dibujas la rutina de clasificación con
/scheduleen tu terminal el martes, luego el jueves (en el navegador de tu teléfono, en un autobús) abresclaude.ai/code/routines, ves la misma rutina y editas su mensaje. Misma habitación, diferente puerta.
Opcional: gestionar una Routine desde la terminal
Puedes gestionar toda la vida de una Routine desde la terminal, en 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 cosas rápidas:
- Horarios personalizados. Las opciones predefinidas cubren los casos habituales (cada día, cada hora, cada día laborable). Para un horario inusual,
updatetambién acepta una expresión cron: un código breve que expresa una hora exacta. Por ejemplo,0 9 * * 1-5significa "9 de la mañana, de lunes a viernes". - Práctica gratuita. Una ejecución única corre 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 una indicación una vez y comprobar que funciona antes de comprometerte a ejecutarla cada día. - Solo por reloj. Desde la terminal solo puedes crear routines que empiecen a una hora fija. Para iniciar una a partir de otra cosa, como otro programa que la llame (una llamada a la API) o un evento en GitHub (como la apertura de una nueva pull request), abre la routine en su página web y añade allí ese desencadenante.
Si /schedule parece faltar en tu CLI, el apéndice de Routines explica qué comprobar.
¿Qué sucede realmente al correr?
A las 8:30 del lunes, los servidores de Anthropic inician una nueva sesión de Claude, le entregan su mensaje y le dan acceso exactamente al repositorio y al conector de Slack que usted enumeró. Lee los números del fin de semana, los etiqueta, los publica en #triage (por ejemplo: "7 problemas nuevos, 1 urgente: falla de inicio de sesión en Android (#412)") y se apaga. El martes a las 8:30 comienza una carrera completamente nueva; La sesión del lunes ya no está. Nada depende de tu máquina: esta es la propiedad que hace que una Rutina sea un verdadero bucle en lugar de una sesión que tienes que cuidar.
Las dos reglas que debes conocer antes de confiar en ello
Regla uno: hay un límite diario. Cada cuenta obtiene una cantidad fija de ejecuciones de rutina por día: en el lanzamiento, 5 en Pro, 15 en Max, 25 en Team y Enterprise. ¿Por qué una gorra? Porque un sistema desatendido que se ejecuta en los servidores de otra persona debe tener un presupuesto; Esto es cierto para todos los servicios en la nube, y es un número que usted diseña, no una sorpresa que descubre.
Ejemplo de presupuesto en una cuenta Pro (5 ejecuciones/día): clasificación matutina (1 ejecución) + un informe vespertino de "resumen de los compromisos de hoy" (1 ejecución) + una rutina de revisión de relaciones públicas en un día con 4 solicitudes de extracción (4 ejecuciones) = 6 ejecuciones. Eres uno más. Sus opciones, en orden de preferencia: fusionar los dos informes diarios en una rutina (guarda una ejecución), dejar que el revisor de relaciones públicas sea lo que compre para uso adicional en los días ocupados o actualizar el plan. El punto es que hiciste esta aritmética antes de que el ciclo se detuviera silenciosamente en la ejecución cinco.
Tres detalles suavizan el límite: esos son números de tiempo de lanzamiento, así que verifique claude.ai/settings/usage para conocer los actuales; las ejecuciones programadas únicas no cuentan; y puedes pagar por el uso adicional más allá.
Regla dos: de forma predeterminada, solo puede enviar a ramas claude/. Una Routine nueva no puede escribir en main. Cada rama que envíe debe empezar por claude/.
Esto es algo bueno, no un obstáculo. Mantiene el trabajo sin supervisión seguro desde el primer día: la Routine puede hacer todo el trabajo que quiera, pero tú sigues decidiendo qué se fusiona.
Aquí tienes un ejemplo. Configuras una segunda Routine para corregir pruebas inestables durante la noche. A las 3 de la madrugada envía su corrección a una rama claude/. Por la mañana lees el cambio, ves que parece correcto y lo fusionas tú mismo. La Routine hizo el trabajo mientras dormías; tú hiciste la comprobación al despertar. Ese intervalo es justo el propósito.
Más adelante, cuando un repositorio se haya ganado tu confianza tras muchas ejecuciones limpias, puedes desactivar la regla solo para ese repositorio con la opción Permitir envíos de rama sin restricciones. Hazlo a propósito, un repositorio a la vez, como quien entrega una llave.
Cuando una rutina en la nube es la elección correcta
Siempre que el trabajo no necesite su máquina: clasificación matutina (nuestro ejemplo), un resumen de "lo que cambió esta semana" el viernes para las partes interesadas, seguimiento del registro de cambios de un competidor, redacción de respuestas a problemas de soporte de rutina. Si piensas "esto debería suceder todos los días sin mí", esta es la herramienta.
2. Tareas programadas en el escritorio: la computadora portátil debe estar encendida
Creado en la aplicación de escritorio. Estos se ejecutan localmente, en sus archivos reales, incluidos los cambios no guardados que se encuentran en su editor, y no necesitan una sesión abierta.
Ejemplo de dónde esta es la herramienta adecuada: todas las tardes a las 6 p. m., "mire todo en lo que trabajé hoy en mis proyectos locales, incluidos los archivos que no he comprometido, y escriba una entrada en el diario de trabajo en
~/journal/". Una rutina en la nube no puede hacer este trabajo a cualquier precio: su tarde no comprometida sólo existe en su máquina. Ese acceso local es la única razón por la que existe esta opción; el intercambio es que su computadora portátil debe estar encendida a las 6 p.m.
3. Tu propio cron: tu máquina, tu programador, sin nube Anthropic
claude -p ejecuta una sola indicación y luego sale (-p es de prompt): sin sesión, sin ventana de chat. 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 desencadenantes, los secretos y los problemas habituales), el apéndice de Routines al final de este curso te lo explica paso a paso.
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.
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.
Esta sección trata sobre los eventos. Un evento es, simplemente, algo que ocurre. Cada tipo de evento tiene un receptor, una herramienta que reacciona ante él, y los receptores no son todos iguales. Los eventos de GitHub y los eventos de "todo lo demás" los recibe una Routine; los mensajes de chat los recibe un Channel. Así que dos de los tres receptores son Routines, y uno (el Channel) no lo es. La única debilidad del Channel, que necesita tu máquina encendida, se muestra con claridad en la tabla de abajo.
Con Claude Code, de dónde procede el evento decide qué herramienta usas. Hay tres rutas:
1. Desde GitHub, usa una Routine. Una Routine no tiene por qué ejecutarse según un reloj; su desencadenante puede ser un evento de GitHub. Funcionan dos tipos: un cambio en una pull request (se abre, se actualiza o se fusiona) y la publicación de una release. Por ejemplo: "cuando se abra una PR, revísala y comenta" o "cuando se publique una release, redacta el registro de cambios".
Tres cosas que debes saber antes de construir una:
- Configuración. La aplicación Claude de GitHub tiene que estar instalada en el repositorio. Cuidado:
/web-setupsolo concede acceso de clonación, no instala la aplicación. Esto hace tropezar a muchos primeros intentos. - Sin desencadenante de push. No existe un evento "al hacer push". Pero si alguien envía commits a una rama que ya tiene una PR abierta, GitHub lo cuenta como una actualización de la PR (el evento
synchronized), así que la Routine se dispara. Envía a una rama sin PR y no ocurre nada. - Filtros. Puedes limitar qué eventos la disparan: por autor, título, etiquetas, rama, estado de borrador y más. La lista completa de campos, los límites por hora y los casos delicados están en el apéndice de Routines (A3).
2. Desde una aplicación de chat, usa un Channel. Un Channel deja caer un mensaje de una aplicación externa directamente en una sesión que ya se está ejecutando. Telegram, Discord e iMessage funcionan de fábrica; para cualquier otra cosa, configuras un webhook. Este es el timbre de la Parte 2: no ocurre 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, sus habilidades y su historial actuales. Un bucle también puede enviar informes de vuelta por ese mismo Channel.
Dos advertencias:
- Necesita una sesión viva. La sesión debe estar ya en marcha (una terminal abierta o una sesión en segundo plano), así que un Channel no funciona con la máquina apagada.
- Es una puerta abierta. Cualquiera que pueda enviar mensajes a esa fuente puede dirigir tu sesión, así que conecta solo fuentes que controles.
Configuración: code.claude.com/docs/en/channels.
3. Desde cualquier otra cosa, usa una Routine con un desencadenante de API. Algunos eventos no vienen ni de GitHub ni de una aplicación de chat: salta una alerta en tu herramienta de monitoreo, termina un despliegue, se envía un formulario. Para estos, dale a la Routine un desencadenante de API, y entonces cualquier sistema que pueda enviar una solicitud web autenticada (una solicitud que demuestra quién es) podrá dispararla, con tu portátil cerrado. Esa solicitud puede incluso llevar los detalles del evento: un campo opcional text pasa contexto específico de la ejecución (el mensaje de la alerta, el registro que falla) a la Routine junto con su indicación guardada. El endpoint, el token y una advertencia sobre reintentos están en el apéndice de Routines (A3).
Elegir entre los tres:
| El evento surge de… | Uso | La obra se ejecuta en… |
|---|---|---|
| GitHub (un PR, un lanzamiento) | una rutina, disparador de GitHub | una nueva sesión en la nube, por evento |
| un mensaje de chat (Telegram, Discord, iMessage) | un canal | la sesión que ya tienes corriendo |
| cualquier cosa que pueda enviar una solicitud web | un disparador API de rutina | una nueva sesión en la nube, por llamada |
Tenga en cuenta el patrón en la primera y tercera filas: cada evento inicia una nueva sesión, por lo que dos eventos no saben nada el uno del otro. Dos impulsos para un RP son dos sesiones separadas. La columna vertebral (Concepto 12) es la forma en que comparten estado.
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.
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? Ejecutar hasta terminar: Mostrar la respuesta
/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.)
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.
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.
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
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.
¿Dónde debe conservar un bucle lo que ha hecho hasta ahora y por qué no debe guardarlo en la conversación? 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.Mostrar la respuesta
Parte 5: Un bucle completo, dos veces
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):
- Latido: cada día laborable a las 9:00.
- Habilidad: una habilidad
daily-triagecontiene los pasos para que la indicación ocupe una sola línea. - Columna vertebral: leer
progress.mdal principio y actualizarlo al final. - Worktree: redactar cada corrección en su propio checkout.
- Creador-revisor: un implementador redacta y otro revisor independiente responde PASS o FAIL.
- 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
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 nota honesta sobre la línea tools: solo admite nombres de herramientas (Read, Bash), por lo que no puede limitar al revisor únicamente a los comandos de test, lint y diff. Por ahora, las instrucciones numeradas se encargan de ese límite. El siguiente curso, Harness Engineering, añade la regla que lo hace cumplir.
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.
En el bucle de triaje matutino, ¿qué impide que una corrección incorrecta se fusione mientras duermes? 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 Mostrar la respuesta
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.
Cómo encaja tu bucle dentro de tres
Acabas de construir un bucle. Tiene seis partes y, una vez que arranca, funciona solo: el agente escribe código, lo prueba, lo corrige y lo intenta de nuevo, sin ti.
Ese es un bucle. Es el más rápido. Gira en minutos. Pero no funciona solo. Es el más pequeño de tres bucles, y los otros dos te toca ejecutarlos a ti.
La forma más fácil de verlos es con un ejemplo. Supongamos que le pides a un agente que construya un pequeño juego de mecanografía para un niño.
- El bucle de código gira en minutos. El agente escribe el juego, lo prueba y corrige errores hasta que coincide con tus instrucciones. Este es el bucle que acabas de construir.
- El bucle de retroalimentación gira 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, añadir un inicio de sesión para que una madre o un padre pueda ayudar. Luego actualizas tus instrucciones y el agente construye de nuevo.
- El bucle exterior gira en días. Personas reales usan el juego. Un amigo lo prueba. Un niño juega con él. Lo que hacen te muestra qué corregir a continuación.
Los bucles no están uno al lado del otro. Están uno dentro del otro. Muchos bucles de código ocurren mientras ejecutas un bucle de retroalimentación. Muchos bucles de retroalimentación ocurren mientras el mundo exterior devuelve una ronda de retroalimentación. El bucle rápido funciona solo. Los bucles lentos te necesitan.
Dos palabras que conviene conocer. Una especificación es tu descripción escrita de qué construir. Las evals son un pequeño conjunto de pruebas que comprueban si el agente acertó. Juntas se sitúan entre los dos primeros bucles y llevan tus decisiones al código.
Ahora la idea principal, de Andrew Ng. ¿Por qué el agente no puede ejecutar los tres bucles por sí solo? Porque tú sabes cosas que él no: quién usará esto, qué necesitan de verdad y cómo se siente lo "bueno". Mientras sepas algo que el agente no sabe, permaneces en el bucle para decírselo. Ng llama a esto tu ventaja de contexto.
Esa es la misma lección con la que termina este curso. La máquina ejecuta el bucle rápido. Tú sostienes las dos cosas que nunca podrá sostener: qué construir y quién responde por ello.
Aunque nunca construyas un producto, guarda este mapa. Muestra dónde se sitúa el humano en el trabajo de cualquier agente. Para afinar la especificación que une los dos primeros bucles, consulta Desarrollo guiado por especificaciones. Para ver cómo crece tu rol a lo largo de los bucles exteriores, consulta Los roles que este libro entrena.
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.
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.
Esas dos personas están bajo la misma fuerza, y esa fuerza tiene nombre. Eric So, de MIT Sloan, la llama gravedad de la IA: el tirón constante que te empuja a dejar que la IA haga cada vez más parte de tu pensamiento. Un bucle es ese tirón con latido propio: corre mientras duermes, así que la distancia entre lo que se entrega y lo que entiendes crece incluso cuando no tocas nada. Si la dejas sola, la gravedad comprime los dos extremos que este curso dice que siguen siendo tuyos: la intención se adelgaza hasta pasar de una condición precisa y comprobable a «que siga funcionando», y la responsabilidad se adelgaza hasta pasar de leer los diffs a confiar en los checks verdes. El bucle seguirá corriendo de cualquier modo. No puede distinguir si sigues siendo quien diseña. El hábito semanal que responde a la pregunta del Concepto 15 —leer lo entregado y comprobar que tu comprensión siguió el ritmo— es la forma de sostener tu peso contra ese tirón.
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>yopencode session listproporcionan 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.)
Hacia dónde seguir
- ¿Construyes bucles para trabajo que no es de programación? El curso acelerado de Cowork y OpenWork muestra la misma idea del latido para profesionales, con tareas programadas en lugar de cron.
- ¿Ajustas los reintentos para ejecuciones sin supervisión? La referencia de errores de Claude Code documenta la configuración de reintentos automáticos, incluidos
CLAUDE_CODE_MAX_RETRIESy el modoCLAUDE_CODE_RETRY_WATCHDOGpara sesiones sin supervisión al estilo de CI. - La especificación que escribiste en Desarrollo basado en especificaciones es la condición de parada de tu bucle: sus criterios de aceptación son lo que el revisor evalúa y lo que
/goaldemuestra antes de detenerse. Cuando un bucle da miedo dejarlo en marcha, la solución casi siempre es una especificación más afinada, no más automatización.
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.
- Andrew Ng: los tres bucles del desarrollo de productos (código ~minutos, retroalimentación del desarrollador ~horas, retroalimentación externa ~días) y la reformulación del "gusto" como la ventaja de contexto del humano. De su publicación en X. https://x.com/AndrewYNg/status/2071988145667928442
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
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-6model 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.