Loops en Claude Code: deja de promptear a tu agente

Respuesta corta: escribir loops es dejar de ser tú quien promptea al agente y escribir lo que lo hace por ti: un programa o un agente que se lanza solo con un cron, encuentra el trabajo, le pasa cada trozo a un agente, revisa lo que devuelve y decide qué toca después. El más pequeño que merece la pena montar esta semana: un agente programado que se despierta cada mañana, lee todas las issues abiertas desde ayer, las etiqueta, prepara un repro y te señala las dos o tres que necesitan que las mires tú.

La última vez escribí sobre codificar mi proceso como agent skills - darle vueltas a la idea, escribir el PRD, cortarla en slices, construirla, mantener las instrucciones limpias. Pensaba que eso era lo más alto de la escalera. Luego vi a Boris Cherny, el responsable de Claude Code, describir el escalón de encima, y me di cuenta de que solo había subido la mitad.

Su frase, en el escenario de Acquired Unplugged, más o menos así: hace un año escribía código con autocompletado. Luego tenía cinco o diez Claudes corriendo en paralelo, y su “programar” era promptear a cada uno. ¿Y ahora? “Ya no prompteo a Claude. Tengo loops corriendo. Ellos son los que promptean a Claude y deciden qué hacer. Mi trabajo es escribir loops.”

Léelo otra vez. La unidad de trabajo pasó de la tecla, al prompt, al loop.

¿En qué escalón de la escalera de abstracción estás?

Boris describe programar como una sola subida larga: tarjetas perforadas, luego ensamblador, luego C, luego los lenguajes de alto nivel, luego los de altísimo nivel. “El nivel de abstracción siempre sube.” Promptear a un agente es solo el siguiente escalón. Y también lo es el de después.

¿Dónde estamos casi todos ahora mismo? Escalón dos. Prompteamos. Como mucho lanzamos un par de agentes a la vez y nos sentimos a la última. El salto que describe Boris es el escalón tres: dejas de ser el que promptea. Construyes el que promptea, y es él quien decide en qué trabajar, despacha a los agentes y revisa los resultados sin que tú toques una tecla. Es el paso de human in the loop (tú apruebas cada paso) a human on the loop: diseñas el sistema y lo supervisas desde fuera, en vez de sentarte dentro de cada iteración.

Suena a ciencia ficción hasta que te das cuenta de que las piezas ya existen. Y no, esto no es solo cron de toda la vida con una capa de IA por encima. Llevamos veinte años programando scripts a una hora fija, pero un script hace exactamente lo que escribiste, mientras que el agente dentro de este loop lee todo tu codebase y decide por su cuenta en qué trabajar. Ese es el cambio entero. El horario es trivial y siempre lo fue; el trabajo está en la puerta que le pones a lo que el agente te devuelve.

¿Qué es un loop? Orquestación, no magia

Quítale el misterio, y pártelo en dos. El harness es el equipamiento: las herramientas, skills y MCPs que le das a un agente para que pueda hacer el trabajo de verdad. El loop es la orquestación que lo rodea: averigua qué trabajo hay → le pasa un trozo a un agente → revisa lo que vuelve → repite, y decide cuándo se lanza, cuándo avanza, cuándo para. El harness es lo que el agente puede hacer; el loop es cuándo y con qué frecuencia lo hace. No escribes el código. Ni siquiera escribes los prompts. Escribes lo que escribe los prompts.

En Claude Code, hoy, eso no es una metáfora. Son tres piezas reales:

• Workflow scripts: código determinista que reparte el trabajo entre muchos subagentes (en paralelo, pasando cada elemento por etapas, en bucle hasta vaciar una cola o agotar un presupuesto de tokens). Esto es, literalmente, un loop que promptea a Claude.
• Agentes en background y en paralelo: lanzas una flota, cada uno en su slice, todos a la vez.
• Agentes programados / cron: la parte que lo hace autónomo. Un agente que se despierta según un horario, lee tus issues de GitHub, tu feedback, tu Slack, y actúa.

