Lección 13 — Del prompting manual a los loops autónomos

Todo lo que aprendiste en las doce lecciones anteriores se apoya en un supuesto: estás sentado frente al teclado, escribiendo instrucciones una por una.

Escribiste AGENTS.md (lecciones 1-4), construiste gestión del estado (5-6), limitaste el alcance con listas de funciones (7-8), dejaste handoffs limpios (9, 12) e hiciste el runtime observable (10-11). Pero el disparador de todo siempre fuiste vos. El agente nunca decidía por sí mismo cuándo empezar a trabajar, porque nadie apretaba “inicio”.

Esta lección trata sobre entregarle el botón de inicio al sistema. No se trata de renunciar al control: se trata de elevarlo al nivel siguiente.

/goal: el loop más simple posible

La mejor entrada al loop engineering no es un diagrama de arquitectura complejo, es un solo comando.

A principios de 2026, Claude Code y OpenAI Codex lanzaron independientemente la misma característica: /goal. Escribís en la terminal:

/goal "Todos los tests pasan, cero warnings de lint, merge a main"

Después cerrás la laptop y te vas a dormir. Ocho horas más tarde, el agente analizó, codeó, testeó, corrigió y fusionó por su cuenta. Reintenta ante fallos, cambia de enfoque cuando se atasca, y se detiene cuando termina.

	Prompt tradicional	/goal
Lo que proporcionás	Qué hacer a continuación	Cómo se ve el estado final
Lo que hace el agente	Ejecuta una vez	Itera hasta lograrlo
Quién juzga si está terminado	Vos	Una condición de parada verificable
Cuándo te podés ir	No podés	En el momento en que escribís /goal

/goal es esencialmente un loop. Tiene exactamente tres partes: un objetivo, un método de verificación y una condición de parada. Solo esas tres cosas te mueven de estar dentro del loop a estar afuera.

Cómo creció /goal orgánicamente

flowchart TD
    E1["Etapa 1 — Prompting manual<br/>«escribí una función», «agregá un test»<br/>Vos sos el planificador"] --> E2["Etapa 2 — Prompts largos multipaso<br/>«analizá, implementá, testeá, corregí»<br/>Todavía hay que vigilar"]
    E2 --> E3["Etapa 3 — Autorreflexión del agente<br/>Mira el resultado y decide el paso siguiente<br/>Problema: ¿cuándo se detiene?"]
    E3 --> E4["Etapa 4 — Juicio de parada independiente<br/>/goal: un juez separado decide<br/>«el que escribe el código no se corrige el examen»"]

Estas cuatro etapas no fueron una hoja de ruta planificada por ninguna empresa. Fueron el camino al que llegó todo el mundo que codea con agentes, de forma independiente, empujado por los mismos puntos de dolor. Que Claude Code y Codex lanzaran /goal casi simultáneamente no fue casualidad: había llegado el momento.

Hay más de un tipo de loop

Tipo	Disparador	Condición de parada	Claude Code	Codex	Mejor para
Basado en turnos	Escribís cada prompt manualmente	El agente cree que terminó, o lo interrumpís	Chat normal	Chat normal	Tareas chicas, trabajo exploratorio
Basado en objetivo	Das un objetivo	Evaluador independiente confirma, o se alcanzan los turnos máximos	/goal	/goal	Tareas complejas con criterios de finalización claros
Basado en tiempo	Intervalo programado	Lo detenés manualmente, o sale al completar	/loop	Thread automation	Consultar estado, verificaciones periódicas
Impulsado por eventos	Evento externo (PR abierto, CI fallido)	Se detiene tras manejar el evento	Routines (API / webhook)	Standalone automation	Flujos reactivos, integración CI/CD

No confundas /goal con /loop

	/goal	/loop
Qué es	Una tarea grande, se ejecuta hasta que termina	Una acción chica, se repite en un intervalo
Condición de parada	Objetivo alcanzado o presupuesto agotado	Lo detenés vos, o la tarea sale sola
Perfil temporal	Una ejecución larga, horas o días	Ráfagas cortas periódicas
Progreso	Se acerca más a la meta en cada iteración	Cada ejecución es independiente
Analogía	Correr un maratón	Un despertador
Uso típico	”Implementar el sistema de pagos completo con tests"	"Chequear si la CI está rota cada 15 minutos”

Un error común: meter algo que debería ser un /goal en un /loop. Escribir /loop 10m "seguí implementando el sistema de pagos" está mal: /loop ejecuta la misma instrucción independientemente cada vez, no recuerda dónde quedó.

