Kodowanie z AI ma problem jednorękiego bandyty

Kodowanie z wsparciem AI zmieniło pętlę sprzężenia zwrotnego.

Wpisujesz prompt. Wciskasz Enter. Kod się pojawia.

Czasem jest dobry. Czasem jest prawie dobry. Czasem kompiluje się, wygląda rozsądnie — i ukrywa trzy złe decyzje pod czystym interfejsem.

I tutaj zaczyna się problem.

Nie dlatego, że AI pisze zły kod. Ludzie też piszą zły kod.

Problem w tym, że kodowanie z AI może czuć się jak gra na jednorękim bandycie.

Wciskasz Enter. Dostajesz wynik. Wciskasz Enter jeszcze raz. Może tym razem zadziała.

Niebezpieczna nie jest generacja

Generowanie kodu nie jest niebezpieczne.

Niebezpieczne jest, gdy generacja zastępuje zrozumienie.

Widziałem ten wzorzec już wielokrotnie — i szczerze mówiąc, łapię się na nim też sam. Prosimy AI o pomoc, dostajemy odpowiedź, kopiujemy ją i idziemy dalej, zanim w pełni zrozumiemy, co zostało wygenerowane.

Czasem to zmiana w kodzie. Czasem to komentarz w recenzji. Czasem to wyjaśnienie błędu.

Forma się zmienia. Mechanizm porażki pozostaje ten sam.

AI wyprodukowało coś, co wygląda na użyteczne — więc traktujemy to jako gotowe.

Im szybsze narzędzie, tym łatwiej pomylić ruch z postępem.

Narzędzie jest szybkie, pewne siebie i zwykle na tyle dobre, by wydawać się pomocne. Usuwa tarcia z pierwszych 80% zadania.

Ale to ostatnie 20% to tam, gdzie dzieje się prawdziwa inżynieria.

"AI to napisało" nie jest strategią recenzji

Jedna z niewygodnych prawd o narzędziach AI to to, że mogą sprawić, że niskonakładowa praca wygląda na wysokonakładową.

Wygenerowany komentarz brzmi przemyślany. Wygenerowany refactor wygląda czysto. Wygenerowany komponent pasuje wizualnie do projektu.

Z zewnątrz wszystko wygląda OK.

Ale oprogramowanie nie ocenia się tylko po tym, co widać na ekranie.

Funkcjonalność może wyglądać na gotową, a jednocześnie być pełna niepotrzebnego stanu, powielonej logiki, słabych granic, skomplikowanych abstrakcji i skopiowanego boilerplate’u. UI może być piękne, podczas gdy wnętrze cicho zamienia się w spaghetti.

Demo działa. Ekran wygląda dobrze. PR jest zielony.

Ale łatwo przegapić najważniejsze pytanie: Czy ten kod jest utrzymywalny?

"Vibe coding" ma swoje miejsce i czas

Krąży ostatnio narracja: jeśli UI działa, to inżynieria za nim nie ma znaczenia. Wystarczy promptować, aż produkt będzie działał.

Rozumiem pokusę. Demy wyglądają imponująco.

I dla prototypów, eksperymentów i tymczasowych pomysłów ta szybkość jest rzeczywiście przydatna.

Problem zaczyna się, gdy workflow prototypowy staje się workflowem produkcyjnym.

Oto, czego nie pokazują te demy: stan kodu sześć miesięcy później.

"Vibe coding" optymalizuje moment, w którym coś zaczyna działać. Prawdziwa inżynieria optymalizuje moment, w którym ktoś będzie musiał to zmienić za sześć miesięcy.

To nie są te same momenty.

Pierwsze pytanie brzmie: "Czy to działa teraz?" Drugie pytanie brzmie: "Czy następna osoba zrozumie, dlaczego to działa?"

Gdy akceptujemy kod bez zrozumienia, co model wygenerował, funkcjonalność może działać — ale zespół dziedziczy zobowiązanie.

Jeśli nikt nie potrafi wyjaśnić, dlaczego to działa, ani bezpiecznie tego zmienić, to zysk produktywności jest głównie iluzją.

To nie jest nowy sposób na budowanie utrzymywalnego oprogramowania.

