Durante dos años, sacarle más provecho a un agente de IA significaba escribir un mejor prompt.
Esa era está terminando silenciosamente. Los mejores ingenieros del mundo dejaron de escribir prompts hace tiempo y empezaron a escribir bucles: sistemas que le indican al agente qué hacer, verifican el resultado y siguen ejecutándose hasta que el trabajo esté terminado.
El script nocturno de Karpathy encontró 20 optimizaciones que él había pasado por alto en dos décadas de ajustes manuales. Boris Cherny, quien construyó Claude Code, no ha escrito una sola línea de código este año. Los ingenieros de Anthropic ahora fusionan casi 8 veces más código por día que en 2024.
Ninguno de ellos escribió nada más inteligente. Simplemente dejaron de escribir.
Esto es lo que realmente es un bucle, cuándo lo necesitas, cuándo no, y cómo construir el primero.
700 experimentos mientras el humano dormía
Marzo de 2026. Andrej Karpathy sube tres archivos a GitHub. Alrededor de 630 líneas de código.
Un archivo contenía el modelo. Otro lo puntuaba. El tercero le decía al agente qué explorar y qué dejar en paz. El agente solo podía tocar el archivo de entrenamiento. Nada más.
El ciclo era aburrido a propósito. Leer el código, proponer un cambio, entrenar durante cinco minutos, verificar si la puntuación mejoraba, conservar el cambio si era así, revertirlo si no, y luego repetir.
Lo apuntó a un modelo que él mismo había ajustado manualmente durante dos décadas. Lo dejó correr durante dos días.
Ejecutó 700 experimentos. Encontró 20 mejoras. Una de ellas era un multiplicador escalar faltante en el mecanismo de atención, sutil, no el tipo de error que un linter detectaría, pero exactamente el tipo de cosa que un ingeniero cuidadoso podría haber encontrado y nunca lo hizo.
El CEO de Shopify ejecutó el mismo truco durante la noche en un modelo interno. Se despertó con una mejora de calidad del 19 por ciento en un modelo la mitad del tamaño del anterior.
La conclusión no es "la IA es más inteligente". Los humanos se cansan después del experimento doce. Los bucles nunca se cansan.
Un bucle no es un prompt programado
La mayoría de la gente escucha "bucle" y piensa en cron. Eso se pierde todo el punto.
Un prompt es una instrucción. Un bucle es un objetivo hacia el cual la IA trabaja hasta alcanzarlo, sin nadie al mando. Planifica, ejecuta, verifica su propio resultado, lo retroalimenta y repite.
Cinco etapas: descubrir, planificar, ejecutar, verificar, iterar. Tres de ellas hacen el trabajo real.
El verificador es el corazón del bucle. Sin una puerta real en la salida, no tienes un bucle, tienes al agente calificando su propia tarea para siempre. Una puerta es una prueba que pasa o falla, una compilación que compila o falla, un linter que devuelve cero o distinto de cero. No un segundo agente con una opinión.
El estado es lo que hace que el bucle aprenda. Un archivo lateral, un tablero Linear, un registro del proyecto, en algún lugar fuera de la conversación que registre lo que se intentó y lo que falló. La ejecución de mañana se reanuda en lugar de empezar desde cero.
Una condición de parada es lo que lo mantiene sensato. Todo bucle real tiene dos salidas: el objetivo se cumple, o se activa un límite máximo. Omite esto y has construido una máquina que funciona toda la noche para nada.
Si falta cualquiera de los tres, no has construido un bucle. Has construido un script caro.
Las cuatro condiciones antes de construir uno
Los bucles solo justifican su costo cuando cuatro cosas son ciertas al mismo tiempo. Si falta una, la configuración toma más de lo que devuelve.
- La tarea se repite al menos semanalmente. Menos que eso y el costo de configuración nunca se amortiza.
- Algo puede fallar automáticamente el trabajo. Una prueba, una verificación de tipos, un linter, una compilación.
- Tu presupuesto de tokens puede absorber el desperdicio. Los bucles releen el contexto, reintentan, exploran.
- El agente tiene herramientas de ingeniero senior. Registros, un entorno de reproducción, la capacidad de ejecutar el código que escribe y ver qué falla.
La versión honesta, la parte que nadie que venda bucles te dirá: la mayoría de la gente todavía no necesita la versión pesada. Si estás en un plan de consumo intentando ejecutar bucles de verificación nocturnos en trabajo serio, la factura de tokens llega antes que la ganancia de productividad.
Los primeros bucles buenos son los aburridos. Triaje de CI. Actualizaciones de dependencias. Pasadas de lint y corrección. Reproducción de pruebas inestables. Borradores de incidencia a PR en una base de código con pruebas sólidas ya establecidas.
Los primeros bucles malos son los interesantes. Reescribir la arquitectura. Código de autenticación. Pagos. Cualquier cosa donde "terminado" sea una decisión subjetiva y un humano aún tenga que opinar.
Los cinco bloques que hacen real un bucle
Todo bucle real se ensambla a partir de las mismas cinco piezas. Claude Code y Codex ya las incluyen todas.
El primero es la automatización. El latido. Algo que activa el bucle según un horario o un evento. /loop se ejecuta en una cadencia. /goal continúa hasta que se cumple una condición que definiste. Sin un latido, el bucle es un script que ejecutaste una vez y olvidaste.
El segundo es una habilidad. Conocimiento del proyecto guardado como un archivo claude-md que el agente lee en cada ejecución. Sin él, el bucle vuelve a derivar tu contexto desde cero en cada ciclo. Con él, la intención se acumula. El bucle conoce tus convenciones, tus pasos de compilación, lo que nunca haces debido a ese incidente de hace tres meses.
El tercero son los subagentes. El creador y el verificador no pueden ser el mismo modelo. El que escribió el código es demasiado generoso al calificar su propio trabajo. El que escribió el artículo pasa por alto sus propias secciones débiles. Escritor rápido y barato. Revisor lento y estricto. Esa separación es la mayor parte de la calidad.
El cuarto son los conectores. El bucle abre la solicitud de extracción, cierra el ticket, notifica al canal cuando CI se vuelve verde. Esta es la diferencia entre un agente que dice "aquí hay una solución sugerida" y un informe esperándote por la mañana que dice que el PR ya está fusionado.
El quinto es el verificador. La prueba, verificación de tipos o compilación que falla automáticamente el trabajo malo. Todo lo demás es fontanería. Este es el bloque que decide si el bucle te ayuda o solo gasta tu dinero.
Apila estos y obtienes lo que los equipos serios ahora ejecutan a escala. Docenas de bucles, cada uno encargado de un trabajo estrecho, ejecutándose uno al lado del otro mientras todos duermen. Un ingeniero usó un bucle de flota como este para reescribir una base de código completa de un idioma a otro en unos seis días, un trabajo que habría llevado cerca de un año a mano.
Donde los bucles fallan en silencio
Los bucles no fallan. Te facturan en silencio. Dos modos de fallo que vale la pena nombrar, ambos empeoran a medida que el bucle mejora, no se vuelven más fáciles.
El primero es el bucle de Ralph Wiggum. El ingeniero Geoffrey Huntley lo documentó. El agente decide que ha terminado demasiado pronto, emite la señal de finalización en un trabajo a medio terminar, y el bucle sale satisfecho. Sin una puerta objetiva, el bucle sigue ejecutándose la noche siguiente, sigue gastando, sigue produciendo trabajo que nadie aceptará.
La solución no es un agente más inteligente. Es una puerta más tonta. Una prueba que pasa o falla. Una compilación que compila o no. Algo sin opinión.
El segundo es más sutil. Deuda de comprensión. Cuanto más rápido el bucle entrega código que no escribiste, mayor es la brecha entre lo que tu repositorio contiene y lo que realmente entiendes. Un bucle que funciona sin problemas cobra intereses compuestos sobre esa brecha. El día que tengas que depurar un sistema que nadie en el equipo ha leído cuesta más que los tokens.
La rendición cognitiva viene con ello. Cuando el bucle se ejecuta solo, es tentador dejar de formarse una opinión y aceptar lo que sea que devuelva. Diseñar el bucle es la cura cuando lo haces con juicio. Es el acelerante cuando lo haces para evitar pensar. Misma acción, resultado opuesto.
Dos personas pueden construir exactamente el mismo bucle y terminar en lugares opuestos. Uno lo usa para moverse más rápido en el trabajo que entiende profundamente. El otro lo usa para evitar entender el trabajo por completo. El bucle no sabe la diferencia. Tú sí.
Empieza con un bucle, no con diez
El error que todos cometen es intentar construir todo el sistema el primer día. Diez bucles, un panel de control, una flota. Se derrumba para el fin de semana porque no puedes distinguir qué bucle hizo qué.
Empieza con uno. Elige la tarea recurrente más molesta que tengas, lo que revisas cada mañana por costumbre, y convierte ese único trabajo en un bucle. Déjalo correr durante unos días. Observa dónde se excede. Observa dónde falla. Ajusta. Luego añade el segundo.
El orden importa más que las herramientas. Primero, haz que una ejecución manual sea confiable, no rápida, confiable. Convierte esa ejecución en una habilidad claude-md. Envuelve la habilidad en un bucle con una puerta objetiva y una condición de parada forzada. Y luego, solo entonces, ponlo en un horario. Saltar adelante, programar algo que no has hecho confiable a mano, es exactamente cómo los bucles explotan mientras duermes.
La métrica que decide si el bucle está funcionando no son los tokens gastados, ni las tareas intentadas, ni los PR abiertos. Es el costo por cambio aceptado. Si tu tasa de cambios aceptados está por debajo del 50 por ciento, estás haciendo el trabajo de revisión que se suponía que el bucle eliminaría, y el bucle está perdiendo.
Karpathy dejó de escribir código de entrenamiento. Cherny dejó de hacer prompts. Ninguno de ellos dejó de pensar. Si te llevas algo de esto, que sea esto. El bucle es un sistema que hace el aburrido 95 por ciento mientras mantienes toda tu atención en el 5 por ciento que realmente conlleva riesgo.
Estás pagando por una flota de agentes y usando una sola ventana de chat.
Sígueme y suscríbete a mi canal de Telegram: https://t.me/+75nMf005jRpjMDU1
