Habr AI: cómo los LLM caros pasaron a ser gestores de estado y recortaron el coste del desarrollo

Habr AI ha publicado un análisis de una arquitectura de desarrollo con IA en la que el LLM caro ya no escribe código, sino que dirige a un ejecutor más barato. El autor afirma que este cambio eliminó los bucles de errores interminables, redujo el contexto y recortó de forma notable el gasto en API.

Dónde fallaban los agentes

El equipo empezó por el camino habitual: tomó Aider y lo integró en CI/CD para que un agente actualizara automáticamente la documentación tras los cambios en el código. Para esa tarea la herramienta funcionó bien y eliminó parte de la deuda técnica. Pero cuando intentaron encargarle el ciclo completo de desarrollo, desde el backlog y las especificaciones hasta el código y las pruebas, el sistema chocó pronto con sus límites. Los problemas principales fueron dos: poco control sobre las integraciones y una transferencia confusa de artefactos entre pasos, en la que el agente crea algo, pero resulta difícil recogerlo de forma fiable e incorporarlo a la siguiente etapa.

El siguiente intento se parecía más a un organigrama convencional: un orquestador plantea la tarea y varios agentes programadores la ejecutan por partes. Sobre el papel el esquema parece lógico, pero en la práctica produjo dos fallos sistémicos. El primero fue una ruptura de responsabilidad: si un agente no termina parte de una función y el siguiente ya construye su lógica encima, el error crece en cascada. El segundo fue la parálisis por análisis. Los modelos leen el repositorio sin parar, revisan archivos una y otra vez y aplazan los cambios reales mientras el contexto se hincha y la factura de tokens crece.

Por qué cambiar los roles

Durante las pruebas, el equipo observó que los distintos modelos sí tienen un «carácter» de trabajo. Gemini 3 Pro se comporta como un desarrollador demasiado seguro de sí mismo y puede apartarse de las especificaciones originales. MiniMax M2.5, al contrario, es cauteloso y lee medio proyecto antes de dar el primer paso. Claude Sonnet 4.6 mostró el mejor equilibrio entre autonomía y disciplina, pero usarlo en cada acción menor resultó demasiado caro para una startup.

De ahí surgió la nueva idea: el modelo fuerte debe dedicarse no a la rutina, sino al control.

«El director general no hace llamadas en frío».

En lugar de un esquema en el que el LLM caro escribe el código más complejo, el equipo introdujo varias reglas estrictas:

• Un agente lleva una especificación de principio a fin y corrige él mismo sus errores.
• El agente trabaja solo con un «escritorio» limitado de 5–8 archivos, no con todo el repositorio.
• Al cerrar un archivo, guarda una memoria breve de los hallazgos útiles para no arrastrar el código fuente completo al contexto.
• El modelo más inteligente no programa a mano, sino que actúa como gestor de estado del trabajador barato.

Cómo funciona el gestor

En la nueva arquitectura, un LLM barato y rápido hace de trabajador: escribe código, llama a herramientas, recibe errores de compilación y realiza las pasadas rutinarias. Cuando el trabajador se topa con un problema o agota su límite de acciones, toma el control el modelo caro, el gestor de estado. No se pone a editar código directamente: lee el historial acumulado, descarta el ruido y prepara para el siguiente paso una versión compacta y útil del contexto.

El gestor de estado hace cuatro cosas seguidas:

• Resume lo que ya se ha hecho de verdad y lo que funciona.
• Actualiza la memoria: variables, decisiones, conflictos de bibliotecas detectados y callejones sin salida.
• Comprueba si tiene sentido continuar o si la tarea ha chocado con los límites de las herramientas.
• Formula una directiva clara sobre cómo debe avanzar el trabajador y sortear los errores.

El truco más interesante es cómo se transmiten estas indicaciones. Además del bloque de memoria, las recomendaciones del gestor se entregan al trabajador como un nuevo mensaje de usuario. Así, el ejecutor las percibe como prioritarias y discute menos con ellas. En paralelo, el sistema limpia su conversación anterior, con registros y errores, para empezar un nuevo ciclo con la «ventana limpia».

El esquema también tiene un riesgo: si el gestor interpreta mal los registros y escribe un dato falso en la memoria, el trabajador seguirá tercamente el rumbo equivocado. Pero el autor señala que, en un papel analítico, el modelo caro alucina mucho menos que cuando genera código directamente.

Un efecto adicional es que las pruebas y la documentación empiezan a aparecer con la tarea por defecto, y los desarrolladores pasan de ejecutores manuales a operadores y arquitectos del proceso.

Qué significa

Este caso muestra que la ventaja en el desarrollo con IA no depende solo de elegir modelo, sino de repartir bien los roles entre ellos. Si el LLM caro se usa como despachador de memoria, controlador de decisiones y freno de emergencia para bucles absurdos, se puede mejorar la estabilidad del proceso y abaratar las correcciones a la vez. Para los equipos que ya se han quemado con los «programadores autónomos», es una de las conclusiones arquitectónicas más prácticas de los últimos meses.