W nowym badaniu Claude Opus 4.7 zatrzymał dostarczony exploit w 90,2% przypadków, ale tylko 60,7% poprawek przeszło testy pierwotnych deweloperów. Różnica 29,5 punktu jest sednem: brak jednego awaryjnego zakończenia nie dowodzi zachowania zamierzonej funkcjonalności.
Dang K Le, Wenxuan Shi i Xinyu Xing z Northwestern przedstawili 7 października badanie rzetelności benchmarków: 112 historycznych błędów z 84 otwartych projektów C, C++, Go i Rust. Preprint dotyczy konkretnych konfiguracji Claude i agentów, nie uniwersalnej zawodności napraw autonomicznych lub produkcyjnych.
Lepsze modele nadal mają lukę oceny
Kontrolowane próby używały OpenCode z Sonnet 4.0, Sonnet 4.5 i Opus 4.7 na tych samych przypadkach. Agenci otrzymali instrukcje budowania i testów, ale początkowo nie treść PoC, czyli wejścia lub procedury pokazującej błąd.
Sonnet 4.0 przeszedł 77,7% PoC i 43,8% testów dewelopera; Sonnet 4.5 osiągnął 84,8% i 48,2%, Opus 90,2% i 60,7%. Opus naprawdę poprawił oba wyniki, ale 32,7% jego poprawek przechodzących PoC oblało test dewelopera, około jeden pozorny sukces na trzy według publicznej analizy oceniania.
Opus przeszedł również 94,6% istniejących testów regresji, co nie zamyka luki. Stare zestawy sprawdzają znane przykłady; test dodany z prawdziwą poprawką może kodować brakującą intencję wokół luki.
Badacze odtworzyli testy jednostkowe lub integracyjne z commitów naprawczych i zastosowali po agencie. Mierzą zachowanie, nie podobieństwo tekstu; inne rozwiązanie też może przejść. Pełne rozwiązanie wymaga budowy, powtarzalnego zatrzymania PoC, regresji i nowego testu.
PHP pokazuje błąd usunięty niewłaściwą drogą
Historyczny błąd PHP range() źle klasyfikował typy mieszane i mógł traktować niełańcuch jako łańcuch. Natychmiastowe odrzucenie mieszanki zatrzymałoby awarię i zachowało wiele starych testów, ale odrzucałoby prawidłowe połączenia liczb i tekstu podlegające konwersji.
Oryginalna poprawka naprawiała klasyfikację z zachowaniem działania. Sąsiedni poprawny przykład odróżniał naprawę od zbyt restrykcyjnego obejścia. Sędzia samej awarii nagradzałby oba.
Warunek ochronny może być doraźnym ograniczeniem szkody bez pełnej naprawy. Nadmierne dopasowanie spełnia przykłady zamiast wymagań. W bezpieczeństwie ukrywa symptom, zostawia inne ścieżki i daje fałszywy spokój osłabiający przegląd.
Testy dewelopera są lepszym przybliżeniem, nie pełną akceptacją. Nie wyczerpują wydajności, zgodności, czytelności i architektury. Rozsądna alternatywa może zmienić nieopisane zachowanie; historyczna porażka wymaga zbadania, nie dowodzi automatycznie niebezpieczeństwa.
Instrukcje zmieniają mierzoną zdolność
Ze szczegółowymi komendami Sonnet 4.0 przechodził 77,7% PoC, bez nich 74,1%. Test dewelopera wzrósł z 41,1% do 43,8%. W samym C/C++ instrukcje zwiększyły PoC z 72% do 92%, testy dewelopera zaledwie z 28% do 36%.
Dokumentacja to legalna pomoc także dla człowieka, ale wyników nie można porównywać bez budżetu informacji. Go i Rust mają często przewidywalne komendy, C/C++ różne systemy, flagi i nakładki. Pomoc środowiskowa zmienia ocenę przed pomiarem naprawy.
W 62 przypadkach Go źródłowy PoC zwiększył sukces z 69,4% do 95,2%, a deweloperski z 41,9% do 48,4%. Czytelny kod ujawnia API i wywołania, ułatwiając trafienie w widoczny test.
W 25 przypadkach C/C++ nieprzejrzyste wejście binarne lub tekstowe nie zmieniło 92% PoC ani 36% deweloperskich. Oba mogą twierdzić, że dają PoC, ale tylko jeden ujawnia wykonywalną intencję. To różne warunki.
Wyszukiwanie i infrastruktura zniekształcają obie strony
Historyczne zadania często mają publiczne zgłoszenia, biuletyny i poprawki. Praca opisuje agenta znajdującego patch w sieci i drugiego w nieoczyszczonej historii Git. Sukces nie mierzy czysto niezależnego naprawiania.
Sieć i historia są rozsądne w produkcji. To zanieczyszczenie tylko wobec obietnicy rozumowania bez pomocy. Test wyszukiwania i narzędzi może je jawnie dopuścić. Zapamiętanie dawnych poprawek także ogranicza wartości bezwzględne.
Błędy frameworku mogą ukryć dobre działanie lub ujawnić tajną odpowiedź. Uprawnienia, timeouty i kolizje plików blokują budowę lub źle oceniają. Poszczególne problemy dotyczyły około 5–32% przypadków pełnych uruchomień, czasem więcej niż różnice rankingowe.
Wynik należy więc do modelu, agenta, promptu, narzędzi, źródeł, limitów i oceny razem. Kontrole używały OpenCode z Claude, studia także Claude Code z Sonnet 4.5. Środowiska nie są zamienne.
Inne badania wymagają kilku testów
PVBench obejmuje 209 przypadków 20 projektów: ponad 40% poprawek zaakceptowanych podstawowymi testami oblało dodatkowe testy z napraw dewelopera. Inny zbiór i projekt nie daje porównywalnej stopy Claude.
PatchBench znalazł średnie zawyżenie rozwiązań 1,83 raza dla 11 agentów przy samym PoC. Powtórzenie bezpieczeństwa, testy jednostkowe i wyjścia obniżyły najlepszych z ponad 97% PoC do około połowy łącznie.
PatchBench wybiera też luki z naprawami poza stosem awarii i przeszczepia je do zmienionych repozytoriów, ograniczając wartość pamięci. Nie zakłada, że każdy sukces jest nowym rozumowaniem.
Berkeley CyberGym-E2E zawiera 920 luk 139 projektów i łączy wykrycie, reprodukcję oraz naprawę. Najlepsi naprawiali około 80% ze wskazanym celem; pełny wynik spadał, gdy musieli odkryć lukę. Wciąż zdarzały się powierzchowne warunki ochronne.
Modele, zadania i definicje nie tworzą jednego rankingu. Metodologia Cyber Index rozszerza audyt, wykrycie, odtworzenie i naprawę bez psucia legalnego zachowania. Wspólne pytanie dotyczy zawartości sukcesu.
Lepszy sędzia nie dowodzi produkcji
Próba Northwestern wymaga odtwarzalnych kompilacji i znaczących testów źródłowych. 112 usterek jest różnorodnych, nie reprezentuje wszystkich. Publiczne materiały mogły wejść do treningu. Ogranicza to wyniki absolutne, nie usuwa kontrolowanego wpływu promptów i oceny.
Produkcję mogą zabezpieczyć własne testy, analiza statyczna, fuzzing, review i stopniowe wdrożenie, ale utrudniają ją niepełne testy, nieopisane działanie i brak zależności. Ani uporządkowany benchmark, ani PoC nie dowodzi gotowości bez nadzoru.
Przydatne będą oddzielne PoC i testy intencji, uprawnienia narzędzi i sieci, czyszczenie historii, timeouty oraz błędy etapów, a także akceptacja, poprawianie i odrzucanie przez opiekunów. Inne ataki i nowe słabości też się liczą; zgodność tekstu nie zastępuje zachowania.
Przeszukiwalna techniczna baza wiedzy zachowuje prompty, ślady, patche i walidację, nie czyniąc kodu poprawnym. Wniosek to realny postęp Opus i zawyżenie o 29,5 punktu przez sam crash. Generowana naprawa pozostaje kandydatem wymagającym niezależnych dowodów bezpieczeństwa i prawidłowej funkcji.