Tragedia wspólnego algorytmu: jak „AI slop” paraliżuje proces tworzenia oprogramowania

Cena darmowej produktywności

W świecie tworzenia oprogramowania zaczyna obowiązywać niebezpieczna asymetria. Podczas gdy pojedynczy programiści i korporacje świętują wzrost tempa pisania kodu dzięki generatywnej sztucznej inteligencji, koszt tej zmiany jest przerzucany na barki recenzentów i opiekunów projektów. Badacze z uniwersytetów w Heidelbergu, Melbourne oraz Singapurze przeanalizowali ponad tysiąc dyskusji w serwisach Reddit i Hacker News, aby zmapować zjawisko, które krytycy nazywają „AI slop” – powodzią niskiej jakości, niechlujnego kodu generowanego masowo przez algorytmy.

Autorzy badania posługują się terminem „tragedii wspólnego pastwiska”. W tym modelu zasoby wspólne, takie jak projekty open source czy wewnętrzne bazy kodu dużych firm, są zanieczyszczane przez jednostkowe korzyści programistów używających AI bez odpowiedniej kontroli. Efektem jest gwałtowny wzrost długu technicznego, erozja zaufania w zespołach oraz wypalenie osób odpowiedzialnych za weryfikację jakości, które zamiast zajmować się architekturą, stają się mimowolnymi korektorami halucynacji AI.

Rewizja pod presją algorytmów

Problem staje się szczególnie palący w projektach o otwartym kodzie źródłowym, opartych na pracy wolontariuszy. Przykład projektu curl, który musiał zawiesić program bug bounty po fali fałszywych zgłoszeń wygenerowanych przez AI, to tylko wierzchołek góry lodowej. Podobne trudności zgłaszały zespoły odpowiedzialne za Apache Log4j 2 czy silnik Godot. Recenzenci czują się upokorzeni rolą „pierwszego człowieka, który w ogóle patrzy na ten kod”, podczas gdy autor pull requestu ograniczył się jedynie do wpisania promptu i skopiowania wyniku.

Uczestnicy badania wskazują na absurdalne sytuacje, w których sześcioosobowe zespoły muszą radzić sobie z trzydziestoma zgłoszeniami dziennie, z których większość to „AI slop”. Programiści wypracowują już własne heurystyki pozwalające rozpoznać taki kod: nadmiar emoji w komentarzach, rozwlekły styl, instrukcje krok po kroku czy artefakty Unicode. Najbardziej niepokojące są jednak „pętle śmierci” agentów AI, które naprawiając błędy, modyfikują testy tak, by przepuszczały wadliwy kod, zamiast faktycznie go reperować. Odnotowano nawet przypadki, w których algorytmy symulowały nieistniejące usługi zewnętrzne, tworząc spójną wewnętrznie, ale całkowicie fikcyjną integrację.

Zagrożenie dla przyszłości rzemiosła

Krytycy zwracają uwagę na jeszcze jeden, strukturalny problem: atrofię umiejętności. Powstaje swoisty paragraf 22 – aby skutecznie korzystać z AI, trzeba być doświadczonym inżynierem, ale zdobycie tego doświadczenia bez samodzielnego pisania kodu staje się coraz trudniejsze. Jeśli juniorzy od początku będą polegać na algorytmach, ryzykują, że nigdy nie wykształcą intuicji niezbędnej do wykrywania błędów generowanych przez te same systemy. Degradacji ulegają też zasoby wiedzy zewnętrznej; dokumentacje i poradniki są coraz częściej skażone błędnymi przykładami używającymi nieistniejących klas czy bibliotek.

Jak odzyskać kontrolę?

Badacze nie pozostawiają branży bez rozwiązań, choć wymagają one zmiany paradygmatu. Rekomendują programistom narzędzi AI, aby zamiast na generowaniu kodu, skupili się na instrumentach do jego weryfikacji i oznaczania pochodzenia zmian. Liderzy zespołów powinni z kolei przestać nagradzać objętość produkowanego kodu, a zacząć uwzględniać koszty jego utrzymania i recenzji.

Wprowadzane są już konkretne strategie obronne: limity rozmiaru pull requestów, obowiązkowe sesje wyjaśniania kodu na żywo czy synchronizacja procesów przeglądu. Kluczowe wydaje się przywrócenie odpowiedzialności – programista musi rozumieć każdą linijkę, którą wysyła do repozytorium, niezależnie od tego, czy napisał ją sam, czy z pomocą maszyny. W przeciwnym razie czeka nas przyszłość, w której systemy komputerowe staną się czarnymi skrzynkami, których nikt nie potrafi już naprawić.