Ingeniería de bucles: De los prompts a la ejecución continua

He decidido dedicar este artículo a cómo crear tu propio agente programable que hará el trabajo por ti, para que no tengas que encender tu computadora cada mañana y darle comandos una y otra vez.

Se despertará solo, encontrará tareas por sí mismo, identificará problemas por sí mismo, y guardará y presentará los resultados en tu escritorio para que los revises.

Prefacio

La idea de Loop no surgió de la nada - durante una sola semana de junio de 2026, tres expertos de la industria expresaron casi simultáneamente el mismo pensamiento: era hora de empezar a desarrollar este nivel.

Una semana después, Andrew Ng colocó esta conversación dentro del contexto más amplio de "Construir Productos de 0 a 1", proporcionando una imagen más completa.

Este artículo comienza con esa historia y luego te guía en la construcción de un loop mínimo pero completo desde cero: 5 movimientos, 6 partes, una puerta que dice "no" y una puerta humana, todo ejecutándose en tu propia máquina y reutilizable en cualquier proyecto de software.

Fuente: HuaShu Orange Book, Loop Engineering: Deja de Preguntarme Qué Es (v260615, junio de 2026)

La semana en que 3 personas encendieron la mecha

Junio de 2026: tres personas, sin coordinación alguna, dijeron casi lo mismo con días de diferencia.

Peter Steinberger, creador de OpenClaw, publicó dos frases en X que alcanzaron 8.9 millones de visitas:

https://x.com/steipete/status/2063697162748260627

Esa publicación es donde realmente comenzó el discurso. No fue un manifiesto ni un ensayo largo, solo dos líneas que nombraron algo que la gente ya estaba haciendo en silencio.

Boris Cherny: Ya no le doy indicaciones a Claude, tengo loops que están funcionando. Ellos son los que le están dando indicaciones a Claude y decidiendo qué hacer.

Addy Osmani: La ingeniería de loops consiste en reemplazarte a ti mismo como la persona que le da indicaciones al agente. Diseñas el sistema que lo hace en tu lugar.

La práctica precedió al nombre por meses, todos ya estaban escribiendo loops, nadie le había puesto un nombre todavía.

Entonces, los loops son ahora una parte clave de cómo permitimos que los agentes de IA trabajen de forma iterativa a largo plazo para crear software.

Andrew Ng organizó los tres loops desde el más interno al más externo según sus escalas de tiempo: el loop más interno es el más rápido, y el loop más externo es el más lento. Además, la entrada del loop más externo proviene de la salida del loop más interno:

Loop

Quién lo ejecuta

Duración del ciclo

Qué produce hacia la capa externa

Loop de codificación del agente

el propio agente

segundos - minutos

una versión que funciona

Loop de retroalimentación del desarrollador

humano + agente

decenas de minutos - horas

una visión y especificación del producto más clara

Loop de retroalimentación externa

usuarios + equipo

horas - semanas

datos reales que evolucionan la visión

Andrew Ng nos dio el mapa por tiempo: tres loops funcionando a diferentes velocidades. Addy Osmani dibujó un segundo mapa por abstracción: indicación -> contexto -> arnés -> loop.

La ingeniería de loops se sitúa en la cima y añade tres verbos que el arnés no tiene. Se ejecuta con un temporizador, genera ayudantes y se alimenta a sí mismo - la salida de hoy se convierte en la entrada de mañana. Eso último es lo que lo convierte en un loop, no la misma tarea ejecutada N veces.

La intuición más importante: el mismo error cuesta una cantidad diferente en cada capa:

Capa

Lo que le importa

Pregunta central

Ing. de indicaciones

escribir una indicación

qué decirle al modelo

Ing. de contexto

qué está cargado en la ventana

qué extraer, resumir, limpiar

Ing. de arnés

preparar una sola ejecución

qué herramientas, qué acciones, qué cuenta como terminado

Ing. de loops

programar sobre el arnés

cómo hacer que se ejecute solo, ronda tras ronda

Un loop es, por diseño, una máquina que hace que el "número de turnos" sea grande. Cada decisión a partir de aquí - evaluador, puerta humana, límite de tokens, archivo de estado - existe para acortar la distancia entre "ocurre un error" y "alguien lo ve".