To spaghetti z ładnym UI na wierzchu.

Czytanie to nowy wąski gardło

Przed erą AI pisaniem kodu często było wąskim gardłem.

Teraz czytanie nim jest.

Kod pojawia się szybciej, niż jesteśmy w stanie go rzetelnie ocenić. Komentarz pojawia się, zanim w pełni zrozumiemy problem. Refactor pojawia się, zanim sprawdzimy, czy abstrakcja nie istnieje już gdzie indziej w kodzie.

To zmienia naszą odpowiedzialność.

Praca nie polega już tylko na pisaniu kodu. Praca polega na walidacji wyjścia.

Czy to rozwiązuje właściwy problem?
Czy to pasuje do naszej architektury?
Czy byłbym w stanie wyjaśnić to podczas code review?

Jeśli odpowiedź brzmie: "Nie wiem, AI to wygenerowało", to praca nie jest skończona.

AI nie zwalnia z odpowiedzialności

To jest ta część, którą zespoły powinny głośno przyznać:

AI może napisać pierwszą wersję. Nie może wziąć odpowiedzialności za wynik.

Odpowiedzialność zostaje po naszej stronie.

Jeśli wklejam wygenerowany kod do repozytorium, to teraz jest mój kod. Jeśli wklejam wygenerowany komentarz do recenzji, to teraz jest mój komentarz. Jeśli akceptuję wygenerowany refactor, to ja biorę na siebie wprowadzaną złożoność.

"AI mi to dało" wyjaśnia proces. Nie zastępuje recenzji.

To samo dotyczy code review. Jeśli AI w recenzji wychwyci coś przydatnego — świetnie. Jeśli coś oczywistego przeoczy, to nie znaczy, że ludzka recenzja znika z procesu.

AI może zmniejszyć obciążenie recenzji, ale nie powinno zastępować inżynierskiego osądu.

Przynajmniej nie w takim kodzie, który ma być utrzymywany przez lata.

Prawdziwa umiejętność to kalibracja

Dlatego wracam do kalibracji.

Dobre użycie AI nie polega na wciskaniu Enter, aż coś zadziała. Polega na wiedzy, jakiego wyjścia oczekujesz, jakiego poziomu jakości wymagasz i gdzie model prawdopodobnie zawiedzie.

Dla kodu tymczasowego — może "działa" wystarczy. Dla kodu produkcyjnego — nie.

Dla małego skryptu wewnętrznego — może wygenerowany boilerplate jest akceptowalny. Dla współdzielonego komponentu używanego w całej aplikacji — zasługuje na dokładniejsze sprawdzenie.

Dla komentarza w recenzji — brzmienie mądrze to za mało. Musi być poprawny, istotny i rzeczywiście przeczytany przez osobę, która go zamieszcza.

Narzędzie może generować. My musimy kalibrować.

Co staram się robić inaczej

Kiedy używam AI do kodowania, staram się zwolnić w momencie, w którym narzędzie każe mi przyspieszyć.

Po wygenerowaniu kodu czytam go linijka po linijce.

Nie dlatego, że nie ufam AI. Dlatego, że nie ufam żadnemu kodowi, którego nie zrozumiałem.

Zadaję sobie pytania:

Jakie założenia przyjął model?
Co zignorował?
Czy napisałbym to tak samo bez AI?

To ostatnie pytanie jest szczególnie przydatne.

Bo jeśli odpowiedź brzmie: "nie", to potrzebuję bardzo dobrego powodu, żeby to zmergować.

Standard, do którego dążę

Nie chcę, żeby deweloperzy przestali używać AI. To byłoby absurdne.

Chcę czegoś przeciwnego: używajcie jej bardziej świadomie.

Używajcie jej, żeby eksplorować. Używajcie jej, żeby tworzyć szkielety. Używajcie jej, żeby porównywać podejścia. Używajcie jej, żeby weryfikować założenia. Używajcie jej, żeby znajdować edge case’y, które przeoczyliście.

Ale nie zlecajcie jej swojego osądu.

W momencie, gdy wyjście AI trafi do kodu, przestaje być wyjściem AI.

Staje się nasze.

A to oznacza, że musimy je przeczytać.