A Diferença do Harness: Quando 42% Vira 78% Sem Trocar o Modelo

Existe um número que deveria encerrar metade dos debates sobre “qual modelo é melhor”: 42% contra 78%.

Mesmo benchmark. Mesmo modelo. Claude Opus 4.5, avaliado no CORE-Bench. A diferença entre os dois resultados não foi uma atualização do modelo, um fine-tuning secreto, ou um dataset maior. Foi o harness. O CORE-Agent marcou 42%. O Claude Code marcou 78%. Depois de corrigir erros no próprio sistema de pontuação do benchmark, o resultado subiu para 95%.

O modelo era idêntico em ambos os casos. A inteligência era a mesma. O que mudou foi tudo ao redor dela.

Os Dados Que Ninguém Compara

O CORE-Bench não é um caso isolado. É um padrão que se repete em cada benchmark onde o mesmo modelo roda em ambientes diferentes.

No SWE-bench Pro, três produtos usam Claude Opus 4.5 para resolver os mesmos 731 problemas de engenharia de software. Os resultados: Auggie alcançou 51,80%. Cursor ficou em 50,21%. Claude Code chegou a 49,75%. Três implementações. Mesmo modelo por baixo. Diferença de dois pontos percentuais entre o melhor e o pior.

O LangChain Terminal Bench mostrou algo parecido com outro modelo. GPT-5.2-Codex, mantido fixo, foi de 52,8% para 66,5% apenas mudando o harness de execução. Quase 14 pontos percentuais. Nenhuma alteração no modelo.

Esses números contam uma história que a indústria prefere ignorar. A corrida por modelos maiores, mais caros, com janelas de contexto maiores, está otimizando a variável errada.

O Que o Harness Realmente Faz

A palavra “harness” é técnica, e propositalmente vaga. Na prática, ela descreve tudo que conecta o modelo ao mundo: como a tarefa é apresentada, quais ferramentas estão disponíveis, como os resultados são validados, quais ciclos de correção existem.

A Vercel demonstrou isso com clareza cirúrgica. Seu sistema v0, rodando o modelo d0, teve a superfície de ferramentas reduzida de 15 para 2. O resultado: a taxa de sucesso subiu de 80% para 100%, e a velocidade de execução aumentou 3,5 vezes.

Menos ferramentas. Mais sucesso. Mais rápido.

Isso contradiz a intuição de que dar mais capacidades ao agente produz resultados melhores. O que produz resultados melhores é restringir o espaço de decisão. Cada ferramenta adicional é uma bifurcação onde o modelo pode errar. Remover bifurcações desnecessárias é engenharia, não limitação.

Como exploramos em a camada agêntica da Stripe, a separação entre nós determinísticos e nós agênticos segue o mesmo princípio. O modelo opera dentro de limites definidos por engenheiros. As paredes importam mais que o motor.

Cursor: A Prova Pela Infraestrutura

O caso da Cursor é instrutivo porque revela onde o investimento de engenharia realmente acontece.

Para resolver o problema de manter o modelo sincronizado com um repositório em constante mudança, a Cursor implementou árvores de Merkle como provas de conteúdo. Cada arquivo recebe um hash. O sistema verifica se o modelo está operando sobre a versão correta antes de executar qualquer ação.

O resultado prático: a latência p99 de indexação caiu de 4,03 horas para 21 segundos. Não porque o modelo ficou mais rápido. Porque a infraestrutura ao redor dele ficou mais inteligente.

A equipe da Cursor não publicou isso como breakthrough de IA. Publicou como engenharia de sistemas. Porque é exatamente isso.

Stripe: 92% Com 63 Turnos

Os dados da Stripe no SWE-bench full-stack adicionam outra dimensão. Seus agentes, usando Opus 4.5, atingiram 92% de resolução. Mas o número que importa é outro: 63 turnos médios por problema.

