El diciembre pasado, Boris Cherny envió 259 pull requests en un solo mes. Todas escritas por Claude. Dice que no abrió un editor en todo ese tiempo.
Su trabajo no era escribir código. Era escribir lo que escribe el código. Peter Steinberger lo resumió en dos líneas que se han visto más de 8 millones de veces: "Ya no deberías estar dándole indicaciones a agentes de código. Deberías estar diseñando bucles que le den indicaciones a tus agentes".
Eso es la ingeniería de bucles. Construyes un sistema pequeño que encuentra el trabajo, se lo pasa a un agente, verifica el resultado y decide el siguiente paso, y luego lo dejas correr mientras duermes.
El problema llegó el mismo mes. El bucle de otra persona corrió once días sin supervisión y quemó $47,000 antes de que alguien lo notara. Así que esto son realmente dos habilidades, y casi todo el mundo enseña solo la primera: construir un bucle que entregue trabajo, y construir los frenos que eviten que te estrelles.
Una pregunta decide qué bucle construiste: ¿converge hacia algo verdadero, o es solo un costoso paseo aleatorio?
1. Un bucle son seis piezas y una pregunta
Debajo del ruido, un bucle funcional tiene seis partes. La lista parece demasiado simple la primera vez que la ves. El detalle dentro de cada parte es donde un bucle se mantiene firme o pierde dinero durante la noche.
Ya no construyes nada de esto a mano. Hace un año, un bucle significaba un montón de scripts de shell que poseías y cuidabas para siempre. Ahora las piezas vienen integradas en los productos, y las mismas seis se aplican tanto a la aplicación OpenAI Codex como a Claude Code. Una vez que ves eso, la herramienta deja de ser el debate y el bucle se convierte en el diseño.
1PIEZA TRABAJO EN EL BUCLE CODEX CLAUDE CODE2------------- ------------------------ ------------------------- --------------------------3Estado recordar entre ejecuciones markdown / Linear (MCP) markdown / Routines + MCP4Automatizaciones ejecutar en un horario Automations tab + Triage /loop (skill), Routines, /goal5Worktrees aislar agentes paralelos Worktree por hilo --worktree, isolation: worktree6Skills codificar tu intención ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Conectores tocar tus herramientas reales Servidores MCP (config.toml) Servidores MCP (.mcp.json)8Subagentes separar creador de revisor TOML en .codex/agents/ .claude/agents/ + agent teams
2. El estado es lo único que hereda la siguiente ejecución
Empieza por lo básico, porque todo lo demás se apoya en ello.
Un modelo olvida cuando una ejecución termina. La conversación muere, el contexto se limpia, la siguiente ejecución despierta sin saber nada. La memoria en el chat muere con la ejecución. Tiene que vivir en el disco.
En la práctica, eso es un archivo. Un STATUS.md en el repositorio, o un tablero de Linear al que se accede a través de un conector, que contiene lo que está hecho, lo que está en progreso, lo que sigue y las pocas cosas que el bucle nunca debe tocar.
1# STATUS.md (el bucle lee esto primero, lo escribe al final)2## Hecho3- [x] auth: migrado a tokens v2, tests en verde4## En progreso5- [ ] billing: refactorización de webhook (PR #214, CI en rojo)6## Siguiente7- [ ] dashboard: test inestable en test/charts8## Nunca9- no modificar infra/ sin un humano
Trata el bucle como un turno de noche que nunca observas. No se te juzga por lo que hizo a las 3 a.m. Se te juzga por la nota que espera en tu escritorio a las nueve. Diseña esa nota primero y la mayor parte del bucle se diseña solo.
3. Las automatizaciones son la diferencia entre un bucle y algo que ejecutaste una vez
Un bucle se gana el nombre solo cuando se activa por sí solo.
En la aplicación Codex construyes uno en la pestaña Automations: el repositorio, la instrucción, la cadencia. Las ejecuciones que encuentran algo terminan en una bandeja de Triage; las que no encuentran nada se archivan solas. OpenAI usa esto para la columna vertebral poco glamorosa de un código base: triaje diario de issues, resúmenes de fallos de CI, atrapar el error que alguien coló la semana pasada.
Claude Code llega a través de algunas primitivas, y los artículos populares se equivocan en los detalles, así que vale la pena ser preciso. /loop es una skill, no un comando integrado, y re-ejecuta una instrucción en una cadencia mientras tu sesión está abierta. Los trabajos recurrentes en la nube son Routines, configurados con /schedule, con un mínimo de una hora, y siguen ejecutándose con tu laptop cerrada. No hay crontab local.
La que vale la pena aprender es /goal. Se ejecuta hasta que una condición que escribiste se cumple, y después de cada turno, un modelo separado más pequeño verifica si realmente has terminado. El agente que escribió el código no puede calificarse a sí mismo.
1# Claude Code: ejecutar hasta que esté realmente terminado, no hasta que se sienta terminado2/goal todos los tests en test/auth pasan y el paso de lint está limpio34# Claude Code: un trabajo recurrente en la nube (mínimo 1 hora)5/schedule triaje diario de PR a las 9am67# Codex: una instrucción de automatización (configura la cadencia en el formulario)8"Días laborables 9am: escanea PRs abiertos, marca CI fallido o sin revisor, publica en Triage."
Escribe la condición de parada como un contrato. "Todos los tests en test/auth pasan" es un contrato. "Hazlo mejor" es cómo un bucle se ejecuta hasta el día de pago.
4. Los worktrees mantienen a los agentes paralelos fuera del camino del otro
En el momento en que ejecutas más de un agente, el modo de fallo cambia. Ya no es el modelo. Son dos agentes escribiendo el mismo archivo, el mismo desastre que dos ingenieros haciendo commit en las mismas líneas sin hablarse.
Un git worktree es el muro entre ellos: un directorio de trabajo separado en su propia rama, compartiendo el historial del repositorio, para que las ediciones de un agente no puedan alcanzar el checkout de otro.
1# Claude Code: un checkout aislado por agente2claude --worktree feature-auth34# o en un subagente, en el frontmatter de .claude/agents/<nombre>.md:5# isolation: worktree67# Codex: elige "Worktree" cuando abras un hilo (cada uno con HEAD separado)
Una advertencia que la herramienta no mencionará. Los worktrees eliminan la colisión, no el cuello de botella. Tú sigues siendo el límite. Por muchos agentes que inicies, tu propio ancho de banda de revisión decide a cuántos puedes confiar.
5. Las skills son tu intención, escrita una vez, en el exterior
Un agente comienza cada ejecución en frío y llena cualquier vacío en tu intención con una suposición confiada. Una skill es esa intención escrita donde el modelo la lee cada vez, para que deje de suponer.
El formato es el mismo en ambas herramientas: una carpeta con un SKILL.md que contiene instrucciones y una descripción, más cualquier script que necesite. Se activa cuando la llamas por su nombre o cuando tu tarea coincide con su descripción, que es exactamente por qué una descripción plana y literal es mejor que una ingeniosa.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Lee los fallos de CI de ayer, issues abiertos y commits5 recientes; escribe cada hallazgo en STATUS.md como una tarea.6---71. Obtén los fallos de CI y agrúpalos por causa raíz.82. Relaciona cada uno con el issue abierto o commit que lo causó.93. Escribe una tarea en STATUS.md por cada hallazgo real. Omite el ruido.
Sin skills, cada ciclo reaprende tu proyecto desde cero. Con ellas, el bucle se vuelve un poco más preciso cada mañana.
6. Los conectores permiten que el bucle actúe, no solo hable
Un bucle que solo puede ver el sistema de archivos es un juguete. Los conectores, construidos sobre el estándar compartido MCP, permiten que el agente lea tu gestor de issues, acceda a una API de staging, consulte una base de datos, publique en un canal.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
Esta es la línea entre un agente que dice "aquí está la solución" y un bucle que abre el pull request, enlaza el ticket e informa que está en verde por sí solo. Como ambas herramientas hablan MCP, un conector que configures para una generalmente funciona en la otra.
7. Los subagentes mantienen al creador alejado del revisor
El movimiento de mayor valor en cualquier bucle es separar al agente que escribe del que revisa.
Un modelo que revisa su propio trabajo se aprueba a sí mismo siempre. Un segundo agente, con instrucciones diferentes e idealmente un modelo diferente, atrapa lo que el primero se convenció a sí mismo de hacer.
1# Codex: .codex/agents/reviewer.toml2name = "reviewer"3description = "Revisor adversarial de PR: corrección, seguridad, tests faltantes."4developer_instructions = "Revisa como un propietario. Asume que el autor está5 equivocado hasta que el diff demuestre lo contrario."6model_reasoning_effort = "high"78# Claude Code: frontmatter de .claude/agents/reviewer.md9# name: reviewer10# description: Revisor adversarial. Usar después de cualquier cambio de código.11# model: opus
Uno explora, uno implementa, uno verifica contra la especificación. Esto es lo que /goal ya hace internamente: un modelo fresco decide si el trabajo está terminado. Las segundas opiniones cuestan tokens, porque cada agente ejecuta su propio modelo y herramientas, así que gaste donde equivocarse es caro.
8. Cómo se ve un bucle
Junta las seis piezas y un solo hilo se convierte en una pequeña máquina.
Una automatización programada se ejecuta cada mañana en el repositorio. Llama a tu skill de triaje, que lee los fallos de CI de la noche, los issues abiertos y los commits recientes, y escribe cada hallazgo real en STATUS.md. Por cada hallazgo que vale la pena hacer, el bucle abre un worktree aislado, envía un subagente a redactar la solución y un segundo a revisarla contra tus skills y tus tests. Los conectores abren el PR y actualizan el ticket. Lo que no puede manejar espera en tu bandeja de triaje. STATUS.md recuerda lo que pasó y lo que aún está abierto, para que mañana comience donde hoy terminó.
Lo que realmente encuentras al despertar es una breve transferencia, no un muro de registros:
1# 9:00am — la transferencia nocturna del bucle (tu bandeja de Triage)2LISTO PARA FUSIONAR3 PR #218 corrige test inestable en test/charts CI verde4 PR #219 reintenta webhook en 429, añade test de backoff CI verde5TE NECESITA6 auth/session.ts dos formas seguras de arreglar esto; no elegí ninguna, tú decides7SIN NOVEDADES8 7 ejecuciones programadas no encontraron nada y se archivaron
Lo diseñaste una vez. No le diste indicaciones a nada de esto.
9. Construye los frenos antes de irte
Esta es la mitad que nadie enseña, y decide si tu bucle es un activo o un pasivo.
Esa factura de $47,000 no fue un modelo inteligente que se volvió loco. Fueron dos agentes, un analizador y un verificador, pidiéndose cortésmente más trabajo el uno al otro, sin límite de pasos, sin techo de presupuesto y sin condición de parada. Corrió once días. Un solo límite lo habría matado en el primero.
Instala los frenos antes que la potencia. No envies el motor hasta que hayas enviado el pedal de freno.
1# Instala estos ANTES de irte:2- límite de pasos: --max-turns 50 (parada forzosa, sin excepciones)3- techo de presupuesto: claude -p --max-budget-usd 10 (modo impresión; por fase)4- radio de explosión: un worktree, una rama, solo lectura fuera de src/5- cortacircuitos: misma herramienta + mismos args 3 veces seguidas = detener6- control de ausencia: escribe un heartbeat en STATUS.md cada ejecución; el silencio te localiza
Delimita un bucle por lo que puede destruir, no por lo que quieres que haga: qué repositorios, qué ramas, cuántos dólares, cuántos pasos antes de que se fuerce a salir. Elige primero el radio de explosión, luego la tarea.
Y ponle un precio honesto. La flota de cien agentes de Steinberger es real, y cuesta alrededor de $1.3 millones al mes. Funciona porque OpenAI ahora lo emplea y paga la factura. El caso puntero está patrocinado. El tuyo no. En un plan de $20 a $200, el bucle que vale la pena es pequeño, limitado y apuntado a un trabajo aburrido, no a un enjambre.
1EL DESGLOSE DE COSTOS (todos reales, todos de los últimos seis meses)2-----------------------------------------------------------------3259 PRs en 30 días un ingeniero, 100% escrito por Claude4$47,000 en 11 días un bucle descontrolado sin límite, nadie mirando5~$1.3M por mes una flota de 100 agentes (la factura está patrocinada)6-----------------------------------------------------------------7Misma tecnología. La diferencia son los frenos.
10. Cómo mueren los bucles
Todo bucle que falla muere de una de cuatro maneras. Aprende los nombres ahora para que los reconozcas a las 3 a.m.
Recursión descontrolada. Dos agentes se alimentan el uno al otro para siempre. La cura es el límite de pasos y el techo de presupuesto de arriba, nada más ingenioso.
Muerte silenciosa. La ejecución nocturna de un desarrollador alcanzó una ventana de contexto completa, se detuvo y luego siguió intentando reanudarse contra la misma pared mientras aún parecía activa. Tu bucle puede estar muerto durante horas y seguir reportando progreso. La cura es un heartbeat y un contexto fresco por fase, no una ejecución interminable.
El paseo aleatorio. Sin una condición de parada verificable, el bucle se aleja del objetivo en lugar de acercarse a él. Un conjunto de pruebas que pasan es un punto fijo que puede alcanzar. "Parece terminado" no lo es.
Deuda de comprensión. Cuanto más rápido un bucle envía código que no escribiste, mayor es la brecha entre lo que tu repositorio hace y lo que entiendes. Déjalo correr el tiempo suficiente sin leerlo y dejas de ser el ingeniero y te conviertes en un sello de goma. La cura es una puerta de revisión humana que el bucle nunca puede saltarse.
11. Construye el bucle. Sigue siendo el ingeniero.
Dos personas pueden construir el bucle idéntico y obtener resultados opuestos. Una lo usa para moverse más rápido en un trabajo que entiende hasta los huesos. La otra lo usa para dejar de entender el trabajo por completo. El bucle no puede distinguirlas. Tú sí.
El punto de Cherny nunca fue que el trabajo se volviera más fácil. Es que el apalancamiento se movió: de la instrucción al bucle, y de escribir a tener criterio. Ese es un trabajo más difícil que dar indicaciones, no más fácil.
Así que aquí está el movimiento, y es pequeño a propósito, porque esto es temprano y los costos varían enormemente. Mañana por la mañana, toma el trabajo más aburrido que aún haces a mano, triar CI, cerrar issues obsoletos, perseguir un test inestable, y envuelve un bucle limitado a su alrededor. Frenos primero. Lo suficientemente pequeño como para que todavía leas cada diff que envía.
Nadie que envía 200 pull requests al mes comenzó con cien agentes. Comenzaron con un bucle en el que confiaban, y siguieron siendo el ingeniero durante todo el camino. Construye ese.
