Sebastian Gomez

Sep 01, 2026

Updated: Sep 01, 2026

Del Prompt al Graph Engineering: Cómo sobrevivir a la fatiga de términos en la era de la IA

Cada semana aparece en redes una nueva forma de llamar a conceptos que la ingeniería de software lleva décadas resolviendo.

Primero fue el Prompt Engineering. Luego vino el Context Engineering, seguido rápidamente por el Harness Engineering y el Loop Engineering. Ahora, la nueva etiqueta que inunda artículos, hilos de Twitter y debates en LinkedIn es el Graph Engineering.

Para quienes llevamos años en el desarrollo de software, esta sensación de vértigo no es del todo extraña. Todos recordamos la época dorada del ecosistema JavaScript, donde cada quince días nacía un framework revolucionario o una nueva librería sobre React que prometía cambiarlo todo. Sin embargo, la fatiga actual en la comunidad no proviene del entusiasmo por aprender cosas nuevas; proviene de la sensación de que cada pequeño ajuste de patrón se presenta como una disciplina profesional completamente nueva y urgente.

¿Qué hay de verdad y qué hay de humo detrás del Graph Engineering? ¿Cómo podemos navegar esta avalancha de conceptos sin perder la cordura ni caer en la trampa del FOMO (Fear of Missing Out)?

Vamos a desglosarlo desde la perspectiva de la arquitectura de software real y la gestión de equipos de ingeniería.

Cambiemos la palabra "Engineering" por "Patrón"

El principal problema de la narrativa actual es que intenta convertir decisiones arquitectónicas en identidades profesionales.

En la programación orientada a objetos todos conocemos los patrones de diseño del Gang of Four (como Singleton, Observer o Factory). Son soluciones estructurales a problemas recurrentes que nos brindan un diccionario común para comunicarnos con otros ingenieros. Pero a nadie en su sano juicio se le ocurriría poner en su perfil de LinkedIn "Singleton Engineer" o pretender que una empresa contrate a un equipo de "cinco Observer Engineers".

Gran parte de la ansiedad colectiva desaparecería si hiciéramos un ejercicio de higiene mental muy simple: reemplazar la palabra engineering por patrón.

No estamos ante una nueva rama de la ciencia de la computación; estamos discutiendo el patrón de bucle (Loop Pattern) o el patrón de grafo (Graph Pattern) para orquestar llamadas a modelos de lenguaje.

¿Qué es realmente el Graph Engineering?

Para entender el patrón de grafo, primero debemos recordar qué propone el Loop Engineering: darle a un agente de IA un objetivo y permitirle ejecutar un ciclo cerrado de pasos (por ejemplo: leer un ticket en Linear o Jira, generar la especificación, escribir el código y crear un Pull Request) hasta completar la tarea.

El llamado Graph Engineering no es más que la evolución natural de este bucle hacia una orquestación multiagente estructurada como un grafo dirigido o una máquina de estados.

En esta arquitectura:

• Cada nodo del grafo es un agente o una etapa especializada con su propio contexto y herramientas.
• Cada arista representa la transición de estado, el intercambio de datos y las condiciones de bifurcación entre etapas.
• La ejecución permite caminos paralelos, bifurcaciones condicionales y pasos de validación antes de continuar al siguiente nodo.

[Nodo 1: Triage/Router]
       │
       ├── (Caso A) ──> [Nodo 2: Worker Especializado] ──> [Nodo 4: Validador] ──> [Fin]
       │                                                         │
       └── (Caso B) ──> [Nodo 3: Worker Alternativo]    ─────────┘

Si este concepto te resulta familiar, es porque las máquinas de estados finitos (FSM) y los flujos de trabajo dirigidos por eventos llevan más de treinta años siendo la columna vertebral del software robusto. Herramientas como AWS Step Functions, GCP Workflows, Temporal o librerías como XState ya hacían exactamente esto mucho antes de que la IA generativa existiera. Lo único que ha cambiado es que ahora el cómputo dentro de cada nodo puede ser una llamada a un LLM.

La trampa del presupuesto ilimitado: Demos vs. Producción

Muchas de estas modas surgen de publicaciones o experimentos realizados por laboratorios como OpenAI o Anthropic. En esos entornos de investigación, los equipos pueden permitirse desplegar redes complejas de decenas de agentes conversando entre sí en bucles infinitos porque son los dueños de la infraestructura y no tienen restricciones de coste de tokens.

En el mundo real de las empresas y los productos comerciales, la realidad es muy distinta:

