Ingeniería de bucles: los bucles ganan donde verificar es barato

Boris Cherny, el ingeniero que creó Claude Code, mantiene de cinco a 10 sesiones abiertas con unos cientos de agentes corriendo durante el día y unos miles corriendo cada noche.² Cuando esta semana se difundió por X un clip suyo diciendo “ya no le doy prompts a Claude… mi trabajo es escribir bucles”, la mayoría de los comentarios trataron la frase como una profecía sobre el desarrollo de software autónomo, y en cuestión de días Addy Osmani le había puesto nombre a una disciplina: ingeniería de bucles.⁷ Saqué las transcripciones completas de las tres charlas detrás del clip. Las transcripciones cuentan una historia más serena, y la versión serena es la que vale la pena construir: cada bucle que Cherny menciona realmente tiene una condición de éxito que una máquina puede comprobar gratis. El costo de verificar, no la construcción del bucle, decide qué puedes automatizar. Llevo corriendo bucles en producción desde febrero, y mis registros coinciden con las transcripciones, incluidos dos incidentes en los que me enseñaron la lección por las malas.

TL;DR / Puntos clave

• La cita viral viene de la entrevista de Cherny en Acquired Unplugged, donde plantea los bucles como el siguiente paso de un continuo que va de las tarjetas perforadas al ensamblador, a los lenguajes de alto nivel y a los prompts.¹ Le da una vida útil corta a la transición: “los próximos meses y quizás durante el resto del año.”¹
• La mecánica es mundana a propósito. En su charla en Sequoia, Cherny describe /loop como Claude usando cron para programar un trabajo que se repite.² Los bucles que menciona cuidan pull requests, mantienen sano el CI y agrupan la retroalimentación de Twitter cada 30 minutos.²
• Cada uno de esos bucles es de mantenimiento. Cada uno tiene un estado final comprobable por máquina: CI en verde, PR rebaseado, retroalimentación agrupada. Ninguno de sus ejemplos construye funciones sin supervisión.
• El trabajo de escribir bucles ya se está disolviendo dentro del modelo. Cherny cuenta que los modelos más nuevos inician bucles por iniciativa propia, y llama a la construcción de bucles del lado del usuario “un problema de diseño de producto” que significa “no estoy haciendo un buen trabajo.”⁵
• La habilidad duradera bajo el meme: decidir qué es seguro automatizar sin supervisión. Esa decisión es un juicio sobre verificabilidad, y se queda contigo después de que la sintaxis del bucle desaparezca.

Lo que dijo realmente

El clip que todos compartieron salió de una entrevista en vivo de Acquired. Cherny prepara la frase con historia familiar: su abuelo programaba con tarjetas perforadas en la Unión Soviética, y su padre escribía ensamblador y “se habría burlado de mí por escribir Python.” Luego viene la parte que viajó:

“Esta es la naturaleza de la programación: el nivel de abstracción siempre sube… La forma en que programaba hace un año era escribir código con algún tipo de autocompletado en un IDE. En noviembre desinstalé mi IDE, porque no lo estaba usando… En ese momento corría quizás cinco, diez Claudes en paralelo, y programar era darle prompts a Claude para que escribiera código. Ahora subió de nivel otra vez… a un punto donde ya no le doy prompts a Claude. Tengo bucles corriendo. Ellos son los que le dan prompts a Claude y, en cierto modo, deciden qué hacer. Mi trabajo es escribir bucles.”¹

La entrevista completa de Acquired Unplugged; el pasaje de los bucles empieza en el minuto 11:14.

Dos detalles de la transcripción completa nunca llegaron a los clips. Primero, Cherny mismo le pone fecha a la transición: los bucles son lo que “vamos a ver en los próximos meses y quizás durante el resto del año.”¹ Describe una fase, no un destino. Segundo, una nota sobre las fuentes para quien quiera rastrear el debate: varias publicaciones virales atribuyeron el material de los bucles a su aparición de una hora en el podcast de Y Combinator. Revisé la transcripción completa de ese episodio. No contiene ni una sola mención a los bucles; el episodio trata sobre el origen del producto y los subagentes.⁶ La sustancia vive en la entrevista de Acquired y en una charla de 24 minutos en Sequoia.

