Ingeniería de bucles (Loop Engineering): 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 situó 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 bucle 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 bucles que se están ejecutando. Son ellos los que le dan indicaciones a Claude y descubren qué hacer.

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

La práctica precedió al nombre por meses; todo el mundo ya estaba escribiendo bucles, pero nadie les había puesto nombre todavía.

Por lo tanto, los bucles 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 bucles del más interno al más externo según sus escalas de tiempo: el bucle más interno es el más rápido y el más externo es el más lento. Además, la entrada del bucle más externo proviene de la salida del bucle más interno:

Bucle

Quién lo ejecuta

Duración del ciclo

Qué produce para la capa externa

Bucle de codificación del agente

el propio agente

segundos - minutos

una versión que funciona

Bucle de retroalimentación del desarrollador

humano + agente

decenas de minutos - horas

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

Bucle de retroalimentación externa

usuarios + equipo

horas - semanas

datos reales que evolucionan la visión

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

La ingeniería de bucles 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 bucle, no la misma tarea ejecutada N veces.

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

Capa

Qué le importa

Pregunta central

Ingeniería de indicaciones

escribir una indicación

qué decirle al modelo

Ingeniería de contexto

qué está cargado en la ventana

qué extraer, resumir, limpiar

Ingeniería del arnés

preparar una sola ejecución

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

Ingeniería de bucles

programación sobre el arnés

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

Un bucle 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:

"Bucle" se malinterpreta como "girar en el mismo sitio". No lo es; cada turno tiene 5 movimientos concretos. Elimina cualquiera y el bucle no se ejecutará, o se ejecutará 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 bucle.

Mapeado al proyecto que vamos a construir: un bucle de clasificación matutina para un equipo pequeño:

Acción

Qué hace

EN EL BUCLE DE CLASIFICACIÓN

Descubrimiento

descubrir qué debe hacer este turno

una habilidad lee CI / issues / commits recientes

Transferencia

despachar la tarea y aislarla

cada hallazgo obtiene su propio worktree

Verificación

intercambiar con otro agente para que diga no

un segundo subagente como revisor, probando tests y habilidades

Persistencia

escribir el estado fuera de la conversación

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

Programación

dejar que se ejecute turno tras turno

el cron de GitHub Actions se activa a las 06:00

Cada una de las 5 lecciones siguientes desarrolla exactamente un movimiento.

Cinco lecciones = un bucle completo.

Y empezamos con la primera: Descubrimiento, porque si el bucle no puede decidir qué vale la pena hacer hoy, nada de lo que sigue importa.

Lección 1 Descubrimiento: escribe un SKILL.md de clasificación matutina

Habilidades, no un muro de indicaciones.

Imagina que es lunes a las 6 a. m. Tu portátil está cerrado 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 frase clave de Osmani: la automatización debería activar una habilidad: conocimiento del proyecto escrito y actualizable, no un muro de indicaciones pegado en un trabajo cron. La indicación pegada simplemente se pudre allí, porque nadie vuelve a actualizar algo enterrado dentro de un horario.

Tu tarea para esta lección: escribe una habilidad 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 bucle 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 repositorio realmente tenga)
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              # el traspaso de "ayer → hoy"
12
13## Judge  (el techo — deja que el bucle 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 tener un worktree HOY.
19
20## Write  (persistencia — plasmar en markdown, no en el 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í lo es.

Judge: este es el techo de todo tu bucle. El bucle 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 lo buenas que sean tus fuentes, si esta sección elige basura, los otros cuatro movimientos están girando sobre trabajo sin valor.

Stop: la única parte de este archivo que no es estándar. El bucle hará todo lo que dice la habilidad, y solo lo que dice la habilidad. Si no escribes "nunca fusionar" - un día lo 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 habilidad funciona más allá de la clasificación matutina: cambia la sección Read por "registros de acceso de ayer + nuevos issues + versión de despliegue actual" y se convierte en un bucle de salud del sitio nocturno. Añade una línea a Judge - "¿es esto una regresión de ayer?" - y desarrolla una comparación entre días.

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

El más común "parece un bucle pero no lo es": el bucle 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 bucle nunca te sorprende, porque solo hace lo que ya sabías que había que hacer.

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

Antes de continuar, responde estas tres preguntas:

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

Si es solo "nunca fusionar" - añade una más: ¿qué otra cosa no debería hacer nunca este bucle 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 habilidad permanece sin cambios durante un año - ¿qué sucede?

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

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

La habilidad de la Lección 1 acaba de ejecutarse. ./state/triage.md ahora contiene 5 hallazgos procesables. El pensamiento más natural a continuación: lanzar 5 agentes a la vez, ir rápido. Ese paso exacto es cómo se cultiva un Bucle 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 verificado 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 (llamado fix/<slug>), envíe un agente para redactar una solución dentro de él, y establezca un límite paralelo para que no se generen infinitamente.

1# read state/triage.md, un worktree por hallazgo
2# cambia: MAX_PARALLEL a lo que tu máquina / factura pueda manejar
3MAX_PARALLEL=3
4
5# cambia: el análisis para que coincida con las columnas de tu triage.md real
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | 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  # cambia: goal es la condición de parada que el evaluador de la Lección 3 leerá
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "draft a fix for: $finding" &
19done
20
21wait   # espera a 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 basándote 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 ejecuta más de 1,000 PRs a la semana a través de bucles como este, y los humanos aún revisan cada uno. El humano no abandonó el proceso, cambió de escritorio: de escribir código a revisar código.

Y un detalle del caso de Stripe que vale la pena copiar: 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 bucle.

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

Un bucle 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 compartir un directorio de trabajo entre agentes.