• Cada nodo y cada arista cuestan dinero: Un grafo con cinco agentes iterando tres veces sobre una tarea puede multiplicar por quince el coste de una consulta simple.
• La latencia se acumula: Los sistemas con múltiples dependencias agénticas introducen segundos (o minutos) de espera que a menudo degradan la experiencia del usuario.
• El riesgo de fallo silencioso crece exponencialmente: Cuanto más complejo es el grafo, más difícil resulta rastrear en qué nodo se introdujo una premisa falsa que contaminó el resultado final.

Los agentes completamente autónomos sin supervisión son fascinantes en una demo, pero en producción, la simplicidad y los límites deterministas siempre ganan.

El filtro de las 5 preguntas para detectar el humo técnico

Para no perder el tiempo persiguiendo cada término viral que surge en redes, utilizo un filtro de cinco preguntas críticas antes de decidir si una novedad merece un estudio profundo:

• ¿Qué problema concreto resuelve? (Debe ser un problema técnico específico y medible, como la trazabilidad o la especialización de contexto, no una promesa vaga).
• ¿Qué capacidades técnicas nuevas me otorga? (¿Me permite estructurar flujos que antes eran imposibles o innecesariamente complejos de mantener?).
• ¿Puedo explicar el concepto sin usar la palabra de moda? (Si no puedes describirlo usando conceptos clásicos de software como máquinas de estados, tuberías de datos o clasificadores, probablemente sea puro envoltorio de marketing).
• ¿Lo necesito para mi arquitectura hoy? (Aplicar grafos agénticos a tareas que se resuelven con una función lineal de veinte líneas es la definición clásica de sobreingeniería).
• ¿Seguiría siendo útil esta técnica si tuviera un nombre ridículo? (Si le quitamos el glamour del término en inglés y evaluamos solo el mecanismo, ¿sigue aportando valor a tu código?).

Si una tecnología supera este filtro, vale la pena profundizar en ella. Si no, puedes dejarla pasar con tranquilidad.

Qué busca realmente un Engineering Manager en la era de la IA

Uno de los errores más comunes que veo actualmente en perfiles de LinkedIn es el uso precipitado de títulos como "AI Engineer" por parte de desarrolladores que únicamente han consumido una API básica de OpenAI o pegado código desde un chat.

Como Engineering Manager, lo que realmente busco en un ingeniero no es que recite los términos virales de la semana, sino su capacidad de aplicar rigor y pensamiento previo antes de tocar una sola línea de código o escribir un prompt:

• Diseño y Blueprint primero: Capacidad para redactar un buen documento de requisitos (PRD), evaluar opciones técnicas, sopesar pros y contras arquitectónicos y definir los contratos de datos antes de acudir a la IA.
• Uso quirúrgico de la herramienta: Utilizar la inteligencia artificial al final del proceso como un acelerador de implementación sobre una solución que ya ha sido conceptualmente validada por el ingeniero.
• Criterio de validación: Saber cuándo una solución agéntica es necesaria y cuándo un simple if o una consulta SQL tradicional resuelve el problema de forma diez veces más barata, rápida y segura.

El camino de los fundamentos: Qué estudiar en lugar de perseguir términos

Si quieres construir sistemas con agentes de IA que sean robustos, predecibles y escalables, mi recomendación no es que leas diez artículos sobre Graph Engineering.

Dedica ese tiempo a estudiar los fundamentos que sostienen estas arquitecturas:

• Máquinas de Estados y Statecharts: Comprende cómo modelar estados, eventos, transiciones y efectos secundarios. Plataformas como AWS Step Functions, Google Cloud Workflows o la librería XState te enseñarán más sobre orquestación que cualquier hilo viral.
• Sistemas de ejecución duradera (Durable Execution): Analiza cómo herramientas como Temporal.io o Inngest gestionan reintentos, fallos parciales y persistencia de estado en procesos asíncronos complejos.
• Observabilidad y trazabilidad estructurada: Aprende a instrumentar llamadas con OpenTelemetry para auditar exactamente qué entra y qué sale de cada componente de tu sistema.

Los términos de moda pasarán y en unos meses inventarán otra etiqueta rimbombante. Quienes dominen los fundamentos arquitectónicos podrán implementar cualquier patrón que venga, sin importar el nombre que le pongan.

¿Cómo estás gestionando tú o tu equipo la avalancha constante de nuevos términos en IA? ¿Has sentido esa fatiga de conceptos o has encontrado utilidad real en alguno de estos patrones?

Déjame tus opiniones y experiencias en los comentarios para seguir debatiendo. ¡Hasta la próxima!