Łatanie luk przez Claude wygląda imponująco — dopóki poprawki nie zostaną ocenione testami maintainerów
Łatanie luk przez Claude zaliczyło 90,2% kontroli opartych na awariach w nowym badaniu, jednak tylko 60,7% poprawek przeszło testy stworzone przez maintainerów. Ta różnica wynosząca 29,5 punktu procentowego zmienia znaczenie pozornego sukcesu. Powstrzymanie pojedynczego złośliwego wejścia przed spowodowaniem awarii programu nie dowodzi, że leżąca u podstaw luka została naprawiona prawidłowo.
Badacze z Northwestern University — Dang K Le, Wenxuan Shi i Xinyu Xing — przedstawili wyniki 7 października. Ich badanie wiarygodności benchmarków objęło 112 historycznych błędów z 84 projektów open source. Zbiór danych obejmował oprogramowanie w językach C, C++, Go i Rust.
Artykuł kwestionuje systemy punktacji wykorzystywane do oceny agentów AI programujących kod. Wiele benchmarków nagradza poprawkę, gdy proof of concept, czyli PoC, przestaje wywoływać zgłoszony błąd. Maintainerzy zazwyczaj oczekują więcej. Poprawka musi zachować zamierzone działanie, usunąć przyczynę źródłową i działać poprawnie dla zbliżonych wejść, których pierwotne zgłoszenie nigdy nie testowało.
Ten konflikt wywiera presję na twórców modeli, projektantów benchmarków i zespoły bezpieczeństwa w przedsiębiorstwach. Claude i inni agenci programistyczni coraz lepiej spełniają widoczne testy. Dowody nie wskazują jednak na równy postęp w kierunku poprawek, które zaakceptowałby maintainer projektu upstream.
Wynik łatania luk przez Claude ukrywa dwa różne rezultaty
Badanie wykazało, że przejście testu awarii i stworzenie akceptowalnej poprawki bezpieczeństwa nie są równoważnymi osiągnięciami.
Badacze uruchomili te same 112 przypadków za pomocą agenta OpenCode, zmieniając jedynie bazowy model Claude. Testowali Claude Sonnet 4.0, Sonnet 4.5 i Opus 4.7. Każde uruchomienie otrzymywało instrukcje budowania i testowania, lecz nie treść PoC.
Sonnet 4.0 powstrzymał dostarczony PoC w 77,7% przypadków. Sonnet 4.5 osiągnął 84,8%, a Opus 4.7 — 90,2%. Rozpatrywany osobno ten postęp sugeruje, że automatyczna naprawa luk zbliża się do nasycenia.
Wyniki zorientowane na maintainerów opowiadają inną historię. Sonnet 4.0 przeszedł testy deweloperów w 43,8% przypadków. Sonnet 4.5 osiągnął 48,2%, a Opus 4.7 — 60,7%.
Opus poprawił więc wyniki w obu miarach, ale nadal dzieliła je znaczna różnica. Spośród poprawek Opus, które przeszły PoC, 32,7% wciąż nie zaliczyło testu deweloperskiego. To w przybliżeniu jeden pozorny sukces na trzy.
Badacze zmierzyli również wyniki zwykłych testów regresji, które sprawdzają, czy wcześniej testowane zachowanie nadal działa. Opus 4.7 przeszedł te testy w 94,6% przypadków. Ten wysoki wynik nie zlikwidował znacznie niższego wyniku testów deweloperskich.
Rozróżnienie ma znaczenie, ponieważ stare zestawy testów regresji rzadko kodują dokładną decyzję projektową stojącą za nową poprawką bezpieczeństwa. Mogą potwierdzić, że znane zachowanie pozostało nienaruszone, jednocześnie nie wykrywając powierzchownej naprawy w pobliżu zgłoszonego błędu.
Testy deweloperskie wykorzystane w badaniu pochodziły z commitów z poprawkami upstream. Były to testy jednostkowe lub integracyjne napisane przez własnych deweloperów projektów podczas naprawiania każdego błędu. Badacze odtworzyli te dodatki i zastosowali je po tym, jak agent AI stworzył swoją poprawkę.
Takie podejście sprawdza, czy wygenerowany kod zachowuje się zgodnie z intencją maintainerów w obszarze luki. Nie wymaga ono, aby AI odtworzyła tekst poprawki maintainerów. Alternatywne poprawki mogą nadal przejść testy, jeśli ich zachowanie odpowiada zaakceptowanej semantyce projektu.
Zbiór danych narzucał także cztery kolejne bramki. Projekt z poprawką musiał się zbudować, blokować PoC podczas wielokrotnych uruchomień, przejść istniejący zestaw testów regresji i przejść dodany test deweloperski. Przypadek uznawano za w pełni rozwiązany dopiero po przejściu każdego etapu.
Publiczna analiza oceniania skupiła się na wskaźniku niepowodzeń wynoszącym jeden na trzy, ponieważ oddaje on praktyczne ryzyko. Atrakcyjny wynik nagłówkowy może się utrzymać, nawet gdy wiele zaakceptowanych poprawek nie przejdzie testu najbliższego intencji maintainerów.
Nie dowodzi to, że Opus 4.7 jest nieskuteczny w pracy nad bezpieczeństwem. Pokazuje, że zgłaszane możliwości silnie zależą od tego, co benchmark uznaje za sukces. Reguła oceniania może zmienić wniosek bez zmiany modelu ani jego poprawki.
Dlaczego powstrzymanie awarii nie jest tym samym co naprawienie błędu
PoC jest dowodem, że jedna awaria zniknęła, a nie potwierdzeniem, że podatne zachowanie naprawiono w całym prawidłowym zakresie działania.
Proof of concept zwykle dostarcza wejście odtwarzające lukę. W przypadku błędów bezpieczeństwa pamięci może ono wywołać awarię sanitizera. W przypadku wad logiki może demonstrować nieprawidłowy stan lub niedozwoloną operację.
Takie wejście jest cenne, ponieważ czyni awarię konkretną i powtarzalną. Ujawnia jednak tylko jedną ścieżkę przez program. Agent może zablokować tę ścieżkę bez zrozumienia szerszego kontraktu regulującego funkcję, której dotyczy problem.
Artykuł Northwestern ilustruje ten problem historycznym błędem PHP związanym z funkcją range(). Mieszane typy wejściowe mogły zostać nieprawidłowo sklasyfikowane, przez co PHP uzyskiwało dostęp do wartości niebędącej ciągiem znaków tak, jakby nią była. Jedno z dostarczonych wejść powodowało awarię.
Defensywna poprawka mogłaby zatrzymać tę awarię, od razu odrzucając mieszane typy. Spełniłaby warunek PoC i zachowała wiele wcześniej testowanych zachowań. Odrzucałaby jednak także prawidłowe mieszane wejścia numeryczne i tekstowe, które PHP miało konwertować.
Poprawka upstream zmieniła wadliwą logikę klasyfikacji, zachowując to zamierzone działanie. Deweloper dodał test dla zbliżonego prawidłowego wejścia, który odróżnił rzeczywistą naprawę od restrykcyjnego obejścia.
To jest centralny problem oceniania. Benchmark sprawdzający wyłącznie wejście powodujące awarię przyznaje obu poprawkom taki sam wynik. Test maintainerów odrzuca poprawkę, która zamienia obsługiwane zachowanie w błąd.
Agenci bezpieczeństwa mają silne bodźce, by optymalizować to, co ewaluator może zaobserwować. Gdy głównym wyrocznią jest awaria, dodanie zabezpieczenia w pobliżu miejsca awarii może być racjonalną reakcją. Wyrocznia to po prostu mechanizm decydujący o tym, czy wynik jest poprawny.
Taka poprawka może być użyteczna jako doraźne ograniczenie ryzyka. Nie powinna jednak automatycznie otrzymywać etykiety kompletnej naprawy. Różnica operacyjna wpływa na przegląd kodu, decyzje wdrożeniowe i poziom zaufania przypisywany systemom autonomicznym.
Problem jest już znany w automatycznej naprawie programów. Poprawka może nadmiernie dopasować się do zestawu testów, podobnie jak model statystyczny może nadmiernie dopasować się do danych treningowych. Spełnia dostępne przykłady, nie uchwytując jednak leżącego u podstaw wymagania.
Bezpieczeństwo podnosi koszt takiego błędu. Powierzchowna poprawka może stworzyć fałszywe poczucie bezpieczeństwa, ukryć widoczny objaw lub przenieść wadę na nietestowaną ścieżkę. Recenzenci mogą wtedy poświęcić mniej czasu kodowi opatrzonemu etykietą automatycznego sukcesu.
Powiązane badanie walidacji poprawek wprowadziło PVBench, wykorzystując 209 przypadków z 20 projektów. Jego badacze stwierdzili, że ponad 40% poprawek zaakceptowanych przez podstawowe testy nie przeszło dodatkowych testów wywiedzionych z poprawek deweloperów.
Ten niezależny wynik wspiera szerszą obawę, choć oba zbiory danych i projekty ewaluacji różnią się. Powtarzająca się lekcja jest taka, że podstawowe kontrole funkcjonalne i jedno wejście exploitowe pozostawiają ważne zachowania niezmierzone.
Łatanie luk przez Claude należy więc interpretować jako zdolność warstwową. Model musi zlokalizować przyczynę, zmodyfikować właściwą logikę, zachować uzasadnione zachowanie i uniknąć nowych słabości. Zatrzymana awaria weryfikuje jedynie część tego łańcucha.
Projekt benchmarku może zmienić wynik bez poprawy jakości poprawki
Szczegóły promptu, dostęp do narzędzi i reprezentacja testów mogą podnieść mierzoną wydajność, nawet gdy jakość zgodna z oczekiwaniami deweloperów niemal się nie zmienia.
Badacze z Northwestern sprawdzili, jak instrukcje budowania wpłynęły na ten sam model i zbiór danych. Z detalicznymi poleceniami budowania i testowania Sonnet 4.0 przeszedł 77,7% PoC. Bez tych instrukcji przeszedł 74,1%.
Ogólna różnica wygląda na niewielką. Wynik na poziomie języków był znacznie większy. W przypadkach C i C++ przekazanie instrukcji podniosło wskaźnik przejścia PoC z 72% do 92%.
Wynik testów deweloperskich w tej grupie wzrósł jedynie z 28% do 36%. We wszystkich językach wzrósł z 41,1% do 43,8%. Lepsze instrukcje przede wszystkim pomogły agentowi obsługiwać środowisko testowe i potwierdzać widoczne rezultaty.
Wynik nie sugeruje, że instrukcje są nieuprawnione. Ludzki inżynier również korzysta z udokumentowanych poleceń budowania. Oznacza to, że wyników z różnych benchmarków nie można bezpiecznie porównywać, jeśli nie ujawniono ich budżetów informacyjnych.
Konwencje języków programowania dodają kolejną zmienną. Projekty Go i Rust często udostępniają przewidywalne polecenia budowania i testowania. Repozytoria C i C++ korzystają z bardziej zróżnicowanej mieszanki systemów budowania, flag, wrapperów i procedur specyficznych dla projektu.
Agent, który nie odkryje tych poleceń, może otrzymać negatywny wynik, zanim jego poprawka zostanie poddana znaczącej ocenie. Z kolei starannie przygotowany prompt może usunąć pracę konfiguracyjną i sprawić, że ten sam model wyda się znacznie bardziej kompetentny.
Reprezentacja PoC stworzyła kolejną dużą różnicę. W 62 przypadkach Go pokazanie agentowi PoC na poziomie kodu źródłowego podniosło jego wynik testu awarii z 69,4% do 95,2%. Wynik testów deweloperskich wzrósł z 41,9% do 48,4%.
Kod źródłowy testu ujawniał wykorzystywane API i strukturę problematycznego wywołania. Ten kontekst pomógł agentowi dostosować się do widocznego testu. Przyniósł znacznie mniejszą poprawę w mierze zorientowanej na maintainerów.
W 25 przypadkach C i C++ udostępnienie nieprzezroczystego wejścia binarnego lub tekstowego nie wpłynęło na wynik PoC. Pozostał na poziomie 92%. Wynik testów deweloperskich również pozostał na poziomie 36%.
Obie konfiguracje benchmarku mogą zgodnie z prawdą stwierdzać, że przekazują agentom PoC. Nie przekazują jednak równoważnych informacji. Jedna ujawnia intencję wykonywalną, podczas gdy druga dostarcza plik wejściowy, którego znaczenie należy wywnioskować.
Dostęp do narzędzi wprowadza bardziej bezpośrednie ryzyko zanieczyszczenia danych. Historyczne luki często mają publiczne zgłoszenia, alerty i poprawki upstream. Agent programistyczny z dostępem do sieci może wyszukać numer zgłoszenia i pobrać zaakceptowaną poprawkę.
Artykuł dokumentuje przypadek, w którym agent użył narzędzi internetowych, aby znaleźć poprawkę upstream przed napisaniem odpowiedzi. W innym przypadku wcześniejsza naprawa została ujawniona przez nieoczyszczoną historię Git. Oba przypadki wygenerowały skuteczne poprawki, ale żaden nie mierzył w sposób czysty niezależnej zdolności naprawy.
Prawdziwi deweloperzy rutynowo przeszukują internet i analizują historię repozytorium. Takie działania są rozsądne w środowisku produkcyjnym. Stają się problematyczne tylko wtedy, gdy benchmark twierdzi, że mierzy samodzielne rozumowanie nad historycznym zadaniem.
Ewaluacja musi zatem określać zamierzoną zdolność. Benchmark wykorzystania narzędzi może dopuszczać wyszukiwanie i nagradzać skuteczne pozyskiwanie informacji. Benchmark rozumowania modelu musi izolować swoje przypadki od wycieku odpowiedzi.
Błędy infrastruktury mogą zniekształcać wyniki w przeciwnym kierunku. Nieprawidłowe uprawnienia mogą ujawnić ukrytą prawdę referencyjną lub uniemożliwić prawidłowe budowanie. Limity czasu mogą karać wolne projekty, a kolizje plików testowych mogą oznaczać poprawne poprawki jako nieudane.
Badacze zaobserwowali indywidualne problemy frameworka wpływające na około 5% do 32% przypadków w pełnych uruchomieniach. Wskaźniki te mogą przekraczać różnicę wyniku dzielącą dwie pozycje w rankingu.
Praktyczny wniosek nie jest taki, że wszystkie wyniki benchmarków są bezużyteczne. Jest nim to, że wynik należy do kompletnego systemu, obejmującego jego prompt, narzędzia, pakietowanie źródeł, limity wykonania i proces oceniania.
Prawdziwy pojedynek to sukces w benchmarku kontra akceptacja maintainerów
Główny problem nie polega już na tym, czy agent AI potrafi napisać wiarygodną łatkę, lecz na tym, czy sygnał sukcesu odpowiada kryteriom akceptacji w środowisku produkcyjnym.
Dostawcy rozwiązań AI do łatania luk w zabezpieczeniach korzystają na zwięzłych wskaźnikach wydajności. Kupujący również oczekują prostego porównania przy wyborze modeli lub ocenie agentów bezpieczeństwa. Te zachęty sprzyjają rankingom z jednym, widocznym wskaźnikiem sukcesu.
Maintainerzy działają według mniej wygodnej definicji. Muszą zdecydować, czy zmiana usuwa pierwotną przyczynę, chroni wspierane zachowanie, jest zgodna z konwencjami projektu i pozostaje zrozumiała po wielu miesiącach.
Zbiór danych Northwestern próbuje przenieść część tej oceny do automatycznej ewaluacji. Testy napisane przez maintainerów nie są pełnym substytutem przeglądu, ale kodują więcej intencji niż sam input wywołujący awarię.
Inni badacze podążają w podobnym kierunku. Wyniki PatchBench wykazały, że walidacja wyłącznie za pomocą PoC zawyżała wskaźniki rozwiązania średnio 1,83 raza w przypadku 11 agentów. Benchmark dodał odtwarzanie scenariuszy bezpieczeństwa, testy jednostkowe i kontrole wyników.
PatchBench uwzględnił również problem zapamiętywania. Wybrano luki, których zaakceptowane poprawki znajdowały się poza zgłoszonym stosem awarii. Następnie luki przenoszono do zmienionych kontekstów repozytoriów, aby ograniczyć korzyści z odtwarzania historycznych łatek.
Najsilniejsze agenty przeszły ponad 97% oryginalnych PoC, lecz rozwiązały około połowy zadań przy połączonej walidacji bezpieczeństwa i semantyki. Ten wzorzec blisko przypomina lukę w ocenianiu zidentyfikowaną przez Northwestern.
Badacze z Berkeley doszli do bardziej optymistycznego, lecz zgodnego wniosku w ramach benchmarku end-to-end. CyberGym-E2E zawiera 920 luk w 139 projektach open source i wspólnie testuje wykrywanie, odtwarzanie oraz łatanie.
Jego najlepsze konfiguracje naprawiły około 80% przypadków po wskazaniu docelowej luki. Wydajność end-to-end spadała, gdy agenty musiały najpierw samodzielnie wykryć problem. Badacze zaobserwowali również powierzchowne łatki, które zabezpieczały przed zgłoszoną awarią, pozostawiając głębszą wadę.
Badania te nie tworzą jednego uniwersalnego rankingu. Wykorzystują różne zadania, agenty, generacje modeli i definicje. Razem pokazują, dlaczego pojedynczy procent nie może reprezentować całego procesu obronnego.
Wyższy standard nie powinien wymagać tekstowego dopasowania do historycznej łatki. Błędy oprogramowania często mają kilka prawidłowych napraw. Benchmark oparty na podobieństwie łatek mógłby odrzucić lepszą alternatywę tylko dlatego, że zmieniła inną funkcję.
Lepszym kierunkiem jest ocena behawioralna. Powinna testować zgłoszony exploit, sąsiednie dane wejściowe, wspieraną funkcjonalność, właściwości bezpieczeństwa i oczekiwania specyficzne dla projektu. Przegląd przez człowieka pozostaje konieczny tam, gdzie tych wymagań nie da się zakodować.
Zespoły korporacyjne powinny stosować to samo rozróżnienie podczas zakupów. Wynik dostawcy dotyczący łatania jest niepełny bez informacji o wyroczni, środowisku, uprawnieniach narzędzi i kategoriach błędów stojących za nim.
Użyteczne pytania są konkretne. Czy agent otrzymał exploit? Czy mógł uzyskać dostęp do internetu lub historii Git? Czy sukces wymagał testów maintainerów? Czy błędy potoku były rozdzielane od nieprawidłowych łatek?
Zespoły powinny także pytać, czy wyniki uwzględniają regresje w łatkach, alternatywne ścieżki exploitu i nowo wprowadzone słabości. Łatka blokująca jeden exploit, a jednocześnie odsłaniająca inny, nie jest obronionym sukcesem.
Ten standard podnosi poprzeczkę dla łatania luk przez Claude i każdego konkurencyjnego systemu. Daje również twórcom modeli wyraźniejszy cel niż zwykłe zwiększanie wskaźników przejścia PoC.
Co badanie dowodzi, a czego nie dowodzi
Dowody pokazują wrażliwość benchmarków, lecz nie ustalają uniwersalnego wskaźnika niepowodzeń dla Claude ani każdego produkcyjnego procesu bezpieczeństwa.
Artykuł jest preprintem arXiv z października 2026 roku. Jego twierdzenia należy oceniać jako wyniki badań, a nie jako ostateczny, branżowy pomiar niezawodności autonomicznego łatania.
Jego 112 przypadków obejmuje cztery kategorie językowe i 84 projekty, co zapewnia analizie użyteczną różnorodność. Jednak uwzględnienie wymagało odtwarzalnych buildów oraz commitów upstream zawierających istotne testy. Taka selekcja nie reprezentuje każdej luki wykrywanej w środowisku produkcyjnym.
Testy deweloperskie są mocniejsze niż kontrole oparte wyłącznie na PoC, lecz nadal stanowią niepełny odpowiednik akceptacji maintainerów. Dodany test projektu uchwytuje wybrane zamierzone zachowanie, a nie wszystkie kwestie wydajności, kompatybilności, czytelności czy architektury.
Wygenerowana łatka może również nie przejść historycznego testu deweloperskiego, pozostając mimo to uzasadniona. Alternatywna naprawa może celowo zmienić nieudokumentowane zachowanie lub zamknąć szerszą powierzchnię ataku. Ludzcy maintainerzy mogą zaakceptować taki kompromis po przeglądzie.
Badanie ogranicza ten problem, wykorzystując testy napisane w poprawce upstream. Nie eliminuje jednak potrzeby analizy poszczególnych rozbieżności. Nieudany test wskazuje na brak zgodności, a nie automatycznie na niebezpieczną łatkę.
Dane historyczne tworzą kolejne ograniczenie. Publiczne zgłoszenia, advisories i poprawki mogły pojawić się w danych treningowych modeli. Badacze przyznają, że zapamiętywanie może wpływać na bezwzględne wskaźniki sukcesu.
Ich kontrolowane porównania pozostają wartościowe, ponieważ utrzymują model i błąd na stałym poziomie, zmieniając warunki benchmarku. Samo zapamiętywanie nie wyjaśnia, dlaczego szczegóły promptu lub wybór wyroczni zmieniają mierzone wyniki.
Eksperymenty wykorzystywały również konkretne kombinacje agentów i modeli. Testy kontrolowane łączyły OpenCode z modelami Claude, podczas gdy studia przypadków łączyły Claude Code z Sonnet 4.5. Różne struktury wspomagające mogą prowadzić do odmiennego zachowania podczas wyszukiwania, edycji i walidacji.
Łatanie luk przez Claude w środowisku produkcyjnym może obejmować testy specyficzne dla organizacji, analizę statyczną, fuzzing, przegląd kodu i etapowe wdrażanie. Te mechanizmy kontroli mogą wychwycić błędy, które akademicki harness rejestruje jako nieudane wyniki.
Prawdziwe jest również przeciwieństwo. Repozytoria produkcyjne mogą zawierać niekompletne testy, nieudokumentowane zachowanie i zależności niedostępne w czystym kontenerze. Rzeczywiste wdrożenie może być trudniejsze niż starannie przygotowany benchmark.
Odpowiedzialny wniosek jest węższy niż marketing czy lekceważenie. Claude Opus 4.7 poprawił się istotnie względem wcześniejszych generacji Claude w tym zbiorze danych. Jego wynik testów awarii nadal zawyżał rezultat zgodny z intencją deweloperów o 29,5 punktu procentowego.
Zespoły bezpieczeństwa powinny traktować wygenerowane łatki jako kandydatów wymagających dowodów. Badanie nie uzasadnia bezobsługowego wdrażania wyłącznie na podstawie zatrzymanego PoC i zielonego zestawu starszych testów.
Trzy sygnały pokażą, czy łatanie przez AI staje się godne zaufania
Postęp zależy teraz od mocniejszego oceniania, przejrzystych potoków ewaluacyjnych oraz dowodów produkcyjnych, że wygenerowane poprawki wytrzymują niezależny przegląd.
Pierwszym sygnałem jest szersze wykorzystanie testów intencji deweloperskiej lub testów semantycznych. Przyszłe wydania modeli powinny raportować zarówno sukces PoC, jak i wyniki testów zaprojektowanych wokół zaakceptowanego zachowania programu.
Kurcząca się luka wzmocniłaby argument, że modele uczą się naprawiać pierwotne przyczyny. Rosnące wyniki testów awarii przy stabilnej luce w testach maintainerów osłabiłyby to twierdzenie.
Drugim sygnałem jest pełne ujawnianie benchmarków. Ewaluatorzy powinni publikować prompty, uprawnienia narzędzi, dostęp sieciowy, oczyszczanie źródeł, limity czasu, błędy stosowania testów oraz wyniki każdego etapu.
Ma to znaczenie, ponieważ wynik może się zmienić, gdy agent otrzymuje instrukcje budowania, czytelne PoC, dostęp do sieci lub ukrytą historię repozytorium. Odtwarzalne artefakty pozwalają badaczom oddzielić postęp modelu od pomocy ze strony harnessu.
Niezależne inicjatywy zaczynają obejmować szerszy cykl obronny. Metodologia Cyber Index łączy audyt repozytorium, wykrywanie luk, ich odtwarzanie i łatanie bez naruszania prawidłowego działania.
Trzecim sygnałem są dowody z przejrzanych łatek produkcyjnych. Organizacje powinny śledzić, jak często wygenerowane poprawki są akceptowane bez zmian, poprawiane przez maintainerów, odrzucane lub prowadzą do regresji bezpieczeństwa.
Ten lejek akceptacji ma większe znaczenie niż liczba awarii wyeliminowanych w kontrolowanym zestawie. Mierzy, czy automatyczne wyniki zmniejszają nakład pracy inżynierskiej bez przenoszenia ukrytego ryzyka dalej.
Do natychmiastowego zastosowania zespoły mogą przyjąć wielowarstwową bramkę. Należy wymagać zatrzymania exploitu, uruchamiać stare testy regresyjne, dodawać przypadki brzegowe, stosować fuzzing tam, gdzie jest to praktyczne, oraz uzyskiwać przegląd przez człowieka przed wdrożeniem.
Powinny zachowywać prompt agenta, ślad narzędzi, łatkę i wyniki walidacji. Przeszukiwalna baza wiedzy inżynierskiej może pomóc zespołom porównywać powtarzające się wzorce błędów między repozytoriami.
Pytanie dla kupujących nie brzmi już, czy agent AI potrafi zmienić czerwony test w zielony. Brzmi: czy ten zielony wynik reprezentuje właściwość bezpieczeństwa, wspierane zachowanie i intencję maintainerów, których wymaga oprogramowanie produkcyjne.
Zanim zaufasz kolejnemu wynikowi łatania luk przez Claude, zapytaj, co mógł zobaczyć oceniający. Następnie zapytaj, czego nigdy nie przetestował.
