Por qué el código se volvió más complejo después de adoptar LangGraph — lecciones aprendidas del fra

Adopté LangGraph con la expectativa de que "la gestión de estado y el control del flujo quedarían más limpios", pero en realidad el código se volvió más complejo.
Este es un registro y una experiencia compartida de haber vivido en carne propia cómo la estructura puede empeorar incluso después de introducir un framework.

Al diagnosticarlo, la situación era esta:

El grafo tenía un solo nodo. Era una estructura current_step → END, sin edges condicionales ni bifurcaciones, y graph.invoke() era exactamente lo mismo que llamar directamente a una función. La transición de Step se decidía en el código de servicio fuera del grafo.
El mismo estado se guardaba en dos lugares. LangGraph MemorySaver (en memoria) y un Checkpointer propio en PostgreSQL almacenaban y restauraban la misma sesión por duplicado, lo que provocaba inconsistencias.
Había duplicación en 3 códigos de ejecución de LangGraph (Executor) de unas 8,700 líneas. La lógica central real era básicamente "llamada al LLM + ensamblado de prompts"; casi todo lo demás era gestión de estado, bifurcaciones condicionales y parches para edge cases.

En la superficie, el problema parecía ser que se había introducido el framework solo como cascarón, sin usar sus funciones reales (edges condicionales, checkpointer integrado, Human-in-the-Loop), pero al profundizar resultó que la causa era otra.

Gran parte se construyó con vibe coding, pero durante el proceso no se revisaron a fondo ni el código interno ni los principios de diseño; simplemente se siguió implementando organizando cada vez solo los requisitos y la intención.
El problema no era el vibe coding en sí, sino avanzar sin validación. Eso optimiza únicamente la funcionalidad inmediata, pero no preserva los límites de responsabilidad de la estructura general. El checkpointing duplicado, el estado disperso y la lógica repetida fueron acumulaciones de optimizaciones parciales.
No es que no hubiera un diseñador; la verdadera causa fue dar instrucciones sobre el framework sin entender lo suficiente para qué responsabilidades había sido diseñado.

Así que lo replanteé y lo revertí de esta manera.

Topología independiente + aislamiento por thread_id para separar sesiones
En State dejar solo metadatos y mover el contenido principal a Store
Usar tool_use nativo en lugar de parsing con regex
Separar nodos para que se puedan probar
Yo mismo necesitaba una comprensión precisa del framework y de su estructura de uso

Este es un registro/compartición no sobre "cómo usarlo", sino sobre "cómo lo usé mal".

Por qué el código se volvió más complejo después de adoptar LangGraph — lecciones aprendidas del fracaso

2 comentarios

Por qué el código se volvió más complejo después de adoptar LangGraph — lecciones aprendidas del fracaso

Lecturas relacionadas

2 comentarios