De 6,7% para 68,3% de taxa de sucesso: foi o harness, não o modelo, que fez a diferença de 10x

A taxa de sucesso do Grok Code Fast num benchmark de codificação era de 6,7%. Sem trocar o modelo, apenas substituindo um formato de edição, passou para 68,3%. Nenhum bit dos parâmetros do modelo foi alterado.

Durante as férias, rodei agentes por conta própria e tive experiências semelhantes. O ritmo de lançamento de modelos é de tirar o fôlego, mas o que separou drasticamente o desempenho na prática não foi o modelo em si. Foi o harness que envolve o modelo: a combinação de prompt de sistema, configuração de ferramentas e middleware.

O mesmo modelo, rankings diferentes

A equipe da LangChain rodou o Terminal Bench 2.0 com seu próprio agente de codificação. Mantendo o GPT-5.2-Codex intacto, ajustou apenas o prompt de sistema, a configuração de ferramentas e o middleware. A pontuação subiu de 52,8 para 66,5, e o agente saiu de fora do top 30 para o top 5 do leaderboard. Custo de treinamento de modelo: zero.

O ponto central foi a distribuição do orçamento de raciocínio. Aplicar xhigh uniformemente em todas as tarefas mantinha o resultado em 53,9%, mas dividir por dificuldade de tarefa em xhigh-high-xhigh elevou para 66,5%. Problemas que antes falhavam por timeout foram resolvidos com essa estratégia de distribuição. Mesmo modelo, mesmo orçamento de tokens, apenas com uma alocação diferente.

O desempenho real escondido pelo formato de edição

Um desenvolvedor de agente open source criou um método de edição chamado hashline. Ao ler um arquivo, cada linha recebe uma tag hash de 2 a 3 caracteres, e ao fazer modificações o modelo referencia apenas essa tag.

No método convencional, o modelo precisava reproduzir o texto original sem errar um único caractere. Um espaço a mais já causava falha. Quem já usou um agente de codificação na prática conhece bem a dor dos erros “String not found” se repetindo. O hashline contorna esse problema de forma estrutural.

Os resultados foram dramáticos. O Grok Code Fast saltou de 6,7% para 68,3%, e o Grok 4 Fast reduziu os tokens de saída em 61%. O GPT-4 Turbo passou de 26% para 59% apenas com a mudança de formato, e o Gemini 3 Flash superou o próprio recorde anterior em 5 pontos percentuais. Tudo isso sem nenhum custo de treinamento, apenas trocando a interface de edição.

Sem loop de validação, o agente para na primeira resposta

Existe um padrão de falha muito comum. O agente escreve o código, relê o que escreveu, conclui que está bom e para. Sem rodar um único teste.

A equipe da LangChain inseriu um middleware que força a validação contra a especificação da tarefa logo antes do agente encerrar. Um “doom loop” de edições repetidas no mesmo arquivo também é detectado por um middleware separado, que induz o agente a reconsiderar a abordagem. Sem esses dois mecanismos, o ganho de pontuação teria sido muito menor. Também foram eficazes a injeção prévia da estrutura de diretórios e das ferramentas disponíveis no agente, além de alertas de orçamento de tempo para induzir a entrada na fase de validação.

Modelos mais baratos são mais sensíveis ao harness

MiniMax M2.5 e Kimi K2.5 são rápidos e eficientes no uso de ferramentas de agente. O preço também é muito mais baixo em comparação com os grandes modelos. Em contrapartida, o conhecimento de base é inferior ao dos grandes modelos americanos. O MiniMax tem uma forte sensação de ter sido treinado desde o início como modelo especializado em agentes. Com menos recursos, optou por especialização em vez de generalização, e graças ao preço acessível o uso está crescendo rapidamente em plataformas como o Openclaw.

Analisando os resultados do benchmark hashline, fica claro que modelos mais fracos apresentaram variações de desempenho muito mais extremas com a mudança de formato. O MiniMax mais que dobrou a taxa de sucesso após a aplicação do hashline. O custo total do benchmark foi de aproximadamente USD 300.

Benchmark não é sinônimo de produção

Há um ponto importante a considerar. Tanto o Terminal Bench quanto o benchmark hashline são métricas medidas em ambiente controlado. Na produção real, há muito mais variáveis: escala do codebase, conflitos de dependências, requisitos ambíguos. Se o agente que marcou 66,5% no benchmark vai entregar o mesmo desempenho num projeto legado de 100 mil linhas ainda não foi verificado. A otimização de harness claramente é eficaz, mas traduzir diretamente o ranking do benchmark em desempenho real é arriscado.

Ainda assim, a direção é clara. Existe um intervalo em que o design do harness supera a escolha do modelo em termos de ROI. Grande parte do ranking de benchmarks que vemos hoje não reflete a capacidade do modelo, mas sim a qualidade do harness.