Fable contra 10 LLMs: ¿quién mejor maneja el god node de un agente real?

El autor de Habr en julio de 2026 realizó un experimento detallado: tomó un god node de un agente LangGraph real que funciona y organizó un torneo en dos fases para 11 modelos de lenguaje — cinco estadounidenses y seis chinos, incluyendo Fable de Anthropic. Adicionalmente, aplicó tres métodos independientes de análisis para entender en quién se puede confiar entre los participantes.

Por qué god node es una prueba justa

En proyectos LangGraph, un god node es un nodo monolítico que asume demasiadas responsabilidades: analiza datos de entrada, toma decisiones sobre invocaciones de herramientas, procesa resultados, forma la salida final. Tales nodos crecen gradualmente: al inicio de un proyecto, los límites de responsabilidad aún no son claros, y luego es aterrador cambiar la arquitectura — y el nodo continúa expandiéndose.

Refactorizar un god node es una tarea en la que un LLM no puede adivinar la respuesta "correcta" basándose en patrones estadísticos. Aquí necesitas una comprensión real de la arquitectura:

• Comprender el grafo en su totalidad y encontrar dependencias ocultas entre nodos
• Proponer un esquema específico de descomposición con justificación de los límites elegidos
• No violar el contrato existente: entradas, salidas, efectos secundarios
• Tener en cuenta las peculiaridades de LangGraph — transferencia de estado, aristas condicionales, puntos de ruptura

Más allá de la comprensión arquitectónica, el cuidado es importante: refactorizar un god node en código de producción corre el riesgo de tocar dependencias inesperadas. Un modelo que propone "simplemente dividir en varias funciones" no entiende el contexto — y su plan es inútil en la práctica.

El autor utilizó no un ejemplo sintético, sino código real que funciona con historial real. Esto es crucial: el código real contiene aleatoriedad, artefactos históricos y dependencias no obvias que no existen en ejemplos de libros de texto.

Cómo funcionó el torneo en dos fases

En la primera fase, cada uno de los 11 modelos recibió un god node y una tarea: proponer un plan específico de descomposición. Entre los participantes estadounidenses está Fable, el modelo más reciente de Anthropic en el momento de la publicación. Seis modelos chinos representaban los mayores laboratorios de IA de China.

En la segunda fase, cada modelo recibió propuestas de los otros diez y tuvo que evaluarlas: encontrar fortalezas y debilidades de cada solución, elegir la mejor y justificar la elección. Esto permite medir dos habilidades a la vez — la capacidad de generar soluciones arquitectónicas y la capacidad de analizar críticamente a otros.

La auditoría cruzada es una técnica metodológicamente no estándar. En benchmarks típicos, un modelo recibe una tarea y produce una respuesta, pero se desconoce si entiende qué es una buena solución en este área. Cuando un modelo evalúa a los competidores, queda claro qué tan bien su comprensión de la respuesta "correcta" se alinea con los estándares reales de ingeniería.

Después de recopilar todas las propuestas y evaluaciones mutuas, el autor aplicó tres métodos independientes de análisis. Los resultados coincidieron parcialmente, divergieron parcialmente — y esto es exactamente lo que se convirtió en la conclusión principal del experimento. De aquí viene "Muerte de los Dioses" en el título: los modelos líderes con la mejor reputación no proporcionaron resultados consistentemente superiores. Según el autor, los benchmarks sintéticos y el código de ingeniería real son dos tareas diferentes, y los líderes en uno no siempre resultan siendo líderes en el otro.

Qué significa esto

La posición en los leaderboards públicos predice mal cómo un modelo manejará la revisión de código o propuestas arquitectónicas en un proyecto específico. La brecha entre "el mejor modelo según la clasificación" y "el mejor modelo para tu stack" puede ser sustancial.

Conclusión práctica: antes de delegar decisiones técnicas a un LLM específico — especialmente en tareas de refactorización o revisión arquitectónica — vale la pena probarlo en tareas de código real. El formato en dos fases con evaluaciones cruzadas de este experimento es un buen plantilla para tal prueba: revela no solo capacidades generativas, sino también comprensión crítica del área temática.