Rodar modelo local para codar: o teste honesto de Böckeler

Enquanto o mercado discute modelos chineses tomando fatia por preço, uma pergunta paralela cresce nos times de engenharia: dá para tirar a nuvem da equação e rodar o modelo na própria máquina? Birgitta Böckeler, Distinguished Engineer da Thoughtworks e uma das vozes mais respeitadas em entrega de software assistida por IA, passou semanas testando exatamente isso e publicou o relato em 8 de julho na série Exploring Gen AI, do site de Martin Fowler. O texto vale pela honestidade: nada de manifesto a favor ou contra, só experimento documentado com as falhas à mostra.

Quem é a voz

Böckeler tem mais de 20 anos como desenvolvedora, arquiteta e líder técnica, e hoje coordena na Thoughtworks o trabalho sobre como IA generativa muda a prática de entrega de software. A série que ela mantém no site de Fowler é leitura obrigatória do tema desde 2023. Quando ela publica um resultado, não é opinião de timeline: é experimento com método descrito.

O que ela testou

O foco foi coding agêntico, não autocomplete: agentes que leem arquivos, chamam ferramentas e editam código. As máquinas: um MacBook M3 Max com 48 GB de RAM e um M5 Pro com 64 GB. Os modelos: variantes do Qwen3.6 35B MoE, Gemma 4 em dois tamanhos e o Qwen3 Coder Next 80B, todos quantizados, rodando via LM Studio com OpenCode ou Pi como harness.

O achado metodológico mais útil é o funil de viabilidade em sete degraus que ela usou para não se perder: o modelo cabe na RAM? Responde em velocidade tolerável? Aguenta tool calling? Produz código funcionalmente correto? Sobrevive a uma conversa longa? Dá conta de tarefa complexa? E, só no fim, a qualidade do código compensa o esforço de revisão? É uma régua reaproveitável para avaliar qualquer modelo, local ou não.

O que aconteceu

O resumo dela: uma montanha-russa. O modelo mais capaz que coube na máquina (Qwen Coder Next 80B) resolveu uma tarefa de frontend em 2,5 minutos e travou o runtime na mensagem seguinte. Modelos médios ajustaram uma ordenação sem drama e depois consumiram 15 minutos de idas e vindas num cálculo de percentual acumulado. Uma tarefa aparentemente simples de gráfico de barras gerou anotações como "desisti depois de 11 minutos". E a avaliação automatizada contradisse a impressão manual: o modelo que parecia melhor no uso interativo falhou 3 de 3 vezes no teste repetido.

O achado mais incômodo: o mesmo modelo, com as mesmas configurações, falhou 5 de 7 vezes na máquina de 48 GB e apenas 1 vez na de 64 GB. A autora chama isso de mistério sem explicação. Para quem opera IA, é um lembrete de que ambiente é variável de resultado, não detalhe.

"No geral, as capacidades de coding agêntico estão definitivamente muito distantes daquilo a que me acostumei com os modelos maiores", conclui a autora.

Mas há um contraponto que ela faz questão de registrar. Trabalhar com modelos fracos foi, nas palavras dela, quase um detox: a sensibilidade maior do modelo a mudanças no setup gerou mais sinal sobre o que ajuda e o que atrapalha, e a tentação de "desligar o cérebro e aceitar o resultado" caiu. Ela voltou a revisar mais, no bom sentido, em vez de adiar a compreensão para depois, quando o retrabalho cobra juros.

Nossa leitura

Primeiro, o caso de uso realista de modelo local hoje é o degrau de baixo de uma arquitetura em camadas: tarefas pequenas, bem definidas, de preferência planejadas por um modelo grande e executadas pelo pequeno. É o mesmo racional do roteamento por custo que os dados de mercado mostram, aplicado ao extremo da privacidade e da independência de fornecedor.

Segundo, o funil de Böckeler é o que separa avaliação de achismo. A contradição entre a impressão manual e o teste automatizado dela é o argumento definitivo: sem eval repetível, você escolhe modelo por carisma. Isso conversa direto com o que o Karpathy diz sobre automatizar só o que dá para verificar e com o gargalo de julgamento que temos discutido: a capacidade de julgar o resultado é o que limita o valor da automação.

Há também um dado de segunda mão que dá esperança a quem quer insistir: um colega dela na Thoughtworks roda o mesmo Qwen 35B quantizado num MacBook de 48 GB e faz quase todo o trabalho diário com ele, numa base de código real em Python e React. A diferença está no harness: ele investe continuamente em skills e ferramentas de busca e compreensão de código que compensam as limitações do modelo, e trata a revisão de código como inegociável. Ou seja, o teto do modelo pequeno depende muito do andaime que você constrói em volta dele.

Terceiro, o detox merece atenção de quem lidera times. Se um modelo fraco força revisão cuidadosa e um modelo forte convida à rendição, o problema não é o modelo forte, é o processo que não exige compreensão. Vale a pergunta: o seu time revisa o que os agentes produzem ou apenas aprova?

Se o seu time está decidindo entre API de fronteira, modelo aberto hospedado e modelo local, chame a gente no WhatsApp que a gente ajuda a montar uma avaliação que caiba na sua realidade.