Nie ufamy kodowi wygenerowanemu przez AI. I nawet go nie czytamy.

Kilka tygodni temu zacommitowałem kod, którego nie przeczytałem.

Nie chodzi o to, że zerknąłem na diff i zaufałem. Ani że przeczytałem, a umknęła mi jedna linijka. Chodzi o coś prostszego: opisałem, czego chcę, patrzyłem, jak pojawia się kilkaset linijek, przewinąłem na sam dół, zobaczyłem, że wygląda sensownie — porządne nazwy, spójny styl, nic, co by kłuło w oczy — i kliknąłem commit. Testy zielone. Wyglądał na przejrzany. Więc uznałem, że skoro wygląda na przejrzany, to jest, i poszedłem dalej.

Kiedy później do mnie dotarło, co zrobiłem, pierwsza była wina. Ta dobrze znana: przecież wiesz lepiej, budujesz systemy do review, a przyklepałeś własny output jak junior na deadline'ie.

Tylko że tę winę odłożyłem na bok, bo to była zła reakcja. Brała sygnał i robiła z niego osobistą wpadkę. A kiedy przestałem czytać to jako wstyd i zacząłem czytać jako dane, zrobiło się znacznie ciekawiej.

Ten paradoks nie jest mój

Skąd wiem, że to nie był po prostu słabszy dzień?

Jedno z ostatnich badań ujęło to bez owijania: 95% programistów deklaruje, że nie ufa kodowi generowanemu przez AI — a tylko 48% regularnie sprawdza go przed wdrożeniem. Najnowsze dane Stack Overflow idą w tę samą stronę: brak zaufania do outputu AI urósł z 31% do 46% w rok, mimo że adopcja przebiła 84%.

Przeczytaj to jeszcze raz. Nie ufamy temu kodowi. Używamy go mimo to. A potem nie czytamy czegoś, czemu nie ufamy.

To nie jest sprzeczność, w którą wpadł jeden zmęczony gość po południu. To cała branża robiąca naraz tę samą, niby-irracjonalną rzecz. A kiedy wszyscy niezależnie lądują w tym samym złym miejscu, "wszystkim brakuje dyscypliny" prawie nigdy nie jest właściwą odpowiedzią. To zła warstwa. Zachowanie jest objawem. Coś pod spodem się ruszyło, a nasze nawyki wciąż stoją tam, gdzie kiedyś był grunt.

Co się tak naprawdę ruszyło

Przez większość historii tego zawodu pisanie kodu było robotą. Było też, po cichu, źródłem zaufania. Nie ufałeś funkcji dlatego, że potem ją sprawdziłeś. Ufałeś jej, bo napisałeś ją linijka po linijce, z całością w głowie, kiedy powstawała. Zrozumienie przychodziło gratis, razem z pisaniem. Nie dało się tego napisać, nie rozumiejąc.

Generowanie zbiło koszt tworzenia kodu praktycznie do zera. A kiedy koszt produkcji czegoś leci na łeb, wartościowa część nie znika — zjeżdża w dół procesu. Z pisania na czytanie, ocenę, decyzję. Z klepania linijek na rozstrzyganie, czy te linijki w ogóle mają prawo istnieć.

Dlatego luka między "nie ufam temu" a "nie przeczytałem tego" to nie wpadka. To dokładnie tak wygląda, kiedy robota przesuwa się szybciej niż nawyki. Praca jest teraz niżej, a my dalej stoimy wyżej, tam, gdzie kiedyś było pisanie, i dziwimy się, czemu stary odruch — skoro to zrobiłem, to wiem, co tam siedzi — już nie zaskakuje.

Nie zaskakuje, bo tego nie zrobiliśmy. Zamówiliśmy.

Czytanie jest trudniejsze, niż pisanie kiedykolwiek było

Niewygodne jest to, że nowy środek ciężkości tej roboty jest realnie trudniejszy od starego — i kompletnie tak nie wygląda. Cztery powody, dla których to boli:

Pisanie dawało zaufanie gratis. Czytanie nie daje. Kiedy coś pisałeś, zrozumienie szło w pakiecie z budowaniem, bez dopłaty. Czytanie ten pakiet rozbija. Możesz przeczytać funkcję do końca i dalej nie czuć jej tak, jak czułbyś coś, co sam zbudowałeś. Więc mózg, całkiem rozsądnie, szuka skrótu.

Kod z AI wygląda, jakby ktoś go już przejrzał. I to ta pułapka mnie wzięła. Wygenerowany kod przychodzi gładki: ładne nazwy, równa struktura, zero literówek — faktura kodu, który ktoś staranny już posprzątał. Wizualna gładkość podszywa się pod poprawność. Po kodzie pisanym ręcznie zwykle widać wahanie — niedokończona nazwa, dziwne wcięcie, komentarz w stylu ogarnąć to. Kod z AI ma gładką fasadę, a za nią nieznane. Wygląda na skończony, więc "wygląda na sprawdzony" bierzemy za "sprawdzony".

Gęsty, obcy i prawdopodobnie poprawny kod to najgorsze, co można dostać do czytania. Review kodu, który najpewniej jest okej, ale czasem subtelnie się myli, męczy bardziej niż napisanie go od zera — i jest dużo nudniejsze. Pisanie staniało. Czytanie kosztuje dokładnie tyle, ile zawsze. Płacimy uwagą po starych cenach za zadanie, które robimy teraz dziesięć razy częściej.