Prueba de una frase: ¿esta cosa tiene un final? Tiene final → /goal. No tiene final, solo necesitás seguir vigilando → /loop.

Junio de 2026: tres personas encendieron la mecha en una semana

En la primera semana de junio de 2026, tres profesionales que construían infraestructura de agentes de programación —sin coordinarse— dijeron lo mismo con palabras distintas.

Peter Steinberger (creador de OpenClaw): “Ya no deberías estar haciendo prompting a agentes de codificación. Deberías estar diseñando loops que hacen prompting a tus agentes.”

Boris Cherny (jefe de Claude Code en Anthropic): “Ya no le hago prompting a Claude. Tengo loops corriendo que le hacen prompting a Claude y descubren qué hacer. Mi trabajo es escribir loops.”

Addy Osmani (líder de ingeniería en Google Chrome) nombró el concepto el 7 de junio de 2026:

Loop engineering es reemplazarte a vos mismo como la persona que hace prompting al agente. Diseñás el sistema que lo hace en tu lugar.

Cherny reveló cifras: durante más de 30 días consecutivos, todas las contribuciones de código a Claude Code fueron realizadas autónomamente por IA —259 PRs fusionados, más del 80% del código de producción autorado por Claude, y una tasa de éxito del 76% en tareas de software abiertas—.

Tres personas, una semana, la misma conclusión. No porque se coordinaran, sino porque la infraestructura había cruzado silenciosamente un umbral: los agentes se habían vuelto lo suficientemente confiables, las primitivas de planificación estaban integradas en las herramientas y el costo de una sola ejecución había bajado lo suficiente.

Fuente: Addy Osmani — Loop Engineering

Dentro del loop vs. fuera del loop

Escenario A: estás dentro del loop (lecciones 1-12). Tenés un harness completo: AGENTS.md con las reglas, feature_list.json limitando el alcance, init.sh para un entorno consistente, PROGRESS.md registrando el avance. Pero cada paso todavía requiere tu iniciación manual. Vos sos el motor del flujo.

Escenario B: estás fuera del loop. Ya no escribís instrucciones. El sistema que diseñaste descubre el trabajo, lo despacha, verifica los resultados, registra el estado y decide el paso siguiente. Tu trabajo se reduce a tres cosas: definir el objetivo y la condición de parada antes de que empiece, revisar la salida después de que termine, y ajustar las reglas cuando el sistema se desvíe.

Las seis primitivas de un loop

flowchart TB
    A["1. Automations<br/>el latido"] --> W["2. Worktrees<br/>aislamiento a escala"]
    W --> SK["3. Skills<br/>dejar de re-explicar el proyecto"]
    SK --> CO["4. Connectors<br/>tocar herramientas reales"]
    CO --> SU["5. Sub-agentes<br/>maker lejos del checker"]
    SU --> A
    ES[("6. Estado externo<br/>la memoria del loop")]
    A -.lee y escribe.-> ES
    W -.lee y escribe.-> ES
    SK -.lee y escribe.-> ES
    CO -.lee y escribe.-> ES
    SU -.lee y escribe.-> ES

El estado externo no es una parada más del loop: es la base sobre la que descansa todo el loop.

1. Automations — el latido

Sin automatización, un loop no es un loop: es una ejecución única que hiciste a mano.

Capa	Claude Code	Codex	Notas
Sondeo en sesión	/loop	Thread automation	Vinculado a la sesión, muere al cerrarla
Tareas programadas locales	Tareas programadas de escritorio	Standalone automation (local)	Corre mientras la máquina está encendida
Tareas programadas en la nube	Cloud Routines	—	Corre con la máquina apagada
Disparadores de eventos	Routines (API / GitHub Webhook)	Standalone automation + plugins	Activados por eventos externos
Totalmente autohospedado	GitHub Actions / cron propio	codex exec + cron	Control total

# Claude Code: correr los tests cada 30 min y arreglar fallos (dentro de la sesión)
/loop 30m Corré la suite de tests y arreglá los que fallen

# Claude Code: chequear el estado del deploy cada 15 minutos
/loop 15m Verificá si el deploy de producción tuvo éxito y reportá el estado

2. Worktrees — aislamiento a escala

En cuanto ejecutás más de un agente, las colisiones de archivos se vuelven el modo de fallo inevitable. git worktree lo resuelve: cada agente trabaja en su propia rama en su propio directorio, y físicamente no pueden tocar el checkout del otro.

Los worktrees eliminan el problema mecánico de colisión, pero recordá: tu ancho de banda de revisión sigue siendo el techo.

