Habr AI: como LLMs caros viraram gerentes de estado e reduziram os custos de desenvolvimento

O Habr AI publicou uma análise de uma arquitetura de desenvolvimento com IA em que o LLM caro não escreve mais código sozinho, mas comanda um executor mais barato. O autor afirma que a mudança eliminou ciclos de erro infinitos, reduziu o contexto e cortou de forma notável os gastos com API.

Onde os agentes falhavam

A equipe começou pelo caminho popular: pegou o Aider e o integrou ao CI/CD para que um agente atualizasse a documentação automaticamente após mudanças no código. Para essa tarefa, a ferramenta funcionou bem e eliminou parte da dívida técnica. Mas, quando tentaram entregar a ela o ciclo completo de desenvolvimento, do backlog e das especificações até o código e os testes, o sistema logo bateu nos limites. Os principais problemas foram dois: pouco controle sobre as integrações e uma passagem confusa de artefatos entre as etapas, em que o agente cria algo, mas é difícil recolher isso com segurança e encaixar na etapa seguinte.

A tentativa seguinte ficou mais próxima de um organograma tradicional: um orquestrador define a tarefa e vários agentes programadores a executam em partes. No papel, o esquema parece lógico, mas na prática gerou duas falhas sistêmicas. A primeira foi a ruptura de responsabilidade: se um agente não termina parte de uma função e o seguinte já constrói sua lógica em cima dela, o erro se espalha em cascata. A segunda foi a paralisia por análise. Os modelos leem o repositório sem parar, reverificam arquivos e adiam as mudanças reais enquanto o contexto incha e a conta de tokens cresce.

Por que trocar os papéis

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

Daí nasceu a nova ideia: o modelo forte deve ser colocado não na rotina, mas no controle.

«O CEO não faz cold calls».

Em vez de um esquema em que o LLM caro escreve o código mais difícil, a equipe adotou algumas regras rígidas:

• Um agente conduz uma especificação do início ao fim e corrige os próprios erros.
• O agente trabalha apenas com uma «mesa» limitada de 5–8 arquivos, e não com o repositório inteiro.
• Ao fechar um arquivo, ele guarda uma memória curta das descobertas úteis, para não carregar o código-fonte completo no contexto.
• O modelo mais inteligente não programa à mão, mas atua como gerente de estado do worker barato.

Como o gerente funciona

Na nova arquitetura, um LLM barato e rápido atua como worker: escreve código, chama ferramentas, recebe erros de compilação e faz as passagens de rotina. Quando o worker esbarra em um problema ou esgota o limite de ações, o controle passa para o modelo caro, o gerente de estado. Ele não mexe diretamente no código: lê o histórico acumulado, descarta o ruído e monta, para o próximo passo, uma versão compacta e útil do contexto.

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

• Registra em poucas palavras o que já foi realmente feito e o que funciona.
• Atualiza a memória: variáveis, decisões, conflitos de bibliotecas encontrados e becos sem saída.
• Verifica se vale a pena continuar ou se a tarefa bateu nos limites das ferramentas.
• Formula uma diretriz clara de como o worker deve avançar e contornar os erros.

O truque mais interessante é a forma de transmitir essas orientações. Além do bloco de memória, as recomendações do gerente chegam ao worker como uma nova mensagem do usuário. Assim, o executor trata as instruções como prioritárias e discute menos com elas. Em paralelo, o sistema limpa a conversa anterior, com logs e erros, para iniciar um novo ciclo com a «janela limpa».

O esquema também tem um risco: se o gerente interpretar mal os logs e gravar um fato falso na memória, o worker seguirá teimosamente o rumo errado. Mas o autor escreve que, no papel analítico, o modelo caro alucina bem menos do que ao gerar código diretamente.

Um efeito adicional é que testes e documentação passam a surgir junto com a tarefa por padrão, e os desenvolvedores deixam de ser executores manuais para virar operadores e arquitetos do processo.

O que isso significa

Esse caso mostra que o ganho no desenvolvimento com IA vem não só da escolha do modelo, mas da distribuição correta de papéis entre eles. Se o LLM caro for usado como despachante de memória, controlador de decisões e freio de emergência para ciclos sem sentido, é possível aumentar a estabilidade do processo e reduzir o custo do retrabalho ao mesmo tempo. Para as equipes que já se queimaram com «programadores autônomos», é uma das conclusões de arquitetura mais práticas dos últimos meses.