« Loop engineering »: ¿nueva disciplina o relanzamiento de los *cron jobs*?

El término *monte*, la encuesta de The Pragmatic Engineer concluye con una mezcla de *triggers*, *cron jobs* y *slop* de LLM. Queda una verdadera pregunta de fondo: ¿quién posee la robustez de un bucle de observar-decidir-actuar alimentado por LLM?

El hecho

The Pragmatic Engineer (Gergely Orosz) publica el 14/07/26 una encuesta sobre el término « loop engineering », que ha resurgido en el vocabulario de los equipos de IA. Su conclusión, resumida al inicio del artículo: bajo la palabra, se esconde una mezcla de triggers, cron jobs, orquestación LLM y « slop » —y un toque de efecto moda.

Nuestra lectura

La palabra no es nueva. Lo que sí lo es un poco más es lo que condensa: cuando un sistema repite en bucle un ciclo observar → decidir → actuar alimentado por un LLM, ¿quién asume la responsabilidad de la robustez de ese bucle? No el modelo, que no tiene estado entre turnos. No el DevOps clásico, que desconoce el no determinismo fino. Surgue un nuevo nicho: instrumentar los runs, contener las derivas, gestionar los retries idempotentes, medir el costo por turno, prever el rollback cuando una decisión afecta a un sistema externo. Estos temas ya los trata el SRE de agentes —el vocabulario solo busca nombrarlos, lo que es señal de adopción más que de moda.

A vigilar

La verdadera señal no será la proliferación de herramientas que lleven la palabra « loop » en su página de aterrizaje. Será la aparición de postmortems públicos que hablen explícitamente de « fallo en el bucle » —deriva, retry-storm, bucle costoso— en lugar de « alucinación ». Ese día, la disciplina habrá cuajado.