Un bucle es un trabajo de cron

La charla de Sequoia aporta la mecánica, y es deliberadamente aburrida:

“Lo único que hay que hacer es que Claude use cron para programar un trabajo en algún punto del futuro, y es un trabajo que se repite. Y puede correr cada minuto, cada cinco minutos, cada día.”²

La charla de Sequoia aporta cada detalle mecánico que los clips virales omitieron; la sección de los bucles empieza en el minuto 7:56.

Cherny corre docenas de estos. Los que menciona: un bucle que cuida sus PRs (arregla el CI, hace rebase automático), un bucle que mantiene sano el CI (repara tests inestables) y un bucle que extrae retroalimentación de Twitter y la agrupa cada 30 minutos.² Routines, anunciado en el evento Code with Claude de Anthropic en mayo, lleva el mismo patrón al lado del servidor para que el bucle sobreviva a una laptop cerrada.² Simon Willison, haciendo un blog en vivo de la keynote, registró el marco que la propia Anthropic usa: las Routines son “prompts de orden superior.”¹² Cherny llevaba meses diciéndole a la gente que /loop y /schedule eran dos de las funciones más potentes del producto; su ejemplo inicial canónico es un bucle de cinco minutos que cuida los PRs.¹¹

El patrón tiene un antepasado más rústico. La técnica de Ralph Wiggum de Geoffrey Huntley es, en sus propias palabras, “Ralph es un bucle de Bash”: un while true que le pasa a un agente el mismo archivo de prompt para siempre, con el progreso persistiendo en archivos y en el historial de git entre iteraciones.⁹ Anthropic ahora distribuye Ralph como un plugin oficial que intercepta los intentos de salida del agente y le vuelve a pasar el prompt hasta que aparece una cadena de finalización o se alcanza un tope de iteraciones.⁹ The Register confirmó que Cherny usa Ralph él mismo, y citó la advertencia de Huntley sobre adónde lleva la economía de esto: las startups usarán la técnica para clonar negocios SaaS existentes y dejarlos por debajo de precio, porque programar con agentes cuesta alrededor de 10 dólares la hora.¹⁰ El linaje importa porque muestra la verdadera antigüedad de la idea: el bucle es la estructura de control más vieja de la computación, y no hay nada novedoso en el constructo en sí.¹⁵

Cada bucle que menciona es de mantenimiento

Aquí está la observación que el debate se saltó. Enumera de nuevo los bucles de Cherny y fíjate en sus estados finales:

Cada uno tiene una condición de éxito comprobable por máquina o produce una salida donde los errores no cuestan nada. Ninguno de sus ejemplos es “construye la función mientras duermo.” El hombre que corre unos miles de agentes cada noche describe su automatización personal como reparación de CI, rebase y triaje de retroalimentación.

El aparente contraejemplo confirma la regla. El propio equipo de ingeniería de Anthropic corrió 16 agentes en bucles infinitos durante dos semanas y produjo un compilador de C de 100.000 líneas en Rust, a un costo de cerca de 20.000 dólares en cómputo.⁸ Un compilador es el artefacto más verificable que existe en el software: una suite gigantesca de programas que o compilan y corren correctamente, o no. El equipo eligió un objetivo donde verificar es casi gratis y, aun así, Nicholas Carlini, quien dirigió el experimento, escribió que el hecho de que los programadores desplieguen software que nunca verificaron personalmente es “una preocupación real.”⁸

El ensayo de Addy Osmani que bautiza la disciplina como “ingeniería de bucles” aterriza en la misma restricción desde el lado del diseño: “Un bucle corriendo sin supervisión es también un bucle cometiendo errores sin supervisión.”⁷ Su arquitectura propuesta (agentes verificadores separados, para que el que produce nunca califique su propio trabajo) es un intento de fabricar verificación barata donde no ocurre de forma natural.⁷

Lo que me enseñaron mis propios bucles

Escribí sobre mi sistema de agentes nocturnos en febrero, cuando el término educado para la técnica todavía era una referencia a Los Simpson.¹⁶ Desde entonces, los bucles que sobrevivieron en mi montaje convergieron todos en la misma forma, y los que fracasaron me enseñaron más que los que funcionaron.

