Loop Engineering: el futuro de cómo trabajamos con agentes de código

Hace dos años, la forma de sacarle algo a un agente de código era escribir un buen prompt y compartir suficiente contexto. Escribís algo, leés lo que devuelve, escribís lo siguiente. El agente es una herramienta y vos la estás sosteniendo todo el tiempo, turno tras turno. Esa etapa terminó — o al menos algunos piensan que va a terminar.

@steipete dijo hace poco: "Ya no deberías estar prompeteando agentes de código. Deberías estar diseñando loops que prompetean a tus agentes." Y @bcherny, head de Claude Code en Anthropic, fue más lejos: "Yo ya no prompeteo a Claude. Tengo loops corriendo que prompetean a Claude y deciden qué hacer. Mi trabajo es escribir loops."

Ahora construís un sistema pequeño que encuentra el trabajo, lo distribuye, lo verifica, documenta lo que está hecho y después decide el próximo paso. Dejás que ese sistema golpee a los agentes en lugar de hacerlo vos.

Ya escribí antes sobre el primo de esto: agent harness engineering, que es construir el entorno donde corre un solo agente, y el factory model, el sistema que construye el software. Loop Engineering está un piso más arriba del harness. El harness pero corriendo con un timer, generando pequeños ayudantes, y alimentándose a sí mismo.

Lo que me sorprendió es que esto ya no es una cuestión de herramientas. Hace un año si querías un loop escribías un montón de bash y mantenías ese montón para siempre, y era tuyo y solo tuyo. Ahora las piezas vienen adentro de los productos. La lista de Steinberger mapea casi exactamente sobre la app de Codex, y casi igual sobre Claude Code. Y una vez que notás que la forma es la misma, dejás de discutir sobre qué herramienta y simplemente diseñás un loop que funciona sin importar en cuál estés sentado.

Un loop necesita cinco cosas y un lugar para recordar:

1. Automatizaciones — se disparan en un schedule y hacen discovery y triage solas.
2. Worktrees — para que dos agentes trabajando en paralelo no se pisen.
3. Skills — para escribir el conocimiento del proyecto que el agente de otra forma adivinaría.
4. Plugins y conectores — para enchufar al agente en las herramientas que ya usás.
5. Sub-agentes — para que uno tenga la idea y otro distinto la verifique.

Y después la sexta cosa: la memoria. Un archivo markdown, un board de Linear, cualquier cosa que viva fuera de la conversación individual y guarde qué está hecho y qué sigue. Suena demasiado tonto para importar. Pero es el mismo truco del que depende cada agente de larga duración: el modelo olvida todo entre ejecuciones, así que la memoria tiene que estar en disco, no en el contexto. El agente olvida, el repo no.

Ambos productos ya tienen los cinco.

Las automatizaciones son lo que hace que un loop sea un loop de verdad y no una ejecución que hiciste una vez.

En la app de Codex creás una en la pestaña Automations: elegís el proyecto, el prompt que va a correr, cada cuánto, y si corre en tu checkout local o en un worktree de fondo. Las ejecuciones que encuentran algo van a un inbox de Triage, y las que no encuentran nada simplemente se archivan solas — lo cual es un buen detalle. OpenAI las usa internamente para cosas aburridas como triage diario de issues, resumir fallos de CI, escribir briefings de commits, cazar bugs que alguien agregó la semana pasada. Y una automatización puede llamar un skill, así que mantenés la tarea recurrente mantenible: disparás $skill-name en vez de pegar una pared de instrucciones en un schedule que nadie va a actualizar nunca.

Claude Code llega al mismo lugar pero a través de scheduling y hooks. Podés correr un prompt o un comando en un intervalo con /loop, podés schedulear una tarea cron, podés disparar comandos de shell en ciertos puntos del ciclo de vida del agente con hooks, o podés empujar todo a GitHub Actions si querés que siga corriendo después de cerrar la laptop. Misma idea exactamente: definís una tarea autónoma, le das una cadencia, y los hallazgos te llegan a vos en vez de ser vos el que va revisando.