3. Skills — dejá de re-explicar tu proyecto

Un skill es una carpeta con un SKILL.md que contiene instrucciones y metadatos, más scripts, referencias y assets opcionales. Se invocan directamente con /nombre-del-skill o se activan implícitamente cuando la tarea coincide con la descripción.

Los skills son fundamentalmente sobre pagar tu deuda de intención. Un agente empieza cada sesión en frío y llena cualquier hueco en tu intención con una suposición segura. Un skill es esa intención escrita por fuera: las convenciones, los pasos de compilación, el “no lo hacemos así por aquel incidente”, escritos una vez y leídos en cada ejecución.

4. Connectors — tu loop toca herramientas reales

Un loop que solo puede ver el sistema de archivos es un loop chico. Los connectors (construidos sobre MCP) permiten al agente leer tu tracker de issues, consultar una base de datos, llamar a una API de staging o dejar un mensaje en un canal.

Son la diferencia entre “acá está la solución” y un loop que abre el PR, enlaza el ticket y avisa al canal una vez que la CI está en verde.

5. Sub-agentes — mantené al maker lejos del checker

La elección de diseño con mayor valor estructural en un loop es separar a quien escribe de quien verifica.

flowchart LR
    P["Planner<br/>expande requisitos<br/>y arma el contrato"] --> G["Generator<br/>implementa función<br/>por función"]
    G --> E["Evaluator<br/>sesión nueva, contexto limpio<br/>verifica con evidencia"]
    E -->|falla, con feedback concreto| G
    E -->|pasa| D["Merge / entrega"]

El /goal de Claude Code ejecuta esto por debajo: una sesión nueva e independiente juzga si el loop debe detenerse, no la sesión que hizo el trabajo.

6. Estado externo — la memoria del loop

Los modelos olvidan todo entre ejecuciones. La memoria debe vivir en el disco, no en la ventana de contexto. Un archivo markdown, un tablero de issues: cualquier cosa que viva fuera de una sola conversación y mantenga lo hecho, lo en progreso y lo que sigue. El agente olvida. El repositorio no.

Un loop completo, anatomizado

flowchart TD
    CRON["Cron 8:00 AM"] --> DISC["Descubrir trabajo<br/>issues nuevas, CI roja, PRs sin revisar"]
    DISC --> STATE[("Estado externo<br/>loop-state.md")]
    STATE --> DISP["Despachar<br/>un worktree por ítem"]
    DISP --> MK["Maker<br/>implementa el fix"]
    MK --> CK["Checker<br/>verifica de forma independiente"]
    CK -->|falla| MK
    CK -->|pasa| PR["Abrir PR + enlazar ticket<br/>vía connectors"]
    PR --> TRI["Bandeja de triage<br/>lo que necesita tu decisión"]
    TRI --> STATE
    TRI --> HUM["Vos: revisar, decidir,<br/>refinar skills y reglas"]

Esto ya no es una sola ejecución de agente: es un sistema que opera continuamente, se despierta cada mañana, barre el piso solo y pone frente a vos las cosas que necesitan tu atención.

Separación generador/evaluador

Esta es la lección más difícil de tragar en loop engineering.

Tu agente más inteligente escribe un pedazo de código hermoso. La lógica es clara, los comentarios exhaustivos, cada función tiene un test. Estás satisfecho. Pero: si dejás que el agente que escribió ese código juzgue si hizo un buen trabajo, ¿qué va a decir?

Se va a dar una nota alta. No por deshonesto, sino porque es el autor: se convenció a sí mismo de que ese camino era correcto durante la generación. Cuando mira atrás no ve errores, ve su propio proceso de razonamiento.

Esto no es un problema de un modelo particular. Es una propiedad de todos los modelos generativos. Un modelo es el mejor abogado defensor de su propia salida.

La solución: nunca dejes que la misma entidad —mismo modelo, mismo prompt— haga el trabajo y la revisión.

• El /goal de Claude Code usa una sesión supervisora independiente.
• El sistema de subagentes de Codex permite definir un verificador con un modelo distinto y distinto esfuerzo de razonamiento.
• La práctica de adversarial verify genera N escépticos independientes por hallazgo, cada uno con la instrucción de refutarlo; el rechazo por mayoría mata el hallazgo.

Una frase para recordar: alguien en tu equipo no debe creerte.

El autoresearch de Karpathy: el ejemplo de manual