Los sobrevivientes tienen forma de comprobación. Un bucle nocturno lee los commits del día, mapea los archivos tocados a URLs en vivo, carga cada página afectada e informa si pasa o falla, con los tiempos de carga. Un bucle de seguridad vigila los endpoints durante la noche y escribe un informe matutino. Un bucle de rastreo lee la actividad de Googlebot y Bingbot en mis propiedades e informa la deriva de indexación. Ninguno de estos crea nada. Cada uno observa, compara contra un estado esperado e informa. Cuando uno falla, el costo es un reporte desactualizado, no un producto roto. La lectura matutina toma minutos porque la salida es binaria por elemento: pasa, falla, mira aquí.

Los fracasos fueron bucles que actuaron. Una función de aislamiento que creaba automáticamente worktrees de git para agentes en paralelo borró dos veces directorios de trabajo temporal que decidió que eran descartables; el radio de impacto de la automatización incluyó archivos que no creó y no entendía. Una purga de caché programada corrió una vez en el orden equivocado respecto a un deploy, y los crawlers de búsqueda pasaron 11 horas recibiendo 404s por páginas que existían, porque la purga desalojó respuestas correctas en caché antes de que el origen sirviera sus reemplazos.¹⁶ Ninguno de los dos fracasos vino de un mal modelo. Ambos vinieron de que yo le otorgué acceso de escritura a un bucle cuyas precondiciones no había fijado. Cada uno tiene ahora una protección: la automatización de worktrees está bloqueada por completo, y las purgas solo corren después de que la verificación del deploy pasa. La regla general que extraje: un bucle que solo lee necesita un horario; un bucle que escribe necesita una prueba de ordenamiento y un límite de radio de impacto antes de ganarse el horario.

Esa regla también explica la parte del montaje de Cherny que a la gente le cuesta más creer. “Ahora, en realidad, la mayor parte de mi trabajo lo hago desde el teléfono”, dice, corriendo sesiones a través de la pestaña de código de la app de Claude.² Un teléfono es un lugar terrible para revisar código y un buen lugar para leer un reporte de pasa/falla. La afirmación del teléfono es una afirmación sobre verificación disfrazada: sus bucles emiten una salida lo bastante legible como para aceptarla o rechazarla de un vistazo, lo cual solo es posible cuando las condiciones de éxito se diseñaron antes de que el bucle empezara a correr.

La escalera del costo de verificación

Si la tesis se sostiene, elegir qué automatizar se reduce a una sola pregunta: ¿quién verifica el resultado, y cuánto cuesta esa verificación? Esta es la escalera que uso antes de darle un horario a cualquier tarea.

La columna que decide es la segunda, y la dificultad de la tarea nunca aparece en ella. Una tarea difícil con un verificador gratis (el test inestable) se automatiza antes que una tarea fácil con uno caro (un cambio de copy de una línea que un humano debe aprobar). Los bucles de Cherny, el compilador de Anthropic y mis sobrevivientes se ubican todos en la mitad superior de la escalera; el comentario viral asumió la mitad inferior.

La forma que sobrevive a la escalera se parece a un único patrón de supervisor, sin importar la escala:

La anatomía de un bucle que se gana su horario. El verificador está dibujado con trazo más grueso porque es la caja que carga el peso: quítalo y el bucle sigue corriendo, pero nadie sabe qué hizo.

El bucle más pequeño que vale la pena correr es de solo lectura, se autoverifica y es legible de un vistazo, lo que lo hace seguro de escribir hoy y aburrido de mirar mañana:

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Dentro de Claude Code, el mismo bucle es una sola línea: /loop 24h seguido de la instrucción. La promoción viene después. Cuando el reporte lleva un mes siendo aburrido, el bucle se ha ganado que se considere subirlo al siguiente peldaño de la escalera, y no antes.

El trabajo que queda

