🤖 AI

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation

Este artigo demonstra que o ambiente de avaliação influencia significativamente o desempenho e a eficiência dos agentes de codificação — frequentemente mais do que a escolha do modelo subjacente — ao revelar variações de até 40x no uso de tokens e padrões de falha independentes do modelo, argumentando, assim, pela divulgação das especificações completas do ambiente e das métricas de tokens/latência juntamente com as comparações de modelos.

Autores originais: Naman Vats, Oleg Golev

Publicado 2026-07-28

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Naman Vats, Oleg Golev

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Mão Invisível por Trás do Programador Robô

Imagine que você está assistindo a uma competição de culinária. Você vê dois chefs brilhantes, o Chef A e o Chef B, ambos tentando assar o bolo de chocolate perfeito. Os juízes geralmente apenas olham para o bolo final e dizem: "O Chef A fez um bolo melhor!". Mas e se os juízes tivessem esquecido de mencionar que o Chef A estava usando uma cozinha automatizada de alta tecnologia que pré-picava cada ingrediente e pré-aquecia o forno no segundo exato, enquanto o Chef B estava trabalhando em um galpão empoeirado com uma faca enferrujada e um fogão quebrado? O resultado não é apenas sobre o talento dos chefs; é sobre a cozinha que lhes foi dada.

No mundo da inteligência artificial, especificamente nos "agentes de codificação" (programas de IA que escrevem software), temos feito exatamente isso. Temos classificado modelos de IA com base em quantos problemas de programação eles resolvem, enquanto ignoramos a "cozinha" em que estão trabalhando. Esta cozinha é chamada de harness (suporte ou estrutura). Pense em um harness como o assistente invisível que entrega as ferramentas à IA, gerencia sua memória e decide quando parar de trabalhar. Alguns harnesses são como um mordomo robô supereficiente que organiza tudo perfeitamente; outros são como um estagiário caótico que fica fazendo a mesma pergunta repetidamente, desperdiçando tempo e energia. A grande questão que os pesquisadores estão fazendo é: o cérebro da IA importa mais, ou a qualidade de seu assistente importa mais?

O Grande Experimento da "Cozinha"

Uma equipe de pesquisadores decidiu parar de adivinhar e começar a medir. Eles montaram um experimento massivo para ver o que acontece quando você troca a "cozinha" (harness) mantendo o "chef" (o modelo de IA) exatamente o mesmo. Eles escolheram dois modelos de codificação de IA muito inteligentes, Qwen 3.6 Plus e MiniMax M2.5, e pediram que resolvessem 50 diferentes enigmas de programação. Mas aqui está a reviravolta: eles rodaram esses mesmos modelos através de três harnesses de código aberto diferentes, chamados Goose, OpenCode e OpenHands-SDK.

Os resultados foram chocantes, para dizer o mínimo.

Quando os pesquisadores observaram quantos enigmas a IA resolveu (a "taxa de aprovação" ou pass rate), a diferença entre os harnesses foi minúscula. Quer a IA estivesse usando o Goose, o OpenCode ou o OpenHands-SDK, ela resolvia aproximadamente o mesmo número de problemas — geralmente entre 38% e 50%. Mudar o harness não fez a IA subitamente se tornar um gênio ou um fracasso; a taxa de sucesso permaneceu majoritariamente estável.

No entanto, quando observaram o custo de resolver esses problemas, a história mudou completamente. Os pesquisadores mediram isso em "tokens", que são basicamente as unidades de dados que a IA processa (como palavras ou partes de código). Eles descobriram que a escolha do harness alterou o custo de forma estrondosa: 40 vezes.

Para colocar em perspectiva: se o harness Goose ajudou a IA a resolver um enigma usando cerca de 28.000 tokens, o harness OpenCode fez a exata mesma IA usar mais de 1,1 milhão de tokens para resolver o mesmo enigma. Essa é uma diferença de 40 vezes no custo para o exato mesmo resultado! É como um chef usando um único ovo para assar um bolo, enquanto o outro chef usa 40 ovos para o exato mesmo bolo, simplesmente porque suas ferramentas de cozinha eram ineficientes.

O Imposto do "Turno Ocioso"

Por que o custo aumentou tanto? Os pesquisadores descobriram um culpado oculto: turnos ociosos (idle turns).

Imagine que você está conversando com um amigo que está tentando consertar seu computador. Às vezes, ele apenas fica parado pensando, "Hum, deixe-me verificar isso...", sem realmente digitar nada ou mudar nada na tela. No mundo da IA, esses são chamados de "turnos de nenhuma ação" (no-action turns). O harness OpenCode fez a IA ficar nesses loops de pensamento cerca de 2 vezes por tarefa, enquanto o harness Goose fazia isso apenas cerca de 0,2 vezes.