Szybkość zabija uwagę. Działa tu prosta odwrotna zależność: im szybciej kod się pojawia, tym mniej siebie dajesz każdej linijce. Funkcja, którą pisałeś godzinę, dostaje uczciwą uwagę. Funkcja wygenerowana w dziewięć sekund dostaje dziewięć sekund rzutu oka. Tempo podaży ustawia budżet uwagi. I na razie tempo podaży wygrywa.

Żaden z tych powodów nie jest wadą charakteru. To właściwości nowego terenu. I o to właśnie chodzi — terenu nie ogarnia się silną wolą.

Dług, którego nikt nie wziął świadomie

Pisałem już o tym, jak ten kod powstaje — o slot-machine'owej pętli: generuj, zerknij, zaakceptuj, powtórz. To druga połowa tej historii: co po niej zostaje.

Klasyczny dług techniczny to decyzja. Ktoś zobaczył skrót, zrozumiał koszt i wziął go świadomie — wiem, że to hack, wrócę do tego w Q3. Jest autor, jest intencja, jest nitka, za którą da się pociągnąć.

To, co narasta, kiedy wdrażamy nieprzeczytany kod, jest czymś innym. Nazwijmy to długiem zrozumienia. Kod działa, testy przeszły, produkcja go przyjęła — a nikt w zespole tak naprawdę go nie rozumie, łącznie z osobą, której nick wisi przy commicie. Nie ma kogo zapytać "dlaczego tak?", bo nikt nie podjął decyzji "tak". To po prostu wsiąkło. To nie skrót, który ktoś wybrał — to dziura, której nikt nie zauważył, kiedy się otwierała.

Dług techniczny da się spłacać, bo zwykle ktoś wie, co i dlaczego. Dług zrozumienia trzeba odtworzyć — reverse-engineerować własne repo tak, jakby napisał je ktoś obcy. Bo w pewnym sensie napisał.

Czytanie jest teraz rzemiosłem. I tak je traktuj.

Tę część zostawiam na koniec, bo diagnoza bez wyjścia to tylko marudzenie z przypisami.

Skoro wartościowy ruch przesunął się na czytanie, to czytanie przestaje być nudnym podatkiem, który płacisz po "właściwej robocie", i samo staje się właściwą robotą. To nie strata. To umiejętność, której nigdy porządnie nie nazwaliśmy, a która właśnie wyszła na pierwszy plan. Kilka rzeczy, które u mnie realnie zadziałały:

Czytaj to jak PR od kogoś obcego — bo nim jest. Najwięcej dało mi porzucenie fikcji, że wygenerowany kod jest "mój". Nie jest. Nie napisałem go — zamówiłem. Review z taką podejrzliwością, z jaką podszedłbyś do pierwszego PR-a od nieznanego kontrybutora, to nie paranoja. To po prostu adekwatne.

Zrób test "wytłumacz to na głos". Zanim kod, który wygenerowałem, wejdzie do repo, zmuszam się, żeby powiedzieć na głos, co robi i dlaczego akurat tak. Nie happy path — edge case, założenie, które przyjmuje, i powód, dla którego to podejście, a nie oczywista alternatywa. Jak się zacinam, kod nie jest gotowy. To zacięcie to dług zrozumienia, który odzywa się przed wdrożeniem zamiast pół roku później.

Zwalniaj proporcjonalnie do tego, jak szybko kod powstał. Brzmi kontrintuicyjnie, działa. Im szybsze generowanie, tym bardziej świadome czytanie. Szybkość na wejściu jest właśnie powodem, dla którego potrzebujesz tarcia na wyjściu. To się nie gryzie — jedno jest ceną drugiego.

Trenuj ten mięsień na poważnie. Dobre czytanie kodu da się wyćwiczyć, a większość z nas przez dekadę ćwiczyła umiejętność odwrotną. Warto robić prawdziwe powtórki: czytać kod, którego nie napisałeś, i odtwarzać intencję autora — tak jak ćwiczy się wszystko, w czym chce się być dobrym, zamiast liczyć, że samo zaskoczy, kiedy będzie trzeba.

W swoim setupie część tej warstwy czytania automatyzuję, ale to temat na osobny tekst — i to dodatek do nawyku, nie jego zamiennik. Żaden system nie przeczyta za ciebie kodu, za który to ty odpowiadasz.

Umiejętność, która po cichu stała się robotą

Optymistyczna narracja tej ery brzmi: kto wyprodukuje najwięcej i najszybciej. Katastroficzna brzmi: kto najgłośniej nie ufa maszynie. Obie mijają się z sednem.

Tej fazy nie wygra najszybszy piszący. Nie wygra jej też najbardziej teatralny sceptyk. Wygra ją ten, kto odbuduje czytanie w świadome rzemiosło, kiedy reszta wciąż dopieszcza tę część roboty, którą właśnie zautomatyzowano.

Nie ufamy kodowi z AI. I dobrze — ten odruch jest słuszny. Teraz trzeba zasłużyć na tę nieufność jedynym sposobem, jaki istnieje:

naprawdę przeczytać to, co mamy przed sobą.