Deja de hacer prompting y empieza a construir loops

El mes pasado, Peter Steinberger publicó un tweet que acumuló ocho millones de visualizaciones: "Ya no deberías estar haciendo prompting a agentes de código. Deberías estar diseñando loops que le hagan prompting a tus agentes." Por la misma época, Boris Cherny—creador de Claude Code—dijo algo parecido en Acquired Unplugged: "Ya no le hago prompting a Claude. Tengo loops ejecutándose. Son ellos los que le hacen prompting a Claude."

Y entonces internet hizo lo que internet hace: todos empezaron a discutir, nadie entendió qué era un loop, y el debate se convirtió en un desastre de abstracciones.

Yo llevo varios meses ejecutando loops reales. No porque esté ahead of the curve—simplemente me harté del trabajo manual de triaje y lo automatiqué. Lo que descubrí me sorprendió: la mentalidad de loops no es una técnica avanzada para power users de IA. Es una evolución natural que ocurre cuando dejas de tratar a los agentes como sofisticadas herramientas de copiar-y-pegar y empiezas a verlos como sistemas que pueden monitorear, decidir y actuar en tu nombre.

Los Tres Sabores de "Loop" en los que Nadie Se Pone de Acuerdo

Aquí está por qué esta conversación se complica: cuando la gente dice "loop", puede referirse a una de tres cosas, y las diferencias importan.

Primero, está el autonomous task loop—básicamente "sigue hasta que esté hecho". Piensa en el script Ralph de Geoffrey Huntley (while :; do cat PROMPT.md | claude-code; done), o el comando /goal que Codex y Claude Code ahora incluyen de serie. Este es el modo "configúralo y olvídalo".

Segundo, está el scheduled or event-driven loop—trabajo que se ejecuta mientras no estás en la silla. El HEARTEBEAT.md de Peter Steinberger en OpenClaw es el ejemplo canónico: una lista de verificación que el agente reconsidera cada 30 minutos. Descendientes de este patrón incluyen las automatizaciones de Codex y las rutinas programadas de Claude Code.

Tercero, está el orchestration fan-out—flujos de trabajo dinámicos con múltiples agentes ejecutándose concurrentemente. Las operaciones estilo map/reduce de Claude Code entran aquí. Esto se parece más al actor model que a un simple loop.

Mi opinión? Steinberger y Cherny están describiendo el segundo tipo, conectado con el primero. Los loops que yo ejecuto son programados y event-driven por fuera, y varios de ellos ejecutan inner loops estilo experimento una vez que se disparan. Esa combinación es donde está el verdadero leverage.

El PR Babysitter: Mi Puerta de Entrada al Diseño de Loops

Ya tenía revisión de código con IA en cada pull request. Claude revisaba primero, luego la revisión integrada de Codex, y después un GitHub Action personalizado donde controlaba exactamente lo que el modelo veía—incluyendo contexto completo de la conversación más el diff del patch.

Mi flujo de trabajo real era absurdo: enviaba un PR, esperaba los reviews, y luego copiaba-y-pegaba los comentarios en el agente. A veces pegaba capturas de pantalla. Era manual, repetitivo, y agotador.

Un día le pregunté a mi agente: "¿No podrías usar el cliente de gh y verificar el estado del review tú mismo?" Podía. Así que naturalmente pregunté: "¿No podrías seguir verificando y avisarme cuando esté listo?"

Esa simple petición transformó mi flujo. Ahora el agente vigila cambios en el estado de los reviews, trae contexto nuevo, analiza el feedback, y hace el trabajo real de abordarlo. El loop termina cuando alcanza una decisión de triaje: aceptar el feedback, rechazarlo, o escalármelo.

El patrón se generaliza perfectamente: vigila cambios de estado en sistemas externos, despierta cuando ocurren, trae contexto fresco, analiza, actúa, y triaje. Una vez que ves esta forma, empiezas a encontrarla en todas partes. El equipo de Codex incluye su propia skill babysit-pr, y los docs de Claude Code ahora mencionan el PR babysitting como caso de uso principal para su comando /loop.

