Como um Dev Melhorou 15 LLMs Sem Alterar o Modelo

Ferramentas de IA — Geral
, ,
1

Screenshot 2026-04-20 at 2.33.13 PM
Screenshot 2026-04-20 at 2.33.13 PM1724×970 364 KB

Vou ser direto: toda a conversa sobre IA e código agora gira em torno dos modelos. GPT-5.4 vs. Claude Opus 4.6. Gemini 3 vs. o que saiu esta semana. Qual modelo escreve melhor código? Qual entende seu codebase mais rápido? Qual alucina menos?

Can Bölük acabou de demonstrar que essa é a pergunta errada.

Bölük — um desenvolvedor com background em segurança de videogames — mantém oh-my-pi, um agente de código open-source forkado do Pi de Mario Zechner. Tem mais de 1.300 commits encima, a maioria melhorando a maquinaria entre o modelo e seus arquivos. A parte que ninguém fala: o harness.

Sua tese é simples e respaldada por dados: a maioria das falhas dos agentes de código não são falhas do modelo. São falhas do harness. O modelo sabe o que mudar. Simplesmente não consegue expressar a mudança de forma confiável através da ferramenta de edição que lhe deram.

Construiu uma técnica chamada Hashline para provar isso. Depois a benchmarkeou contra 16 modelos, 180 tarefas e 3 execuções cada uma. Os resultados deveriam mudar a forma como você pensa sobre ferramentas de código com IA.

O Problema da Ferramenta de Edição do Qual Ninguém Fala

Todo agente de código precisa modificar arquivos. Parece trivial. Não é. As três abordagens dominantes têm problemas fundamentais:

OpenAI Codex usa apply_patch — um formato de diff próprio. O modelo gera algo que parece um diff, e o harness o aplica. O problema? Esse formato está essencialmente treinado dentro dos modelos Codex. Dê esse formato para qualquer outro modelo e as falhas de patch explodem. Bölük mediu uma taxa de falha de 50.7% para Grok 4 e 46.2% para GLM-4.7. Não são modelos ruins — simplesmente não falam o formato.

Claude Code usa str_replace — encontrar texto exato, substituí-lo por texto novo. Conceitualmente simples, mas o modelo tem que reproduzir cada caractere perfeitamente: espaços, indentação, aspas. Múltiplas correspondências no arquivo? Rejeitado. O erro “String to replace not found in file” é tão comum que tem seu próprio megathread no GitHub Issues com mais de 27 issues relacionadas.

Cursor treinou uma rede neural separada de 70B cujo único trabalho é pegar um rascunho de edição e fazê-lo merge corretamente no arquivo. O problema do harness é tão difícil que uma das empresas de IA mais bem financiadas decidiu jogar outro modelo em cima.

Os benchmarks próprios do Aider mostraram que a escolha de formato sozinha fez o GPT-4 Turbo passar de 26% para 59% de taxa de sucesso. O paper Diff-XYZ do JetBrains confirmou sistematicamente: nenhum formato de edição domina em todos os modelos. O fio condutor é que todas essas abordagens forçam o modelo a reproduzir conteúdo que já viu. Quando não consegue — e muitas vezes não consegue — a gente culpa o modelo.

Hashline: Referenciar Linhas por Hash, Não por Texto

A ideia de Bölük é elegante. Quando o modelo lê um arquivo, cada linha vem etiquetada com um hash de conteúdo de 2 caracteres:

1:a3|function hello() {
2:f1|  return "world";
3:0e|}

Quando o modelo edita, referencia essas etiquetas: “substituir linha 2:f1”, “substituir intervalo 1:a3 até 3:0e”, “inserir após 3:0e.” O modelo nunca precisa reproduzir o conteúdo anterior. Sem reprodução de espaços em branco, sem “string not found”, sem correspondências ambíguas.

E tem um mecanismo de segurança incorporado: se o arquivo mudou desde a última leitura, os hashes não vão coincidir e a edição é rejeitada antes que qualquer coisa se corrompa. O modelo recebe um erro claro que lhe diz para reler o arquivo, não uma falha críptica.