Hay una segunda primitiva in-session que vale la pena conocer, y es la que está más cerca de lo que trata este artículo. /loop re-ejecuta con una cadencia. /goal sigue hasta que una condición que escribiste es realmente verdadera, y después de cada turno un modelo chiquito separado verifica si terminaste — así que el agente que escribió el código no es el que lo evalúa. Le das algo como "todos los tests en test/auth pasan y el lint está limpio" y te vas. Codex tiene lo mismo, también llamado /goal, sigue trabajando entre turnos hasta que una condición de parada verificable se cumple, con pausa, resume y clear.

Esta es la parte que saca el trabajo a la superficie. El resto del loop es lo que actúa sobre él.

En el segundo que corrés más de un agente, los archivos empiezan a chocar. Ahí está la falla. Dos agentes escribiendo el mismo archivo es exactamente el mismo dolor de cabeza que dos ingenieros commiteando a las mismas líneas sin hablarse primero. Un git worktree lo resuelve: es un directorio de trabajo separado en su propia rama, compartiendo el historial del repo, así que los edits de un agente literalmente no pueden tocar el checkout del otro.

Codex construye el soporte de worktrees directo para que varios hilos peguen al mismo repo al mismo tiempo sin chocar. Claude Code te da el mismo aislamiento con git worktree: un flag --worktree para abrir una sesión en su propio checkout, y un setting isolation: worktree que le ponés a un sub-agente para que cada ayudante tenga un checkout fresco que se limpia solo después. Ya escribí sobre el lado humano de esto en el impuesto de orquestación: los worktrees eliminan la colisión mecánica pero VOS seguís siendo el techo — tu bandwidth de revisión decide cuántos podés realmente correr, no la herramienta.

Un skill es cómo dejás de re-explicar el mismo contexto del proyecto en cada sesión como un pez dorado. Ambas herramientas usan el mismo formato: una carpeta con un SKILL.md adentro que tiene instrucciones y metadata, y después scripts opcionales, referencias, assets.

Codex ejecuta un skill cuando lo llamás con $ o /skills, o solo cuando tu tarea matchea la descripción del skill — razón por la cual una descripción ajustada y aburrida le gana a una ingeniosa. Claude Code lo hace igual.

Los skills también son donde la intención deja de costarte una y otra vez. Argumenté en el concepto de intent debt que un agente empieza cada sesión en frío y va a llenar cualquier agujero en tu intención con una suposición confiada. Un skill es esa intención escrita por fuera: las convenciones, los pasos de build, el "no hacemos esto así por ese incidente", escrito una vez donde el agente lo lee cada ejecución. Sin skills, el loop re-deriva todo tu proyecto desde cero en cada ciclo. Con skills, de alguna forma compone.

Una cosa para tener clara: el skill es el formato de autoría, y un plugin es cómo lo distribuís. Cuando querés compartir un skill entre repos o empaquetar varios juntos, los empaquetás como plugin. Funciona en Codex, funciona en Claude Code.

Un loop que solo puede ver el filesystem es un loop chiquito. Los conectores, que están construidos sobre MCP, dejan que el agente lea tu issue tracker, consulte una base de datos, pegue a una API de staging, tire un mensaje en Slack. Codex y Claude Code ambos hablan MCP, así que el conector que escribiste para uno generalmente funciona en el otro. Y los plugins empaquetan conectores y skills juntos para que tu compañero instale tu setup de una en vez de reconstruir todo de memoria.

Esta es la diferencia entre un agente que dice "acá está el fix" y un loop que abre el PR, linkea el ticket de Linear y pinguea el canal cuando CI está verde, solo. Los conectores son la razón por la que el loop puede actuar dentro de tu entorno real en vez de solo decirte lo que haría si pudiera.