Inner Loops: Haciendo que el Agente Ejecute Sus Propios Experimentos

Hay otro patrón de loop que me tomó más tiempo apreciar: el experiment loop. El concepto de autoresearch de Andrej Karpathy me hizo pensar en esto—ejecutar muchas iteraciones, medir resultados, quedarte con lo que funciona. Lo apunté a un path lento en Python y ejecuté 49 experimentos en una hora, reduciendo el p95 latency de 339ms a 34ms por unos $24.

El mismo patrón aplica a problemas más difíciles: hacer debug del comportamiento de agentes en producción. Cuando algo sale mal—un trace raro en Braintrust, feedback de usuarios en Slack, o algo que yo mismo encuentro—lanzo un worktree, pego el trace, e invoco el test loop.

Aquí está lo que hace diferente a este loop: fuerza una disciplina que la intuición naive del modelo intenta resistir. Si se deja solo, un modelo codificará "nunca hacer X, Y, Z" en el system prompt y sobreajustará al único trace que le mostraste. Las referencias de la skill destilan la investigación sobre por qué ese enfoque falla, y el contrato del loop requiere una hipótesis y una matriz de pruebas.

Necesito tres casos: el caso original que falla, un positivo adyacente que debería tomar el mismo path, y un contraejemplo que debería tomar uno diferente. Tres o cuatro probes se ejecutan concurrentemente contra dev local, reconstituyendo el contexto exacto del usuario desde el trace. Cada ejecución se puntúa en tool calls, latency, delta de input tokens, y correctness. El modelo no puede hacer trampa memorizando—tiene que entender realmente.

Lo Que Realmente Cambia Cuando Construyes Loops

El cambio más grande no es técnico—es conceptual. Cuando le haces prompting a un agente, sigues siendo tú el que conduce. Tú eres el acelerador, el navegador, el quality checker. Los loops invierten eso. Te conviertes en el arquitecto de sistemas que se conducen solos.

Esto no significa que la autonomía completa sea el objetivo. Yo sigo en la puerta de triaje en todo lo importante. Los loops manejan lo tedioso, el monitoreo, la repetición. Yo manejo las llamadas de juicio que realmente importan.

El segundo cambio es que los loops te obligan a ser explícito sobre los criterios de éxito. Un buen loop tiene condiciones de salida claras, puntos de decisión claros, paths de escalamiento claros. No puedes construir un loop sin definir qué significa "hecho". Esa disciplina se filtra a todo lo demás.

Tercero, los loops son composables. El PR babysitter trabaja junto al experiment loop. Verificaciones programadas disparan respuestas on-call. Empiezas a construir una biblioteca de comportamientos que trabajan juntos en lugar de un pile of one-off prompts.

El Punto de Partida Práctico

Si quieres experimentar con loops, empieza con algo que ya hayas automatizado mal. Probablemente tienes un GitHub Action que hace algo en un schedule, o una sesión de Claude Code que re-ejecutas manualmente, o un proceso de review que involucra copiar-y-pegar outputs entre herramientas.

Elige el más molesto. Pregúntate: ¿qué cambio de estado estoy esperando realmente? ¿Qué contexto necesita el agente cuando ese cambio ocurre? ¿Qué decisión necesita tomar?

Luego construye el loop. No necesita ser elegante. Necesita funcionar, y necesita devolverte el control de tu propio tiempo.

Los configs completos, skills, y workflow de CI detrás de los loops que ejecuto están en un repo público: camwest/agent-skills. No es un producto pulido—es un sistema funcional que evoluciona conforme aprendo. Ese es el punto. Los loops no son un destino; son una práctica.

El discourse alrededor de agentes de IA se está ahogando en abstracciones. Aquí está la versión concreta: deja de hacer prompting, empieza a construir loops, y mira qué pasa cuando dejas que la máquina maneje el monitoreo mientras tú manejas el significado.