O czym jest ten film
- Agenty kodujące z AI potrafią być szybsze i lepsze od inżynierów, ale bezpieczeństwo to ich systematycznie najsłabszy obszar — zawodzą w nim częściej niż w dokumentacji, wydajności czy reużywalności kodu.
- Luki trafiają do projektu dwiema drogami: agent sam pisze podatny kod (np. otwarty na SQL injection) albo instaluje zewnętrzną bibliotekę z zarejestrowaną podatnością CVE.
- Dwa główne powody porażek: agenci nie śledzą łańcuchów zależności transytywnych, a rejestr CVE jest tak ogromny, że nie mieści się w kontekście modelu.
- Autor przypuszcza, że modele bywają trenowane „na skróty” dla szybkości, a same dane treningowe pełne są luk zostawionych przez ludzi.
- Istnieje cicha wersja problemu: agent wykrywa lukę, ale zamiast ją naprawić, wspomina w opisie pull requesta, że „do obsłużenia w kolejnym zgłoszeniu”.
- Intuicyjne rozwiązanie — drugi agent w roli recenzenta — to wciąż proces losowy: recenzent może przeoczyć dokładnie to samo, co wykonawca.
- Właściwy mechanizm to bramka deterministyczna: skan podatności uruchamia skrypt przez API SonarQube, więc wynik za każdym razem jest identyczny.
- Całość działa jak pętla: raport trafia do agenta, ten naprawia czerwone pozycje, skan się powtarza — dopiero ocena A i zero zgłoszeń pozwalają zakończyć zadanie.
- Autor pokazuje implementację w swoim narzędziu Arkon, ale wzorzec da się przenieść na dowolny stos; skan można też wpiąć bezpośrednio w CI.
- Autor otwarcie mówi o partnerstwie z Sonar i udostępnia swój workflow w opisie filmu — m.in. po to, by można go było podać własnemu agentowi do analizy lub integracji.
Redakcyjne tłumaczenie
Bezpieczeństwo: najsłabszy punkt agentów kodujących
Agenci kodujący ze wsparciem sztucznej inteligencji potrafią być niemal pod każdym względem lepsi i szybsi od inżynierów — o ile działają w dobrze zbudowanym systemie i o ile jasno zakomunikujemy im, czego chcemy. To oczywiście spore „o ile”, ale teza tego materiału jest bardziej radykalna: nawet w idealnym systemie agenty zawodzą w kwestii bezpieczeństwa częściej niż w innych aspektach jakości kodu — w dokumentacji, wydajności czy możliwości ponownego wykorzystania. Dlatego bezpieczeństwem trzeba zająć się osobno, a ludzie poświęcają mu dziś stanowczo za mało uwagi. Krążące historie o kodzie generowanym przez AI, pełnym luk, powinny być sygnałem alarmowym.
Chcę pokazać bardzo prostą koncepcję — bramki deterministyczne (ang. deterministic gates) — czyli sposób na to, by kod pisany przez AI stawał się bezpieczniejszy. Poza samą ideą pokażę mój codzienny proces, narzędzia, których faktycznie używam, oraz to, jak wplatuje się w niego bezpieczeństwo.
Dwa filary: Arkon i SonarQube
Obecnie całe swoje kodowanie z AI przepuszczam przez Arkon — to mój główny silnik. Arkon to moje narzędzie open source do budowania przepływów pracy: pozwala wziąć dowolny proces realizowany dziś z agentami kodującymi i zamknąć go w jednym pliku, który łatwo rozwijać i uruchamiać równolegle. W praktyce łączy się w nim węzły — wywołania agentów i skrypty — które przeprowadzają całość od początku do końca. Budujemy w ten sposób system okalający agentów, żeby dodać ich pracy determinizmu, a częścią tej determinizacji są kroki weryfikacyjne, czyli bezpieczeństwo wpisane bezpośrednio w proces.
Do weryfikacji używam SonarQube. Sporo mówiłem o tej platformie na kanale; jest dla mnie kluczowa, bo daje bardziej przewidywalne kontrole w obszarach takich jak wykrywanie luk. Nie poprzestaję więc na wysyłaniu kolejnego agenta, żeby zrobił przegląd kodu — choć o tym też zaraz porozmawiamy. Arkon i SonarQube to para, na której opiera się wszystko, co omówimy.
Nie znaczy to jednak, że musisz używać dokładnie tych aplikacji. Cały omawiany materiał wykracza poza jakiekolwiek pojedyncze narzędzie — wystarczy mieć coś, co wykona tę samą robotę. Tak, to moje rekomendacje; łączy mnie też z Sonarem umowa partnerska, bo szczerze cenię ich platformę i wierzę, że rozwiązują właściwe problemy w inżynierii agentów.
(Informacja dodatkowa: autor jednoznacznie zaznacza w filmie, że współpracuje partnersko z firmą Sonar — warto o tym pamiętać, oceniając jego rekomendacje narzędzi.)
Plan jest następujący: najpierw zobaczymy, dlaczego agenty kodujące tak często zawodzą w bezpieczeństwie i na jakich ścieżkach dochodzi do błędów. Potem omówimy intuicyjne rozwiązanie — osobnego agenta w roli recenzenta — i dlaczego w większości przypadków nie wystarcza. Wreszcie przejdziemy do podejścia właściwego, czyli dodawania determinizmu do zadań procesu kodowania z AI. Chodzi o gwarancję, że luki są wykrywane zawsze według tej samej recepty — jeszcze zanim otworzymy pull request albo odzyskamy kontrolę nad zadaniem — oraz o to, by agent nie tylko wykrywał problemy, lecz także iteracyjnie je naprawiał.
Dwie drogi, którymi luki trafiają do projektu
W jaki sposób agenty kodujące wprowadzają podatności do bazy kodu? Robią to bez przerwy, na dwa sposoby. Albo agent pisze lukę bezpośrednio w kodzie — na przykład wystawiając go na atak typu SQL injection — albo instaluje zależność, czyli zewnętrzną bibliotekę, w której podatność siedzi od początku.
Niestety dzieje się to znacznie częściej, niż branża software’owa chciałaby przyznać. Istnieją biblioteki z zarejestrowanymi podatnościami CVE. Skrót wart tu wyjaśnienia: CVE (Common Vulnerabilities and Exposures) to ogromny, publicznie prowadzony rejestr sposobów, w jakie kod może stać się podatny na atak. Właśnie taki kod potrafi wygenerować agent i właśnie te rzeczy powinniśmy umieć wykrywać w pakietach, które sprowadzamy do środowiska.
Same agenty nie robią praktycznie nic, żeby wychwycić podatności — ani we własnym kodzie, ani w pakietach, które przynoszą do projektu. Pewnie widziałeś to na własne oczy: gdy agent pracuje nad bazą kodu, bez końca zaciąga zewnętrzne biblioteki — w duchu zresztą słusznego „nie wynajdujmy koła na nowo” — ale ani przez chwilę się nie zastanawia ani nad konkretną wersją instalowanego pakietu, ani nad samym pakietem.
Dlaczego agenty zawodzą właśnie w bezpieczeństwie
Zatrzymajmy się na moment, żeby pogłębić obraz — chcę pokazać, jak naprawdę zła jest ta sytuacja. Są dwie główne przyczyny.
Pierwsza: pakiety zewnętrzne, które ciągle sprowadzamy do naszych baz kodu, same mają zależności. Może się więc zdarzyć, że instalujemy porządną bibliotekę, której własny kod jest bez zarzutu, ale któraś z jej zależności drugiego rzędu nosi jedną lub dwie podatności CVE. Dla każdego pakietu osobno rozciąga się rozgałęziony, potencjalnie bardzo rozległy łańcuch, który trzeba przejrzeć. Agent sam z siebie tego nie zrobi. Może rzucić okiem na najwyższy poziom, może coś poszukać o zależności przed instalacją — ale nie prześledzi całego łańcucha.
Druga sprawa: sam rejestr CVE jest gigantyczny. Naprawdę nie zdajemy sobie sprawy — i moim zdaniem nikt z nas nie jest w stanie ogarnąć — ile istnieje sposobów, żeby zepsuć kod i wprowadzić lukę. Agenty nie sprawdzą wszystkiego z tej listy; to po prostu przekracza pojemność ich kontekstu.
Do tego dochodzi jeszcze coś, czego nie mam pewności, ale w co mocno wierzę: duże modele językowe bywają trenowane tak, żeby czasem iść na skróty — dla szybkości, bo ludzie chcą wyników natychmiast. Oznacza to, że laboratoria mają bodziec, by na takie przyśpieszenia pozwalać. A do tego same dane treningowe pełne są repozytoriów i przykładów ludzi, którzy również schodzili na skróty i zostawiali po sobie luki. Nie wystarczy więc zostawić agentowi wykrywania tych rzeczy ani wypatrywać, że sam je zauważy. Będzie je przeoczał i wprowadzał w kółko.
Cicha podatność: agent widzi lukę i ją zostawia
Widziałem jeszcze gorszy, „cichy” wariant tego problemu: agent zauważa lukę, ale jej nie naprawia. Na przykład otwiera pull request i wspomina w jego opisie: „ta podatność wymaga obsłużenia w kolejnym zgłoszeniu”. Oczywiście nic nie gwarantuje, że to kolejne zgłoszenie kiedykolwiek powstanie. Luka trafia do bazy kodu tak czy inaczej.
Czego potrzebujemy: powtarzalności, nie nieomylności
Co jest więc niezbędne w procesie kodowania z AI — i czego nie wolno pominąć — to gwarancja, że luki sprawdzamy za każdym razem dokładnie tak samo. Nie chodzi o wykrycie każdej podatności pod słońcem. Chodzi o dodanie deterministycznego kroku, który zapewnia powtarzalność: skoro zawsze wykonujemy te same kontrole, to wszystko, co się w nich pojawi, będziemy też za każdym razem naprawiać.
Kuszące rozwiązanie: drugi agent w roli recenzenta
Zacznijmy od pokusy — od probabilistycznego podejścia do wykrywania luk, czyli po prostu od kolejnego agenta. Przyznaję się bez bicia: sam zaczynałem w ten sposób, używając promptu jako bramki. Po utworzeniu pull requesta moim pomysłem na security review było wysłanie innego agenta, który patrzy na zmiany wyłącznie pod kątem luk i zwraca moją uwagę na rzeczy wymagające reakcji — może do wspólnej pracy z agentem głównym.
Szczerze? Działało to… przyzwoicie. Agent wyłapał całkiem sporo, ale to nie było wystarczająco dobre. Pokażę, jak to wygląda w praktyce — zapewne właśnie na tym etapie jesteś teraz — zanim przejdziemy do bramek deterministycznych i do tego, jak pracuję z Sonarem.
Proces bazowy: od zgłoszenia do pull requesta
Większość mojej pracy to dziś zamiana zgłoszeń (issues) z GitHuba w pull requesty. Wejściem procesu jest zgłoszenie, wyjściem — pull request. W najbardziej podstawowym wydaniu wygląda to tak: najpierw ustalam, czy mam do czynienia z błędem wymagającym zbadania, czy z nową funkcją do zaplanowania. W zależności od typu wybieram jedną z tych ścieżek, przechodzę do implementacji według planu i na końcu tworzę pull request.
Zaleta Arkona jest taka, że cały ten proces mogę zwizualizować — diagram narysowałem w Excalidraw. Każdy przepływ w Arkonie to po prostu zbiór węzłów, które łączymy ze sobą: deterministyczny węzeł pobiera treść zgłoszenia i zasila krok klasyfikacji i planowania, następnie powstaje plan, który trafia do wykonania. Jeśli nie używasz Arkona, to w praktyce jest to zestaw umiejętności, które ręcznie przełączasz między sesjami różnych agentów kodujących. Ja zarządzam wszystkim jako jednym przepływem sterowanym przez Arkona, a pracę kończę pull requestem.
Dlaczego recenzent-agent to tylko dobry początek
Gdy pull request powstanie, agent wykonawczy zgłasza gotowość. I tu kusi, żeby dołożyć na to jeszcze jednego agenta, który zrecenzuje zmiany — i uznać, że kwestia przeglądu jest załatwiona.
Proszę, nie zrozum mnie źle: to nie jest zły punkt wyjścia. Mieć w procesie osobnego agenta (albo inną umiejętność), który przegląda pull request, przechodzi po wszystkich zmianach i próbuje wychwycić luki oraz inne problemy — to podejście dobre i je polecam. Ale nie może to być koniec drogi w wykrywaniu podatności, bo dokładasz na wierzch kolejny proces probabilistyczny. Jeśli agent wykonawczy przeoczył pewne luki, jest spora szansa, że recenzent wpadnie na dokładnie tę samą przeszkodę. Pull request może po przeglądzie wyglądać na czysty, a mimo to przemkną nim problemy.
Właściwe rozwiązanie: bramka weryfikacyjna
Proces, który właśnie opisałem — planowanie, implementacja, pull request, jakiś przegląd na końcu — to dobry start. Ale pomysł, który robi z tego coś znacznie lepszego, to bramka kontrolna. Potrzebujesz mechanizmu, który gwarantuje wykrycie luk bezpieczeństwa na podstawie rejestru CVE — nie chcesz zostawiać tej robocy agentowi w spadku. Potrzebujesz podejścia w duchu tego, co daje Sonar: narzędzie wskazuje problemy, a jeśli cokolwiek świeci się na czerwono, zmuszasz agenta wykonawczego do kolejnej iteracji. Dopiero gdy wszystko jest zielone, dopuszczasz otwarcie pull requesta. W ten sposób wyłapujemy znacznie więcej luk niż w pierwszym podejściu, a przy okazji lżej się pracuje z pull requestem w ogóle, bo nie zadowalamy się pierwszym przejściem agenta.
Zbudowałem właśnie taki przepływ w Arkonie — to rozwinięta wersja diagramu, który pokazywałem wcześniej. Znowu zaczynamy od klasyfikacji; początek wcale nie musi być inny, ulepszamy wyłącznie etap weryfikacji na końcu. Klasyfikujemy, planujemy funkcję albo badamy błąd, wysyłamy to do implementacji. Pull request nadal otwieramy po zakończonej pracy agenta i możemy odpalić testy itp. Ale potem wchodzi krok o deterministycznym wyniku: wywołujemy Sonara. Przepływ w Arkonie korzysta z API SonarQube i wykonuje skan wobec rejestru podatności. W tle dzieje się sporo więcej, ale sedno jest takie, że wraca odpowiedź. Workflow podaje ją agentowi, by ten wskazał, co wymaga obsłużenia. Zmuszamy agenta do iteracji, a bramka weryfikacyjna potwierdza, że wszystko, co świeciło na czerwono, faktycznie zostało naprawione. Dopiero wtedy przygotowujemy pull request. Wyłącznie gdy wszystko jest zielone, kończymy przepływ i przejmujemy stery — na przykład po to, by przejrzeć zmiany ręcznie przed scaleniem.
(Informacja dodatkowa: „bramka jakości” (quality gate) to wbudowany mechanizm SonarQube, który porównuje wyniki analizy z ustalonymi progami — np. zerem nowych podatności — i wydaje jednoznaczny werdykt „przeszło/nie przeszło”.)
Pod maską: skrypt zamiast agenta
Pokażę jeszcze ten etap od strony technicznej — bo nawet jeśli nie używasz Arkona, możesz przejąć moje podejście do Sonara i deterministycznych kontroli. Link do całego workflow zostawiam w opisie filmu. Jeśli zajrzymy do kroku skanu wykonywanego po otwarciu pull requesta, widać, że zależy on od tego, czy pull request już istnieje. Używam węzła bash — w Arkonie oznacza to wywołanie skryptu, a nie agenta, bo ten krok ma być w pełni powtarzalny. Ustawiam parametry, po czym uruchamiam skrypt, który przez API SonarQube (z tokenami i całą resztą) generuje raport dla pull requesta. Za chwilę pokażę, jak to wygląda na GitHubie. Raport trafia potem do agenta, żeby obsłużył czerwone pozycje.
Tak — to nadal krok probabilistyczny. Ale gwarancja polega na tym, że dane wejściowe przychodzą zawsze identycznie, a na końcu potwierdzamy, że agent naprawdę wszystko obsłużył. Wracamy do Sonara, upewniamy się, że jest zielono, i dopiero wtedy kończymy przepływ i dopieszczamy pull request.
Na marginesie: SonarQube można oczywiście uruchamiać bezpośrednio w CI, tuż po utworzeniu pull requesta. Powód, dla którego robię to wprost w moim procesie w Arkonie, jest inny: mogę wtedy automatycznie przekazać raport agentowi, by pracował na nim iteracyjnie.
SonarQube Cloud w praktyce
Wracamy do naszego pull requesta na GitHubie — zobaczmy, jak to wszystko spina się w wykrywaniu luk. Pierwsze wywołanie w moim procesie daje właśnie raport, a ponieważ chcę pokazać przykład z prawdziwymi problemami, mamy trzy znalezione zgłoszenia. To pulpit SonarQube Cloud — widzę tu dokładnie to samo, co dostaje mój agent. Każda pozycja przynosi mnóstwo informacji: skąd pochodzi i jak ją poprawić. Mogę kliknąć w przykład — tu na instance prawdopodobnie zaszyte na sztywno hasło, wykryte w moim kodzie metodą deterministyczną, a nie na traffic modelu. Szczegóły pokazują, jak takie schematy prowadziły kiedyś do realnych luk. Przypominam skrót CVE — rejestr jest gigantyczny, stąd te długie, wieloczłonowe identyfikatory. Właśnie dlatego potrzebujemy platformy typu Sonar do zdecydowanych kontroli wobec tej wielkiej listy — agent sam z siebie nie zawsze potrafi te rzeczy wyłapać.
Gdy raport trafia do agenta, ten obsługuje zgłoszenia i oczywiście ponawia skan, żeby upewnić się, że wszystko gra. Na pulpicie — i w oczach agenta — robi się wtedy zielono: ocena bezpieczeństwa A, zero zgłoszeń. Dopiero teraz pull request jest naprawdę gotowy.
Cały przepływ w akcji
Na koniec pokażę ten proces w działaniu — od pierwszej komendy w Arkonie do końca. Po zainstalowaniu Arkona buduje się własny workflow (instrukcję podrzucę linkiem w opisie). W głównym agencie wystarczy powiedzieć: „chcę, żebyś użył tego workflow do naprawy zgłoszenia numer 79”. Można nawet uruchomić kilka takich zadań równolegle, dla różnych zgłoszeń — to właśnie siła Arkona. Agent ładuje umiejętność Arkona, odnajduje przepływ i odpala interfejs wiersza poleceń, żeby zacząć zadanie w tle. Ono zaś przechodzi cały opisany łańcuch: planowanie, implementacja i wszystko, co wiąże się z SonarQube.
Głównego agenta można przy tym użyć do nadzoru: niech zerka w logi, sprawdza, czy wszystko idzie gładko, i podaje status. W demie pytam: „dokąd już doszło?” — agent patrzy w logi i odpowiada, że właśnie trwa etap planowania, więc skan z Sonarem jeszcze się nie zaczął. Chwilę dalej w transkrypcie rozmowy widać, że jednak się zaczął i skończył: skan wrócił, bramka czerwona. Pierwsze przejście wykryło te same trzy luki, które pokazywałem wcześniej w pull requeście numer 73. Widać wymagany próg — to nasz cel. Przechodzimy więc do kroku naprawy: agent obsługuje zgłoszenia, skan rusza ponownie i teraz wszystko gra. Po jednej iteracji osiągnęliśmy wymagany poziom, pull request został zgłoszony i jesteśmy w idealnej sytuacji.
Na zakończenie
Celem tego materiału było przede wszystkim pokazanie różnicy między tymi dwoma podejściami — oraz wyjaśnienie, dlaczego w ogóle się tym przejmujemy. Dlaczego przegląd agenta nie wystarcza? Jak buduje się takie zabezpieczenia? Świadomie trzymałem poziom dość ogólny. Wewnętrzne mechanizmy bramki — jak dokładnie używamy SonarQube, jak iterujemy na otrzymywanym raporcie — kryją mnóstwo dodatkowych, złotych wskazówek. Jeśli poważnie myślisz o budowaniu oprogramowania gotowego na produkcję, w którym rzeczy muszą być bezpieczne i niezawodne, zachęcam, żebyś się w to zagłębił. Możesz wziąć mój workflow (link w opisie), podać go swojemu agentowi kodującemu — Claude Code czy czemukolwiek używasz — i poprosić o wyciągnięcie pomysłów, albo po prostu wpleść go u siebie, jeśli jak ja chcesz działać z Arkonem i Sonarem. U mnie działa znakomicie.
Mój proces kodowania z AI nie jest idealny, ale z każdym dniem bliżej do ideału. Cenię niezawodność, jaką daje mi to podejście, i lubię pracę z Sonarem. Ich hasło brzmi: prowadź, weryfikuj, napraw — to pełny cykl inżynierii agentowej, a oni budują produkty dla każdego jego etapu. Nie tylko weryfikacja w SonarQube Cloud, którą pokazałem w tym filmie — choć to duży kawałek tego, co integruję — ale i pozostałe obszary. Linki zostawię w opisie, podobnie jak link do Arkona: razem tworzą znakomity duet.
Cieszę się, że znów zrobiłem film o bezpieczeństwie — dawno temu nie było, a temat jest zbyt ważny, żeby nie poświęcić mu osobnego materiału. Trudno przy okazji każdego ogólnego przepływu pracy mówić dużo o bezpieczeństwie, więc mam nadzieję, że wynieśliście stąd sporo. Jeśli chcecie więcej o inżynierii agentów i bezpieczeństwie kodowania z AI, polubienie i subskrypcja bardzo pomogą. Do zobaczenia w następnym filmie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Bezpieczeństwo wydziel jako osobny, obowiązkowy etap
Na czym polega: Agenty zawodzą w bezpieczeństwie częściej niż w dokumentacji, wydajności czy reużywalności — ta dyscyplina nie powstaje sama, trzeba ją wymusić procesem.
Jak stosować: Przejrzyj swój proces pracy z agentem i zapytaj wprost: w którym konkretnie miejscu wykrywane są luki? Jeśli nie ma takiego punktu, dodaj go jako wyodrębniony etap, zamiast zakładać, że „agent o tym pomyśli”.
Na co uważać: Kontrola „na oko” daje pozorne poczucie bezpieczeństwa. Testem jest to, czy weryfikacja odpala się zawsze — także wtedy, gdy agent się spieszy albo zadanie wydaje się banalne.
2.Pilnuj obu dróg wejścia luk: kodu i zależności
Na czym polega: Luki trafiają do projektu, gdy agent pisze podatny kod (np. otwarty na SQL injection) albo gdy instaluje bibliotekę z podatnością z rejestru CVE.
Jak stosować: Skan konfiguruj tak, by obejmował zarówno nowy kod, jak i drzewo zależności; instalację pakietu przez agenta traktuj jako zdarzenie wymagające zatwierdzenia wersji.
Na co uważać: Bezpieczna na pierwszy rzut oka biblioteka może ciągnąć za sobą podatną zależność drugiego rzędu — czysty kod samej biblioteki niczego tu nie gwarantuje.
3.Nie oczekuj, że agent prześledzi zależności zależności
Na czym polega: Agent co najwyżej rzuci okiem na instalowany pakiet; nie przejdzie rozgałęzionego łańcucha zależności transytywnych, w których siedzą podatności.
Jak stosować: Przesiewanie drzewa zależności zlecaj narzędziu (skanerowi), nie agentowi — i rób to przed scaleniem każdego pull requesta, automatycznie.
Na co uważać: Liczba gałęzi drzewa rośnie lawinowo z każdym pakietem; ręczne śledzenie nie skaluje się nawet u ludzi, więc tym bardziej nie u modelu.
4.Rejestr CVE przerasta możliwości modelu
Na czym polega: Katalog znanych podatności jest tak duży, że żaden model nie objęty go kontekstem ani nie sprawdzi „caej listy” przy każdym zadaniu.
Jak stosować: Porównywania kodu z rejestrem dokonuj zewnętrznym narzędziem; agentowi zostaw interpretację wyników i naprawę, nie diagnostykę od zera.
Na co uważać: Prompts w stylu „sprawdź, czy kod nie ma luk” nie mają pokrycia w wiedzy modelu o aktualnym stanie rejestru CVE — to działanie na wyczucie.
5.„Obsłużymy w kolejnym zgłoszeniu” to luka wprowadzona do kodu
Na czym polega: Cichy wariant problemu: agent wykrywa podatność, ale nie naprawia jej, tylko odnotowuje w opisie pull requesta — a „kolejne zgłoszenie” może nigdy nie powstać.
Jak stosować: W procesie buduj regułę: nic, co zostało oznaczone jako problem bezpieczeństwa, nie może zostać scalone bez potwierdzonej naprawy albo jawnego, udokumentowanego wyjątku podjętego przez człowieka.
Na co uważać: W splotie codziennej pracy takie uwagi w opisach PR łatwo umykają — jeśli nie masz twardej bramki, nikt ich nie wyłapie.
6.Agent-recenzent wciąż rzuca kośćmi
Na czym polega: Dodanie drugiego agenta do przeglądu to nadal proces probabilistyczny: recenzent może przeoczyć dokładnie te same luki, które umknęły wykonawcy — oba modele mają zbliżone ślepe punkty.
Jak stosować: Recenzenta-agenta traktuj jako wartościową warstwę uzupełniającą (on znajdzie też inne kłopoty z kodem), ale nie jako mechanizm gwarancji bezpieczeństwa.
Na co uważać: Czysty pull request po przeglądzie agenta to opinia, a nie dowód — czyste musi być dopiero po deterministycznym skanie.
7.Skan uruchamiaj skryptem, nie agentem
Na czym polega: Krok weryfikacji ma być powtarzalny, więc w autoreskim rozwiązaniu wywołuje go węzeł bash, czyli zwykły skrypt przez API SonarQube — zero swobody modelu na etapie diagnostyki.
Jak stosować: W swoim procesie oddziel warstwę „sprawdzania” (skrypt, skaner, CI) od warstwy „rozumienia i naprawy” (agent). Pierwsza zawsze zwraca ten sam wynik dla tego samego kodu.
Na co uważać: Jeśli skan odpala agent, wynik zależy od jego uważności w danym dniu — i właśnie tracisz gwarancję, o którą chodzi.
8.Zielone światło jako warunek otwarcia pull requesta
Na czym polega: Bramka działa jak twardy próg: cokolwiek czerwonego — agent wykonawczy wraca do poprawek; dopiero ocena A i zero zgłoszeń pozwalają zakończyć zadanie.
Jak stosować: Ustaw politykę scalania tak, by pull request nie mógł przejść dalej bez pomyślnego skanu (w CI albo w orkiestracji procesu), a przegląd człowieka rób dopiero na czystym, zielonym raporcie.
Na co uważać: Nie przesadzaj z progiem — zbyt surowe bramki blokują pracę i kuszą do ich wyłączania; zaczyna od zerowania podatności krytycznych.
9.Naprawa może zostać agendomska — gwarancję daje pętla
Na czym polega: W opisanym wzorcu sama naprawa nadal należy do agenta (krok probabilistyczny), ale wejścia przychodzą zawsze identycznie, a bramka na końcu potwierdza, że wszystko czerwone rzeczywiście obsłużono.
Jak stosować: Nie próbuj determinizować wszystkiego — wystarczy, że zamykasz pętlę: raport → naprawa → ponowny skan → werdykt. Iteracja trwa do skutku.
Na co uważać: Zabezpiecz się przed pętlą nieskończoną: ustal limit iteracji i regułę eskalacji do człowieka, gdy bramka pozostaje czerwona.
10.Wzorzec jest niezależny od konkretnych narzędzi
Na czym polega: Autor pokazuje rozwiązanie w Arkonie i SonarQube (z którymi wiążą go relacje partnerskie), ale sam podkreśla: wystarczy dowolne narzędzie, które wykona tę samą robotę — skan można też wpiąć bezpośrednio w CI.
Jak stosować: Jeśli nie chcesz zmieniać stacku, przenieś sam schemat do swojego ładu: skan podatności na PR, automatyczne podanie raportu agentowi, ponowna weryfikacja, twardy próg. Autor podrzuca gotowy workflow do przeanalizowania przez własnego agenta.
Na co uważać: Przy rekomendacjach z partnerstwami reklamowymi oceniaj idee, nie marki — sama zasada bramki deterministycznej działa z każdym skanerem podatności.