Lo estructuralmente más útil en un loop, por lejos, es separar al que escribe del que revisa. El modelo que escribió el código es demasiado bueno corrigiendo su propia tarea. Un segundo agente con instrucciones distintas — y a veces un modelo distinto — atrapa las cosas de las que el primero se convenció solo.

Codex solo spawnea sub-agentes cuando se lo pedís, los corre al mismo tiempo y después pliega los resultados en una sola respuesta. Definís tus propios agentes como archivos TOML en .codex/agents/, cada uno con nombre, descripción, instrucciones y modelo y esfuerzo de razonamiento opcionales — así tu revisor de seguridad puede ser un modelo fuerte con esfuerzo alto mientras tu explorador es algo rápido y read-only. Claude Code hace lo mismo con sub-agentes en .claude/agents/ y equipos de agentes que se pasan trabajo entre ellos.

La división usual en ambos es: un agente explora, uno implementa, uno verifica contra la spec. Ya hice este caso dos veces, una como la orquesta de agentes de código y otra como code review adversarial. La razón por la que esto importa específicamente adentro de un loop es que el loop corre mientras no estás mirando — así que un verificador en el que realmente confiás es la única razón por la que podés irte. Los sub-agentes sí queman más tokens ya que cada uno hace su propio trabajo de modelo y herramientas, así que gastalos donde una segunda opinión vale la pena pagar.

Esto es básicamente lo que hace /goal de Claude Code por debajo: un modelo fresco decide si el loop terminó en vez del que hizo el trabajo — la división maker-checker aplicada a la condición de parada misma.

Juntalo todo y un solo hilo se convierte en un pequeño panel de control. Esta es una forma que vengo usando.

Una automatización corre cada mañana sobre el repo. Su prompt llama a un skill de triage que lee los fallos de CI de ayer, los issues abiertos, los commits recientes, y escribe los hallazgos en un archivo markdown o un board de Linear. Para cada hallazgo que vale la pena, el hilo abre un worktree aislado y manda un sub-agente a redactar el fix, y un segundo sub-agente revisa ese borrador contra los skills del proyecto y los tests existentes.

Los conectores dejan que el loop abra el PR y actualice el ticket. Lo que el loop no puede manejar aterriza en el inbox de triage para mí. El archivo de estado es la columna vertebral de todo: recuerda qué se intentó, qué pasó, qué sigue abierto — así que mañana a la mañana la ejecución retoma donde hoy paró.

Y mirá lo que realmente hiciste ahí. Lo diseñaste una vez. No prompeteaste ninguno de esos pasos. Ese es todo el punto de Steinberger hecho real. Y es el mismo loop en Codex o en Claude Code porque las piezas son las mismas.

El loop cambia el trabajo. No te elimina del trabajo. Y tres problemas se vuelven más filosos a medida que el loop mejora, no más fáciles.

La verificación sigue siendo tuya. Un loop corriendo sin supervisión es también un loop cometiendo errores sin supervisión. La razón entera de separar el sub-agente verificador del que hace es para que el "está hecho" del loop signifique algo — y aún así "hecho" es una afirmación, no una prueba. Sigo diciendo la misma línea de code review en la era de la IA: tu trabajo es entregar código que confirmaste que funciona.

Tu comprensión se pudre si la dejás. Cuanto más rápido el loop shippea código que no escribiste, más grande es la brecha entre lo que existe y lo que realmente entendés. Eso es comprehension debt, y un loop suave solo lo hace crecer más rápido — a menos que leas lo que el loop produjo.

Y sí, la postura cómoda es probablemente la riesgosa. Cuando el loop corre solo, es muy tentador dejar de tener opinión y simplemente aceptar lo que devuelve. A eso lo llamé cognitive surrender. Diseñar el loop es la cura cuando lo hacés con criterio — y el acelerante cuando lo hacés para evitar pensar. Misma acción, resultado opuesto.