El pasaje más extraño de la charla de Sequoia socava el meme que él mismo engendró. Cherny dice que los modelos más nuevos empezaron a iniciar bucles sin que se les pidiera: él solicita una consulta de datos, y el modelo nota que los datos cambian con el tiempo, propone un reporte recurrente cada 30 minutos, y conecta el reporte a Slack por su cuenta.⁵ Su conclusión: “No es responsabilidad de los usuarios descubrir cómo sostener mejor las herramientas… en realidad es un problema de diseño de producto y no estoy haciendo un buen trabajo.”⁵ El argumento de la regresión que los escépticos plantearon en X (si hoy los humanos escriben los bucles, mañana los modelos escribirán los bucles) resulta ser la hoja de ruta de Anthropic, concedida por la persona de la que trata el meme.

Va más lejos: “A medida que el modelo ha mejorado, la capa intermedia se vuelve menos importante”, prediciendo que los modos de permisos, las defensas contra inyección de prompts y los puntos de control con humano en el bucle se desvanecen a medida que mejora la alineación.³ Tomaré el otro lado de la mitad de esa apuesta. El andamiaje de seguridad puede encogerse. El andamiaje de orquestación se está convirtiendo en todo el trabajo, según sus propias palabras: los agentes de los ingenieros de Anthropic se coordinan entre sí por Slack mientras sus dueños trabajan, y “ya no tenemos código escrito a mano en ninguna parte de la empresa. Todo el SQL lo escriben los modelos.”⁴ Alguien decide qué pueden tocar esos agentes, qué cuenta como terminado, y qué pasa cuando dos de ellos no están de acuerdo. Esa capa de decisión es la verdadera interfaz del agente, y cron es la parte fácil.

Así que la habilidad duradera no es la sintaxis de los bucles, que el modelo ya está absorbiendo, ni los prompts, que los bucles absorbieron primero. La habilidad duradera es el juicio que está debajo de ambos: decidir qué es seguro automatizar sin supervisión. Esa decisión es siempre una pregunta sobre el costo de verificación. La reparación del CI se automatizó primero porque la suite de tests ya era el verificador. El agrupamiento de retroalimentación se automatizó porque los errores son gratis. El desarrollo de funciones se resiste porque verificar todavía cuesta que un humano lea el diff, y un ingeniero senior en Hacker News expuso la trampa resultante sin rodeos: la herramienta requiere un juicio experto para dirigirla, y usar la herramienta erosiona justamente ese juicio.¹⁴

La entrevista de Casey Newton para Platformer con Cherny salió bajo el titular “El creador de Claude Code sobre el fin del ingeniero de software.” En ella, Cherny predice que el título de “ingeniero de software” se disuelve en algo parecido a “constructor” para fin de año, mientras que el número de personas que escriben código a través de agentes crece cien veces.¹³ Los constructores, en ese pronóstico, son las personas que eligen los bucles. Elegir bien significa saber, antes de que algo corra, cómo sabrás que funcionó.

Puntos clave

Para ingenieros que corren agentes de programación: - Audita tus candidatas a automatización por costo de verificación, no por entusiasmo. La reparación de CI, el rebase, el monitoreo y la generación de reportes tienen verificadores gratis hoy; automatiza esas primero. - Aplica la división lectura/escritura: un bucle de solo lectura necesita un horario, mientras que un bucle con acceso de escritura necesita una restricción de ordenamiento explícita y un límite de radio de impacto antes de correr sin supervisión. - Diseña el reporte antes que el bucle. Si no puedes rechazar la salida del bucle desde tu teléfono en 10 segundos, el bucle no está listo para correr de noche.

Para líderes de equipo: - Tu ancho de banda de revisión, no tu número de agentes, es el techo del paralelismo útil. Agregar agentes más allá de ese techo produce merges sin revisar, no rendimiento. - Separa a los productores de los verificadores. Un agente que verifica su propio trabajo afirma corrección; un verificador separado, con un punto de vista distinto, tiene al menos una oportunidad de atrapar esa afirmación.

Para quienes construyen herramientas: - Cherny llama a la construcción de bucles del lado del usuario un fracaso de diseño de producto, y los modelos ya están iniciando bucles por sí mismos.⁵ Construir una UX para escribir bucles significa construir para una capa que el proveedor del modelo pretende absorber. La superficie más longeva es la verificación: evidencia, trazas y la ergonomía de aceptar/rechazar.

Preguntas frecuentes

Referencias