¿Es real la "ingeniería de grafos"? Por qué todos hablan de ella

El editorial de esta edición de FOD (Turing Post) analiza un fenómeno muy reciente en la conversación sobre desarrollo de agentes de IA: el término "loop engineering" (ingeniería de bucles) fue declarado obsoleto apenas seis semanas después de acuñarse, sustituido por un nuevo término, "graph engineering" (ingeniería de grafos).

El origen de la polémica: el 18 de julio, Peter Steinberger preguntó en X si la comunidad seguía hablando de "loops" o ya había pasado a hablar de "grafos". Pocas horas después, Hamel Husain publicó lo que el newsletter describe como el "obituario" del término anterior, con un post titulado "Loop Engineering Is Dead. Enter Graph Engineering." Para el domingo siguiente, la conversación en redes ya había generado cursos, hojas de ruta, listas de herramientas e hilos explicando que Microsoft, Stanford y Anthropic habrían llegado todos a la misma idea de forma independiente.

El término "loop engineering" apenas tenía seis semanas de vida: fue popularizado por un ensayo de Addy Osmani publicado el 7 de junio, que a su vez se apoyaba en un eslogan anterior de Steinberger y en una declaración de Boris Cherny, creador de Claude Code, quien afirmó "ya no le hago prompts a Claude": su trabajo, según explicó, consiste en escribir los bucles (loops) que sí lo hacen. La idea central del "loop engineering" es sencilla: en lugar de guiar a un agente turno a turno, se le da un objetivo, una forma de comprobar su propio trabajo y un ciclo que puede repetir hasta terminar la tarea.

El newsletter explica la diferencia entre un loop y un grafo. Un loop describe el ciclo básico de un agente: encontrar el siguiente trabajo, planificar, actuar, comprobar el resultado y continuar o detenerse. Ese esquema funciona bien hasta que la tarea se complica: por ejemplo, cuando varias partes pueden ejecutarse en paralelo, cuando un paso necesita un modelo de código y otro necesita búsqueda, cuando un agente produce una respuesta y otro intenta refutarla, o cuando algunas decisiones pueden automatizarse mientras otras requieren aprobación humana. En ese punto, diseñar el loop ya no basta: hay que decidir también cómo se conectan las distintas piezas, y esa estructura mayor es el grafo.

Según el correo, la arquitectura de un grafo no tiene nada de exótico: tiene nodos, aristas (edges) y estado (state). Un nodo es una unidad de trabajo (un agente, una llamada a un modelo, un fragmento de código ordinario o una decisión humana). Una arista determina qué ocurre a continuación. El estado transporta la información relevante de un paso a otro. Y aquí el propio newsletter señala la ironía: un loop ya es un grafo, simplemente uno cuyo camino regresa a un nodo anterior. Nada de esto es nuevo para la ingeniería de software: las máquinas de estados, los DAG, los motores de flujo de trabajo y los sistemas de orquestación llevan décadas haciendo versiones de esto. Se recuerda que LangChain lanzó LangGraph en enero de 2024 específicamente para ayudar a construir flujos de trabajo de agentes con estado.

Lo que sí está cambiando, según el texto, es el papel que se asigna al modelo. Los primeros sistemas de agentes pedían al modelo que hiciera casi todo: decidir qué pasaba a continuación, elegir una herramienta, interpretar el resultado, actualizar el plan y decidir cuándo detenerse. Eso lucía muy general en una demo, pero también generaba muchas formas de fallar en producción: los agentes entraban en bucles innecesarios, se saltaban lógica de negocio requerida, perdían de vista el estado y llenaban su ventana de contexto con salidas de herramientas.

El correo cita dos ejemplos concretos de esta transición. Google, al explicar su Agent Development Kit (ADK) 2.0, planteó que el código debe controlar el enrutamiento predecible, mientras que los modelos deben encargarse de los pasos que requieren interpretación o juicio. Anthropic, por su parte, aborda el mismo problema desde otro ángulo: los "dynamic workflows" de Claude Code permiten que Claude escriba un script de orquestación en JavaScript que coordina subagentes en paralelo, de forma que el modelo gasta menos tokens decidiendo repetidamente qué hacer a continuación. Para el newsletter, esta es una versión práctica de "ingeniería de grafos": el modelo opera dentro de un sistema de ejecución más amplio, donde la fiabilidad depende también de cómo se enruta el trabajo, se conserva el estado, se verifican las salidas y se gestionan los fallos.

Una parte importante del artículo advierte sobre la ambigüedad del término "grafo", que la gente está usando para referirse a cosas distintas: un grafo de control (la estructura del flujo de trabajo y las reglas sobre qué se ejecuta a continuación, como LangGraph o ADK); un grafo de conocimiento (información almacenada como entidades y relaciones, como el GraphRAG de Microsoft, que extrae un grafo estructurado de documentos y lo usa durante la recuperación de información); una traza de ejecución (el grafo que muestra qué ocurrió durante una ejecución concreta de un agente, útil para depuración y observabilidad); y, una cuarta interpretación propuesta este fin de semana por Carlos Perez, un grafo de loops de mejora, donde un loop optimiza una métrica, otro vigila la métrica contraria y otros más auditan si esas métricas siguen representando el objetivo real —algo especialmente relevante para sistemas que se automejoran, ya que un loop de optimización sin un loop de verificación puede volverse muy bueno produciendo el resultado equivocado—.

Finalmente, el newsletter desmiente explícitamente una afirmación viral que circuló en redes: que la "ingeniería de grafos" había "sustituido a RAG" en Microsoft, Stanford y Anthropic, con una mejora de precisión del 18% y una reducción de costes del 85%. Según el correo, esa cifra no es cierta y proviene de un artículo académico que aplicaba GraphRAG a diagramas de ingeniería industrial, un resultado interesante pero limitado a un caso concreto. El texto aclara además que Microsoft describe GraphRAG como un tipo de RAG y no como su reemplazo, que DSPy de Stanford optimiza programas basados en modelos de lenguaje y no es un sistema de grafos de conocimiento, y que Anthropic no ha anunciado ninguna disciplina o producto llamado "graph engineering".

Además del editorial, la edición incluye una sección "This Week in Turing Post" con enlaces a un análisis del viernes sobre por dónde fallan los rankings globales de IA y una pieza del domingo sobre protocolos de IA que todo desarrollador debería conocer, así como contenido patrocinado por MongoDB sobre infraestructura para plataformas agénticas, que cita una predicción de Gartner según la cual el 40% de los proyectos de IA agéntica serán cancelados para 2027 por problemas de seguridad, coste y evaluación, no por el modelo en sí.