AI w kodzie: gdy automatyzacja staje się pułapką

W zeszłym tygodniu patrzyłem, jak kolega odpala npm test na pull requeście, który został „wysłany" przez asystenta AI. Testy nie tylko nie przeszły — zawiodły spektakularnie, z błędami, przy których nawet junior developer by się zaczerwienił. Brak kluczy API. Endpointy zwracające JSON w zupełnie złym formacie. Middleware autoryzacyjny, który nie autoryzował niczego.

Commit brzmiał: "Zaimplementowano flow autentykacji użytkowników 🍕"

Ta emoji z pizzą powinna była być naszym pierwszym ostrzeżeniem.

To nie jest historia o tym, że AI jest złe. Generowanie kodu przez AI naprawdę usprawniło moją pracę na wiele sposobów. To historia o niebezpiecznym złudzeniu kompetencji — niezręcznej dolinie pewnego siebie outputu AI, który wygląda tak dopracowanie, że nikt nie myśli, żeby go zakwestionować, aż produkcja pada o 2 w nocy.

Problem asystenta-godzika

Oto co nikt o tym nie mówi: asystenci kodowania AI to ostateczni pochlebcy. Nie odpychają. Nie zadają pytań wyjaśniających o 3 w nocy, kiedy to ty powinieneś był je sobie zadać wcześniej. Generują to, o co poprosiłeś — lub to, co, jak im się wydaje, chciałeś powiedzieć — z nieuzasadnioną pewnością siebie absolwenta konsultingu.

Twój senior developer, który mógłby powiedzieć „właściwie, to zły pomysł, ponieważ..." — ta osoba nie istnieje w twoim IDE. Jest tylko ty, silnik autouzupełniania i 10 000 linii kodu, które „wyglądają dobrze", dopóki nie spróbujesz to faktycznie uruchomić.

To jest pułapka. Najłatwiejsza ścieżka to zawsze akceptowanie sugestii AI. I jak każdy mięsień, którego nie ćwiczysz, zdolność oceny decyzji architektonicznych zanika po cichu, aż uświadamiasz sobie, że miesiącami zatwierdzałeś zły kod.

Deficyt testowania

Oto statystyka, która powinna zaniepokoić każdego managera: badania sugerują, że deweloperzy spędzają mniej niż 20% czasu na faktycznym testowaniu tego, co budują. Teraz dorzuć na to kod generowany przez AI i masz przepis na katastrofę.

Kiedy AI generuje kod, robi to bez uruchamiania go w twoim specyficznym środowisku, z twoim specyficznym stanem bazy danych, przeciwko twoim specyficznym zależnościom zewnętrznym. Kod istnieje w próżni — technicznie poprawny, kontekstowo bankruto.

Rozwiązanie nie polega na tym, żeby przestać używać AI. Rozwiązanie polega na tym, żeby być religijnym wobec prostej zasady: nigdy nie merge'uj kodu, którego nie przetestowałeś osobiście w środowisku lokalnym.

Tak, to wolniejsze. Tak, wygląda jak walka z produktywnością AI. Ale chodzi o to — ta obiecywana 10-krotna poprawa produktywności? To net negative, jeśli wysyłasz bugi szybciej, niż możesz je naprawiać.

Klif kognitywnego odciążania

Pomyśl o asyście AI jak o kalkulatorze w matematyce. Kalkulatory nie sprawiły, że ludzie są gorsi z matmy — uwolniły nas od żmudności, żebyśmy mogli skupić się na pojęciach wyższego rzędu. Ale jeśli nigdy nie nauczyłeś się dzielenia pisemnego, nie zrozumiesz, co kalkulator tak naprawdę robi, kiedy daje ci odpowiedź.

To samo dotyczy tworzenia oprogramowania. Jeśli pozwolisz AI obsłużyć „nudne części" bez zrozumienia, co te części robią, w końcu dojdziesz do punktu, w którym nie będziesz w stanie ocenić, czy output AI jest poprawny. Bierzesz słowo maszyny za wszystko, co jest tak samo mądre, jak pozwolić samochodowi jechać samemu przez strefę budowy bez patrzenia na drogę.

To nie jest o zachowywaniu programowania jako rzemiosła dla purystów. Chodzi o utrzymanie zdolności łapania katastrofalnych błędów, zanim dotrą do użytkowników.

Znajdowanie równowagi

Nie jestem przeciwko AI. W NameOcean nasza platforma Vibe Hosting korzysta z AI, żeby pomóc deweloperom wysyłać szybciej. Te narzędzia są niesamowite, kiedy służą jako wzmacniacze ludzkiego osądu, nie zastępniki.

Zdrowa relacja z AI kodowaniem wygląda tak:

• Używaj AI do generowania boilerplate'u, scaffoldu i pierwszych szkiców
• Używaj AI do eksplorowania nieznanych API i dokumentacji
• Nigdy nie używaj AI jako substytutu zrozumienia własnego codebase'u
• Zawsze testuj to, co AI wyprodukuje, zanim dotknie produkcji
• Traktuj sugestie AI jak feedback od code review — użyteczny input, nie ewangelia

Deweloper, który wysłał ten nieprzetestowany PR? Nie był leniwy ani niekompetentny. Wpadł w pułapkę, którą cała branża obecnie dla siebie kopie: uwodzenie momentum ponad jakość.

Ship fast, break things, move quick — tak brzmi mantration. Ale gdzieś po drodze zapomnieliśmy, że popsute rzeczy kosztują prawdziwe pieniądze, prawdziwych użytkowników i prawdziwe zaufanie do odbudowania.

Konkluzja

Asystenci kodowania AI to dla współczesnego developmentu to, czym spell-check dla pisania — użyteczne narzędzia, które łapią literówki, ale nie powiedzą ci, czy twój argument ma sens. Wciąż potrzebujesz ludzkiego mózgu, żeby zadać pytanie „czy w ogóle powinniśmy budować tę funkcję?" i „czy to faktycznie rozwiązuje problem użytkownika?".

Deweloperzy, którzy będą prosperować w tej nowej erze, to nie ci, którzy używają najwięcej AI. To ci, którzy używają AI strategicznie, jednocześnie utrzymując ostry osąd inżynierski. To ci, którzy wciąż rozumieją, co się dzieje pod maską, nawet jeśli nie przekręcają każdej śrubki ręcznie.

AI nie jest problemem. Założenie, że AI czyni ludzki nadzór opcjonalnym — to jest problem.

Więc śmiało, vibe-coduj przez tego MVP. Ale zanim wciśniesz merge, zapamiętaj: tej pizzy w commit message nie będzie, kiedy twoi użytkownicy dostaną 500 o północy.