Habr AI: cómo los LLM costosos se convirtieron en gestores de estado y redujeron los costos de desarrollo

En Habr AI se publicó un análisis de la arquitectura del desarrollo impulsado por IA, en el que un LLM caro ya no escribe código por sí mismo, sino que gestiona un ejecutor más barato. El autor argumenta que esta reestructuración ayudó a eliminar ciclos infinitos de errores, reducir el tamaño del contexto y reducir significativamente los gastos en API.

Dónde Fallaron los Agentes

El equipo comenzó con un enfoque popular: tomaron Aider e lo integraron en CI/CD para que el agente actualizara automáticamente la documentación después de cambios en el código. Para esta tarea, la herramienta funcionó bien y resolvió parte de la deuda técnica. Pero cuando intentaron darle el ciclo completo de desarrollo — desde el backlog y especificaciones hasta código y pruebas — el sistema rápidamente tropezó con limitaciones. Había dos problemas principales: control débil sobre las integraciones y transferencia poco clara de artefactos entre pasos, cuando un agente creaba algo pero era difícil extraerlo y integrarlo de forma confiable en la siguiente etapa.

El siguiente intento fue más cercano a una estructura organizacional familiar: un orquestrador asigna la tarea, y varios agentes-programadores la ejecutan en partes. En el papel, el esquema parecía lógico, pero en la práctica produjo dos fallas sistémicas. La primera fue una ruptura de responsabilidad: si un agente no completaba parte de una función, y el siguiente ya construía su lógica sobre ella, el error comenzaba a propagarse en cascada. La segunda fue parálisis analítica. Los modelos leían infinitamente el repositorio, verificaban archivos nuevamente y retrasaban cambios reales mientras el contexto se hinchaba y la factura de tokens crecía.

Por Qué Cambiar de Roles

Durante las pruebas, el equipo notó que diferentes modelos de hecho tienen un "carácter" de trabajo distinto. Gemini 3 Pro actúa como un desarrollador demasiado confiado y puede desviarse de la especificación original. MiniMax M2.5, por el contrario, es cauteloso y lee la mitad del proyecto antes de dar el primer paso. Claude Sonnet 4.6 mostró el mejor equilibrio entre autonomía y disciplina, pero usarlo en cada pequeña acción resultó demasiado caro para una startup.

Así surgió la nueva idea: un modelo fuerte debe asignarse no a la rutina, sino al control.

"El CEO no hace llamadas en frío."

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

• Un agente lidera una especificación de principio a fin y corrige sus propios errores.
• Un agente trabaja solo con un "escritorio de trabajo" limitado de 5-8 archivos, no con todo el repositorio.
• Al cerrar un archivo, guarda una breve memoria de hallazgos útiles para evitar arrastrar código fuente completo al contexto.
• El modelo más inteligente no codifica directamente, sino que actúa como gestor de estado para un trabajador barato.

Cómo Funciona el Gestor

En la nueva arquitectura, un LLM barato y rápido actúa como trabajador: escribe código, llama herramientas, recibe errores de compilación y realiza pasadas rutinarias. Cuando el trabajador encuentra un problema o alcanza su límite de acciones, el control es asumido por el modelo caro — el gestor de estado. No modifica el código directamente, sino que lee el historial acumulado, filtra ruido y reúne una versión compacta y útil del contexto para el siguiente paso.

El gestor de estado realiza cuatro cosas en secuencia:

• Registra brevemente qué se ha hecho realmente y qué funciona.
• Actualiza la memoria: variables, decisiones, conflictos de biblioteca encontrados y callejones sin salida.
• Verifica si tiene sentido continuar o si la tarea ha topado con limitaciones de herramientas.
• Formula una directiva clara sobre cómo el trabajador debe avanzar y evitar errores.

La técnica más interesante es cómo se transmiten estas instrucciones. Las recomendaciones del gestor, además del bloque de memoria, se presentan al trabajador como un nuevo mensaje del usuario. Por esto, el ejecutor percibe las instrucciones como prioritarias y las cuestiona menos. En paralelo, el sistema limpia la conversación anterior del trabajador con logs y errores para iniciar un nuevo ciclo con una "ventana limpia".

Hay riesgo en este enfoque: si el gestor interpreta mal los logs y escribe un hecho falso en memoria, el trabajador seguirá obstinadamente un curso errado. Pero el autor escribe que en el rol analítico, el modelo caro alucina mucho menos frecuentemente que en la generación directa de código.

Un efecto adicional — las pruebas y documentación comienzan a aparecer junto con la tarea por defecto, y los desarrolladores se desplazan del rol de ejecutores manuales al rol de operadores y arquitectos de proceso.

Qué Significa Esto

Este caso demuestra bien que el éxito en desarrollo de IA viene no solo de elegir un modelo, sino también de distribuir correctamente los roles entre ellos. Si usas un LLM caro como despachador de memoria, controlador de decisiones y disyuntor para ciclos sin sentido, puedes simultáneamente aumentar la estabilidad del proceso y reducir el costo de reelaboración.

Para equipos que ya se han quemado con "programadores autónomos", esta es una de las conclusiones arquitectónicas más prácticas de los últimos meses.