AI potrafi przyspieszyć pracę jak mało które narzędzie. Problem w tym, że równie skutecznie przyspiesza popełnianie błędów.
Przy odpowiedniej liczbie dostępnych tokenów jesteśmy dziś w stanie zakodować prawie wszystko. Niekoniecznie dobrze, ale za to szybko. A gdy kolejne pliki pojawiają się jeden po drugim, łatwo pomyśleć:
Działa? Działa. To lecimy dalej.
No właśnie — nie zawsze działa.
Co może pójść nie tak?
Podczas szybkiego kodowania z AI możemy dostać:
- kod słabej jakości,
- nieprzemyślaną architekturę,
- źle zaprojektowaną logikę,
- niepotrzebne abstrakcje,
- klasy i interfejsy, których nikt nigdy nie potrzebował.
Ale to wszystko jeszcze pół biedy.
Kod można poprawić. Klasy można przenieść. Architekturę można uprościć. Najgorzej jest wtedy, gdy wygenerowana logika wygląda sensownie, przechodzi pobieżny przegląd, ale działa błędnie.
I właśnie taki błąd potrafi zostać w projekcie najdłużej.
AI nie ma problemu z produkowaniem kodu
Bez AI prawdopodobnie zatrzymalibyśmy się na chwilę i zastanowili:
- czy to rozwiązanie ma sens,
- czy potrzebujemy tutaj abstrakcji,
- czy warto wydzielić osobną klasę,
- czy nie komplikujemy prostego problemu,
- jakie przypadki brzegowe trzeba obsłużyć.
Pisanie kodu kosztuje czas, więc naturalnie staramy się go nie produkować więcej, niż naprawdę potrzebujemy.
AI usuwa tę barierę.
Przecież to nie my musimy napisać kolejnych pięciu klas. Nie my musimy stworzyć interfejs, fabrykę, trzy implementacje i testy. Wystarczy poprosić, a tokeny zrobią brrr.
I właśnie dlatego szybkie rozwiązanie jest tak kuszące.
Szybko nie zawsze znaczy dobrze
Problemem nie jest samo korzystanie z AI. Problemem jest moment, w którym szybkość generowania kodu zaczynamy mylić z szybkością rozwiązywania problemu.
To, że LLM przygotował rozwiązanie w kilka minut, nie oznacza, że:
- dobrze zrozumiał wymagania,
- wybrał właściwą architekturę,
- uwzględnił wszystkie przypadki,
- poprawnie odwzorował logikę biznesową,
- nie stworzył problemów, które zauważymy dopiero za miesiąc.
Kod pojawił się szybko. Myślenie nadal musi wykonać człowiek.
Największe ryzyko
Słaby kod zazwyczaj widać.
Błędną nazwę można poprawić. Zbyt dużą klasę można podzielić. Niepotrzebną abstrakcję można usunąć.
Znacznie groźniejsza jest logika, która wygląda poprawnie, ale daje błędne wyniki.
Im szybciej generujemy kolejne fragmenty systemu, tym łatwiej taki błąd przeoczyć. Szczególnie gdy AI przygotowało dużo kodu, a my zaczynamy go przeglądać bardziej jak zmęczony akceptant regulaminu niż programista.
Klik, klik, wygląda dobrze, merge.
Pośpiech nadal jest pośpiechem
AI zmieniło sposób, w jaki piszemy kod, ale nie zmieniło podstawowej zasady:
Szybko napisany kod nadal wymaga spokojnej weryfikacji.
Możemy dostarczać rozwiązania szybciej. Możemy testować więcej pomysłów. Możemy automatyzować żmudne fragmenty pracy.
Nie możemy jednak całkowicie oddać myślenia modelowi.
Jak ograniczyć ryzyko i nie dać się wciągnąć w bezmyślne generowanie kolejnych plików? O tym opowiem w następnym wpisie.