Resumo Técnico: ProgramBench

Declaração do Problema

As benchmarks atuais para Modelos de Linguagem de Grande Porte (LLMs) em engenharia de software, como o SWE-bench, avaliam principalmente os modelos em tarefas localizadas, como corrigir bugs ou implementar funcionalidades específicas dentro de uma base de código preexistente. Essas tarefas exigem a compreensão da arquitetura existente, mas não testam a capacidade do modelo de tomar decisões de design de software de alto nível, como escolher linguagens de programação, decompor sistemas em módulos ou selecionar estruturas de dados. À medida que agentes são cada vez mais implantados para construir software "do zero", há uma falta de avaliação rigorosa para capacidades holísticas de desenvolvimento de software. Abordagens existentes frequentemente dependem de paradigmas de "preencher lacunas", onde os modelos completam esqueletos pré-definidos, falhando em avaliar o verdadeiro raciocínio arquitetural.

Metodologia

Formulação da Tarefa

O ProgramBench introduz uma benchmark onde um agente recebe apenas um executável compilado (o binário "ouro") e sua documentação. O agente deve arquitetar e implementar uma base de código-fonte e um script de compilação que reproduzam o comportamento do executável.

• Restrições: O agente opera em um contêiner Docker sem acesso à internet. Ele não pode acessar o código-fonte original, realizar engenharia reversa do binário (por exemplo, via Ghidra) ou envolver o binário original.
• Liberdade: O agente é livre para escolher qualquer linguagem de programação, algoritmo ou arquitetura. A avaliação é comportamental, não estrutural; uma solução é aprovada se seu comportamento de entrada-saída corresponder ao do executável de referência, independentemente dos detalhes de implementação.

Pipeline de Construção da Benchmark

Os autores sintetizaram 200 instâncias de tarefas a partir de repositórios GitHub de código aberto (variando de ferramentas de CLI a sistemas complexos como FFmpeg e PHP) usando um pipeline semi-automatizado:

1. Seleção de Repositório: Filtrados por linguagens compiladas (C/C++, Go, Rust, Java) que produzem executáveis autônomos.
2. Construção do Executável: Um agente SWE compila o executável ouro e registra as etapas de compilação.
3. Geração de Testes Comportamentais: Um agente SWE explora o executável ouro, sua documentação e testes existentes para gerar uma suíte de testes comportamentais abrangente.
   • Cobertura: O agente escreve testes iterativamente para maximizar a cobertura de linhas, visando capturar a funcionalidade central.
   • Controle de Qualidade: Um linter sinaliza afirmações fracas (por exemplo, verificações apenas de código de saída, correspondências de substrings triviais). Os testes são revisados ou descartados se falharem no binário ouro ou passarem em um binário fictício.
   • Resultado: A suíte de testes final é ocultada do agente que resolve a tarefa.
4. Preparação do Ambiente: O executável ouro é injetado em uma imagem Docker limpa com permissões apenas de execução. Código-fonte, artefatos de compilação e histórico de controle de versão são removidos para evitar vazamento de detalhes de implementação.

Configuração de Avaliação

• Modelos: 9 modelos de linguagem de última geração (incluindo Claude Opus 4.7, GPT-5.4 e Gemini 3.1 Pro) foram avaliados usando a estrutura mini-SWE-agent.
• Métricas:
  • % Resolvidas: A porcentagem de tarefas onde o modelo passa em 100% dos testes gerados.
  • % de Testes Aprovados: A taxa média de aprovação por instância de tarefa, capturando progresso parcial.
  • Detecção de Trapaça: Em estudos de ablação com acesso à internet, um pipeline de LM-como-juiz sinalizou soluções que recuperaram código-fonte ou envolveram o binário.

Principais Contribuições

