Dlaczego AI nie sprawdzi własnego kodu dobrze?

Wszystko się zmieniło, ale nie to, co najważniejsze

Jeszcze kilka lat temu wąskim gardłem w programowaniu było samo pisanie kodu. Dziś jest nim czytanie, zrozumienie systemu oraz branie odpowiedzialności. Duże modele językowe generują setki linii w kilkanaście sekund. Żaden zespół nie jest w stanie przeczytać i zrozumieć tego kodu w tym samym tempie, w jakim powstaje.

Ta szybkość ma swoją cenę. Generowanie kodu przez LLM wiąże się z pewną nieprzewidywalnością efektu końcowego. Model nie „wie”, że rozwiązanie jest poprawne, on ocenia, że jest prawdopodobne. A jakość oprogramowania nie może być zmienna. System bankowy, kalendarz, sklep internetowy albo aplikacja do zamawiania posiłków działa poprawnie albo nie.

I tu pojawia się kuszący skrót: skoro nie zdążymy przeczytać kodu, niech AI napisze też testy. Zielony build, dwie sekundy, gotowe.

Pułapka powierzchownego nadzorcy

To jest sedno problemu. Kiedy cykl „prompt -> wynik” dzieje się zbyt szybko, człowiek przestaje być aktywnym uczestnikiem, a staje się powierzchownym nadzorcą. Nadzorowanie nie angażuje naszych procesów poznawczych. Patrzymy na zielony build i kiwamy głową. Działa - no to lecimy dalej.

Jeśli człowiek tylko akceptuje wyniki, nie buduje własnego zrozumienia systemu. A bez zrozumienia nie zadamy pytania, które naprawdę ma znaczenie: Czy to robi to, co myślę, że robi?

Gdzie człowiek jest niezastąpiony?

Jeśli AI pisze kod, a AI nie powinno samo go testować, to co zostaje dla człowieka? Trzy rzeczy, których model nie zrobi za Nas dobrze.

Definiowanie fundamentalnych własności

Nie „dla tego przykładu”, ale „dla wszystkich możliwych przypadków”. Użytkownik nigdy nie widzi stack trace. Każdy element posortowanej listy jest mniejszy lub równy następnemu. Suma pieniędzy po przelewie między kontami się nie zmienia. Jedna osoba nie może być na dwóch spotkaniach jednocześnie. Takie inwarianty wynikają ze zrozumienia systemu, a nie ze składni. Badanie z konferencji FSE 2025 pokazało, że modele potrafią wyekstrahować poprawne własności w około 76 procentach przypadków, a kod zgodny z nimi generują w około 52 procentach. To za mało, żeby oddać ten krok maszynie. Nie możemy liczyć, że raz co się uda, a następny przypadek w innych warunkach już nie.

Rozumienie kontrprzykładów

Wyobraźmy sobie, że AI napisało funkcję liczącą cenę koszyka po zastosowaniu kodu rabatowego. Kody mogą być procentowe („-20%”) albo kwotowe („-30 zł”). Model dopisał też testy przykładowe: koszyk za 100 zł z kodem -20% daje 80 zł, koszyk za 100 zł z kodem -30 zł daje 70 zł. Oba przechodzą. Zielony build. W dobie pracy z AI moglibyśmy stwierdzić, że skoro wszystko działa, testy przechodzą to nie ma potrzeby dalszej weryfikacji, ale czy na pewno?
Osoba znająca system oraz założenia może obalić Naszą pewność o poprawności jednym prostym założeniem: „Cena po rabacie nigdy nie jest niższa niż zero i nigdy nie jest wyższa niż cena przed rabatem.”
Najprostszy surowy przykład, którego w żaden sposób AI nie założyło:

• koszyk: jeden produkt za 15 zł

• kod rabatowy: - 30 zł

• wynik funkcji: - 15 zł

Teraz błąd widzi każdy. Funkcja odejmuje kwotę rabatu od sumy koszyka i nie sprawdza, czy rabat nie jest większy niż sam koszyk. Klient z takim kodem dostałby ujemną cenę, a w zależności od dalszej logiki albo błąd płatności, albo, co gorsza, zwrot pieniędzy za zakup.

Dlaczego model tego nie sprawdził ani w kodzie, ani w testach? Bo w jego „wyobrażeniu” zadania kod rabatowy zawsze był mniejszy niż koszyk. W treści promptu nikt tego nie napisał, ale nikt też nie napisał, że może być inaczej. Ten sam brak w modelu trafił do implementacji i do testów jednocześnie. Ten sam błąd dwa razy.

Kontrprzykład robi tu coś więcej niż wskazanie jednej linii do poprawy. Zmusza do pytania: a co jeszcze może być „większe niż zakładałem”? Rabat procentowy powyżej 100%? Dwa kody użyte jednocześnie? Rabat naliczany na koszyk, z którego klient w międzyczasie usunął produkty? Z jednego kontrprzykładu wynikają trzy kolejne własności do sprawdzenia, a z nich prawdopodobnie kolejne kontrprzykłady. Każda taka pętla pogłębia rozumienie systemu, którego wcześniej nie mieliśmy, mimo że kod „działał”.

Rozwiązywanie problemu, nie samo pisanie kodu

Pisanie kodu to tylko jedna część inżynierii. Zrozumienie problemu, wyznaczenie granic poprawności i weryfikacja, czy system ich nie przekracza, to część, która nie tanieje. Przez lata te dwie rzeczy były sklejone, bo ten sam człowiek robił obie i często odkrywał decyzję do podjęcia dopiero w trakcie pisania. AI je rozkleiło. Weźmy kod rabatowy jako przykład. Programista, który rozumie moduł rabatów, nie musi otwierać kodu, żeby odpowiedzieć: „co się stanie, gdy klient użyje dwóch kodów naraz?”. Gdy usunie produkt z koszyka po wpisaniu kodu? Gdy kod wygaśnie między dodaniem do koszyka a płatnością? Zna odpowiedzi nie dlatego, że pamięta każdą linijkę na pamięć, ale dlatego, że ma w głowie model tego, jak rabaty działają: jakie są ich rodzaje, w którym momencie są naliczane, co ma pierwszeństwo, gdzie są granice.

Rozumienie nie skaluje się z kodem

I tu tkwi zasadniczy problem ery AI. Kod można dziś produkować w tempie, z którym żaden człowiek nie nadąży. Rozumienie powstaje w tempie ludzkiego myślenia i nie da się go przyspieszyć promptem. Każdy wygenerowany moduł, którego nikt w zespole nie rozumie, to dług: system działa, ale nikt nie umie przewidzieć, kiedy przestanie i dlaczego. Ten dług nie widnieje w żadnym narzędziu do mierzenia jakości kodu. Ujawnia się dopiero przy awarii, przy zmianie wymagań albo przy odejściu jedynej osoby, która „coś tam pamiętała”. Nie chodzi o czytanie każdej linijki, bo to niewykonalne. Chodzi o to, by w procesie były miejsca, w których człowiek musi sformułować, co system ma robić, przewidzieć, jak się zachowa, i skonfrontować to z rzeczywistością. Własności, rozumienie problemu i kontrprzykłady są narzędziami do tworzenia takich miejsc. Ale narzędzie jest wtórne. Pierwotny jest cel: Zespół musi wiedzieć, jak działa to, co oddaje klientowi - i to wartość która przyświeca naszej działalności.