# Szybkość mija. Złożoność zostaje.

> Trzy niezależne badania, trzy różne metody — celowane badanie podatności, kontrolowane porównanie człowiek–model i rok obserwacji prawdziwych repozytoriów — zbiegają się w tym samym ustaleniu: kod generowany przez AI niesie mierzalny koszt jakościowy, który przeżywa zysk produktywności, z którym przyszedł.

Source: https://counterproof.io/pl/notes/szybkosc-mija-zlozonosc-zostaje/ · Published 25 August 2026 · CounterProof jest praktyką Clavestra Capital Limited (Malta, C 113987).


„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*](https://counterproof.io/notes/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*](https://counterproof.io/notes/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](https://research.counterproof.io/) (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.*