Resumo Técnico: Benchmarks de Codificação estão Desalinhados com a Engenharia de Software Agêntica

Declaração do Problema

O artigo argumenta que os atuais benchmarks de codificação estão fundamentalmente desalinhados com a realidade da engenharia de software agêntica. Embora os agentes de codificação (sistemas compostos que compreendem LLMs, loops de ferramentas, andaimes [scaffolding] e ambientes) tenham se tornado um modo primário de engenharia de software, as métricas de avaliação utilizadas para avaliá-los foram projetadas para uma era pré-agente.

O desalinhamento central decorre de três falhas estruturais nos benchmarks existentes (ex: SWE-Bench, HumanEval, MBPP):

1. Conflação de Modelo e Harness: Os benchmarks colapsam o modelo, o harness do agente (camada de orquestração) e o ambiente em uma única pontuação de ponta a ponta. Isso obscurece o fato de que o "agente" é um sistema composto onde as escolhas de harness podem deslocar margens de desempenho comparáveis às diferenças entre gerações de modelos.
2. Ancoragem em Referência Única: A graduação é tipicamente realizada contra uma única solução de referência (ex: um patch específico). Isso penaliza implementações alternativas igualmente válidas, escolhas arquiteturais ou refatorações que não correspondam à decomposição ou ao estilo específico da referência, medindo efetivamente a "proximidade a uma referência" em vez da "correção funcional" ou "qualidade de design".
3. Ausência de Sinal ao Nível de Componente: Pontuações de ponta a ponta não fornecem sinal sobre qual componente específico do sistema (contexto, ferramenta, verificador ou modelo) falhou. Isso impede a iteração eficiente, forçando desenvolvedores a depender da intuição ou de estudos de ablação demorados, em vez de melhorias direcionadas.

Metodologia e Estrutura

O artigo não propõe um novo conjunto de benchmarks, mas sim uma estrutura conceitual para reavaliar como os agentes de codificação são medidos. Os autores introduzem o conceito de Harness do Sistema, distinguindo-o do Harness do Agente:

• Harness do Agente: Um modelo de linguagem interagindo com ferramentas para resolver uma única tarefa (ex: Claude Code, SWE-Agent).
• Harness do Sistema: A camada de orquestração externa que transforma objetivos de alto nível em tarefas, gerencia ambientes, roteia saídas através de loops de feedback e lida com o trabalho de engenharia de vários dias.

Os autores categorizam os sinais de feedback dentro do harness do sistema em três níveis:

• Inner-loop (Loop Interno): Sinais rápidos e de baixo nível (testes, checagem de tipos, linting) usados para refinar soluções em tempo real.
• Middle-loop (Loop Médio): Sinais que cobrem política, gosto e eficiência (solicitações de revisores, simulação, manutenção automatizada).
• Outer-loop (Loop Externo): Sinais atrasados e de alta confiança (aceitação de PR, taxas de incidentes, feedback de clientes) que aproximam a verdade fundamental (ground truth).

O artigo analisa os benchmarks existentes (SWE-Bench, Terminal-Bench, etc.) através desta lente, destacando como eles falham em capturar a complexidade do harness do sistema. Ele utiliza a teoria da validade (Wallach et al., Jacobs e Wallach) para argumentar que os benchmarks atuais sofrem de problemas de validade de construto (medindo a coisa errada) e validade discriminante (falhando em separar o modelo do harness).

Principais Contribuições

O artigo identifica três "sintomas" específicos do desalinhamento e propõe remédios estruturais para cada um:

1. Conflacionar o Modelo com o Harness

• Observação: Os benchmarks frequentemente atribuem uma única pontuação de ponta a ponta ao modelo, ignorando que o harness (andaime, ambiente, engenharia de prompt) é uma variável massiva. Dados mostram que alterar o harness para um modelo fixo (ex: Claude Opus 4.6) pode resultar em variações de taxa de sucesso de mais de 20 pontos percentuais.
• Remédio: As submissões de benchmarks devem incluir metadados conscientes do harness (versão do modelo, versão do harness, hash do ambiente, versão do dataset). As submissões também devem incluir estudos de ablação em eixos não relacionados ao modelo para isolar a contribuição do harness.

