El loop engineering es un término que lleva apenas unos meses circulando —lo acuñó el ingeniero de Google Addy Osmani en un ensayo publicado en O'Reilly Radar en junio de 2026— pero describe algo que quienes trabajan a diario con agentes de código como Claude Code o Codex ya venían notando: cada vez prompteaban menos a mano y diseñaban más sistemas que promptean por ellos. Como resume Boris Cherny, responsable de Claude Code en Anthropic y citado en ese mismo ensayo: "ya no prompteo a Claude. Tengo loops corriendo que promptean a Claude".
De prompt engineering a loop engineering
La definición que propone Osmani es concreta: loop engineering es diseñar el sistema que prompta, verifica, reintenta y detiene a un agente, en vez de guiarlo tú mismo turno a turno. Un loop, en ese sentido, funciona como un objetivo recursivo: defines un propósito y el agente itera hasta completarlo, sin que nadie tenga que escribir el siguiente mensaje. Es un salto respecto al prompt engineering clásico —elegir bien las palabras de una instrucción— y también respecto al context engineering que lo precedió, centrado en decidir qué información entra en la ventana de contexto en cada momento.
Los cinco ingredientes de un loop
El ensayo de Osmani describe la anatomía de un loop en cinco piezas. Las automations son tareas programadas que descubren trabajo pendiente y lo triagan solas, el "latido" que convierte una ejecución puntual en algo verdaderamente cíclico. Los worktrees son directorios de Git aislados que permiten que varios agentes trabajen a la vez sin pisarse los cambios. Las skills son carpetas de instrucciones reutilizables con el conocimiento y las convenciones del proyecto, para que el agente deje de reexplicarse el mismo contexto en cada sesión. Los connectors —construidos sobre MCP— conectan al agente con herramientas reales (gestores de incidencias, bases de datos, mensajería) para que pueda actuar, no solo sugerir. Y los subagentes y la memoria añaden un reparto de roles entre quien produce el cambio y quien lo verifica, más un almacenamiento externo persistente que recuerda qué está hecho y qué falta.
El problema que resuelve: la ventana de contexto no es infinita
Anthropic lleva meses documentando la parte técnica que hace posible que un loop no se descarrile. En su artículo sobre context engineering describe el "context rot": a medida que crece la ventana de contexto, el rendimiento del modelo se degrada porque la arquitectura transformer genera relaciones n² entre tokens, y la atención se estira más fina. La respuesta pasa por tratar el contexto como un recurso finito: comprimir la conversación cuando se acerca al límite (compaction) conservando las decisiones clave y descartando salidas de herramientas redundantes, dejar que el propio agente lleve notas persistentes fuera de la ventana de contexto —algo tan simple como un NOTES.md que consulta y actualiza—, y delegar trabajo en subagentes especializados que devuelven resúmenes condensados en vez de su historial completo.
Y el que crea: tareas que sobreviven a varias sesiones
Ese mismo problema reaparece cuando una tarea es demasiado larga para una sola ventana de contexto, y ahí entra lo que Anthropic llama un harness: un marco con dos piezas, un agente inicializador que prepara el entorno la primera vez y un agente de codificación que retoma el trabajo en cada sesión posterior con un traspaso claro. Sin un harness bien diseñado, los fallos se repiten siempre igual: el agente da por terminada una tarea antes de tiempo, deja el código en un estado roto sin documentar, marca funciones como completas sin haberlas probado de extremo a extremo, o gasta tokens averiguando en qué punto se quedó en vez de avanzar. La receta que propone Anthropic —una lista de funcionalidades pendientes en JSON, un script de arranque del entorno, un fichero de progreso y verificación real con herramientas de automatización de navegador antes de dar nada por bueno— se parece, no por casualidad, a cómo se organiza un equipo humano que se releva por turnos.
Lo que Osmani advierte que no hay que soltar
El propio autor del término es el primero en poner límites. Un loop que corre sin supervisión es, también, un loop que comete errores sin supervisión. Osmani insiste en tres responsabilidades que siguen siendo humanas por mucho que el bucle sea autónomo: la verificación del resultado sigue siendo tuya, la "deuda de comprensión" crece cuanto más rápido corre el loop —cada ciclo que no revisas es una capa más de código que nadie del equipo entiende del todo—, y el mayor riesgo no es técnico sino de actitud: la "rendición cognitiva" de aceptar lo que produce el loop sin cuestionarlo.
Para quien programa hoy, la conclusión práctica no es sustituir el prompting por loops de la noche a la mañana, sino entender que el trabajo se está desplazando: menos tiempo escribiendo el próximo mensaje, más tiempo diseñando el sistema que decide cuándo parar, cómo verificar y qué hacer cuando algo sale mal.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!