Quando Seu Agente de IA Congela: Uma História de Infraestrutura Escondida

Existe um tipo específico de frustração em ver um sistema inteligente falhar porrazões idiotas. Recentemente vivi isso testando agentes de codificação com IA rodando localmente — uma tendência que cresce à medida que modelos open-weight ficam mais capazes e o desenvolvimento focado em privacidade ganha força.

O teste era simples: um agente rodando inteiramente no meu hardware conseguiria construir um jogo funcional? Não um demo trivial, mas algo com gerenciamento de estado real, lógica de renderização, обработка de inputs e uma interface jogável. A resposta, depois de muita dor de cabeça, foi sim — mas chegar lá expôs uma classe de problemas que o ecossistema de ferramentas de IA não está tratando bem.

A Configuração Que Deveria Funcionar

O stack tinha três componentes representando o estado da arte em desenvolvimento de IA local: um CLI de agente de codificação provider-agnostic, Ollama servindo uma API compatível com OpenAI via localhost, e Qwen3.8 27B rodando na máquina. Para contexto, não era uma configuração fraca — o modelo 27B com 17GB cabe tranquilamente em 32GB de memória unificada e suporta tool calling com capacidades de raciocínio respeitáveis.

Os resultados iniciais eram promissores. Em quinze minutos, o agente tinhaproduced uma estrutura HTML completa e quase 200 linhas de CSS com visual de console NES, bordas biseladas e paleta de cores adequada. Mais impressionante: o agente pegou seu próprio erro no meio do processo — escreveu um arquivo, relatou, percebeu uma discrepância entre o que pretendia e o que foi salvo, e consertou sem nenhuma instrução. Esse é comportamento genuinamente agentic, e indicava que o modelo daria conta do recado.

Então o agente tentou escrever o arquivo de lógica do jogo, e tudo parou.

A Espiral da Morte

O que veio depois foi uma sequência que qualquer pessoa que já enfrentou problemas com ferramentas de IA vai reconhecer. Treze tentativas consecutivas de escrever o arquivo do motor do jogo, cada uma terminada no meio da geração. O stream simplesmente morria, sem erro, sem explicação, sem output utilizável.

O aspecto mais enlouquecedor não era a falha em si — era observar o processo de raciocínio do agente. Como cada tentativa começava do zero, o modelo derivava as mesmas decisões de design do zero, chegando a tabelas de pontuação e abordagens de implementação diferentes a cada vez. Três tentativas significavam três respostas diferentes para a mesma questão arquitetural. O agente passava uma hora pensando e não entregava nada.

O culpado óbvio parecia ser pressão de memória. Fechar abas do browser liberou vários gigabytes de RAM e as coisas melhoraram marginalmente, o que parecia confirmar o diagnóstico. Mas essa era a lição errada para tirar.

O Que os Logs Realmente Revelavam

Voltando aos logs do servidor, a história era outra. Não havia um único erro de out-of-memory em nenhum deles. A memória livre do sistema ficava confortavelmente entre 21 e 27 gigabytes o tempo todo, contra um footprint de 17 gigabytes do modelo. Memória nunca foi o problema.

O problema real era um mismatch de configuração que nãoproduzia nenhum erro visível. A configuração do agente divulgava uma context window de 32.768 tokens. Mas o servidor Ollama tinha sido reiniciado com um teto de 8.192 tokens, e essa discrepância passava despercebida. O agente planejava felizmente escrever um arquivo de 800 linhas de uma vez, porque pelo que sabia, tinha 32k de margem. Quando a geração real batia na parede de 8k no meio do tool call, a conexão era cortada sem mensagem de erro que o agente pudesse processar.

Havia uma complicação secundária espreitando nos logs de inicialização: o Ollama tinha iniciado com context shifting habilitado, o que permitiria a janela deslizar quando acabasse o espaço, sacrificando tokens mais antigos para abrir lugar para os novos. Mas a arquitetura do modelo não suportava esse recurso, então foi silenciosamente desabilitado. O que deveria ser um limite suave virou uma parede dura.

A Disciplina DevOps Que o Desenvolvimento com IA Exige

Essa experiência cristalizou algo importante sobre desenvolvimento de IA local que o entusiasmo ao redor de modelos open-weight tende a obscurecer. Quando você roda modelos no seu próprio hardware, não está apenas escrevendo código — está operando infraestrutura. E infraestrutura exige a mesma disciplina de diagnóstico, gerenciamento de configuração e atenção a parâmetros operacionais que sistemas em produção demandam.

Context windows não são propriedades abstratas do modelo para configurar e esquecer. São parâmetros operacionais que interagem com sua cadeia de ferramentas de formas não óbvias. Quando o contexto configurado no agente não corresponde ao teto real do servidor, você não recebe um warning — recebe falhas silenciosas que parecem incompetência do modelo quando na verdade são misalignment operacional.

O aprendizado prático para desenvolvedores explorando agentes de codificação com IA local é direto: valide seu ambiente tão rigorosamente quanto validaria um deployment em produção. Verifique que a configuração do agente corresponde aos parâmetros de runtime. Leia os logs do servidor, não apenas a saída do agente. Entenda quais features sua arquitetura de modelo realmente suporta versus o que as ferramentas tentam habilitar.

Os modelos estão ficando melhores. As ferramentas estão amadurecendo. Mas a lacuna entre "funciona em demos" e "funciona de forma confiável no uso diário" ainda requer julgamento humano para preencher — e esse julgamento se parece muito com disciplina tradicional de DevOps aplicada a uma nova classe de infraestrutura.

A build do Tetris eventualmente funcionou. Levou quatro horas e meia ao longo de dois dias, produziu código limpo em três arquivos, e funciona corretamente. Mas as lições vieram não do sucesso, mas de entender por que as falhas aconteceram — e reconhecer que às vezes os problemas mais caros não têm nada a ver com inteligência.