„AI pisze kod szybciej" nie podlega sporowi. Czy pisze kod gorzej, to osobne, empiryczne pytanie — i wolimy odpowiadać na nie pomiarami niż sloganami którejkolwiek ze stron. Trzy niezależne badania, trzema różnymi metodami, zbiegają się w tej samej odpowiedzi.
Punkt wyjścia: udokumentowany wskaźnik defektów
Badanie założycielskie omawiamy szczegółowo w A Clean Benchmark Is Not a Clean Codebase (po angielsku): Pearce i in. (IEEE S&P 2022) stwierdzili, że około 40 % z 1 689 programów wygenerowanych przez Copilota było podatnych na klasy słabości z listy Top 25 MITRE. Badanie jest już na tyle stare, że jego liczby nie należy czytać jako aktualnej — modele zmieniły się od 2022 roku. Co ustaliło i na czym buduje późniejsza praca: pytanie jest realne i można na nie odpowiedzieć standardowymi metodami — celowane scenariusze, duża próba, analiza statyczna względem nazwanej listy słabości.
Mechanizm: nie losowe błędy, lecz systematyczny brak
Sama liczba nie mówi, co robić. Kontrolowane porównanie kodu pisanego przez ludzi i generowanego przez LLM — struktury danych, algorytmy, procedury kryptograficzne i zadania w stylu LeetCode, z testami jednostkowymi, fuzzingiem i analizą statyczną (arXiv:2409.19182) — poszło dalej i znalazło to: kod generowany przez LLM jest mniej bezpieczny przede wszystkim dlatego, że brakuje mu konstrukcji programowania defensywnego — kontroli zakresów i walidacji wejścia, które staranny inżynier dodaje z nawyku, a nie funkcji, o którą faktycznie proszono. Właśnie ten brak zaprasza przepełnienia bufora i przekroczenia zakresu liczb całkowitych. Pod fuzzingiem kod generowany przez LLM był bardziej podatny na zawieszenia i awarie niż pisany przez ludzi punkt odniesienia. Błędy poprawności bywały subtelne, nie oczywiste: w jednym przypadku model wytworzył błędną implementację SHA-1, która mimo to kompilowała się czysto — błędna, i milcząca w tej sprawie.
Ustalenie, które powinno niepokoić każdego, kto uważa „poproś model, żeby to naprawił" za siatkę bezpieczeństwa: to samo badanie zbudowało pętlę zwrotną, prosząc model o ponowne wygenerowanie kodu i usunięcie właśnie pokazanych problemów. Nie działało to niezawodnie. W części przypadków poprawka się udawała. W innych „naprawiony" kod zawierał nowe problemy — a bywało, że sam akt promptowania wnosił problemy do plików, które wcześniej były czyste. Pozwolić autorowi oceniać własną pracę domową to nie jest przegląd.
Dowód z produkcji: koszt nie mija wraz z nowością
Najświeższy dowód pochodzi całkowicie spoza laboratorium. Badanie śledziło 807 repozytoriów open source na GitHubie, które wdrożyły asystenta kodowania Cursor między styczniem 2024 a marcem 2025 r., względem grupy kontrolnej 1 380 porównywalnych repozytoriów bez niego — z SonarQube jako narzędziem pomiaru ostrzeżeń analizy statycznej, duplikacji i złożoności, aż do sierpnia 2025 r. Historia produktywności potoczyła się zgodnie z oczekiwaniami: krótkotrwały skok commitów i dodanych linii w pierwszych jednym–dwóch miesiącach, powrót do linii bazowej w trzecim. Koszt jakościowy z nim nie minął. Ostrzeżenia analizy statycznej wzrosły po wdrożeniu o około 30 % i pozostały podwyższone. Złożoność kodu wzrosła o ponad 40 % — bardziej, niż wyjaśniłby sam wzrost bazy kodu. Zysk szybkości był przejściowy. Dług nie.
Uczciwa granica
To nie jest twierdzenie, że kod generowany przez AI jest zawsze gorszy, jako prawo ogólne. Zadanie, model i sposób pracy — wszystko ma znaczenie, a zespół traktujący wynik AI jako pierwszy szkic zasługujący na tę samą dyscyplinę przeglądu co pull request młodszego inżyniera widzi inne wyniki niż zespół wysyłający go bez przeglądu. Powyższe badania nie testują każdego modelu ani każdego sposobu pracy i żadne nie izoluje dyscypliny przeglądu jako zmiennej. Co ustalają konsekwentnie, trzema niezależnymi metodami (celowane testy CWE, kontrolowane porównanie, podłużne dane produkcyjne): efekt jest realny i systematyczny, a nie okazjonalny — i proszenie modelu o sprawdzenie własnej pracy nie zastępuje tego, żeby zrobił to ktoś inny.
Dlaczego to kwestia zgodności, nie tylko inżynierii
Na mocy Cyber Resilience Act producent musi zapewnić, że produkty z elementami cyfrowymi „należy projektować, opracowywać i produkować tak, by zapewniały odpowiedni poziom cyberbezpieczeństwa stosownie do ryzyka" i że „są udostępniane bez żadnych znanych i możliwych do wykorzystania podatności" (rozporządzenie (UE) 2024/2847, załącznik I część I pkt 1 i pkt 2 lit. a). Żadna z tych klauzul nie wspomina, jak kod został napisany. Obie stają się trudniejsze, nie łatwiejsze, do spełnienia, im więcej powierzchni bazy kodu wytworzył proces ze zmierzonym, systematycznym brakiem dokładnie w tych konstrukcjach — kontrolach zakresów, walidacji wejścia — które nie pozwalają znanej klasie słabości stać się możliwą do wykorzystania. Szybsze generowanie bez odpowiednio większego przeglądu nie jest skrótem wokół tego obowiązku. Jest rosnącym dystansem do niego.
Dlaczego nas to obchodzi
W CounterProof praktykujemy adwersaryjny przegląd kodu pisanego przez maszyny, a te trzy badania opisują dokładnie tę lukę, do której zamykania nasza praktyka istnieje: traktowanie wyniku AI — tego, który generuje, i tego, który przegląda — jako twierdzenia do sprawdzenia, nie wyniku do zaufania. Zob. tekst siostrzany A Clean Benchmark Is Not a Clean Codebase (po angielsku) o tym, co się dzieje, gdy narzędzie sprawdzające też jest oparte na AI, a jego własna niezawodność pozostaje niezbadana. Dłuższy wywód, łącznie z warunkową formą każdego twierdzenia powyżej, znajduje się w naszym dokumencie roboczym o kolacjonowaniu i proweniencji tekstu generowanego przez maszyny, czytelnym w całości tutaj (po angielsku). To szkic preprintu, bez recenzji naukowej, i mówi to wprost.
Źródła cytowane powyżej zweryfikowano względem opublikowanych streszczeń. Liczba Pearce’a i in. pochodzi z IEEE S&P 2022 i opisuje Copilota z czasu tamtego badania, nie obecne modele. Liczby dotyczące Cursora pochodzą z badania podłużnego 807 repozytoriów względem grupy kontrolnej 1 380, śledzonych od stycznia 2024 do sierpnia 2025 r. Cytowane przepisy CRA odsyłają do rozporządzenia (UE) 2024/2847 i zweryfikowano je względem oficjalnej polskiej wersji językowej. Ta strona jest tłumaczeniem angielskiego oryginału; w razie rozbieżności rozstrzyga oryginał. Jeśli coś tu jest błędne, poprawimy to na piśmie na tej stronie.