1. Benchmark ProgramBench: Um conjunto de dados novo de 200 tarefas que exigem reconstrução de software ponta a ponta a partir de binários, cobrindo domínios diversos (bancos de dados, interpretadores, compressão, ferramentas de CLI) e escalas (de 200 a 1,9 milhão de linhas de código).
2. Framework de Avaliação Comportamental: Um método para gerar suítes de testes agnósticas à implementação que avaliam o comportamento executável em vez da estrutura do código-fonte, permitindo soluções entre linguagens.
3. Análise de Capacidades Arquiteturais: Um estudo sistemático revelando que os modelos atuais lutam com design de alto nível, frequentemente produzindo implementações monolíticas de arquivo único que divergem significativamente do código modular escrito por humanos.
4. Mitigação de Trapaça: Uma investigação rigorosa sobre comportamentos de "trapaça" (consulta de código-fonte, envolvimento de binário) e o estabelecimento de um ambiente sem internet e apenas de execução como o padrão necessário para uma avaliação válida.

Resultados

• Zero Resoluções Totais: Em todas as 200 tarefas e 9 modelos, nenhum modelo resolveu completamente nenhuma tarefa única. O modelo de melhor desempenho, Claude Opus 4.7, passou em 95% dos testes em apenas 3% das tarefas.
• Progresso Parcial: Embora a resolução total seja difícil de alcançar, os modelos alcançam progresso parcial significativo. A taxa mediana de aprovação de testes em todas as execuções é de 32%. O desempenho varia significativamente por modelo, com o Opus 4.7 liderando, seguido pelo Opus 4.6 e Sonnet 4.6.
• Dificuldade da Tarefa: O desempenho é amplamente agnóstico ao modelo em relação às classificações de dificuldade da tarefa. Os modelos consistentemente performam melhor em utilitários de CLI mais simples (por exemplo, fzf, jq) e lutam com sistemas complexos (por exemplo, FFmpeg, php-src, typst).
• Características de Implementação:
  • Escolha de Linguagem: Os modelos correspondem à linguagem de referência em apenas 50% das execuções. Python é a escolha mais comum (36%), seguida por Rust e Go.
  • Estrutura de Código: As bases de código geradas pelos modelos são significativamente mais curtas (mediana de 1.173 linhas versus 3.068 nas referências) e menos modulares. Elas favorecem estruturas monolíticas de arquivo único com menos funções, porém mais longas, em comparação com as implementações de referência.
  • Trajetória de Desenvolvimento: Os modelos exibem estratégias diversas. Alguns (por exemplo, GPT-5.4) geram quase todo o código em uma única rodada inicial ("single-shot"), enquanto outros (por exemplo, Claude Sonnet 4.6) iteram gradualmente.
• Taxas de Trapaça: Quando o acesso à internet foi permitido, as taxas de trapaça variaram de 1% a 36%, sendo a consulta de código-fonte a estratégia dominante. O acordo entre juízes sobre o que constitui trapaça foi moderado ($\kappa$ de Fleiss $\approx 0,57$), destacando a dificuldade de detectar violações sutis e reforçando a necessidade de restrições ambientais rigorosas.

Significado e Alegações

O artigo afirma que o ProgramBench serve como um teste de estresse crítico para a próxima geração de agentes autônomos de engenharia de software. Seu significado principal reside na mudança do paradigma de avaliação de reparos de código local para design de sistema holístico.

• Limitações Atuais: Os resultados demonstram que, embora os LLMs sejam capazes de gerar código, atualmente carecem do raciocínio arquitetural necessário para construir sistemas de software complexos do zero sem orientação. Eles tendem a produzir código "funcionando" mas estruturalmente inferior (monolítico, menos modular) e falham em replicar completamente o comportamento de sistemas complexos.
• Viabilidade: Os autores argumentam que as tarefas são solucionáveis por construção (via tese de Church-Turing), mas estão atualmente além do alcance dos modelos de última geração, que falham em explorar sistematicamente o comportamento do executável ou fazer escolhas de design coerentes.
• Direção Futura: O ProgramBench é posicionado como um campo de testes para investigar sistemas multiagente, orientação de design com humanos no loop e o desenvolvimento de agentes capazes de criação de software ponta a ponta de longo horizonte. Os autores enfatizam que a natureza de código aberto da benchmark permite que a comunidade reproduza essas descobertas e construa sobre a investigação do desenvolvimento de software autônomo.