Qué sucede dentro de un turno:

"Loop" se malinterpreta como "girar en el mismo lugar". No lo es, cada turno tiene 5 movimientos concretos. Elimina cualquiera y el loop no funcionará, o funcionará sin llegar a ninguna parte.

1. La verificación es el movimiento que dice "no".
2. La programación es el movimiento que alimenta este turno en el siguiente.

Esa es exactamente la parte que lo convierte en un loop.

Mapeado al proyecto que vamos a construir: un loop de triaje matutino para un equipo pequeño:

Acción

Qué hace

En el LOOP DE TRIAJE

Descubrimiento

decidir qué debe hacer este turno

una skill lee CI / issues / commits recientes

Transferencia

despachar la tarea y aislarla

cada hallazgo obtiene su propio worktree

Verificación

intercambiar por otro agente que diga no

un segundo sub-agente como revisor, probando tests y skills

Persistencia

escribir el estado fuera de la conversación

PR + ticket de Linear + ./state/triage.md

Programación

dejarlo ejecutarse turno tras turno

cron de GitHub Actions se activa a las 06:00

Cada una de las 5 lecciones a continuación desarrolla exactamente un movimiento.

Cinco lecciones = un Loop completo.

Y empezamos con la primera: Descubrimiento, porque si el Loop no puede decidir qué vale la pena hacer hoy, nada de lo demás importa.

Lección 1 Descubrimiento: escribe un SKILL.md de triaje matutino

Skills, no un muro de indicaciones.

Imagina, es lunes a las 6 a.m. Tu laptop está cerrada y GitHub Action se despierta y ejecuta claude --skill morning-triage: lo que lee, lo que juzga como procesable, dónde escribe los resultados - todo eso vive dentro del SKILL.md que estás a punto de escribir.

La línea clave de Osmani: la automatización debería activar una skill - conocimiento del proyecto escrito y actualizable, no un muro de indicaciones pegado en un cron job. La indicación pegada simplemente se pudre ahí, porque nadie vuelve a actualizar algo enterrado dentro de un horario.

Tu tarea para esta lección: escribe una skill en .claude/skills/morning-triage/SKILL.md que lea tres fuentes (CI / issues / commits) por sí sola, decida qué vale la pena hacer por sí sola, escriba los resultados en ./state/triage.md - y tenga una sección explícita de Stop que detalle lo que el loop NO tiene permitido hacer.

Aquí tienes el punto de partida - cambia tres cosas y es tuyo:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (entradas de descubrimiento — cambia por las fuentes que TU repo realmente tiene)
8- Ejecuciones de CI que fallaron desde la última ejecución      # gh run list --status failure
9- issues abiertos en las últimas 24h               # gh issue list --search "created:>=…"
10- commits fusionados desde ayer              # git log --since=yesterday
11- el ./state/triage.md anterior              # la transferencia "ayer → hoy"
12
13## Judge  (el techo — deja que el loop elija, no le des una lista)
14Para cada candidato, decide:
15- ¿es procesable AHORA, o es ruido?
16- ¿bloquea un lanzamiento? → prioridad = P0
17- ¿ya se está rastreando? → saltar
18Conserva solo lo que vale la pena un worktree HOY.
19
20## Write  (persistencia — plasmar en markdown, no en chat)
21Añade a ./state/triage.md:
22| hallazgo | fuente | prioridad | estado |
23Haz commit del archivo para que mañana pueda leerlo.
24
25## Handoff  (preparación para la Lección 2)
26Para cada hallazgo conservado, emite una línea de tarea:
27  worktree=fix/<slug>
28  goal=<condición-de-parada>
29
30## Stop   (la ÚNICA sección que no es estándar — piensa bien aquí)
31Nunca fusionar. Nunca eliminar.
32Cualquier cosa de la que no estés seguro → ./inbox/ para un humano.
33NO es un PR.

Tres secciones hacen el trabajo real aquí:

Read: esta es la entrada del Descubrimiento - enumera fuentes concretas, hasta el comando real. Recuerda, "leer el contexto" no es una fuente, pero gh run list --status failure sí es una fuente.

Judge: este es el techo de todo tu loop. El loop decide "procesable vs ruido" por sí mismo - no recibe una lista tuya, porque si todavía le estás dando una lista cada mañana, automatizaste el hacer pero no el elegir. Y elegir suele ser el paso más costoso. No importa qué tan buenas sean tus fuentes, si esta sección elige basura, los otros cuatro movimientos están girando en trabajo sin valor.

Stop: la única parte de este archivo que no es estándar. El loop hará todo lo que diga la skill, y solo lo que diga la skill. Si no escribes "nunca fusionar" - un día fusionará por ti.

Detalla las líneas rojas: nunca fusionar, nunca eliminar, nunca hacer push a main, cualquier cosa incierta va a ./inbox/ para un humano, no a un PR.

Una cosa más que vale la pena saber: esta misma estructura de skill funciona más allá del triaje matutino: cambia la sección Read por "registros de acceso de ayer + nuevos issues + versión de despliegue actual" y se convierte en un loop de salud del sitio nocturno. Añade una línea a Judge - "¿es esto una regresión de ayer?" - y crece una comparación entre días.

La enfermedad que esta lección previene - Loop Ciego:

El más común "parece un loop pero no lo es.": el loop se ejecuta, pero todavía estás asignando el trabajo cada mañana ("oye, mira estos tres errores"). Eso es automatización de la ejecución, no automatización del descubrimiento.

Síntoma: el loop nunca te sorprende, porque solo hace lo que ya sabías que había que hacer.

Solución: pon Judge dentro de la skill y deja que elija el trabajo de hoy por sí mismo.

Antes de continuar, responde estas tres:

1/ ¿Cuántas líneas tiene tu sección Stop?

Si es solo "nunca fusionar" - añade una más: ¿qué más debería este loop nunca hacer por ti? (nunca cerrar issues / nunca hacer push a main / nunca tomar más de 3 hallazgos a la vez...)

2/ Reescribe la primera línea de Read en un comando que realmente se ejecute en TU proyecto

**3/ Si esta skill no cambia durante un año - ¿qué sucede?

**Ahora compara: ¿qué le sucede a un muro de indicaciones pegado en un cron job durante un año?

Lección 2 Transferencia: reparte el trabajo y aíslalo

La skill de la Lección 1 acaba de ejecutarse. ./state/triage.md ahora contiene 5 hallazgos procesables. El pensamiento más natural a continuación - ejecutar 5 agentes a la vez, ir rápido. Ese paso exacto es cómo se cultiva un Loop Enredado: varios agentes editando los mismos archivos en el mismo directorio, y el día de la fusión se convierte en arqueología.

El antídoto es una línea: cada hallazgo obtiene su propio worktree.

git worktree es un mecanismo integrado de git: un repositorio, múltiples directorios de trabajo independientes, cada uno en su propia rama. git worktree add ../fix-auth fix/auth abre un espacio de trabajo completamente aislado en ../fix-auth. compilaciones, ediciones, pruebas - nada toca a nadie más. un worktree por hallazgo = agentes físicamente separados.

Tu tarea para esta lección: escribe un script que lea cada hallazgo de ./state/triage.md, abra un worktree aislado por hallazgo (nombrado fix/<slug>), envíe un agente para redactar una solución dentro de él - y establezca un límite de paralelismo para que no se generen infinitamente.

