170 planes generados con LLM: los tres fallos que un modelo mayor no arregla

Un motor que combina dos LLM con una capa de validación determinista ha generado 170 planes de cambio reales en 40 dominios distintos —desde gestión de identidades y operaciones multiagente hasta SRE, políticas de cadena de suministro y FinOps— por 0,49 dólares en total. De los 132 bloqueos concretos que detectó, 121 cayeron en solo tres familias de fallos. Y cambiar a un modelo mayor no movió ninguna.

El diseño de PlannerCritic es sencillo a propósito. Un primer LLM produce un plan estructurado: tareas, precondiciones, orden y rollback. Una capa de reglas deterministas lo valida contra condiciones duras. Un segundo LLM, el crítico, revisa lo que sobrevive a esas puertas. Si el crítico bloquea, el planificador revisa, con un tope de revisiones. Si no converge, el motor escala a una persona en lugar de adivinar. Las puertas son la pieza que importa: se ejecutan sin ninguna llamada a un modelo, tardan unos 4,7 segundos en 1.295 comprobaciones y son la razón de que un plan malo no llegue a un humano disfrazado de bueno.

Tres familias, no casualidades

Los fallos no eran aleatorios. Dependencias sin verificar: 57 bloqueos. El plan da por hecho algo que ninguna tarea anterior produce; en una migración de servidores de modelos, se cortaba el 100% del tráfico sin comprobar que las etapas del 10% y el 50% estuvieran sanas. Secuenciación insegura: 46. Pasos colocados antes de sus requisitos; una migración de índices de embeddings rellenaba vectores antes de la comprobación de calidad que debía autorizarlo. Rollback débil: 18. Pasos de alto impacto cuyo retroceso no deshace nada; en una partición de base de datos multiinquilino, el rollback volvía a escritura única sin tocar las inconsistencias que la doble escritura pudiera haber dejado.

El instinto habitual es tirar de un modelo mayor. El autor probó GPT-4o como planificador con el modelo pequeño de crítico, y GPT-4o en ambos papeles. Mismo patrón de defectos, mejor prosa. El planificador conocía los pasos correctos; lo que no sabía era cerrar el grafo de dependencias ni imponer el orden.

El bucle de revisión tampoco salva la situación. Tras una mediana de dos revisiones, el planificador deja de introducir cambios con sentido: arregla un bloqueo y crea otro. Un detector de convergencia corta y escala a un humano. El crítico, en cambio, encontraba los mismos bloqueos una y otra vez: el fallo estaba en la incapacidad del planificador de reparar la estructura, no en el juicio del revisor.

La solución es código, no parámetros

El cambio de mayor rendimiento fue un verificador de precondiciones: un linter determinista que se ejecuta después del borrador y comprueba que cada precondición la produce una tarea anterior. Una sola pasada eliminaría 64 de los 132 bloqueos, casi la mitad, sin pedirle al modelo que sea más listo. Los demás necesitaron dos mecanismos más: reparación topológica automática, que reordena tareas para que los requisitos vayan primero y solo marca bloqueo cuando el grafo es realmente cíclico, y detección de oscilación, que termina el bucle cuando el planificador alterna entre dos órdenes en lugar de gastar revisiones. Esta última se activó en cinco objetivos estrictos del barrido de la v0.2.1.

Para quien construya agentes que planifiquen en varios pasos, el resultado es incómodo: el cuello de botella no está en el modelo, sino en la estructura del plan. Las cifras son del propio autor y no las ha contrastado nadie fuera de su banco de pruebas, así que conviene tomarlas como lo que son, un experimento personal. Pero la lección se traslada igual: un fallo estructural no se arregla con un prompt ni con más parámetros, sino con validaciones que no llaman a ningún modelo.