Eso último es exactamente lo que Boris contaba que tenía corriendo a escala: “un par de cientos de Claudes corriendo… mirando feedback de Twitter, issues de GitHub, Slack. Están decidiendo qué construir a continuación.”

No necesitas cien. El loop más pequeño y real que puedes montar esta semana: un agente programado (cron) que se despierta una vez cada mañana, coge cada issue abierta desde ayer y ejecuta una sola instrucción sobre cada una. Léela, contrástala con el codebase, etiquétala, redacta un repro y marca las dos o tres que merecen tu tiempo. Es un único agente programado con un archivo de skill y un techo de tokens, no una flota. Eso es el escalón tres, hoy, con un solo agente. Lees lo que saca antes de fiarte, y a partir de ahí escalas.

Este es ese loop como script. Cron lo lanza cada mañana desde tu repo; gh encuentra el trabajo, Claude Code en modo headless (claude -p) hace cada trozo, y una etiqueta lo marca como hecho para que la pasada de mañana se lo salte:

#!/usr/bin/env bash
# triage.sh, desde cron: 0 7 * * * cd ~/code/mi-app && ./triage.sh
set -euo pipefail

for n in $(gh issue list --search "-label:triaged" --json number --jq '.[].number'); do
  claude -p "Haz el triage de la issue #$n de GitHub. Léela con gh issue view, contrástala con este codebase \
y deja un único comentario: causa probable, un repro mínimo si puedes escribirlo, y P1, P2 o P3. \
No cambies código." \
    --allowedTools "Read" "Grep" "Glob" "Bash(gh issue view:*)" "Bash(gh issue comment:*)" \
    --max-budget-usd 0.50 < /dev/null
  gh issue edit "$n" --add-label triaged
done

Tres líneas cargan con todo. La lista de --allowedTools deja al agente leer código y comentar, nada más. --max-budget-usd es la condición de parada por issue. Y la revisión eres tú, leyendo los comentarios con el café, hasta que el loop se gane que le prestes menos atención.

Por qué las skills son el requisito previo (esto es la secuela, al fin y al cabo)

Aquí está la parte que la gente se salta, y es la razón entera por la que escribí primero el post de las skills.

No puedes automatizar de forma segura la invocación de un proceso que no has codificado.

Un loop no hace listo a un agente. Lo hace frecuente. Si los agentes dentro de tu loop no siguen un proceso de verdad (darle vueltas a la idea, cortarla en vertical, construir con disciplina, obedecer un AGENTS.md mínimo), entonces un loop solo genera basura más rápido. Un chorro de cosas plausibles pero equivocadas. Y los prompts que dispara el loop siguen teniendo que ser buenos. Los fundamentos para escribir un prompt afilado no dejan de importar porque los teclee un script en vez de ti.

Las skills son lo que convierte un loop de máquina de slop en un proceso que se ejecuta solo. Boris dijo lo mismo, casi de pasada: las empresas tienen “documentos de principios” para no tomar las mismas decisiones una y otra vez, y “el modelo también puede usar esos principios, y vienen en forma de skills.” El escalón dos (skills) no es un paso que te puedas saltar para llegar al escalón tres (loops). Es el muro de carga.

La parte honesta: la mayoría de lo que escupe un loop es malo

No te voy a vender el sueño sin el asterisco.

Boris, hablando de sus cientos de agentes buscando qué construir: “la mayoría de las ideas son malas, pero quizá un 20% son buenas.” Un veinte por ciento. Lo dice quien construyó la herramienta.

Y el propio ensayo de Anthropic sobre auto-mejora recursiva llega al mismo cuello de botella por el lado opuesto. Su descripción de la trayectoria (humanos escribiendo código, luego agentes escribiendo archivos enteros, luego agentes pasándole horas de trabajo a otros agentes) suena triunfal hasta que llegas a la trampa: la revisión humana se ha convertido en el cuello de botella. La ejecución se abarató. El criterio no.

