Czym jest AI slop i jak go naprawić

„AI slop” to kod, który asystent generuje tak, że się kompiluje, przechodzi pobieżne spojrzenie i czyta się wiarygodnie, ale pod spodem jest błędny. Nie psuje się tak, żeby było to widać na demie. Psuje się później, na produkcji, kiedy w końcu wykona się ścieżka, której nikt nie przetestował. Nazwa brzmi lekceważąco, ale problem jest realny i konkretny, a jego naprawa polega bardziej na czytaniu niż na przepisywaniu.

Jak to naprawdę wygląda

Slop ma rozpoznawalny kształt, kiedy już znasz sygnały:

• Zduplikowana logika. Ta sama walidacja albo to samo pobierz-i-zmapuj pojawia się w pięciu miejscach z drobnymi różnicami, bo model wygenerował to od nowa, zamiast użyć ponownie.
• Nadmiarowa asekuracja. try/catch wokół wszystkiego i sprawdzanie null tam, gdzie null wystąpić nie może. To ukrywa prawdziwą awarię, zamiast ją obsłużyć, więc błąd wychodzi daleko od swojej przyczyny.
• Obejścia typów. Rzutowania na any, as unknown as, # type: ignore. Typy się skompilowały, bo model je wyciszył, a nie dlatego, że się zgadzają.
• Testy, które kopiują kod. Sprawdzają, że funkcja robi to, co robi jej ciało, linijka po linijce, więc przechodzą zawsze i nie wyłapują niczego. Prawdziwy test sprawdza wynik, na którym zależy użytkownikowi.
• Komentarze narracyjne. Komentarz przy każdej linii, powtarzający kod. Objętość, nie treść.
• Sekrety i konfiguracja w kodzie. Klucze API, dane połączenia i magiczne stałe wklejone wprost do źródła.

Dlaczego tak się dzieje

Asystent dopisuje najbardziej prawdopodobne kolejne tokeny do promptu, który ma przed sobą. Nie pamięta twojej architektury, nie ma interesu w tym, żeby system przetrwał rok, i nie widzi pozostałych dwudziestu plików. Optymalizuje dokładnie pod „wygląda wiarygodnie”, a „wygląda wiarygodnie” to właśnie definicja slopu. Nic z tego nie jest powodem, żeby przestać pisać kod z AI. To powód, żeby między asystentem a produkcją postawić krok weryfikacji, czyli ten, który został pominięty.

Jak go znaleźć, zanim zaszkodzi

Nie musisz czytać każdej linii. Musisz uruchomić kontrole, które model pominął, i zajrzeć tam, gdzie nie zajrzał żaden człowiek:

• Uruchom linter, kontrolę typów w trybie strict i audyt zależności. Każde z nich w kilka sekund wyciąga inną kategorię slopu.
• Otwórz testy i zapytaj, czy którykolwiek z nich padłby, gdyby funkcja po cichu się zepsuła. Jeśli nie, masz teatr pokrycia, a nie pokrycie.
• Zrób grep po oczywistych słowach kluczowych: any, szerokie except, klucze w kodzie, TODO, FIXME.
• Znajdź pliki, które rosły najszybciej i których dotykał tylko asystent. Tam gęstość jest największa.

Jak naprawiać, w tej kolejności

Cała sztuka jest w kolejności. Przepisywanie, zanim zrozumiesz, tylko pogarsza sprawę.

1. Najpierw czytaj, potem przepisuj. Zmapuj, co kod naprawdę robi i gdzie są prawdziwe szwy. Nie zmienisz bezpiecznie tego, czego nie rozumiesz.
2. Dodaj testy, które sprawdzają zachowanie. Zanim coś zmienisz, upewnij się, że masz testy opisujące oczekiwane zachowanie. Jeśli ich nie ma, zacznij od ich napisania.
3. Wyznacz granice. Rozdziel sklejoną masę na moduły z jasnym wejściem i wyjściem, żeby zmiana w jednym miejscu przestała rozlewać się na pięć innych.
4. Najpierw wyeliminuj oczywiste ryzyka. Wyciągnij sekrety z repozytorium i jego historii oraz wymuś autoryzację na poziomie API, a nie tylko na froncie.
5. Mierz. Wstaw analizę statyczną i testy do CI, żeby kolejny slop wyłapać na wejściu, a nie na produkcji.

W tej kolejności kod robi się bezpieczniejszy na każdym kroku i agentowi trudniej przemycić pójście na łatwiznę.

Kiedy wezwać profesjonalistę na pomoc

Jeśli kod ma już realnych użytkowników albo masz go zaraz skalować lub zbudować wokół niego zespół, spojrzenie z zewnątrz się zwraca: ten, kto go napisał (albo wypromptował), najpóźniej zauważa, czego brakuje. Krótka, szczera ocena tego, co solidne, co kruche i co ruszyć najpierw, zamienia „działa u mnie” w plan, na którym można polegać.

Tym właśnie jest Przegląd. Wychodzisz z niego z pisemnym obrazem kodu i wyceną reszty, a co dalej, decydujesz ty.