Cada vez que a IA entra em um desses loops, ela tem que enviar todo o seu histórico de conversa de volta para o servidor para manter o registro de onde está. Isso é como enviar um diário de 100 páginas toda vez que você faz uma pausa para pensar. Como o OpenCode fez a IA pausar e pensar com muito mais frequência, ele consumiu tokens a uma taxa massiva. Os pesquisadores chamam isso de "imposto de espera por tarefa" (per-task wait tax). Não é apenas um custo em dinheiro; é um custo em tempo. Um desenvolvedor humano observando a IA tem que esperar através desses loops ociosos, encarando uma tela que não está fazendo nada, apenas queimando dinheiro e paciência.

A "Impressão Digital" do Fracasso

O estudo também descobriu que cada harness tinha sua própria maneira única de falhar, como uma impressão digital. Esses padrões não mudavam com base no modelo de IA usado; eram causados pelo próprio harness.

Goose era o cauteloso. Quando ficava travado, ele parava e dizia: "Eu não consigo fazer isso", em vez de tentar adivinhar. Raramente perdia tempo tentando verificar uma ideia ruim.
OpenHands-SDK era o persistente. Ele continuava tentando verificar suas respostas ou executando até atingir um limite rígido de quantas vezes poderia tentar (o limite de "máximo de turnos" ou max turns).
OpenCode era o que ficava preso em loops. Ele esgotava o tempo (o limite de "tempo de execução" ou wall-time) ou ficava em um estado de "travamento" (hang), girando em falso sem nunca terminar.

Isso significa que, se você é um desenvolvedor, você não está apenas escolhendo uma IA; você está escolhendo um estilo de falha. Você quer uma IA que desista rápido e honestamente, ou uma que continue girando as rodas até que você perca a paciência?

A Grande Lição

A principal lição deste artigo é que temos olhado para os benchmarks de codificação de IA de forma errada. Temos classificado modelos como Qwen ou MiniMax como se eles fossem a única coisa que importa. Mas este estudo mostra que o harness (a cozinha) é tão importante quanto o modelo (o chef).

Se você quiser saber quanto uma IA custará realmente ou quanto tempo levará para terminar um trabalho, você não pode apenas olhar para o nome do modelo. Você tem que olhar para o par: o modelo e o harness no qual ele está rodando. Um modelo inteligente em um harness ruim pode ser 40 vezes mais caro do que um modelo inteligente em um bom harness.

Os pesquisadores sugerem que, no futuro, não devemos apenas relatar a "Taxa de Aprovação" (Pass Rate). Precisamos relatar o custo por tarefa resolvida, o número de turnos ociosos e os padrões de falha. Porque, para um desenvolvedor humano real, a diferença entre uma taxa de sucesso de 50% que custa US$ 1 e uma taxa de sucesso de 50% que custa US$ 40 é a diferença entre uma ferramenta útil e um poço de dinheiro. O "Efeito de Suporte" (Scaffold Effect) é real, e é hora de pararmos de ignorar a mão invisível que guia o robô.

Resumo Técnico: O Efeito de Andaime (Scaffold Effect) em Agentes de Codificação

Declaração do Problema
Os atuais placares públicos para agentes de codificação classificam primariamente os sistemas pelo nome do modelo e pela taxa de aprovação, tratando o "andaime" (harness) circundante — o suporte que emite ferramentas, gerencia o contexto e determina a terminação — como uma constante fixa ou subespecificada. Essa abordagem confunde o desempenho do modelo com a eficiência do andaime. Quando os andaimes variam, as métricas de desempenho (taxa de aprovação) e as métricas de eficiência (uso de tokens, latência) tornam-se entrelaçadas, obscurecendo o verdadeiro custo e o ônus de supervisão para a implantação de um agente. O artigo argumenta que, para uma avaliação centrada no ser humano, a unidade de comparação deve ser o par andaime–modelo, e não o modelo isoladamente, pois o andaime dita os custos do mundo real e a natureza da supervisão humana necessária.

Metodologia
Os autores conduziram um estudo controlado para isolar os efeitos do andaime em relação ao modelo.

Modelos: Dois modelos agentes de codificação recentes foram avaliados: Qwen 3.6 Plus e MiniMax M2.5.
Andaimes (Harnesses): Três andaimes distintos de código aberto foram testados, cada um com filosofias de suporte diferentes:
- Goose: Um agente de IDE de peso pesado com pré-injeção ávida de árvore de arquivos.
- OpenCode: Um agente de loop de ferramenta persistente sem pré-carregamento automático de contexto.
- OpenHands-SDK: Uma arquitetura de micro-agente apresentando delegação de sub-agentes, tentativas internas (retries) e etapas de verificação explícitas.
Tarefas: Um subconjunto estratificado de 50 tarefas foi extraído do conjunto de dados Terminal-Bench Pro, cobrindo oito arquétipos (Correção de bugs, Construção, Dados, Implementação, ML, Puzzle, Segurança, Sistema). Todas as tarefas utilizaram suítes de avaliação pytest determinísticas.
Protocolo: Todos os testes foram executados através da API OpenRouter com instruções de tarefa e prompts de sistema idênticos (variando apenas no vocabulário específico da ferramenta). O estudo manteve constantes o manifesto da tarefa, o ambiente de sandbox e o limite de tempo de execução (wall-time) de 900 segundos, permitindo que cada andaime operasse com suas APIs de ferramentas nativas, gerenciamento de contexto e lógica de tentativa interna.
Métricas: O estudo mediu taxas de aprovação, total de tokens por tarefa resolvida, média de turnos, "turnos de nenhuma ação" (turnos sem edições de arquivo ou novos comandos) e uma taxonomia de falha de seis classes (REASON, VERIFY, TIME, MAX TURNS, HANG, ERROR). A significância estatística foi avaliada usando intervalos de confiança de bootstrap de tarefas pareadas de 95% ( $B=10.000$ ).

