AI generuje lepszy spam, przez co moderatorzy mają więcej pracy

Przez lata sektor open-source zmagał się z zalewem tzw. AI slop — niskiej jakości, generowanych masowo raportów o błędach, które były łatwe do zidentyfikowania i odrzucenia. Jednak sytuacja uległa drastycznej zmianie. Modele językowe stały się na tyle zaawansowane, że generowane przez nie analizy bezpieczeństwa brzmią profesjonalnie i wiarygodnie, co paradoksalnie staje się największym koszmarem dla programistów utrzymujących kluczowe projekty infrastrukturalne.

Kiedy sztuczna inteligencja wykonuje lwią część pracy przy skanowaniu kodu, ciężar weryfikacji wyników nadal spoczywa na barkach ludzi. Problem polega na tym, że przy rosnącej jakości zgłoszeń, ich liczba drastycznie rośnie, paraliżując pracę zespołów, które muszą ręcznie sprawdzać każdy "prawdopodobny" scenariusz ataku.

Ewolucja od spamu do wiarygodnych raportów

Daniel Stenberg, twórca i lider projektu curl, zauważył istotną zmianę w charakterze otrzymywanych zgłoszeń. W swoim niedawnym wpisie podkreślił, że era prymitywnego spamu AI dobiegła końca. Zamiast oczywistych błędów, projekt otrzymuje teraz coraz większą liczbę niezwykle dopracowanych raportów dotyczących bezpieczeństwa, które niemal w całości są przygotowywane przy użyciu narzędzi AI. Choć brzmi to jak sukces technologii, dla maintainerów oznacza to drastyczny wzrost nakładu pracy.

Zjawisko to nie dotyczy wyłącznie curl. Podobne obserwacje płyną z obozu Linux kernel. Greg Kroah-Hartman, jeden z kluczowych deweloperów jądra Linux, przyznał, że raporty wspierane przez AI zawierają obecnie znacznie mniej "śmieci", a więcej realnych obaw dotyczących architektury kodu. O ile duże zespoły, jak te pracujące nad Linuksem, starają się adaptować do nowej rzeczywistości, o tyle mniejsze projekty open-source zaczynają uginać się pod ciężarem zbyt dobrych, by je zignorować, zgłoszeń.

• Wzrost wiarygodności: Raporty są spójne technicznie i używają profesjonalnej terminologii.
• Szybsza dystrybucja: Automatyzacja pozwala na wysyłanie zgłoszeń niemal natychmiast po wykryciu potencjalnej luki.
• Problem skali: Liczba zgłoszeń rośnie szybciej niż możliwości ich weryfikacji przez ludzi.

Pułapka "prawdopodobnych" błędów

Głównym problemem jest fakt, że nawet jeśli raport jest technicznie poprawny, nie oznacza to automatycznie, że opisuje on krytyczną lukę bezpieczeństwa (CVE). Daniel Stenberg wskazuje na publiczną listę zamkniętych zgłoszeń curl jako dowód: większość spraw zostaje zamknięta, ponieważ zidentyfikowane problemy nie stanowią realnego zagrożenia, które można by wykorzystać w ataku. Często są to kwestie czysto "informacyjne", jak np. data race w bibliotece, który choć wymagał poprawki, nie był błędem krytycznym.

W efekcie maintainerzy marnują godziny na analizę scenariuszy, które AI uznało za ryzykowne, a które w rzeczywistym środowisku mają znikome znaczenie. Jest to klasyczny przykład przenoszenia kosztów — użytkownicy narzędzi AI zyskują na "produktywności", generując masowe zgłoszenia, podczas gdy koszt ich procesowania i weryfikacji zostaje przerzucony na deweloperów pracujących pro bono nad otwartym oprogramowaniem.

Koniec ery nagród za błędy

W obliczu nowej fali zgłoszeń, organizacje zaczynają wycofywać zachęty finansowe, które wcześniej stymulowały społeczność do poszukiwania luk. Internet Bug Bounty ogłosił wstrzymanie wypłat nagród pieniężnych z końcem marca 2026 roku, co dotknęło m.in. program Node.js. Decyzja ta wynika z naruszenia równowagi między tempem odkrywania podatności a zdolnością projektów open-source do ich naprawiania.

„Krajobraz odkrywania błędów się zmienia. Badania wspomagane przez AI zwiększają zasięg i szybkość wykrywania luk w całym ekosystemie. Odpowiedzialność wobec społeczności wymaga od nas ponownego rozważenia struktury zachęt” – czytamy w oświadczeniu Internet Bug Bounty.

Sam Stenberg już wcześniej przestał wypłacać nagrody za zgłoszenia w projekcie curl. Celem było wyeliminowanie motywacji finansowej dla osób, które używają systemów zautomatyzowanych do masowego wysyłania niezweryfikowanych raportów, licząc na łatwy zysk przy minimalnym nakładzie pracy własnej.

Nowe zasady gry w świecie LLM

Deweloperzy tacy jak Willy Tarreau z zespołu jądra Linux sugerują, że nadszedł czas na radykalną zmianę zasad raportowania błędów. Skoro autorzy zgłoszeń dysponują potężnymi modelami LLM, powinni zostać zobligowani do wykonania większej części pracy analitycznej, zanim wyślą raport do maintainera. Proponowane zmiany mają na celu zmniejszenie narzutu związanego z tzw. triage, czyli wstępną selekcją i klasyfikacją błędów.

Wizja programisty jako "10x dewelopera" dzięki AI ma swoją ciemną stronę — to także "10x więcej sprzątania". Jeśli narzędzia AI nie zaczną brać na siebie również odpowiedzialności za weryfikację i dowodzenie realnego wpływu błędu na bezpieczeństwo, model open-source może stanąć w obliczu kryzysu wydolnościowego. Produktywność zyskana na etapie pisania kodu zostanie całkowicie skonsumowana przez nieskończony proces recenzji generowanych masowo treści.

Współczesna sztuczna inteligencja nie zwiększa kompetencji człowieka w pętli decyzyjnej, a jedynie przyspiesza procesy, które i tak wymagają ludzkiego zatwierdzenia. Branża musi wypracować nowe standardy filtrowania treści, w których to AI będzie pomagać maintainerom w odsiewaniu ziarna od technicznego plewu, zamiast tylko zasypywać ich coraz lepiej napisanymi, ale wciąż zbędnymi analizami.