- Ao testar vários LLMs nas mesmas condições, o desempenho melhorou bastante apenas trocando a ferramenta de edição de código
- Em vez dos métodos tradicionais de Patch·Replace, foi aplicado o formato “Hashline”, que atribui hash tags a cada linha de código, aumentando a precisão das edições
- O Hashline apresentou precisão superior ao método anterior em 14 dos 16 modelos, e também mostrou um efeito de redução média de 20~30% nos tokens
- Em especial, o modelo Grok Code Fast 1 teve sua taxa de sucesso saltando de 6,7% para 68,3%, um ganho de 10x com uma simples mudança no harness
- O estudo mostra que, mais do que o próprio modelo, o “harness” é o gargalo do desempenho real, e destaca a necessidade de colaboração no ecossistema open source
Visão geral do benchmark de edição de código
- O experimento comparou três formatos de edição: Patch, Replace e Hashline
- 16 modelos executaram a mesma tarefa de correção de código
- Cada modelo foi testado corrigindo bugs em arquivos escolhidos aleatoriamente em uma base de código React
- O formato Hashline superou o Patch em 14 modelos e, em média, economizou 20~30% de tokens
- A maior melhora foi no modelo Grok Code Fast 1, cuja taxa de sucesso subiu de 6,7% para 68,3% (+61,6 pp)
- Gemini 3 Flash melhorou 5,0 pp, e Claude Sonnet 4.5, 1,6 pp
O problema do harness
- Atualmente, a discussão costuma se concentrar em “qual modelo programa melhor”, mas o gargalo real é o harness, não o modelo
- O harness é a interface central que gerencia os tokens de entrada e conecta a saída do modelo às mudanças no workspace
- A maior parte das falhas não vem do modelo, mas de limitações estruturais do harness
- O autor tentou melhorar isso por meio do projeto pessoal oh-my-pi, um fork do agente de programação open source Pi, realizando cerca de 1.300 commits
- Esse ambiente é independente de modelo e permite experimentar mantendo apenas o harness como variável
Limitações das ferramentas de edição existentes
- O método
apply_patch do Codex usa um formato diff específico da OpenAI, o que leva a altas taxas de falha em outros modelos
- Exemplo: taxa de falha de patch de 50,7% no Grok 4 e de 46,2% no GLM-4.7
- O método
str_replace do Claude Code exige correspondência exata de string, então diferenças de espaço ou indentação geram erros
- O erro “String to replace not found in file” foi relatado muitas vezes no GitHub
- O Cursor treina um modelo separado de 70B para lidar com o merge, mas em arquivos com menos de 400 linhas uma reescrita completa (full rewrite) produz resultados melhores
- Pesquisas como Diff-XYZ da JetBrains e EDIT-Bench também confirmaram que o desempenho varia muito conforme o formato de edição
Como funciona o método Hashline
- Cada linha de código recebe um hash de conteúdo com 2~3 caracteres, permitindo que o modelo identifique com clareza o alvo da modificação
- Exemplo:
22:f1| return "world";
- O modelo faz pedidos de edição com base no hash, como “replace line 2:f1”
- Se o arquivo mudar e o hash não coincidir, a edição é rejeitada para evitar corrupção
- Como o modelo não precisa reproduzir o conteúdo existente, esse método reduz erros de espaço e indentação e permite edições mais estáveis
Resultados do benchmark
- O teste foi composto por 180 tarefas de correção de bugs, 3 repetições e 4 ferramentas (read, edit, write, etc.)
- No resultado final, o formato Patch foi o pior em quase todos os modelos, enquanto o Hashline foi equivalente ou superior ao Replace
- Quanto mais fraco o modelo, maior foi a melhora
- O Grok 4 Fast reduziu os tokens de saída em 61%, e o MiniMax melhorou mais de 2x
- O aumento de +8% na taxa de sucesso do Gemini é maior do que uma atualização típica de modelo, e foi alcançado sem treino adicional
Políticas dos vendors e o ecossistema open source
- A Anthropic bloqueou o acesso do Claude Code no agente de programação open source OpenCode
- O motivo foi “engenharia reversa de API privada”, mas na prática isso foi interpretado como um sinal de “use apenas nosso próprio harness”
- O Google bloqueou a conta do autor e impediu o acesso ao Gemini
- Isso ocorreu logo após um benchmark em que o desempenho do Gemini 3 Flash subiu para 78,3% com a aplicação do Hashline
- O autor aponta que essas medidas são ações retrógradas que bloqueiam oportunidades de melhorar os modelos
- A otimização do harness é uma pesquisa pública que melhora a qualidade de todos os modelos, não de um modelo específico
- Com a expressão “o modelo é o fosso, o harness é a ponte”, ele enfatiza que uma abordagem fechada prejudica o avanço do ecossistema
Conclusão
- O problema do harness foi confirmado como um fator mensurável que afeta diretamente o desempenho real
- Mesmo uma simples mudança de formato pode gerar ganhos comparáveis a uma atualização de modelo
- O caminho para avanços futuros não deve ser uma melhoria fechada de uma única empresa, mas uma colaboração aberta baseada na comunidade
- Todo o código, benchmarks e resultados de execução estão públicos no repositório GitHub oh-my-pi
3 comentários
O modelo está estranho, então por que fazer engenharia de prompt de novo...
Harness e engenharia de prompt são coisas completamente diferentes.
Comentários do Hacker News
Li este texto com muito interesse. Acho que o autor acertou exatamente no ponto central.
Mesmo com os modelos que já existem hoje, ainda há muito espaço para torná-los muito mais eficientes dependendo de como projetamos o harness de agente.
Eu não vejo “IA” apenas como o próprio LLM, mas como todo o sistema cibernético em que o LLM e o harness estão ligados por um loop de feedback.
Como modelo e harness se reforçam mutuamente e evoluem juntos, os dois são igualmente importantes.
Essa perspectiva não só melhora desempenho, como também permite reinterpretar a IA generativa como um projeto neuro-simbólico (neurosymbolic)
Eu realmente criei um agente de programação com a versão de 2023 do GPT-4.
Trabalhar com um modelo antigo obriga a manter a simplicidade, e isso acaba fazendo você enxergar o problema de outra forma.
Por exemplo, em Python, uma compressão semântica simples como
grep -r def .é essencial.Se você adicionar hooks simples assim a uma ferramenta como o Claude Code, ela consegue entender a estrutura do código de imediato sem desperdiçar tokens
Com apenas algumas horas de ajuste de prompt e código de tratamento de resposta, a qualidade de saída de modelos locais pequenos melhora de forma surpreendente
Link do GitHub
A OpenAI depurou seu próprio processo de treinamento e gerenciou implantações com uma versão inicial do GPT-5.3-Codex.
O Claude Code envia mais de 20 PRs por dia, todos gerados pelo próprio código
Na prática, nem sabemos direito quais modelos são sensíveis a uma boa engenharia de contexto.
Mas concordo que claramente ainda há muitos ganhos fáceis (low hanging fruit)
A técnica é interessante, mas dá a sensação de estar superestimada.
O autor viu uma melhora de 5% em um benchmark simples de localizar/substituir que ele mesmo criou e fala como se o desempenho total tivesse subido 14 pontos.
Na prática, é bem provável que isso represente menos de 1% de melhora na eficiência total de tokens.
Além disso, o tom exagerado do texto e o estilo típico do ChatGPT diminuem a confiança
Este texto mostra bem o tamanho da margem para melhorias no nível do harness.
Agentes desperdiçam muitos tokens em edição, sandbox e passagem de dados entre chamadas de ferramenta.
A combinação de endereçamento baseado em conteúdo + numeração de linhas é prática e elegante
Isso facilita o desenvolvimento inicial, mas acaba acionando modelos desnecessariamente grandes, o que é ineficiente
No CC, dá para ver o custo por sessão com o comando
/cost, e esse tipo de métrica é útil para avaliar a eficiência de pluginsA importância do harness é muito maior do que a maioria das pessoas imagina.
Por exemplo, a pontuação do Opus no benchmark CORE quase dobrou ao trocar do harness próprio para o Claude Code
Link relacionado
ele também explica que a maior pontuação no TerminalBench veio graças ao harness Terminus 2
Ficar preso a um harness específico por causa de uma assinatura de 20 dólares por mês não faz sentido
Eu criei uma ferramenta chamada tilth que implementa um método de leitura/edição baseado em hash.
Ela pode ser instalada via npm e cargo e se integra a editores como Claude Code e Cursor
Link do GitHub
O objetivo é fazer o LLM usar ferramentas com mais eficiência e desperdiçar menos tokens
Eu cheguei independentemente a um método parecido, mas desisti por causa da dependência da abstração.
Em vez disso, usei a distância de Damerau-Levenshtein para calcular a similaridade das edições e permitir a modificação quando passa de um certo limiar.
Isso faz o modelo emitir explicitamente os tokens de origem a serem substituídos, o que aumenta a precisão
Exemplo de código
O ponto-chave é que as mensagens de erro precisam ser específicas — o tratamento de erro deve incluir instruções de recuperação, como “Content mismatch. Reread the file”.
Essa abordagem funciona bem até com modelos 4B e, para modelos sem suporte a chamadas de ferramenta, ela usa um hack de injeção no prompt do sistema
Código relacionado
Mesmo modelos antigos conseguiam resultados bastante precisos.
O segredo era “lidar com o modelo da forma certa”.
Este texto sugere que o avanço seria ainda maior se o modelo pudesse lidar diretamente não apenas com texto, mas com uma representação estrutural do código-fonte (AST).
Por exemplo, o OpenRewrite usa uma Lossless Semantic Tree que inclui tipo, formatação e dependências do código.
Se o modelo pudesse aproveitar essa estrutura, daria para fazer modificações muito precisas sem desperdiçar tokens desnecessariamente.
No fim, é a mesma razão pela qual a resposta para a discussão “Vim vs Emacs” é “IntelliJ” — informação estrutural é uma arma poderosa.
Se um modelo aprendesse junto código, documentação e árvores sintáticas/semânticas, ele se tornaria um verdadeiro modelo de programação neuro-simbólico
Ao experimentar LLMs no Emacs com o gptel, descobri que LLMs não são bons em editar código com a ferramenta Unix patch.
Então criei eu mesmo uma ferramenta para o gptel usando o tree-sitter do Emacs.
Fazendo o modelo modificar diretamente nós da AST com comandos como
tree_sitter_list_nodesetree_sitter_update_nodes, funcionou perfeitamenteO
apply_patchdo Codex na verdade usa um esquema de amostragem restrita.Código relacionado
Como o autor fez a comparação sem saber disso, um benchmark mais realista deveria ser feito com esse esquema ativado
Entre as citações deste texto, houve uma que me marcou especialmente
“O modelo não deixa de entender o problema; a representação é que é instável. Não culpe o piloto por um problema no trem de pouso.”
“O modelo é o fosso (moat), o harness é a ponte (bridge).”
“A diferença entre uma demo impressionante e uma ferramenta confiável não é mágica, mas sim uma engenharia entediante, porém refinada.”