A implementação técnica usa xxHash32 mapeado para um alfabeto de 16 caracteres, produzindo âncoras curtas e memoráveis. São aproximadamente 200 linhas de código core.

Os Números que Deveriam Mudar a Conversa

O benchmark: 180 tarefas geradas a partir de arquivos reais do codebase do React, com mutações mecânicas (trocas de operadores, flips de booleanos, erros off-by-one, guard clauses deletadas). 3 execuções por tarefa, sessão do agente fresca cada vez, quatro ferramentas (read, edit, write). Três formatos de edição testados: apply_patch, str_replace e hashline.

Os resultados principais:

Grok Code Fast 1: 6.7% → 68.3%. Uma melhoria de dez vezes. A capacidade real de codificação do modelo estava quase completamente oculta atrás de falhas mecânicas de edição.

Gemini 3 Flash: +5 pontos percentuais sobre str_replace — superando a melhor tentativa do Google para resolver esse problema.

Grok 4 Fast: 61% de redução em tokens de output. O modelo parou de queimar contexto em loops de tentativas por edições falhadas.

MiniMax: Mais que dobrou sua taxa de sucesso.

O padrão é consistente: hashline iguala ou supera str_replace para quase todos os modelos testados, e os modelos mais fracos são os que mais ganham. Os modelos que pior pareciam no papel não eram ruins programando. Eram ruins reproduzindo texto exato para ferramentas de edição que exigiam isso.

A conclusão de Bölük vale a pena internalizar:
“+8% de melhoria na taxa de sucesso do Gemini é maior do que o que entregam a maioria das atualizações de modelos, e custou zero compute de treinamento.” Apenas uma interface de edição diferente e ~$300 em custos de benchmarking.

O Ângulo do Vendor Lock-In

Aqui é onde a história fica afiada. Enquanto Bölük rodava esses benchmarks, duas coisas aconteceram:

Anthropic bloqueou OpenCode — um agente de código open-source muito popular — para que não pudesse acessar Claude através de assinaturas de Claude Code. Sua posição: “OpenCode fez engenharia reversa de uma API privada.” Tecnicamente justo. Mas o sinal que manda é claro: não construa harnesses alternativos. Use o nosso.

Google baniu a conta Gemini de Bölük completamente. Não o rate-limitou. Não o avisou. Desabilitada. Por rodar um benchmark — o mesmo que mostrou que seu próprio modelo melhorava 5 pontos percentuais com sua técnica.

O argumento de Bölük contra essa postura é convincente: nenhum vendor vai otimizar seu harness para os modelos da concorrência. Anthropic não vai tunear para Grok. xAI não vai tunear para Gemini. OpenAI não vai tunear para Claude. Mas um harness open-source tuneia para todos, porque os contribuidores usam modelos diferentes e consertam as falhas que encontram pessoalmente.

O modelo é o fosso. O harness é a ponte. Queimar pontes significa que menos gente se importa em cruzar.

O Que Isso Significa para Desenvolvedores

Se você está usando qualquer agente de código com IA — Claude Code, Codex, Cursor, Windsurf, ou uma alternativa open-source — você precisa entender que um percentual significativo das falhas que você atribui a “o modelo é burro” são na verdade a ferramenta de edição falhando silenciosamente.

Três conclusões:

O formato de edição importa tanto quanto o modelo. Aider provou, JetBrains confirmou, e Bölük quantificou. Quando vê seu agente lutando com edições, o gargalo pode não ser a inteligência — pode ser a interface entre a inteligência e seus arquivos.

Os harnesses open-source é onde está a inovação. Os vendors têm incentivos fortes para mantê-lo em seu harness. A comunidade tem incentivos fortes para que todos os modelos funcionem melhor. oh-my-pi, OpenCode, Aider — esses projetos estão melhorando todo o ecossistema, não apenas um modelo.

“Qual modelo é o melhor?” é cada vez mais a pergunta errada. A melhor pergunta é: qual sistema — modelo mais harness mais ferramentas — produz os melhores resultados para seu trabalho específico? Can Bölük melhorou 15 modelos simultaneamente mudando uma única variável. Essa variável não era o modelo.

Estamos culpando o piloto pelo trem de pouso. É hora de olhar para o harness.

Links: