Num novo estudo, Claude Opus 4.7 bloqueou o exploit fornecido em 90,2% dos casos, mas apenas 60,7% das correções passaram testes dos programadores originais. O desvio de 29,5 pontos é central: eliminar uma falha não prova preservar o comportamento pretendido.
Dang K Le, Wenxuan Shi e Xinyu Xing, da Northwestern, apresentaram em 7 de outubro o estudo de fiabilidade dos benchmarks, com 112 erros históricos em 84 projetos abertos de C, C++, Go e Rust. O preprint trata configurações específicas Claude–agente, não uma taxa universal de falha de reparação autónoma ou em produção.
Melhores modelos mantêm uma diferença
Os ensaios controlados usaram OpenCode com Sonnet 4.0, Sonnet 4.5 e Opus 4.7 nos mesmos casos. Receberam instruções de compilação e teste, mas inicialmente não o corpo do PoC, entrada ou procedimento que demonstra o defeito.
Sonnet 4.0 passou 77,7% dos PoC e 43,8% dos testes dos programadores; Sonnet 4.5 atingiu 84,8% e 48,2%, Opus 90,2% e 60,7%. Opus melhorou ambos, mas 32,7% das correções aprovadas pelo PoC falharam o teste seguinte: um sucesso aparente em três, segundo a análise pública da avaliação.
Opus passou também 94,6% dos testes de regressão existentes, sem fechar o desvio. Suites antigas verificam exemplos conhecidos; um teste acrescentado com a reparação real pode codificar comportamento antes ausente junto da falha.
Os investigadores reconstruíram testes unitários ou de integração dos commits corretivos e aplicaram-nos depois da correção. Medem comportamento, não semelhança textual: outra implementação pode passar. Resolver exigia compilação, supressão repetida do PoC, regressões e novo teste.
PHP mostra uma falha eliminada pelo motivo errado
Um erro histórico de PHP range() classificava mal tipos mistos e podia tratar valor não textual como string. Rejeitar logo a mistura evitava a falha e podia manter testes antigos, mas recusava combinações numéricas e textuais válidas que PHP devia converter.
A reparação original corrigia a classificação preservando comportamento válido. Um teste de entrada vizinha válida distinguia reparação e contorno restritivo. Um juiz só de falhas recompensaria ambos.
Uma barreira pode ser mitigação urgente sem reparação completa. Sobreajustar aos testes satisfaz exemplos em vez de requisitos. Em segurança pode ocultar sintomas, deixar outras vias e criar confiança falsa que reduz revisão.
Testes do programador são melhor aproximação, não aceitação integral. Não esgotam desempenho, compatibilidade, legibilidade ou arquitetura. Uma alternativa defensável pode alterar comportamento não documentado; falhar teste histórico exige inspeção, não prova perigo automático.
As instruções mudam a capacidade medida
Com comandos detalhados, Sonnet 4.0 passou 77,7% dos PoC, sem eles 74,1%. O teste do programador passou de 41,1% para 43,8%. Apenas em C/C++, instruções elevaram PoC de 72% para 92%, mas testes de 28% para 36%.
Documentar é ajuda legítima também humana, mas resultados não se comparam sem orçamento de informação. Go e Rust têm frequentemente comandos previsíveis; C/C++ muitos sistemas, opções e wrappers. Preparar o ambiente muda a pontuação antes de avaliar a reparação.
Em 62 casos Go, mostrar PoC em código elevou sucesso de 69,4% para 95,2%, contra 41,9% para 48,4% no teste do programador. O código revela API e chamadas, facilitando cumprir o teste visível.
Em 25 casos C/C++, mostrar entrada binária ou textual opaca não alterou 92% PoC nem 36% do programador. Ambos podem dizer que fornecem PoC, mas só um revela intenção executável. Não são condições equivalentes.
Pesquisa e infraestrutura distorcem nos dois sentidos
Casos históricos costumam ter problemas, avisos e reparações públicas. O artigo documenta um agente que encontrou a correção na Web e outro no histórico Git não limpo. O sucesso não mede claramente raciocínio independente.
Pesquisar Web e histórico faz sentido em produção. Só contamina face à promessa de raciocínio sem ajuda. Um teste de pesquisa e ferramentas pode permiti-lo explicitamente. Memorização das correções também limita taxas absolutas.
Erros do sistema podem ocultar bom trabalho ou revelar soluções secretas. Permissões, limites de tempo e colisões de ficheiros impedem compilação ou classificam mal. Problemas individuais afetaram cerca de 5–32% dos casos em execuções completas, por vezes mais do que diferenças de classificação.
O resultado pertence ao conjunto de modelo, agente, instruções, ferramentas, fontes, limites e avaliação. Os controlos usavam OpenCode com Claude; casos incluíam Claude Code com Sonnet 4.5. Os ambientes não são intercambiáveis.
Estudos relacionados exigem múltiplos testes
PVBench analisou 209 casos de 20 projetos: mais de 40% das correções aceites por controlos básicos falharam testes derivados das reparações dos programadores. Dados e desenho diferem; não é uma taxa Claude comparável.
PatchBench encontrou inflação média de 1,83 nas taxas de resolução de 11 agentes com apenas PoC. Reexecução de segurança, testes unitários e saídas baixaram os melhores de mais de 97% dos PoC para cerca de metade na validação combinada.
PatchBench escolheu também vulnerabilidades reparadas fora da pilha da falha e transplantou-as para repositórios alterados para reduzir memória histórica. Não assume que cada sucesso seja raciocínio novo.
CyberGym-E2E, de Berkeley, cobre 920 vulnerabilidades de 139 projetos e combina descoberta, reprodução e reparação. Os melhores repararam cerca de 80% com alvo conhecido; o resultado completo caiu quando tinham de o descobrir. Persistiram barreiras superficiais.
Modelos, tarefas e definições não formam uma classificação única. A metodologia Cyber Index também amplia auditoria, descoberta, reprodução e reparação sem quebrar comportamento legítimo. A questão comum é o que inclui o sucesso.
Um juiz melhor não prova produção
A amostra Northwestern exigia compilações reproduzíveis e testes originais significativos. Os 112 erros são variados, não representativos de tudo. Material público pode ter entrado no treino. Limita taxas absolutas, não apaga sensibilidade controlada a instruções ou avaliação.
Produção pode ser mais segura com testes próprios, análise estática, fuzzing, revisão e implementação gradual, mas mais difícil com testes incompletos, comportamento não documentado e dependências ausentes. Nem suite cuidada nem PoC passado prova prontidão sem supervisão.
Seriam úteis resultados separados de PoC e intenção, permissões de ferramentas e rede, histórico limpo, tempos e falhas por fase, além de aceitação, revisão ou rejeição de responsáveis reais. Vias alternativas e novas falhas contam; semelhança textual não substitui comportamento.
Uma base de conhecimento técnico pesquisável conserva instruções, trajetórias, correções e validação sem tornar código correto. A conclusão é progresso real de Opus e sobrestimação de 29,5 pontos só com falhas. A reparação gerada continua candidata e precisa de provas independentes de segurança e comportamento legítimo.