Así que un loop sin filtro es un lastre, no una palanca. Lo que hace los loops soportables es la puerta a la salida: una revisión adversarial, un control de calidad duro, tests que de verdad fallen. El loop genera; algo tiene que hacer de portero. Si el 80% es basura, tu ventaja es la velocidad y la calidad de tu “no”.

Y hay un segundo contador en marcha: el dinero. Un loop que despacha subagentes encadenados mientras duermes no solo produce slop, te lo factura. Cada iteración sin supervisión gasta tokens valga o no la pena lo que sale, así que un techo de tokens y una condición de parada no son un extra: son parte del harness. Ponle un tope duro (con cinco euros o veinte iteraciones por noche te sobra para empezar), y haz que pare y te avise al llegar, en vez de seguir a ciegas. Decide ambos antes de dejar uno corriendo solo.

Hacia dónde va esto (y por qué no es solo hype)

Aleja el plano y el “yo escribo loops” de Boris es la foto a escala personal de lo que Anthropic sostiene que le está pasando a todo el sector. Su ensayo dibuja un futuro donde la IA automatiza cada vez más el propio desarrollo de IA, y el rol humano se comprime hacia una sola cosa: dirección y criterio. Elegir qué merece la pena hacer. Distinguir un buen resultado de uno malo.

Yo cogería los números concretos con pinzas, y para ser justos, ellos también. Reconocen abiertamente que las líneas de código son una métrica mala, que las mejoras que ellos mismos reportan probablemente están infladas, y que si los modelos de hoy pueden desarrollar verdadero gusto investigador por su cuenta es, en sus palabras, genuinamente incierto. Esa honestidad es justo por lo que merece leerse: optimista con la trayectoria, sincero con la incertidumbre. La dirección es real aunque las fechas no lo sean.

Lo que sigue siendo tuyo

Esto es lo que la escalera te está diciendo en voz baja.

Cada escalón que subes, tu ventaja deja de ser lo de debajo. Dejó de ser “sé escribir el código”. Está a punto de dejar de ser “sé escribir el prompt”. Lo que queda, arriba del todo, es lo que no se automatiza: decidir qué merece la pena construir, juzgar lo que vuelve, y los valores que metes en el sistema que corre mientras duermes.

A Boris le preguntaron cuál será la última habilidad solo-humana. Su respuesta: “lo último que le enseñaremos al modelo son valores. Igual que enseñamos a nuestros hijos a ser buenas personas, le enseñaremos al modelo a ser un buen modelo.”

Así que no romantices los loops. Monta uno. Codifica tu proceso como skills primero, envuélvelo en un loop pequeño, y pon una puerta de revisión brutal a lo que produzca. Esa es la jugada entera: el escalón tres no necesita cien agentes. Necesita un buen loop y tu criterio al otro lado.

Ya tienes la versión más pequeña unos párrafos más arriba. Esta noche, apunta un agente programado a una sola etiqueta de issues, ponle un techo de tokens, y por la mañana lee lo que ha redactado antes de creerte una palabra. Eso es el escalón tres, esta semana, vigilado. A partir de ahí amplías, cuando se haya ganado tu confianza.

Lectura relacionada: esto solo funciona si el proceso de debajo es sólido. Empieza por las cinco agent skills que gobiernan todo mi flujo, y luego envuélvelas en un loop. Y qué modelo pones en el loop también cuenta: desgrané el que ahora elijo en mi reseña de Claude Fable 5.

Fuentes

• Boris Cherny (responsable de Claude Code), Acquired Unplugged: la frase “yo escribo loops” y el “la mayoría de las ideas son malas, ~20% buenas”, vía el clip de @codingvic en X.
• Anthropic, Recursive self-improvement: el marco a escala de empresa y los matices.

P.D. ¿Montando loops en serio? Quiero saber qué has automatizado y qué te explotó en la cara. Escríbeme en LinkedIn.