Hay un discurso nuevo dando vueltas en X: el del loop. Tres voces lo articulan casi al mismo tiempo y desde lados muy distintos del campo.
Peter Steinberger lo plantea como recordatorio mensual: "ya no deberías estar prompteando agentes de programación. Deberías estar diseñando loops que los prompteen". Boris Cherny, miembro del equipo de Claude Code en Anthropic, refuerza el mismo punto: "ya no le prompteo a Claude. Escribo loops y los loops hacen el trabajo".
Andrej Karpathy lo lleva un paso más arriba en un video sobre Autoresearch. La idea, en sus palabras, es sacarse a uno mismo del bottleneck: "no podés estar ahí para promptear lo siguiente. Tenés que salirte del medio. Tenés que arreglar las cosas para que sean completamente autónomas y mientras más sepas cómo maximizar tu throughput de tokens y no estar en el loop, mejor".
¿Qué es Loopcraft y por qué importa?
La newsletter AINews, hoy una sección de Latent Space, bautizó la práctica como Loopcraft: el oficio de apilar loops. La tesis es que ya operamos dentro de muchos loops sin notarlo —chat, edición, pull request, deploy— y que la pregunta verdadera es a qué nivel poner la atención.
En la fase temprana de cada tecnología, dice AINews, conviene saber bajar un loop cuando algo falla, por confiabilidad. Pero a medida que los modelos mejoran, conviene subir un loop más arriba, por leverage. Karpathy lo sintetiza así: "no quiero ser el investigador en el loop mirando resultados. Estoy frenando al sistema. Entonces la pregunta es: cómo refactorizo las abstracciones para arreglar las cosas una vez y apretar go".
La "Salty Lesson" para agentes
Richard Sutton tiene su Bitter Lesson para modelos: lo que escala vence a lo que se diseña a mano. AINews propone su contraparte para agentes, la Salty Lesson:
"No arregles las cosas vos mismo, como hacías antes. Enfocate en sistemas que escalan con más agentes, como metas y orquestación."
La traducción práctica al trabajo diario tiene varias capas. El loop interno es la pregunta-respuesta clásica: el desarrollador escribe un prompt, el agente devuelve un parche, el desarrollador valida. El loop intermedio automatiza ese ciclo en un proceso que dispara al agente, valida con tests, intenta de nuevo si falla, hasta cerrar el ticket. El loop externo —el más interesante— vigila múltiples tickets a la vez, asigna agentes a cada uno, mide costo en tokens y latencia, escala recursos según el resultado.
¿Qué cambia para un equipo de ingeniería?
El cambio operativo concreto es desplazar la inversión de "prompt engineering" hacia orquestación. Eso implica infraestructura clásica de software: colas de tareas, reintentos exponenciales, observabilidad de tokens consumidos por loop, presupuestos de gasto por ticket. Herramientas que no son nuevas, pero que ahora ganan importancia.
También implica un cambio cultural más profundo: dejar de medir la productividad del equipo en commits hechos por humanos y empezar a medirla en outcomes producidos por loops supervisados. Es el mismo salto conceptual que en su momento exigió pasar de "líneas de código por hora" a "features por sprint", pero llevado un escalón más arriba.
Para quien recién está adoptando Claude Code o Codex en su pipeline, la lectura es directa: el siguiente nivel de productividad no está en escribir prompts más finos. Está en pensar el proceso completo como una arquitectura de loops anidados y decidir, para cada nivel, si conviene bajar por confiabilidad o subir por leverage.