Resultos Principais

Disparidade de Custo de Tokens (A Lacuna de 40×): A escolha do andaime induziu uma diferença massiva na eficiência. O OpenCode consumiu aproximadamente 40× mais tokens por tarefa resolvida do que o Goose (ex: ~1,5M de tokens vs. ~37K tokens para o MiniMax). Em contraste, atualizar o modelo mantendo o andaime fixo resultou em apenas uma diferença de 1,0–1,3× no uso de tokens.
Estabilidade da Taxa de Aprovação: Dentro de um modelo fixo, as diferenças de taxa de aprovação entre os andaimes foram pequenas, variando de 0 a 8 pontos percentuais. A maioria das diferenças pareadas foi estatisticamente indistinguível de zero (os ICs de 95% incluíram zero), exceto pela maior lacuna.
Impressões Digitais de Falha: Modos de falha específicos replicaram-se em ambos os modelos, indicando que são propriedades do andaime, não do modelo:
- Goose: Dominado por falhas de REASON (parar quando travado) com zero falhas de VERIFY.
- OpenHands-SDK: Caracterizado por falhas de VERIFY e MAX TURNS, indicando uma tendência a persistir em direção ao fechamento ou esgotar limites de iteração.
- OpenCode: Caracterizado por falhas de TIME e HANG (esgotar limites de tempo de execução) com zero MAX TURNS (devido à falta de uma flag de orçamento de turnos) e zero VERIFY.
Turnos de Nenhuma Ação como um Imposto de Supervisão: O OpenCode exibiu 10× mais turnos de nenhuma ação (loops de raciocínio ociosos) do que o Goose. Esses turnos acumulam tokens de contexto sem progresso, criando um "imposto de espera por tarefa" para usuários humanos que devem monitorar esses loops ociosos.
Eficiência de Pareto: O Goose dominou a fronteira de Pareto, oferecendo taxas de aprovação comparáveis aos outros andaimes por uma fração do custo de tokens. O OpenCode foi dominado em Pareto por ambos os outros andaimes.

Principais Contribuições

Quantificação do Efeito de Andaime: O estudo fornece evidência controlada de que a escolha do andaime impulsiona uma lacuna de 40× nos custos de tokens enquanto altera as taxas de aprovação em no máximo 8 pontos percentuais, demonstrando que a eficiência é, em grande parte, uma propriedade do suporte.
Impressão Digital de Falha Independente de Modelo: Os autores identificam que modos de falha específicos (ex: REASON vs. VERIFY vs. TIME) são consistentes entre diferentes modelos quando o andaime é fixo, provando que estes são vieses estruturais do suporte.
Proxy Mecanístico para Supervisão: O artigo introduz os "turnos de nenhuma ação" como um proxy para o ônus de supervisão humana, enquadrando-os como um custo (tanto financeiro quanto temporal) que um usuário humano no ciclo (human-in-the-loop) deve absorver, distinto dos simples custos de tokens.
Unidade de Avaliação Proposta: Os autores argumentam que o par andaime–modelo é a unidade correta de comparação para avaliação centrada no ser humano, em vez de apenas o nome do modelo.

Significância e Alegações
O artigo alega que o relato atual de benchmarks é incompleto porque isola o modelo do seu andaime. Ao relatar apenas as taxas de aprovação, os placares obscurecem o custo real, a latência e o esforço de supervisão necessários para implantar um agente. Os autores afirmam que, para implantação prática, os desenvolvedores devem avaliar pares andaime–modelo sob orçamentos específicos de tokens/latência. Eles recomendam que futuras avaliações relatem tokens por tarefa resolvida, média de turnos de nenhuma ação e vetores de categoria de falha juntamente com as taxas de aprovação para fornecer uma visão holística da capacidade de implantação de um agente. O estudo não pretende resolver o problema da avaliação de agentes, mas sim sistematizar a observação de que a "escolha do andaime" é um motor primário de eficiência e perfis de falha, muitas vezes superando as atualizações de modelo.