25 de agosto de 2026 # Loop engineering, dos meses después: qué es un bucle y cuándo compensa montarlo  En junio escribíamos por aquí sobre *loop engineering*, cuando la palabra llevaba poco circulando. [[Newsletter/2026/86-Loop-engineering-vs-prompt-engineering|Aquel texto iba de qué es un bucle]] y de quién está en condiciones de montar uno. Desde entonces tengo cuatro artículos más sobre bucles guardados en la carpeta de recortes, y dos de los cuatro son publicidad. Publicidad sin disimular, además. Uno explica bastante bien qué es un bucle durante seis apartados para intentar venderte un bot de Telegram. El otro hace exactamente lo mismo y termina en un comando de instalación de no-se-qué aplicación. La estructura es idéntica en los dos: la parte buena es el cebo, el producto va al final, y por el camino te has creído que estabas aprendiendo. Es el formato del momento y lo vamos a ver mucho este otoño. Los otros dos sí valen. Uno es del equipo de Claude Code y va de lo práctico; lo tenéis [[El Abismo de Máquina/Ecos/2026.08/Eco-Getting-Started-With-Loops|entero y resumido aquí al lado]], en un Eco. El otro es un ensayo que se mete con el bucle justo por donde no funciona bien. Entre los dos contestan a lo que se me quedó colgando en junio: vale, muy bien, ¿y yo qué hago con esto? ## Un bucle es poner a la máquina a trabajar por tí  El equipo de Claude Code publicó su definición a finales de junio, tres semanas después del tuit que armó todo el ruido, y es la menos épica de todas las que circulan: **un bucle es un agente repitiendo ciclos de trabajo hasta que se cumple una condición de parada**. Ya está. A partir de ahí clasifican cuatro tipos según cómo arrancan y cómo se detienen. Lo bueno no es la clasificación. Es que cada tipo es un trabajo concreto que podemos delegar a la IA: - **Por turnos.** Dejas de comprobar tú. Escribes el prompt, el agente trabaja y decide él si ha terminado. Es lo que ya hacemos todos los días sin llamarlo bucle. - **Por objetivo.** Dejas de dar tú el visto bueno. Tú escribes qué es estar terminado, y un modelo evaluador le devuelve el trabajo cada vez que intenta terminar antes de tiempo. El ejemplo que ponen: sube la puntuación de la página a 90 o más, y ríndete a los cinco intentos. - **Por tiempo.** Dejas de lanzarlo tú, y a partir de ahí se lanza solo cada equis minutos. Si corre en tu portátil, muere cuando lo apagas; si lo subes a la nube, no. - **Proactivo.** Dejas hasta de escribir el prompt. Lo dispara un evento o un horario, no hay nadie delante, y cada tarea termina cuando cumple su objetivo. Puesto así, *"montar un bucle"* deja de sonar a proyecto de ingeniería y pasa a ser una pregunta que os podéis hacer esta tarde: de estas cuatro piezas, ¿cuál podría dejar de hacer yo y delegársela a la IA en forma de petición-bucle? Muchas veces la respuesta es ninguna, y tampoco pasa nada. Ellos lo dicen en la entradilla, antes de explicar nada: no todas las tareas necesitan un bucle complicado, empezad por lo más simple y usad estos patrones con cuentagotas. Leer eso en 2026 ya es raro, y que lo escriba el fabricante, más. ## La pieza cara es la comprobación  De las cuatro, la primera es la que más cuesta dejar de hacer y la que más da si sale bien. Un agente que hace el trabajo y decide él solo que está bien es un becario muy rápido al que nadie corrige. Y ya sabemos cómo acaba eso. La receta que dan no tiene ningún misterio: coge la comprobación que haces tú a mano y escríbela en un fichero, paso por paso, para que el agente la ejecute entera antes de decir que ha terminado. En su ejemplo, para un cambio de interfaz: arranca el servidor, abre la página, pulsa el botón, captura antes y después, comprueba que la consola no tiene errores nuevos, mide el rendimiento. Y si falla cualquier paso, vuelve al primero. Cuanto más medible es la comprobación, menos margen tiene el agente para darse el aprobado. La segunda parte de la receta me parece todavía más útil: que revise otro agente distinto, con el contexto limpio. El que ha escrito el trabajo llega al final convencido de su propio razonamiento, y eso le pasa a la máquina igual que nos pasa a nosotros. > Aquí hablo de lo mío, que es un caso pequeño. Este verano, mientras los chavales aprendían a *farmear aura*, yo he estado jugando con *vibe coding* para hacerme un par de plugins de Obsidian, y el código era la parte fácil. Lo que me comía el tiempo era probarlos: abrir el plugin, activar una opción, desactivar otra, comprobar que no se rompía nada, y otra vez lo mismo con el cambio siguiente. Con unos pocos ajustes ya salen más combinaciones de las que vas a repasar tú a mano. > > Así que dejé de probarlos yo. El método que acabé usando era pedirle al agente que abriera Obsidian él mismo, con Computer Use -la función que le deja manejar el ordenador como lo manejaríais vosotros, moviendo el ratón y pulsando-, y que recorriera todas las combinaciones posibles de la interfaz antes de decirme que había terminado. Es la misma comprobación que hacía yo a mano, escrita para que la ejecute otro, y además se puede medir sin discusión, porque o ha pasado por todas las combinaciones o no ha pasado. Y hay una frase del artículo que me gustaría que se leyera en más sitios: cuando un resultado no da la talla, no te quedes en arreglar ese resultado, intenta dejarlo escrito en el sistema para todas las vueltas siguientes. Eso es lo que separa un bucle que mejora de un bucle que solo repite trabajo. ## Un bucle solo ve su número  El otro artículo es un ensayo, no lleva producto detrás, y empieza con un caso que os va a sonar. Un equipo de soporte monta su primer bucle de mejora sobre el chatbot de atención al cliente. Eligen una medida, el porcentaje de tickets resueltos, la miden cada semana y ajustan el bot cada vez que el número baja. Cinco meses seguidos subiendo. Entonces llegan los datos de renovación y resulta que los clientes se están yendo al doble de velocidad que antes. El bot había aprendido a resolver tickets cerrando conversaciones deprisa, poniendo difícil que el cliente contestara y dando por solucionado lo que en realidad la gente había abandonado. El bucle funcionaba perfectamente. El número subía. Y por eso mismo salía mal, porque un bucle solo ve su medida, y esa medida hacía meses que había dejado de significar lo que todos creían. Esto es la ley de Goodhart de toda la vida, de la que ya hablamos aquí con [[Posts/2026.08/04-El-efecto-cobra-en-las-métricas-de-IA|el efecto cobra]]: premias una medida y el sistema te produce esa medida. Lo nuevo es la velocidad. Un equipo humano tarda trimestres en aprenderse las trampas de un indicador; un bucle bien montado tarda unas semanas, y encima no se cansa ni se va de vacaciones en agosto. El ensayo cuenta cuatro formas de fallar, y de las cuatro hay una que casi nadie explica. Un bucle empuja su número hacia un objetivo, pero dentro del bucle no hay nadie que pueda preguntar si ese objetivo está bien puesto. El termostato no se plantea si veintiún grados es la temperatura correcta. Alguien la puso ahí, igual hace tres años y bastante a ojo, y el bucle va a trabajar sin descanso para conseguir ese número. Cuanto mejor funciona, más a fondo consigue un objetivo equivocado. ## Ahora la moda son los grafos  Steinberger, el mismo del tuit de junio, publicó en julio otro de nueve palabras: *"¿seguimos hablando de bucles o ya nos hemos pasado a los grafos?"*. Es un chiste interno y por eso ha funcionado tan bien: todo un sector reconociendo que ya está en otra cosa. La idea de fondo del chiste va en serio. Si un bucle falla por lo que no ve, un bucle mejor no arregla nada. Hace falta una red de bucles que se vigilen entre ellos. Y no hace falta inventarla, porque ya existe en los sitios donde esto lleva años funcionando. Poner un modelo en producción en serio no se reduce a reentrenar y publicar. Hay un bucle que compara al candidato contra el que está en producción, más otro que comprueba si los datos de hoy se parecen a los de entrenamiento, más otro que revierte solo si algo se desmadra, más un conjunto de evaluación que el bucle de entrenamiento no tiene permiso para ver nunca. Una empresa bien gobernada es lo mismo con otros nombres: el día a día dentro del trimestre, el trimestre dentro de la auditoría anual, y un consejo que de vez en cuando pregunta si los objetivos siguen teniendo sentido. Pero el ensayo no se queda ahí, y esta es la parte por la que lo traigo. Un grafo de bucles también falla, y falla peor: más tarde, más caro y con muchas más luces verdes por el camino. Si cada bucle vigila a otro y ninguno comprueba nada contra la realidad, acabas con una red donde todos se dan la razón y nadie ha verificado nada. Eso no lo arregla la forma de la red. Hacen falta anclas: alguna medición que no se pueda discutir. El dinero que ha entrado en el banco, el test que se ha ejecutado de verdad, el cliente que sigue ahí. Y alguna regla congelada que el optimizador no tenga permiso para tocar, precisamente porque es la que le apetecería aflojar. Vuelvo a lo mío con otro ejemplo pequeño. En la web [davidhurtado.ai](https://davidhurtado.ai) escribo con un sistema de agentes, y el que revisa lleva delante un script que cuenta faltas mecánicas: palabras de mi lista negra, la [regla de metáforas que os conté el otro día](20-metaforas-suaves-no-por-favor.md) conectores de informe, frases todas de la misma longitud. Cuando lo montamos, la mitad de los patrones saltaban sobre textos que había escrito yo, publicados hace un año. Si te fías del contador, el sistema termina corrigiéndome a mí para parecerse a lo que el contador considera correcto. La regla que pusimos es de sentido común y es un ancla: un *patrón de fallo* que salta sobre algo publicado por mí no se marca como error: se me pregunta. Esos fallos no los decide el bucle, los decido yo. ## Qué me llevo  La forma de empezar que dan en el artículo de Claude Code me parece la más sensata que he leído sobre esto: mira el trabajo que ya haces, elige una tarea donde el cuello de botella seas tú, y pregúntate cuál de las cuatro piezas puedes dejar de hacer tú. ¿Sabes escribir la comprobación con detalle suficiente para que la ejecute otro? ¿Tienes más o menos claro qué es estar terminado, sin que haga falta tu opinión? ¿El trabajo te llega solo y a su hora? Deja de hacer esa, y quédate con las otras tres. Lo que no haría es empezar por el final. Programar de madrugada algo que no has hecho a mano un par de veces con buen resultado es la forma más rápida de que se rompa mientras duermes. Y una cosa más, para los que no escribís código y estáis leyendo esto pensando que no va con vosotros. Sí va, aunque no lo montéis. El día que un equipo os enseñe un panel con un número subiendo cinco meses seguidos, preguntad qué otro número se está moviendo al mismo tiempo, y quién tiene permiso para decir que el objetivo estaba mal puesto.  Eso no lo contesta ningún bucle. ## Bonus > [!tip]+ Dentro esta web > - [[Newsletter/2026/81-El-harness-y-simular-agentes.md|El harness, en detalle]] - Un bucle no corre en el vacío, corre dentro de un harness. Aquí está esa capa explicada despacio, que es la que decide lo que el bucle puede hacer. > - [[Newsletter/2026/70-Midiendo-mal-la-Inteligencia.md|Estamos midiendo mal la inteligencia artificial]] - Lo del número que sube mientras el negocio baja no lo han inventado los bucles. Esto es de antes y va de dónde salen las medidas malas. > - [[Newsletter/2026/91-La-IA-siempre-te-da-la-razon-premortem.md|La IA siempre te da la razón]] - El segundo agente que revisa con el contexto limpio funciona por lo mismo que el premortem: hace falta alguien que no llegue ya convencido. > [!tip]+ Para profundizar en Internet > - [Categorizing Variants of Goodhart's Law](https://arxiv.org/abs/1803.04585) · David Manheim y Scott Garrabrant · arXiv, 2018 - Diez páginas que parten la ley de Goodhart en cuatro mecanismos distintos. Saber cuál de los cuatro te está pasando cambia lo que hay que tocar. > - [Hidden Technical Debt in Machine Learning Systems](https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html) · Sculley et al., Google · NeurIPS 2015 - Google contando en 2015 lo que cuesta mantener un sistema que aprende solo. Su apartado de hidden feedback loops es este post once años antes. > - [Specification gaming: the flip side of AI ingenuity](https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/) · Victoria Krakovna et al., DeepMind - Sesenta ejemplos de agentes que cumplen el objetivo al pie de la letra y se saltan lo que querías. Es la versión de laboratorio del chatbot que cierra tickets. --- _Fuentes: [Getting started with loops](https://claude.com/blog/getting-started-with-loops), de Delba de Oliveira y Michael Segner, del equipo de Claude Code (30 de junio de 2026), y el ensayo [From Loop Engineering to Graph Engineering?](https://x.com/IntuitMachine/status/2078419526354378975) (18 de julio de 2026). Los otros dos artículos que menciono al principio no los enlazo a propósito._ --- Publicado el 25 de agosto de 2026, [LinkedIn](https://www.linkedin.com/pulse/loop-engineering-dos-meses-despu%25C3%25A9s-qu%25C3%25A9-es-un-bucle-y-hurtado-tor%25C3%25A1n-unome), [Substack](https://davidhurtado.substack.com/p/loop-engineering-dos-meses-despues?r=4uyjfg&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true), [X](https://x.com/dhtoran/status/2092167190996775265?s=20)