1# leer state/triage.md, un worktree por hallazgo
2# cambiar: MAX_PARALLEL a lo que tu máquina / factura pueda manejar
3MAX_PARALLEL=3
4
5# cambiar: análisis para que coincida con las columnas reales de tu triage.md
6hallazgos=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for hallazgo in $hallazgos; do
10  slug=$(echo "$hallazgo" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # la línea clave: aislamiento físico por agente
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # cambiar: goal es la condición de parada que el evaluador de la Lección 3 leerá
16  claude --worktree ../wt-$slug \
17    --goal "las pruebas en tests/$slug pasan y el lint está limpio" \
18    "redacta una solución para: $hallazgo" &
19done
20
21wait   # deja que todos los agentes paralelos terminen
22
23# regla de cierre: los agentes nunca se auto-fusionan — los worktrees esperan
24# la puerta humana en la Lección 5
25echo "Todos los worktrees listos para revisión:"
26git worktree list

Las reglas que importan aquí: nunca trabajar en main.

Main es la pista de aterrizaje para la revisión humana - no el escritorio de los agentes. Todos los agentes viven en worktrees fix/*.

Limita el paralelismo: la generación ilimitada es la puerta de entrada a una explosión de tokens (la Lección 5 vuelve a esto). elige MAX_PARALLEL basado en una pregunta honesta: no "cuántos puede ejecutar mi máquina" sino "cuántos PRs puedo revisar realmente".

La fusión es una decisión humana: Stripe procesa más de 1,000 PRs a la semana a través de loops como este, y los humanos aún revisan cada uno. El humano no salió del proceso - cambió de escritorio: de escribir código a revisar código.

Y un detalle del caso de Stripe que vale la pena robar: usaron, de manera contraintuitiva, un modelo más pequeño con puertas deterministas estrictas en lugar del modelo más grande disponible.

La lección: una puerta de verificación estricta supera al poder bruto del modelo para el trabajo en loop.

La enfermedad que esta lección previene - Loop Enredado:

Un loop de un solo agente parece perfectamente saludable. El problema solo aparece el día que te vuelves paralelo - cinco agentes se ejecutan, cinco diffs chocan en el mismo archivo, la fusión es un caos.

Solución: cada tarea obtiene su propio worktree, nunca compartas un directorio de trabajo entre agentes.

Antes de continuar, responde estas tres:

**1/ ¿Qué número configuraste para MAX_PARALLEL y por qué?

**(¿dinero? ¿máquina? ¿o "cuántos PRs puedo revisar honestamente"?)

**2/ Si un worktree falla - el agente sale sin tocar nada

**¿qué debería registrar el archivo de estado de mañana sobre él?

**3/ Stripe usó un modelo más pequeño + puertas deterministas estrictas

**En lugar del modelo más grande, ¿qué significa esa elección para TU loop?

Lección 3 Verificación: instala una puerta que diga "no" (la lección más pesada)

Este es el movimiento más difícil en la ingeniería de loops, y merece más esfuerzo que cualquier otra lección.

El ingeniero de Anthropic, Prithvi Rajasekaran, trabajando en aplicaciones agentivas de larga duración, notó algo: pídele a un agente que califique el código que acaba de escribir, y casi siempre se elogiará a sí mismo - incluso cuando un humano puede ver de un vistazo que es mediocre.

Esto no es que el modelo sea tonto: calificar tu propia tarea está estructuralmente roto. Para cuando el código está terminado, el contexto del agente está lleno de la cadena de autojustificación de por qué escribió las cosas de esta manera. Al mirar su propia salida, no ve el resultado - ve el argumento a favor del resultado.

Pon eso dentro de un loop y se amplifica en un desastre: cada turno de "¿es esto suficientemente bueno?" es respondido por el agente que acaba de escribirlo. Cada turno se asiente a sí mismo. Cuanto más tiempo se ejecuta, más se aleja de la calidad real. Ese es el Loop Asentidor - y es la enfermedad más costosa de la lista.

La solución de Rajasekaran, en sus propias palabras:

"Ajustar un evaluador independiente para que sea escéptico es mucho más factible que hacer que un generador sea crítico de su propio trabajo."

Esto es un problema estructural, no un problema de redacción. No puedes pedirle a un autor que salga de su propia cabeza, pero puedes traer a un agente diferente, con instrucciones completamente diferentes, mirando el código desde cero - sin ninguna cadena de autojustificación adjunta.

La analogía proviene de las GANs: una red construye, otra ataca: creador y verificador. La misma vieja regla bancaria: la persona que transfiere el dinero y la persona que lo aprueba deben ser personas diferentes.

Tu tarea para esta lección - escribe dos cosas:

1) Un prompt de sistema de evaluador en .claude/agents/reviewer.md con cinco secciones: ROLE + ASSUME + CHECK + USE + VERDICT.

2) Un comando /goal que declare la condición de parada de este loop - juzgada por un modelo nuevo separado, no por el generador.

1# .claude/agents/reviewer.md  (cambia 3 cosas)
2ROLE: Revisor de código adversarial.
3ASSUME: este código está ROTO hasta que se demuestre lo contrario.
4NO elogies. Encuentra lo que falla.
5
6# cambiar: ordena CHECK por los modos de falla reales de tu proyecto,
7# primero las comprobaciones ejecutables
8CHECK, en orden:
9  1. ¿Funciona?  (ejecutar, no leer)
10  2. Pruebas: ejecútalas, pega la salida real.
11  3. Casos límite que el autor omitió.
12  4. ¿El comportamiento coincide con el ticket?
13
14# cambiar: qué MCP depende de lo que estés probando —
15# frontend → Playwright, API → curl/httpie
16USE Playwright MCP: abre la página, haz clic,
17captura pantalla, inspecciona el DOM.
18Juzga el comportamiento, no la intención.
19
20VERDICT: PASS solo si cada comprobación se cumple.
21         De lo contrario REJECT + enumera cada razón.

1# condición de parada — juzgada por un modelo pequeño nuevo, NO el generador
2# cambiar: cambia por la condición verificable real de tu hallazgo
3/goal todas las pruebas en test/auth pasan y el paso de lint está limpio
4
5# cuidado: /goal y /loop NO son lo mismo
6#   /loop = re-ejecutar en intervalo (sin juicio de parada — peligroso)
7#   /goal = ejecutar hasta que un modelo nuevo juzgue la condición como verdadera

Dos agentes, idealmente dos modelos: "mismo modelo, prompt diferente" a menudo conserva los mismos puntos ciegos. cambia el modelo también si puedes.

Escepticismo por defecto: la línea base del evaluador es ASUMIR ROTO - la confianza debe ganarse pasando comprobaciones, no otorgarse por defecto.

Juzga el comportamiento, no la intención: "este JSX se ve bien" y "hice clic en el botón, la página navegó, aquí está la captura de pantalla" son dos universos diferentes. el evaluador debe actuar - ejecutar las pruebas, hacer clic en la página, no leer el código y tener una corazonada.

Rechazar con razones: un REJECT sin razones enumeradas no es un rechazo - el generador no tiene idea de qué arreglar.

Y la prueba de fuego: ¿tu evaluador ha rechazado realmente algo en los últimos 5+ turnos? Un loop que nunca ha dicho "no" en cientos de turnos es estadísticamente imposible en cualquier carga de trabajo real. Por lo tanto, prueba que el evaluador no está funcionando.

La enfermedad que esta lección previene - Loop Asentidor:

El loop se ejecuta, el agente escribe código, el mismo agente dice "se ve bien." cada turno se autoaprueba, acumulando errores de apariencia plausible a velocidad de máquina. solución: toda esta lección: separación estructural + escepticismo por defecto + juzgar por acción + una condición de parada de terceros.

Antes de continuar, responde estas tres:

1/ ¿Tu evaluador es el mismo modelo con un prompt diferente, o un modelo diferente? ¿por qué?

**2/ Traduce "juzga el comportamiento, no la intención" a una oración concreta de tu proyecto:

"mi evaluador no lee código, ejecuta _____, y solo PASA cuando ve _____"

3/ ¿Qué tan probable es que un modelo nuevo "suficientemente bueno" PASE FALSAMENTE tu condición /goal?

si tu modo de falla más aterrador es X - añade una comprobación para X a la condición de parada ahora mismo

Lección 4 Persistencia: haz que el trabajo de hoy sobreviva hasta mañana

La Lección 3 terminó. tu evaluador juzgó tres hallazgos - dos PASS, uno REJECT. pregunta: ¿dónde viven esos tres veredictos ahora mismo?

si la respuesta es "en la ventana de contexto" - entonces mañana a las 6 a.m., el loop se despierta con un contexto vacío y no recuerda nada. Vuelve a hacer triaje desde cero, tropieza con el REJECT no solucionado de ayer, quizás asigna otro agente para arreglarlo de nuevo, quizás lo pierde por completo, quizás cae en el mismo agujero.

Ese es el Loop Amnésico - cada día comienza desde el mismo punto.

El antídoto en una línea: la memoria es el estado escrito en el disco, no el contexto. un archivo markdown, un tablero de Linear, una base de datos - una vez que está escrito, no importa qué tan a fondo el agente lo olvide.

Estos dos se confunden constantemente, así que fija la diferencia:

CONTEXTO = la ventana que el agente ve ESTE turno -> se borra en cada actualización.

MEMORIA = estado que vive a través de turnos y días -> escrito en el disco (markdown / BD / tablero).

Un loop conecta hoy -> mañana solo a través de la MEMORIA.

Tu tarea para esta lección:

1. Crea ./state/triage.md con al menos 4 columnas (hallazgo / fuente / prioridad / estado) - la skill de la Lección 1 lo escribe, los worktrees de la Lección 2 lo leen.
2. Conecta un conector (MCP): un veredicto PASS abre automáticamente un PR, un REJECT actualiza automáticamente el ticket.
3. Verifica que el loop de mañana pueda leer realmente el estado de hoy.

1# ./state/triage.md  (la memoria del loop — cambiar según sea necesario)
2
3| hallazgo         | fuente       | prioridad | estado     |
4|-----------------|--------------|----------|------------|
5| prueba auth inestable | CI #4821     | P0       | arreglando |
6| desreferencia nula      | issue 92     | P1       | PR abierto    |
7| dependencia obsoleta       | commit a3f9c | P2       | inbox      |
8
9# extiende las columnas según sea necesario: ultima_vista, contador_reintentos, asignado_a
10# este archivo DEBE tener commit en el repositorio —
11# de lo contrario, el ejecutor en la nube de mañana no puede verlo

1// .mcp/connectors.json — conecta el loop con el mundo exterior
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← DEBE ser false. puerta humana = Lección 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Bloqueado", "reason": "${verdict.reasons}" }
15  }
16}

Por qué cada columna importa: sin fuente -> no puedes auditar de dónde vino un hallazgo. sin prioridad -> no puedes ordenar el trabajo. sin estado -> mañana no puede tomar el relevo.

Y la verificación para esta lección es la única que no puedes fingir: espera hasta mañana. Despierta, verifica - ¿el inbox sigue ahí? ¿Los hallazgos incompletos aún mantienen su estado? ¿La ejecución de las 6 a.m. retomó donde terminó ayer en lugar de empezar de nuevo? Esta la descubres ejecutándola, no razonando sobre ella.

Una disciplina silenciosa que viene con la persistencia - lee una muestra, siempre.

Una vez que la persistencia funciona, se abre una trampa: el loop envía PRs a velocidad, te sientes productivo - y tu mapa mental del código base se desactualiza silenciosamente. la regla: no leas todo (eso anula el propósito del loop), pero lee un PR de muestra al día y oblígate a explicar qué cambió el loop y por qué.

En el momento en que no puedas explicarlo - tu mapa se ha quedado atrás. Arreglar eso en una mañana tranquila cuesta diez minutos. Arreglarlo durante un incidente de producción cuesta mucho más.

La enfermedad que esta lección previene - Loop Amnésico:

El loop encuentra buen trabajo, lo hace, luego olvida que lo hizo - porque el resultado solo vivió en un contexto vaciado. El siguiente turno redescubre el mismo trabajo, o peor - lo rehace y sobrescribe el primer intento.

Síntoma: sin progreso acumulado, cada día comienza desde el mismo lugar. Solución: archivo de estado en el disco.

Antes de continuar, responde estas tres:

1/ Traduce "memoria ≠ contexto" a una oración concreta

de tu propio proyecto: "mi _____ es memoria, mi _____ es contexto"

**2/ El loop de mañana se despierta - ¿qué COLUMNA de state.md

**lee primero para decidir su primer movimiento? ¿nombres esa columna correctamente, o acabas de enterrar una mina terrestre para él?

**3/ Disciplina: ¿a qué hora del día leerás tu

**PR de muestra? configura el recordatorio del calendario ahora mismo - esto es un contrato contigo mismo.

Lección 5 Programación: hazlo real, hazlo seguro, mantén una puerta abierta

Las Lecciones 1-4 están instaladas, pero el loop aún se detiene en el momento en que dejas de presionar el botón. El movimiento final es un verbo: cuélgalo de un disparador.

Pero la parte más peligrosa de esta lección no es equivocarse con cron. Es hacer cron bien - porque entonces el loop realmente funciona solo, y un error puede hacer que gire toda la noche, ayudantes generando ayudantes, hasta que te despiertes con una factura que no reconoces.

Así que esta lección en realidad hace tres cosas: cuelga el disparador, establece los límites, mantén una puerta humana.

Primero - elige tu programador:

1Nube (GH Actions)   Escritorio programado   /loop (en CC)
2se ejecuta en          nube                tu máquina        tu máquina
3¿máquina encendida?         no necesario           necesario              necesario
4¿sesión abierta?       no necesario           no necesario          necesario
5intervalo mínimo        1 hora               1 minuto            1 minuto
6¿ve archivos locales?   no                   sí                 sí

La pregunta decisiva: ¿puede este trabajo salir de tu laptop?

1"revisar mi servidor de desarrollo local cada minuto"
2   → debe ser local + /loop (el intervalo de 1 hora de la nube no puede alcanzarlo)
3
4"escanear issues de GitHub a las 3 a.m. y abrir PRs"
5   → debe ser nube (tu laptop está cerrada — el loop no puede
6     estar esperándola)

Y el autoengaño más sigiloso de toda la práctica: tratar un temporizador local como "funcionando mientras duermes". No lo es. es "ejecutando algunos turnos extra mientras todavía estoy cerca."

Tu tarea para esta lección:

1. Escribe .github/workflows/triage.yml con un disparador cron que ejecute la habilidad morning-triage.
2. Establece tres límites: presupuesto por ejecución, presupuesto diario y reintentos máximos.
3. Finaliza el flujo de trabajo con la regla: los PR nunca se auto-fusionan, cualquier cosa incierta va a ./inbox/.

1# .github/workflows/triage.yml  (cambia 3 cosas)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # cambia: las 06:00 de tu zona horaria en UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← límite por ejecución · cambia
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← límite diario · cambia
22          MAX_RETRIES: '3'          # ← límite de reintentos · cambia
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: abrir PRs (NUNCA auto-fusionar)
29        run: |
30          # Los PRs se abren automáticamente. La fusión sigue siendo humana.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # no hay `gh pr merge` aquí — a propósito
35
36      - name: enrutar lo incierto a la bandeja de entrada
37        run: |
38          ls ./inbox/ && echo "elementos esperando revisión humana"

Las tres reglas que lo mantienen vivo al sexto mes:

Pon límites antes de lanzar: tres niveles - tiempo de espera por ejecución, presupuesto diario, reintentos máximos - establecidos antes de la primera ejecución autónoma, no después de la primera factura aterradora. Un límite de tokens no se trata de ahorrar dinero. Es un cortacircuitos que convierte el riesgo abierto en riesgo acotado. Un bucle sin límites ha delegado su autoridad de gasto a sus propios errores.

Para que te des una idea: Uber limitó a los ingenieros a $1,500 por persona por herramienta por mes después de quemar su presupuesto de IA en cuatro meses. Tu límite por bucle es la versión granular de esa lección.

Mantén una puerta abierta: los PR no se auto-fusionan. Los elementos inciertos caen en la bandeja de entrada. Lees una muestra al día. La puerta no está ahí porque un humano siempre la va a cruzar, está ahí porque el hecho de que la puerta exista te mantiene en una posición donde puedes hacerlo. Suelda cada puerta, y el día que necesites entrar, habrás perdido la llave.

Verifica que realmente se active. Ejecútalo al menos 3 veces (las ejecuciones de prueba cuentan). El fallo más común: deslumbrante el día de la demostración, muerto para el jueves. "La última ejecución fue el día de la demo" es la firma diagnóstica de un Bucle Manual.

Funciona igual fuera de Claude Code - las capacidades no están atadas a un proveedor, solo renombradas:

1CAPACIDAD            Claude Code          Codex
2programación         /loop · worker       pestaña Automations
3ejecutar hasta condición  /goal           re-ejecución automática + juez
4aislamiento paralelo --worktree           worktree en segundo plano
5sub-agentes          .claude/agents/      .codex/agents/
6conexión externa     MCP + plugins        conector MCP
7habilidad explícita  SKILL.md             $skill-name
8ejecución sin PC     Cloud Routines       nube (planeado)

La pregunta nunca fue "qué proveedor". Es "¿están instaladas las seis capacidades?".

La enfermedad que esta lección previene - Bucle Manual:

Cuatro movimientos construidos hermosamente, sin cron. No es un bucle - es un script que ejecutaste una vez y olvidaste.

Solución: cuelga cualquier disparador que no dependa de que tú lo recuerdes.

Antes de lanzar, responde estas tres:

1/ ¿Cuáles son los números exactos de tus tres límites?

Si un error gira toda la noche - ¿qué límite rompe la caída primero? Si ninguno lo hiciera... ¿qué te dice eso?

2/ ¿Cómo se ve tu puerta humana?

(¿Revisión de PR / bandeja de entrada / muestra diaria / conciliación semanal?) Escríbelo = firma el contrato contigo mismo.

3/ La pregunta final: dentro de seis meses, ¿este bucle te habrá hecho más fuerte (comprensión, criterio, sentir el sistema) - o te habrá convertido en el cuidador de una máquina que no puedes leer? ¿Cuál es tu plan para evitar lo segundo?

Las 4 deudas y seguir siendo el ingeniero

Tu bucle está construido: se despierta, encuentra trabajo, se critica a sí mismo, recuerda y programa su propio mañana.

Mientras un bucle se ejecuta, cuatro cosas se acumulan silenciosamente - y su rasgo compartido es que ninguna de ellas activa una alarma.

1DEUDA DE VERIFICACIÓN     salida no rechazada acumulándose
2DETERIORO DE COMPRENSIÓN  la base de código crece, tu mapa mental no
3RENDICIÓN COGNITIVA       "ya no tengo ganas de escudriñar"
4EXPLOSIÓN DE TOKENS       un error gira toda la noche → lo ves como una factura

Se alimentan entre sí: la salida no verificada erosiona tu comprensión -> la comprensión erosionada invita a la rendición -> la rendición deja que el bucle funcione más tiempo y gaste más -> lo que produce más salida no verificada.

Audita tu nuevo bucle contra las cuatro antes de su primera ejecución en solitario:

• Mi evaluador realmente rechaza - no es decoración.
• Leo una muestra de PR al día y puedo explicar qué cambió.
• Mantuve el hábito de decir "esto está mal".
• Mis límites se establecieron ANTES de la primera ejecución, no después de la primera factura.

Y aquí está la parte que lo decide todo:

El mismo bucle, construido por dos personas, puede terminar en lugares opuestos. Uno lo usa para moverse más rápido mientras aún lee el código y mantiene la dirección - el bucle amplifica el criterio que ya tiene.

El otro usa exactamente el mismo bucle específicamente para no entender nunca nada otra vez - seis meses después, el primero es más agudo, y el segundo es un cuidador de una máquina que no puede leer.

Addy Osmani: "construye el bucle, pero constrúyelo como alguien que tiene la intención de seguir siendo el ingeniero - no solo la persona que presiona 'iniciar'".

Los bucles hacen que la generación sea casi gratuita, lo que sigue siendo escaso es el criterio: qué plan es correcto, en qué línea detenerse, qué cosa funciona pero está mal en su raíz. El bucle no devalúa el criterio - despoja todo lo que no es criterio, y deja solo eso.

Un bucle es un multiplicador fiel:

Trae comprensión - amplifica la comprensión.

Trae pereza - amplifica la pereza.

Decide qué quieres que se amplifique - antes de construirlo.

¡Mantente al tanto!

Buena suerte :)