En marzo de 2026, Karpathy publicó un proyecto Python de 630 líneas. Le das una GPU y una dirección de investigación, corre toda la noche completando cientos de experimentos de entrenamiento de ML y se queda solo con los que realmente mejoran. Alcanzó más de 66.000 estrellas en pocos días.

Tres archivos, tres roles

Archivo	Quién lo edita	Qué hace
prepare.py	Nadie (solo lectura)	Preparación de datos, tokenizador, harness de evaluación. Infraestructura fija.
train.py (~630 líneas)	El agente	Definición del modelo, optimizador, loop de entrenamiento. El patio de juegos del agente.
program.md	Vos	Metodología de investigación en lenguaje natural. Cómo explorar, cómo evaluar, qué no tocar.

Esta división de tres vías es el alma del diseño: los humanos no tocan el código, tocan la dirección; los agentes no tocan la dirección, tocan el código.

Qué contiene program.md

program.md es el cerebro del loop. No es código, es un manual de metodología escrito en Markdown:

• Objetivo: optimizar val_bpb (bits por byte de validación, menor es mejor)
• Restricciones: no tocar prepare.py, mantenerse dentro del presupuesto de VRAM, entrenamiento fijo de 5 minutos
• Direcciones de exploración: probar distintas arquitecturas, optimizadores, schedules de learning rate
• Reglas de evaluación: qué cuenta como mejora, cómo registrar resultados, qué hacer ante fallos
• Regla de hierro: nunca te detengas; una vez que el loop empieza, sigue

Tu prompt de arranque puede ser una sola oración: “Mirá program.md y arranquemos un experimento nuevo”.

El ratchet de nueve pasos

flowchart TD
    A["1. Leer program.md<br/>y results.tsv"] --> B["2. Elegir la próxima<br/>hipótesis"]
    B --> C["3. Modificar train.py"]
    C --> D["4. Entrenar<br/>5 min exactos"]
    D --> E["5. Medir val_bpb"]
    E --> F{"6. ¿Mejoró<br/>respecto al mejor?"}
    F -->|Sí| G["7. Commit<br/>el ratchet avanza"]
    F -->|No| H["7'. Revert<br/>el ratchet no retrocede"]
    G --> I["8. Registrar en results.tsv"]
    H --> I
    I --> J["9. Escribir la nota<br/>de investigación"]
    J --> A

Ejecuta aproximadamente 12 experimentos por hora. Una corrida nocturna de 8 horas son unos 100 experimentos. El presupuesto fijo de 5 minutos es una elección de diseño clave: sin importar qué cambie el agente, cada experimento toma exactamente el mismo tiempo, así que todos los resultados son directamente comparables.

Qué encontró realmente

De la corrida inicial de 2 días y ~700 experimentos de Karpathy:

• De ~700 intentos, aproximadamente 20 mejoras reales acumulables
• Redujo el tiempo de entrenamiento a nivel GPT-2 de nanochat en 8×H100 de 2,02 h a 1,80 h, alrededor de 11% más rápido

¿Fueron todas descubrimientos trascendentales? No. La mayoría fueron optimizaciones chicas que se acumularon. Pero esas 20 mejoras le habrían tomado a un investigador humano semanas de trabajo manual.

El detalle más revelador

program.md es un documento Markdown, no un script de Python. El loop está escrito en español (o en inglés), no en código. Esta es la plantilla del loop engineering: no le des al agente una tarea, dale una metodología. Dejá que la metodología sea el loop.

Cuatro costes silenciosos

Cuando un loop empieza a correr, no vas a ver los problemas de inmediato. Estos cuatro costes se acumulan en silencio.

1. Deuda de verificación

Los loops rápidos te tientan a saltear la verificación. “Se ve bien” no es lo mismo que “confirmado correcto”. La solución: las condiciones de parada deben ser comprobables por máquina, nunca “se siente más o menos bien”.

2. Deterioro de la comprensión

Cuanto más rápido despacha código un loop, más se aleja tu comprensión de tu propia base de código de la realidad. El equipo de Cherny tenía el 80% del código autorado por agentes. Si no leés y usás lo que produce el loop, tu comprensión decae continuamente. Los loops rápidos requieren lectura rápida.

3. Rendición cognitiva

Cuando el loop corre sin problemas, la postura más cómoda es dejar de tener opiniones. Ahí es exactamente donde empieza el peligro: estás usando el loop para evitar pensar, en lugar de amplificar el pensamiento.

Osmani: “Dos personas pueden construir exactamente el mismo loop y obtener resultados opuestos. Uno lo usa para ir más rápido en trabajo que entiende; el otro lo usa para evitar entender el trabajo. El loop no sabe la diferencia. Vos sí.”

