El diciembre pasado, Boris Cherny envió 259 solicitudes de extracción 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 han sido vistas más de 8 millones de veces: "Ya no deberías estar dándole instrucciones a agentes de codificación. Deberías estar diseñando bucles que den instrucciones a tus agentes."
Eso es la ingeniería de bucles. Construyes un pequeño sistema que encuentra el trabajo, se lo pasa a un agente, revisa el resultado y decide el siguiente paso, luego lo dejas correr mientras duermes.
La advertencia llegó ese mismo mes. El bucle de alguien más corrió durante once días sin supervisión y quemó $47,000 antes de que alguien se diera cuenta. Así que esto es realmente dos habilidades, y casi todos enseñan solo la primera: construir un bucle que entregue trabajo, y construir los frenos que eviten que te despeñe por un acantilado.
Una pregunta decide qué bucle construiste: ¿converge hacia algo verdadero, o es solo un costoso paseo aleatorio?
1. Un bucle tiene 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 unido 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 corresponden tanto en la aplicación OpenAI Codex como en Claude Code. Una vez que ves eso, la herramienta deja de ser el argumento 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 pestaña Automations + 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)8Sub-agentes 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 desde abajo, porque todo lo demás se apoya en ello.
Un modelo olvida cuando termina una ejecución. La conversación muere, el contexto se limpia, la siguiente ejecución se 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 accedido 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- [ ] facturación: 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 nocturno que nunca observas. No te juzgan por lo que hizo a las 3 a.m. Te juzgan 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 sola.
3. Las automatizaciones son la diferencia entre un bucle y algo que ejecutaste una vez
Un bucle se gana el nombre solo cuando se dispara 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 caen en una bandeja de entrada Triage; las ejecuciones 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 eso a través de algunos primitivos, y los artículos populares se equivocan en los detalles, por lo que vale la pena ser exactos. /loop es una skill, no un comando incorporado, y vuelve a ejecutar 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 computadora cerrada. No hay un crontab local.
El 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 y más pequeño verifica si realmente terminaste. El agente que escribió el código no puede calificarlo.
1# Claude Code: ejecutar hasta que esté realmente terminado, no hasta que se sienta terminado2/goal all tests in test/auth pass and the lint step is clean34# Claude Code: un trabajo recurrente en la nube (mínimo 1 hora)5/schedule daily PR triage at 9am67# Codex: una instrucción de automatización (configura la cadencia en el formulario)8"Días laborables 9am: escanear PRs abiertos, marcar CI fallido o sin revisor, publicar en Triage."
Escribe la condición de parada como un contrato. "All tests in test/auth pass" es un contrato. "Make it better" es cómo un bucle se ejecuta hasta el día de pago.
4. Los worktrees mantienen a los agentes paralelos fuera del camino de los demás
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 a las mismas líneas sin que nadie hable.
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 sub-agente, en el frontmatter de .claude/agents/<name>.md:5# isolation: worktree67# Codex: elige "Worktree" al abrir 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 techo. 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, escritas una vez, por fuera
Un agente comienza cada ejecución en frío y llena cualquier vacío en tu intención con una suposición segura. Una skill es esa intención escrita donde el modelo la lee cada vez, para que deje de adivinar.
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 lo llamas por nombre o cuando tu tarea coincide con su descripción, que es exactamente por qué una descripción plana y literal vence a una ingeniosa.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Leer los fallos de CI de ayer, issues abiertos y commits5 recientes; escribir cada hallazgo en STATUS.md como una tarea.6---71. Obtener CI fallido y agrupar por causa raíz.82. Emparejar cada uno con el issue abierto o commit que lo causó.93. Escribir una tarea en STATUS.md por cada hallazgo real. Ignorar 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, llame 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 en verde por sí solo. Debido a que ambas herramientas hablan MCP, un conector que configuras para una generalmente funciona en la otra.
7. Los sub-agentes mantienen al creador alejado del revisor
El movimiento de mayor valor en cualquier bucle es separar el agente que escribe del agente que revisa.
Un modelo revisando su propio trabajo se aprueba a sí mismo cada vez. Un segundo agente, con instrucciones diferentes e idealmente un modelo diferente, atrapa lo que el primero se convenció a sí mismo.
1# Codex: .codex/agents/reviewer.toml2name = "reviewer"3description = "Revisor adversarial: corrección, seguridad, tests faltantes."4developer_instructions = "Revisa como un dueño. Asume que el autor está equivocado5 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 nuevo decide si el trabajo está terminado. Las segundas opiniones cuestan tokens, porque cada agente ejecuta su propio modelo y herramientas, así que gástalos donde equivocarse es costoso.
8. Cómo se ve un bucle
Pon las seis juntas 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 sub-agente para redactar la solución y un segundo para 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 entrada de triaje. STATUS.md recuerda lo que pasó y lo que aún está abierto, así que mañana comienza donde hoy terminó.
Lo que realmente ves al despertar es un breve informe, no un muro de registros:
1# 9:00am — el informe nocturno del bucle (tu bandeja de entrada Triage)2LISTO PARA FUSIONAR3 PR #218 corregir test inestable en test/charts CI verde4 PR #219 reintentar webhook en 429, agregar test de backoff CI verde5TE NECESITA6 auth/session.ts dos formas seguras de solucionar esto; no elegí ninguna, tú decides7TRANQUILO8 7 ejecuciones programadas no encontraron nada y se archivaron solas
Lo diseñaste una vez. No le diste instrucciones a nada de eso.
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ó rebelde. Fueron dos agentes, un analizador y un verificador, cada uno pidiendo cortésmente al otro más trabajo, sin límite de pasos, sin límite 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 envíes el motor hasta que hayas enviado el pedal de freno.
1# Pon estos ANTES de irte:2- límite de pasos: --max-turns 50 (parada dura, sin excepciones)3- límite de presupuesto: claude -p --max-budget-usd 10 (modo print; 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 = detenerse6- comprobación de hombre muerto: escribir un heartbeat en STATUS.md cada ejecución; el silencio te alerta
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 precio honestamente. 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 extremo está patrocinado. El tuyo no. En un plan de $20 a $200, el bucle que da resultados es pequeño, limitado y apuntado a un trabajo aburrido, no a un enjambre.
1LA DISTRIBUCIÓN 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, sin supervisión5~$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
Cada bucle que falla muere de una de cuatro muertes. Aprende los nombres ahora para que los identifiques a las 3 a.m.
Recursión desbocada. Dos agentes se alimentan mutuamente para siempre. La cura es el límite de pasos y el límite de presupuesto anteriores, nada más ingenioso.
Muerte silenciosa. La ejecución nocturna de un desarrollador alcanzó una ventana de contexto llena, se detuvo, y luego siguió intentando reanudarse contra la misma pared mientras aún parecía vivo. Tu bucle puede estar muerto por horas y aún reportar progreso. La cura es un heartbeat y un contexto nuevo 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. Una suite de tests que pasa es un punto fijo al que puede llegar. "Parece terminado" no lo es.
Deuda de comprensión. Cuanto más rápido un bucle entrega código que no escribiste, más amplia 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 mismo bucle y obtener resultados opuestos. Una lo usa para moverse más rápido en trabajo que entienden hasta los huesos. La otra lo usa para dejar de entender el trabajo por completo. El bucle no puede diferenciarlos. 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 juzgar. Eso es un trabajo más difícil que dar instrucciones, 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 oscilan salvajemente. Mañana por la mañana, toma el trabajo más aburrido que aún haces a mano, triaje de 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 aún leas cada diff que entregue.
Nadie que envíe 200 pull requests al mes comenzó con cien agentes. Comenzaron con un bucle en el que confiaban, y siguieron siendo ingenieros durante todo el camino. Construye ese.
