Habr AI: como LLMs de alto custo se tornaram gestoras de estado e reduziram os custos de desenvolvimento

No Habr AI, foi publicada uma análise da arquitetura de desenvolvimento de IA, na qual um LLM caro não escreve código por si só, mas gerencia um executor mais barato. O autor argumenta que essa reestruturação ajudou a eliminar ciclos infinitos de erros, reduzir o tamanho do contexto e reduzir significativamente as despesas com API.

Onde os Agentes Falharam

A equipe começou com um caminho popular: pegou o Aider e o integrou ao CI/CD para que o agente atualizasse automaticamente a documentação após alterações no código. Para essa tarefa, a ferramenta funcionou bem e resolveu alguma dívida técnica. Mas quando tentaram dar a ele o ciclo completo de desenvolvimento — desde o backlog e especificações até código e testes — o sistema rapidamente atingiu limitações. Havia dois problemas principais: controle fraco sobre integrações e transferência de artefatos pouco clara entre etapas, quando um agente criava algo, mas era difícil extrair e integrar confiávelmente na próxima etapa.

A próxima tentativa foi mais próxima de uma estrutura organizacional familiar: um orquestrador define a tarefa e vários agentes-programadores a executam em partes. No papel, o esquema parecia lógico, mas na prática produziu dois falhas sistêmicas. A primeira foi uma quebra de responsabilidade: se um agente não completasse parte de uma funcionalidade e o próximo já construísse sua lógica sobre ela, o erro começava a se propagar em cascata. A segunda foi paralisia analítica. Os modelos liam infinitamente o repositório, verificavam arquivos novamente e atrasavam as mudanças reais enquanto o contexto inchava e a conta de tokens crescia.

Por Que Mudar de Papéis

Durante os testes, a equipe notou que diferentes modelos de fato têm um "caráter" de trabalho distinto. Gemini 3 Pro age como um desenvolvedor muito confiante e pode se desviar da especificação original. MiniMax M2.5, ao contrário, é cauteloso e lê metade do projeto antes de dar o primeiro passo. Claude Sonnet 4.6 mostrou o melhor equilíbrio entre autonomia e disciplina, mas usá-lo para cada pequena ação era muito caro para uma startup.

Aqui é onde cresceu a nova ideia: um modelo forte deve ser atribuído não à rotina, mas ao controle.

"O CEO não faz ligações a frio."

Em vez de um esquema onde um LLM caro escreve o código mais complexo, a equipe introduziu várias regras rígidas:

• Um agente lidera uma especificação do início ao fim e corrige seus próprios erros.
• Um agente funciona apenas com uma "mesa de trabalho" limitada de 5-8 arquivos, não com todo o repositório.
• Ao fechar um arquivo, ele salva uma breve memória de descobertas úteis para evitar arrastar código-fonte inteiro para o contexto.
• O modelo mais inteligente não codifica diretamente, mas atua como gerenciador de estado para um trabalhador barato.

Como o Gerenciador Funciona

Na nova arquitetura, um LLM barato e rápido atua como trabalhador: escreve código, chama ferramentas, recebe erros de compilação e faz passagens rotineiras. Quando o trabalhador enfrenta um problema ou atinge seu limite de ações, o controle é assumido pelo modelo caro — o gerenciador de estado. Ele não conserta código diretamente, mas lê o histórico acumulado, filtra ruído e monta uma versão compacta e útil do contexto para a próxima etapa.

O gerenciador de estado faz quatro coisas em sequência:

• Registra brevemente o que foi realmente feito e o que funciona.
• Atualiza a memória: variáveis, decisões, conflitos de biblioteca encontrados e beco sem saída.
• Verifica se faz sentido continuar ou se a tarefa atingiu limitações de ferramentas.
• Formula uma diretiva clara de como o trabalhador deve avançar e contornar erros.

A técnica mais interessante é como essas instruções são transmitidas. As recomendações do gerenciador, além do bloco de memória, são apresentadas ao trabalhador como uma nova mensagem do usuário. Por isso, o executor percebe as instruções como prioritárias e as questiona menos. Paralelamente, o sistema limpa sua conversa anterior com logs e erros para iniciar um novo ciclo com uma "janela limpa".

Há risco nessa abordagem: se o gerenciador interpretar mal os logs e escrever um fato falso na memória, o trabalhador seguirá obstinadamente um curso errado. Mas o autor escreve que no papel analítico, o modelo caro alucina muito menos frequentemente do que na geração direta de código.

Um efeito adicional — testes e documentação começam a aparecer junto com a tarefa por padrão, e os desenvolvedores se deslocam do papel de executores manuais para o papel de operadores e arquitetos de processo.

O Que Significa

Este caso demonstra bem que o sucesso em desenvolvimento de IA não vem apenas da escolha do modelo, mas também da distribuição correta de papéis entre eles. Se você usar um LLM caro como despachante de memória, controlador de decisões e disjuntor para ciclos sem sentido, pode simultaneamente aumentar a estabilidade do processo e reduzir o custo de retrabalho.

Para equipes que já foram queimadas por "programadores autônomos", esta é uma das conclusões arquitetônicas mais práticas dos últimos meses.