Sessenta e três interações entre o agente e o ambiente para resolver um problema de engenharia. Isso não é um modelo gerando resposta em um turno. É um sistema executando ciclos de tentativa, validação, correção e nova tentativa, dentro de um grafo de execução que alterna entre passos determinísticos e passos agênticos.

O resultado alto não vem da capacidade do modelo. Vem da persistência estruturada que o harness permite. A amostra é pequena (n=4), o que limita generalizações. Mas o padrão é consistente com os outros dados: sistemas que investem em ciclos de correção superam sistemas que dependem de acerto no primeiro turno.

O Teto Ainda Existe

Seria desonesto ignorar os limites. O APEX-Agents, benchmark de fronteira para tarefas de pesquisa científica, registrou um melhor resultado de apenas 24%. O harness ajuda. Mas para tarefas que exigem raciocínio genuinamente novo, onde não existe padrão a seguir, o modelo continua sendo gargalo.

A distinção importa. Para tarefas de engenharia de software (onde padrões existem, testes são possíveis, e validação é automatizável), o harness determina a maior parte da performance. Para tarefas na fronteira do conhecimento, onde o modelo precisa raciocinar sem andaimes, a qualidade do modelo ainda domina.

Saber em qual categoria seu problema se encaixa é metade da decisão de investimento.

A Inversão Econômica

Os modelos estão ficando mais baratos. Cada geração custa menos por token. Cada trimestre traz alternativas open-source mais competitivas. O preço de inferência é uma curva descendente.

A engenharia de harness, por outro lado, é um investimento que se acumula. Como discutimos em por que harness engineering não é algo novo, as práticas subjacentes (documentação estruturada, validação automatizada, isolamento de ambiente) são investimentos em infraestrutura. Eles não depreciam com a próxima geração de modelo. Eles se tornam mais valiosos.

Uma organização que gasta 80% do orçamento em modelos e 20% em harness está otimizando o componente que está barateando e negligenciando o componente que gera diferenciação.

A inversão correta: investir no que fica, não no que muda.

O Modelo Não É o Produto

Aqui está a tese condensada.

Quando o CORE-Bench mostra 42% contra 78% com o mesmo modelo, o que está sendo medido não é a capacidade do modelo. É a qualidade da engenharia ao redor dele.

Quando o SWE-bench Pro mostra três produtos com resultados quase idênticos usando o mesmo modelo, a diferenciação entre eles não está no modelo. Está na experiência do usuário, na integração com o workflow, na velocidade de iteração.

Quando a Vercel reduz ferramentas e aumenta performance, está demonstrando que subtração pode ser a forma mais eficaz de engenharia.

Nenhuma dessas conclusões é confortável para quem vende modelos. E todas elas são úteis para quem constrói produtos com modelos.

O modelo é um componente. O harness é o sistema. O sistema é o produto.

Para quem está construindo agentes em produção, a pergunta certa não é “qual modelo devo usar?” É: “qual sistema estou construindo ao redor do modelo que escolhi?”

A resposta para essa segunda pergunta determina se você vai ficar nos 42% ou chegar aos 78%.

Fontes

CORE-Bench. Resultados comparativos CORE-Agent vs Claude Code com Opus 4.5. 2026.
SWE-bench Pro. Leaderboard público, 731 problemas, resultados Auggie/Cursor/Claude Code. 2026.
LangChain. Terminal Bench, resultados comparativos de harness com GPT-5.2-Codex. 2026.
Vercel. Dados de redução de ferramentas e performance do d0. 2026.
Stripe Engineering. “Minions: Stripe’s one-shot, end-to-end coding agents.” Fevereiro 2026.
Cursor. Implementação de árvores de Merkle para indexação de repositórios. 2026.
APEX-Agents. Benchmark de fronteira, resultados máximos de 24%. 2026.

Na Victorino, ajudamos organizações a investir na camada que gera diferenciação: a engenharia de sistemas ao redor dos modelos de IA, não os modelos em si: contato@victorino.com.br | www.victorino.com.br