In un nuovo studio Claude Opus 4.7 ha bloccato l’exploit fornito nel 90,2% dei casi, ma solo il 60,7% delle patch ha superato i test degli sviluppatori originali. La distanza di 29,5 punti è centrale: fermare un crash non prova che la riparazione conservi il comportamento voluto.
Dang K Le, Wenxuan Shi e Xinyu Xing di Northwestern hanno presentato il 7 ottobre lo studio di affidabilità dei benchmark, su 112 bug storici di 84 progetti aperti in C, C++, Go e Rust. Il preprint riguarda configurazioni precise di Claude e agenti, non un tasso universale di fallimento delle riparazioni autonome o produttive.
Modelli migliori, distanza persistente
Le prove controllate usano OpenCode con Sonnet 4.0, Sonnet 4.5 e Opus 4.7 sugli stessi casi. Gli agenti ricevono istruzioni di compilazione e test, ma inizialmente non il contenuto del PoC, l’input o procedura che dimostra il difetto.
Sonnet 4.0 supera il 77,7% dei PoC e il 43,8% dei test sviluppatore; Sonnet 4.5 raggiunge 84,8% e 48,2%, Opus 90,2% e 60,7%. Opus migliora davvero entrambi, ma il 32,7% delle patch approvate dal PoC fallisce il test sviluppatore, circa un successo apparente su tre secondo l’analisi pubblica della valutazione.
Opus passa anche il 94,6% dei test di regressione esistenti, senza chiudere il divario. Le vecchie suite verificano esempi noti; il test aggiunto con la vera correzione può codificare il comportamento prima mancante vicino alla falla.
I ricercatori ricostruiscono test unitari o d’integrazione dei commit correttivi e li applicano dopo la patch. Valutano comportamento, non somiglianza testuale; una soluzione diversa può passare. La risoluzione completa richiede build, ripetuta soppressione del PoC, regressioni e nuovo test sviluppatore.
PHP mostra un crash eliminato per il motivo sbagliato
Un vecchio bug di PHP range() classificava male tipi misti e poteva trattare un valore non stringa come stringa. Rifiutare subito i tipi misti poteva eliminare il crash e mantenere molti vecchi test, ma respingeva combinazioni numeriche e testuali valide da convertire.
La correzione originale sistemava la classificazione conservando il comportamento. Un test con input valido vicino distingueva riparazione e soluzione troppo restrittiva. Un giudice del solo crash premiava entrambe.
Una guardia può essere mitigazione urgente senza correzione completa. Il sovradattamento ai test soddisfa esempi invece del requisito. In sicurezza può nascondere un sintomo, lasciare percorsi e produrre falsa fiducia che riduce la revisione.
I test sviluppatore sono un indicatore migliore, non accettazione totale. Non esauriscono prestazioni, compatibilità, leggibilità o architettura. Un’alternativa ragionevole può cambiare comportamento non documentato; il fallimento storico richiede esame, non prova automatica di pericolo.
Le istruzioni cambiano la capacità misurata
Con comandi dettagliati Sonnet 4.0 supera il 77,7% dei PoC, senza il 74,1%. Il test sviluppatore passa da 41,1% a 43,8%. Per C/C++ soltanto, le istruzioni portano PoC dal 72% al 92%, ma i test sviluppatore dal 28% al 36%.
La documentazione è aiuto legittimo anche umano, ma i punteggi non si confrontano senza budget informativi. Go e Rust hanno spesso comandi prevedibili; C/C++ molti sistemi, opzioni e wrapper. L’assistenza all’ambiente può cambiare il risultato prima della qualità della patch.
In 62 casi Go, un PoC sorgente porta il successo sul crash da 69,4% a 95,2%, contro 41,9% a 48,4% sui test sviluppatore. Il codice del test rivela API e chiamate e facilita adattarsi al controllo visibile.
In 25 casi C/C++, fornire input binario o testuale opaco non cambia né 92% PoC né 36% sviluppatore. Entrambe le configurazioni possono dire di fornire il PoC, ma solo una rivela l’intento eseguibile: l’informazione non è equivalente.
Ricerca e infrastruttura distorcono in entrambe le direzioni
I compiti storici hanno spesso issue, avvisi e patch pubbliche. Lo studio documenta un agente che trova la patch originale sul Web e uno nella cronologia Git non ripulita. Il successo non misura così ragionamento indipendente.
Cercare Web e cronologia è sensato in produzione. La contaminazione dipende dalla promessa di ragionamento senza aiuti. Un test di recupero e strumenti può consentirlo esplicitamente. La memorizzazione delle patch limita inoltre i tassi assoluti.
Errori del framework possono invece nascondere buoni risultati o esporre risposte segrete. Permessi, timeout e file in conflitto impediscono build o giudicano male. Problemi singoli influenzavano circa il 5–32% dei casi nei cicli completi, talvolta più delle distanze in classifica.
Il punteggio appartiene quindi a modello, agente, prompt, strumenti, sorgenti, limiti e valutazione insieme. I controlli usavano OpenCode con Claude; i casi comprendevano anche Claude Code con Sonnet 4.5. I supporti non sono intercambiabili.
Gli studi vicini chiedono più test
PVBench esamina 209 casi in 20 progetti: oltre il 40% delle patch approvate da controlli basilari fallisce test aggiunti dalle riparazioni sviluppatore. Disegno e dati differiscono; non è un tasso Claude direttamente confrontabile.
PatchBench trova inflazione media di 1,83 nei tassi di risoluzione su 11 agenti con solo PoC. Replay di sicurezza, test unitari e output portano i migliori da oltre 97% sui PoC a circa metà con validazione combinata.
PatchBench sceglie anche difetti con riparazione fuori dallo stack del crash e li trapianta in repository cambiati per ridurre il ricordo storico. Non presume che ogni successo sia nuovo ragionamento.
CyberGym-E2E di Berkeley comprende 920 vulnerabilità in 139 progetti e combina scoperta, riproduzione e patch. I migliori riparano circa l’80% se ricevono il bersaglio; il risultato completo scende se devono scoprirlo. Restano guardie superficiali.
Modelli, compiti e definizioni non formano una classifica comune. La metodologia Cyber Index estende audit, scoperta, riproduzione e riparazione senza rompere comportamento legittimo. La domanda condivisa è cosa includa il successo.
Un giudice più forte non prova la produzione
Northwestern richiede build riproducibili e test originali significativi. I 112 difetti sono vari, non rappresentativi di ogni falla. Materiale pubblico può essere entrato nel training. Limita i tassi assoluti, non cancella gli effetti controllati di prompt o giudizi.
La produzione può essere più sicura con test propri, analisi statica, fuzzing, revisione e rilascio progressivo, ma più difficile con test incompleti, comportamento non scritto e dipendenze assenti. Né benchmark curato né PoC riuscito provano il rilascio incustodito.
Servono risultati separati di PoC e intenzione, permessi di strumenti e rete, cronologia ripulita, timeout e fallimenti per fase, oltre a patch accettate, riviste o respinte in produzione. Percorsi alternativi e nuovi problemi contano; uguaglianza testuale non sostituisce comportamento.
Una base di conoscenza tecnica ricercabile conserva prompt, tracce, patch e verifiche, senza rendere il codice corretto. La conclusione sostenuta è un vero progresso Opus e una sovrastima di 29,5 punti col solo crash. Una riparazione generata rimane candidata e richiede prove indipendenti di sicurezza e comportamento valido.