2. Ancoragem em uma Única Solução de Referência

• Observação: Graduar contra um único patch "ouro" falha em considerar o fato de que a engenharia de software frequentemente envolve a escolha entre formas arquiteturais válidas ou refatoração. Também falha em distinguir entre "código funcional" e "bom código" (ex: abstração adequada, design de sistema).
• Remédio: Mover de conjuntos de testes de referência única para verificadores comportamentais de múltiplas formas. Isso inclui testes de propriedade, oráculos de referência ou testes diferenciais contra implementações alternativas. Se um único patch de ouro for usado, o benchmark deve declarar explicitamente quais comportamentos são obrigatórios e quais são incidentais à implementação de referência.

3. Ausência de Sinal ao Nível de Componente

• Observação: Uma métrica única de passar/falhar de ponta a ponta não fornece informações diagnósticas. Não consegue dizer se uma falha foi devida a uma recuperação de contexto deficiente, um erro de ferramenta ou uma alucinação do modelo.
• Remédio: Tratar os componentes do sistema (contexto, ferramentas, verificadores) como alvos de avaliação por si só. Os benchmarks devem reportar métricas para componentes individuais (ex: "efetividade do contexto", "aderência a invariantes") juntamente com a pontuação de ponta a ponta, de forma semelhante a como a engenharia de software utiliza tanto testes unitários quanto de integração.

Resultados e Evidências

O artigo sustenta seus argumentos com várias observações empíricas e citações:

• Sensibilidade do Harness: A Tabela 1 (derivada do Terminal-Bench) demonstra que, para um modelo fixo (Claude Opus 4.6), diferentes harnesses de agente alcançam precisões variando de 58,0% a 79,8% na mesma distribuição de tarefas — uma oscilação de 20 pontos comparável às diferenças entre gerações de modelos.
• Falhas de Solução de Referência: O artigo cita estudos que mostram que benchmarks do tipo SWE-Bench sofrem de vazamento de solução (solution leakage), testes fracos e que muitos patches "resolvidos" falham em testes escritos por desenvolvedores ou divergem do comportamento pretendido.
• Lacuna do Mundo Real: Dados de Li et al. indicam que as taxas de aceitação de PRs escritos por agentes no mundo real (35–64%) são significativamente menores do que as figuras de destaque dos benchmarks (>70%), sugerindo que os benchmarks superestimam a utilidade prática.
• Natureza Composta: Fan et al. são citados para mostrar que a eficácia do scaffold não é uma propriedade inerente do scaffold, mas emerge de sua integração com o modelo base.

Significância e Alegações

O artigo posiciona-se como um chamado para uma mudança estrutural na avaliação da engenharia de software agêntica, em vez de um ajuste metodológico. Sua principal significância reside em:

1. Reenquadrar a Unidade de Análise: Afirmar que o "agente de codificação" não é o modelo LLM, mas o harness do sistema composto. Portanto, os benchmarks devem medir o sistema, não apenas o modelo.
2. Abordar a Lacuna de Operacionalização: Identificar o "problema aberto mais difícil" como a capacidade de especificar o que um sistema deve fazer (invariantes, correção funcional) em termos que possam ser medidos automaticamente, sem prescrever como o agente deve alcançá-lo.
3. Alinhar a Pesquisa com a Prática: Argumentar que os benchmarks atuais incentivam direções de pesquisa que otimizam para "passar em um conjunto de testes específico" em vez de "produzir software sustentável e bem arquitetado".

Os autores concluem que, até que os benchmarks sejam redesenhados para expor sinais ao nível de componente, admitir múltiplas formas de soluções válidas e tratar o harness como o objeto primário de medição, eles continuarão a induzir a comunidade ao erro sobre as verdadeiras capacidades da engenharia de software agêntica.