4. Explosión de tokens

Cada iteración acumula más contexto: código escrito, errores encontrados, decisiones tomadas. Sin gestión del contexto, el tamaño del prompt crece aproximadamente de forma cuadrática con el número de turnos. Codex aborda esto con compactación automática de contexto. Es una preocupación de ingeniería que tenés que abordar desde el primer loop.

Construyendo tu primer loop

Paso 1 — Elegí una tarea recurrente. Algo que hagas manualmente al menos dos veces por semana: triaje de issues por la mañana, lint y tests antes de cada revisión de PR, actualizar docs de progreso al final del día.

Paso 2 — Escribí un objetivo y una condición de parada.

Objetivo: revisar las 10 issues más recientes del repo.
Para cada issue:
  - Si ya tiene labels claros y asignado, saltear
  - Si no tiene tags, agregar labels apropiados según el contenido
  - Si es arreglable en menos de 10 minutos, crear una rama e intentar el fix
Detenerse cuando: todas las issues elegibles fueron procesadas,
o una issue requiere decisión humana.

Paso 3 — Separá maker y checker. Implementador: lee la issue, escribe el fix, escribe los tests. Verificador: corre tests independientemente, revisa el diff, juzga si el fix realmente resuelve el problema.

Paso 4 — Agregá memoria. Un archivo markdown que registre qué pasó en cada ejecución. La ejecución siguiente empieza leyéndolo.

Paso 5 — Poné un temporizador. Empezá con una vez por día. Observá durante una semana.

La escalera de madurez

Nivel	Qué es	Ejemplo
1	Ejecutor de objetivos	/goal con una condición de parada; el agente itera hasta cumplirla
2	Tarea única programada	Una automatización corre una tarea en un temporizador
3	Loop de múltiples agentes	Separación maker/checker; cada hallazgo crea un worktree aislado
4	Loop autoalimentado	El loop descubre su tarea siguiente desde el estado externo
5	Orquestación de flota	Múltiples loops en paralelo, independientes pero compartiendo memoria

La mayoría de los equipos están entre el nivel 2 y el 3. El nivel 1 es el camino más rápido para ver retornos.

Ideas clave

• Loop Engineering no reemplaza a Harness Engineering: construye un piso encima. El harness hace fiables las ejecuciones individuales; el loop hace autónomas las ejecuciones continuas.
• /goal es el loop más simple posible: objetivo + verificación + condición de parada.
• Seis primitivas (automations, worktrees, skills, connectors, subagentes, estado externo) son los bloques de construcción. No todas cada vez, pero tenés que saber cuándo usar cuál.
• El maker y el checker deben estar separados. Un verificador independiente es la garantía de fiabilidad básica de cualquier loop.
• Los loops hacen que la generación sea casi gratis y dejan el juicio como el recurso escaso.
• Cuatro costes silenciosos se agudizan cuanto más corre el loop: deuda de verificación, deterioro de la comprensión, rendición cognitiva, explosión de tokens.
• Empezá chico. Un /goal, un cron, un archivo markdown de memoria.

Ejercicios

1. Convertí una tarea recurrente en un /goal: escribí su objetivo, método de verificación y condición de parada. Ejecutalo una vez y compará tiempo y calidad contra hacerlo a mano.
2. Separá maker y checker: elegí una tarea que hayas hecho con un agente. Esta vez escribí dos prompts distintos, uno para el implementador y otro para el verificador, usando modelos distintos. Registrá cantidad y tipo de problemas encontrados en cada modo.
3. Dale memoria a tu loop: creá un archivo de estado markdown. En cada iteración escribí qué se hizo, resultados de verificación, estado y qué sigue. Corré tres rondas y observá la diferencia de comportamiento.
4. Auditá los costes silenciosos: después de una hora corriendo, evaluá cuánta verificación fue “se siente bien” en lugar de confirmada por máquina, qué tan bien podés explicar el código producido, cuántas veces pensaste “lo veo después” y nunca lo viste, y cómo está tendiendo el tamaño del contexto.

Lecturas adicionales

• Addy Osmani: Loop Engineering
• Addy Osmani: Agent Harness Engineering
• Simon Willison: Designing Agentic Loops
• Karpathy: autoresearch
• Loop Library (Forward Future) — corpus público de 50 loops reales

---

Anterior: Lección 12 — Dejá un handoff limpio al final de cada sesión · Siguiente: Lección 14 — De los loops únicos a la ingeniería de grafos