Antes de continuar, responde estas tres preguntas:

**1/ ¿Qué número estableciste 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 ello?

**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 bucle?

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 bucles, y merece más esfuerzo que cualquier otra lección.

El ingeniero de Anthropic, Prithvi Rajasekaran, trabajando en aplicaciones de agentes 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 propio trabajo está estructuralmente roto. Para cuando el código está listo, 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 para el resultado.

Pon eso dentro de un bucle y se amplifica en un desastre: cada turno responde a "¿es esto suficientemente bueno?" con 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 Bucle de Asentimiento - 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 GAN: 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) Una indicación 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 bucle - 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# cambia: ordena CHECK por los modos de fallo reales de tu proyecto,
7# primero las comprobaciones ejecutables
8CHECK, en orden:
9  1. ¿Se ejecuta?  (ejecuta, no leas)
10  2. Tests: ejecútalos, pega la salida real.
11  3. Casos límite que el autor omitió.
12  4. ¿El comportamiento coincide con el ticket?
13
14# cambia: 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 la 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 por el generador
2# cambia: por la condición real verificable de tu hallazgo
3/goal all tests in test/auth pass and the lint step is clean
4
5# cuidado: /loop y /goal 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, diferente indicación" a menudo conserva los mismos puntos ciegos. Cambia también el modelo si puedes.

Escepticismo por defecto: la línea de base del evaluador es ASUMIR ROTO - la confianza debe ganarse pasando las comprobaciones, no concederse 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 los tests, hacer clic en la página, no leer el código y tener una corazonada.

Rechaza con razones: un RECHAZO 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 bucle que nunca ha dicho "no" a lo largo de cientos de turnos es estadísticamente imposible en cualquier carga de trabajo real. Por lo tanto, demuestra que el evaluador no está funcionando.

La enfermedad que esta lección previene - Bucle de Asentimiento:

El bucle 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 preguntas:

1/ ¿Tu evaluador es el mismo modelo con una indicación 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é probabilidad hay de que un modelo nuevo "suficientemente cercano" PASE FALSAMENTE tu condición /goal?

si tu modo de fallo 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 bucle se despierta con un contexto vaciado y no recuerda nada. Vuelve a clasificar desde cero, se topa con el RECHAZO 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 Bucle 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 cuán a fondo el agente 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 = el estado que vive a través de turnos y días -> se escribe en el disco (markdown / DB / tablero).

Un bucle puentea hoy -> mañana a través de la MEMORIA solamente.

Tu tarea para esta lección:

1. Crea ./state/triage.md con al menos 4 columnas (hallazgo / fuente / prioridad / estado) - la habilidad 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 bucle de mañana pueda leer realmente el estado de hoy.

1# ./state/triage.md  (la memoria del bucle — cambia según sea necesario)
2
3| hallazgo         | fuente       | prioridad | estado     |
4|-----------------|--------------|----------|------------|
5| auth test flaky | CI #4821     | P0       | arreglando |
6| null deref      | issue 92     | P1       | PR abierto |
7| stale dep       | 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 bucle 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 falso. puerta humana = Lección 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "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. Despiértate, comprueba: ¿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 bucle 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 bucle), pero lee un PR de muestra al día y oblígate a explicar qué cambió el bucle y por qué.

En el momento en que no puedas explicarlo - tu mapa se ha quedado atrás. Arreglarlo 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 - Bucle Amnésico:

El bucle 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 preguntas:

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

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

**2/ El bucle 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? establece el recordatorio del calendario ahora - 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 bucle 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 acertar con cron correctamente - porque entonces el bucle realmente se ejecuta solo, y un error puede hacer que gire toda la noche, ayudantes generando ayudantes, hasta que te despiertes con una factura que no reconoces.

Por lo tanto, esta lección realmente hace tres cosas: cuelga el disparador, establece los límites, mantén una puerta humana.

Primero - elige tu programador:

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

La pregunta decisiva: ¿puede este trabajo salir de tu portátil?

1"revisa 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"escanea issues de GitHub a las 3 a. m. y abre PRs"
5   → debe ser en la nube (tu portátil está cerrado — el bucle no puede
6     estar esperándolo)

Y el autoengaño más astuto en toda la práctica: tratar un temporizador local como "ejecutándose 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 fusionan automáticamente, 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 fusionar automáticamente)
29        run: |
30          # Los PRs se abren automáticamente. La fusión sigue siendo humana.
31          gh pr create --draft --base main \
32            --title "[bucle] $(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 interruptor automático que convierte el riesgo abierto en riesgo acotado. Un bucle sin límites ha externalizado su autoridad de gasto a sus propios errores.

Para que te hagas una idea: Uber limitó a los ingenieros a $1,500 por persona por herramienta al 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 PRs no se fusionan automáticamente. 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 despierte. Ejecútalo al menos 3 turnos (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 que se demostró" es la señal de diagnóstico 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 de automatización + 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 máquina  Cloud Routines     nube (planeado)

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

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

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

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

Antes de lanzar, responde estas tres preguntas:

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 es 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, juicio, sensibilidad por 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 los cuatro antes de su primera ejecución en solitario:

• Mi evaluador realmente rechaza - no es decoración.
• Leo un PR de muestra 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 juicio que ya tiene.

El otro usa exactamente el mismo bucle específicamente para no volver a entender nada nunca más - 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 'ir'."

Los bucles hacen que la generación sea casi gratuita, lo que sigue siendo escaso es el juicio: qué plan es correcto, en qué línea detenerse, qué cosa funciona pero está mal de raíz. El bucle no devalúa el juicio - despoja todo lo que no es juicio, 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 amplificar - antes de construirlo.

¡Mantente atento!

Buena suerte :)