AI miało ułatwić programistom życie i w wielu sytuacjach faktycznie to robi. Tyle że razem z tą wygodą przyszło coś jeszcze: coraz częściej mniej czasu spędzamy na pisaniu kodu od zera, a więcej na sprawdzaniu tego, co podsunęła nam sztuczna inteligencja.
I tu zaczyna się ciekawsza część całej historii. Problemem nie jest to, czy AI pomaga w programowaniu, bo pomaga. Problem pojawia się chwilę później, kiedy łapiesz się na tym, że zamiast spokojnie budować rozwiązanie, głównie przeglądasz kolejne sugestie, poprawiasz je i pilnujesz, żeby do repo nie trafiło coś, co tylko wygląda sensownie.
I właśnie tu kryje się najciekawsza zmiana. AI nie tyle zabiera programowanie, co przesuwa środek ciężkości. Coraz częściej nie jesteś już tylko autorem kodu. Jesteś jego recenzentem, operatorem i kontrolerem jakości.
Obietnica była prosta: mniej ręcznej roboty
Obietnica narzędzi AI dla programistów była bardzo atrakcyjna. Mniej boilerplate’u, mniej przeklikiwania dokumentacji, szybsze pisanie testów, łatwiejszy refaktor, sprawniejsze wejście w obcy kod. Wszystko to jest prawdą. W wielu przypadkach AI naprawdę skraca drogę między pomysłem a pierwszą działającą wersją.
Problem polega na tym, że pierwsza działająca wersja coraz rzadziej jest wersją, której można zaufać.
Kod wygenerowany przez AI często wygląda sensownie. Ma poprawną składnię, znajome wzorce i przekonujący ton. Czasem nawet przechodzi podstawowe testy. Ale to jeszcze nie znaczy, że dobrze wpisuje się w architekturę, nie psuje założeń domenowych, nie tworzy ukrytego długu i nie zostawia po sobie min pod przyszłe utrzymanie.
W efekcie zysk z szybszego generowania kodu zaczyna być częściowo zjadany przez koszt jego weryfikacji.
Dziś mniej piszesz, a częściej oceniasz
To jest chyba najbardziej niedoszacowana zmiana w codziennej pracy z AI. W klasycznym modelu programista przede wszystkim konstruował rozwiązanie. Myślał, pisał, testował, poprawiał. W modelu z AI coraz częściej działa inaczej:
- AI proponuje strukturę.
- AI dopisuje fragmenty.
- AI poprawia funkcje.
- AI sugeruje testy.
- AI robi refaktor.
- Człowiek ocenia, czy to wszystko ma sens.
Na pierwszy rzut oka wygląda to jak awans. Mniej klepania, więcej decyzji. W praktyce bywa odwrotnie. Bo decyzje podejmowane w trybie ciągłego review są męczące. Zwłaszcza wtedy, gdy każda propozycja jest „w miarę dobra”, ale żadna nie jest naprawdę gotowa.
To trochę jak praca redaktora, który dostaje dużo tekstów poprawnych językowo, ale słabych merytorycznie. Nie pisze od zera, ale wcale nie ma lekko. Musi cały czas być czujny.
Największy koszt: zmęczenie poznawcze, nie sam kod
Wielu programistów opisuje dziś podobny problem, choć nie zawsze tak go nazywa. Po kilku godzinach pracy z AI czują nie tyle klasyczne zmęczenie kodowaniem, co przeciążenie decyzyjne.
- Trzeba ocenić, czy wygenerowany fragment rozwiązuje właściwy problem.
- Trzeba sprawdzić, czy nie przemyca złych założeń.
- Trzeba porównać dwie albo trzy wersje odpowiedzi.
- Trzeba zdecydować, czy szybciej poprawić kod ręcznie, czy jeszcze raz promptować.
- Trzeba pamiętać, że poprawnie brzmiący komentarz albo pewny siebie opis nie są dowodem jakości.
To jest inny rodzaj wysiłku niż zwykłe programowanie. Mniej liniowy, bardziej poszatkowany, oparty na ciągłym przełączaniu kontekstu. Generator, diff, test, poprawka, kolejny prompt, kolejny diff, kolejna kontrola. Zamiast wejść głęboko w problem, łatwo ugrzęznąć w rytmie reakcji na cudze propozycje.
I właśnie dlatego AI potrafi jednocześnie zwiększać produktywność i obniżać satysfakcję z pracy.
Fałszywe poczucie produktywności jest bardzo realne
Jedna z pułapek pracy z AI polega na tym, że tempo produkcji kodu łatwo pomylić z tempem rozwiązywania problemów.
Repo rośnie szybciej. Commity wpadają częściej. Rzeczy „się robią”. Tyle że nie zawsze rośnie to, co w dłuższej perspektywie liczy się najbardziej: zrozumienie systemu, klarowność decyzji i jakość architektury.
Można w dwa dni wygenerować więcej kodu niż wcześniej w tydzień. Pytanie brzmi: ile z tego kodu naprawdę ktoś rozumie? Ile będzie łatwe do utrzymania za trzy miesiące? Ile nie okaże się tylko kosztownie opakowaną prowizorką?
Jeśli zespół nie ma dobrego procesu, AI bardzo łatwo zamienia się w akcelerator bałaganu. Nie dlatego, że generuje wyłącznie zły kod. Raczej dlatego, że generuje go szybciej, niż ludzie są w stanie go sensownie przetrawić.
Gdzie AI faktycznie działa świetnie
Nie ma sensu popadać w drugą skrajność i udawać, że wszystko z AI to kłopot. Są obszary, w których wartość jest bardzo konkretna.
AI dobrze działa tam, gdzie wynik da się łatwo ocenić i tanio zweryfikować. Na przykład przy:
- pisaniu boilerplate’u,
- tworzeniu prostych testów,
- porządkowaniu powtarzalnego kodu,
- robieniu pierwszej wersji dokumentacji,
- wyjaśnianiu obcego API,
- proponowaniu kierunków refaktoru,
- tworzeniu roboczych wersji narzędzi wewnętrznych.
W takich zadaniach AI może skrócić czas dojścia do sensownego punktu startowego. Nie musi być idealne. Wystarczy, że daje materiał, który człowiek szybko oceni i dopracuje.
Problem zaczyna się wtedy, gdy z tej skuteczności wyciągamy zbyt szeroki wniosek. Skoro dobrze radzi sobie z prostszymi rzeczami, to może poradzi sobie też z tym, co krytyczne. I tu właśnie wiele zespołów wpada na minę.
Im bliżej domeny, bezpieczeństwa i odpowiedzialności, tym mniej autopilota
Kod nie jest równy kodowi. Są fragmenty, przy których drobna pomyłka kosztuje kilka minut. Są też takie, przy których koszt błędu wychodzi dopiero po czasie i bywa bardzo drogi.
Dlatego szczególnej ostrożności wymagają obszary takie jak:
- logika biznesowa,
- uprawnienia i autoryzacja,
- bezpieczeństwo,
- migracje danych,
- integracje płatnicze,
- kod operacyjny i infrastrukturalny,
- miejsca o wysokim wpływie na niezawodność systemu.
Tu AI nie powinno działać w trybie „wygeneruj i lecimy dalej”. Im większa odpowiedzialność fragmentu kodu, tym bardziej potrzebujesz świadomego autora, a nie tylko sprawnego operatora promptów.
AI może pomóc przygotować warianty, checklistę, szkic rozwiązania albo testy. Ale odpowiedzialności za decyzję architektoniczną nie da się delegować na model tylko dlatego, że napisał coś szybko i pewnym tonem.
Najlepsi nie będą generować najwięcej. Będą najlepiej filtrować
To jest, moim zdaniem, najważniejsza kompetencja najbliższych lat. Nie „kto umie najwięcej promptów”, tylko kto potrafi ustawić współpracę z AI tak, żeby zyskać szybkość bez utraty kontroli.
Dobry programista z AI nie przypomina człowieka, który bezmyślnie akceptuje kolejne sugestie. Bardziej przypomina redaktora technicznego z bardzo dobrą intuicją do ryzyka. Wie, kiedy odpuścić, kiedy przepisać ręcznie, kiedy zawęzić problem, a kiedy w ogóle nie wpuszczać AI do krytycznego fragmentu.
To mniej efektowna narracja niż „AI zrobi za ciebie wszystko”. Ale dużo bliższa prawdziwej pracy.
Jak nie utknąć w roli wiecznego reviewera
Najgorsze, co można zrobić, to pracować z AI bez żadnych zasad. Wtedy szybko pojawia się chaos: duże diffy, mało zrozumienia, rosnące zmęczenie i niejasna odpowiedzialność.
Lepiej działa prosty framework:
- Dawaj AI małe, ograniczone zadania. Nie proś od razu o przebudowę połowy modułu. Lepsze są małe porcje, które da się szybko ocenić.
- Zatwierdzaj tylko to, co umiesz wyjaśnić własnymi słowami. Jeśli kod „wygląda sensownie”, ale nie potrafisz powiedzieć, dlaczego działa właśnie tak, to znak ostrzegawczy.
- Po każdym większym kroku warto zatrzymać się na chwilę i sprawdzić, czy wszystko idzie w dobrą stronę. Im mniej opierasz się na wrażeniu, a bardziej na weryfikacji, tym mniejsze ryzyko kosztownych niespodzianek.
- Traktuj AI jak juniora z ogromną prędkością, a nie jak architekta. Bywa bardzo pomocne, ale potrzebuje zakresu, kontekstu i nadzoru.
- Oceniaj nie tylko to, czy kod działa. Patrz też, czy jest czytelny, spójny, utrzymywalny i zgodny z resztą systemu.
- Nie bój się przepisać czegoś ręcznie. Czasem pięć minut świadomego kodowania daje lepszy efekt niż pół godziny walki z kolejnymi iteracjami promptu.
AI zmienia zawód, ale nie w sposób, który najczęściej widzimy w nagłówkach
Dużo mówi się dziś o tym, że AI zabierze programistom pisanie kodu. To chwytliwa narracja, ale trochę mija się z tym, co naprawdę dzieje się na co dzień.
Dużo ciekawsze jest coś innego: jak zmienia się praca programisty, kiedy sam kod da się tworzyć szybciej niż wcześniej, ale coraz więcej czasu trzeba poświęcić na sprawdzanie i pilnowanie jakości.
Bo właśnie to widać dziś najlepiej. Coraz mniejsze znaczenie ma samo pisanie kolejnych linijek. Coraz większe ma to, czy umiesz dobrze ocenić wygenerowane propozycje, wychwycić słabe miejsca i nie dopuścić do bałaganu.
AI nie zabiera programowania. Bardziej zmienia to, na czym ta praca naprawdę polega.
I bardzo możliwe, że w najbliższych latach jedną z najważniejszych umiejętności programisty będzie nie samo pisanie kodu, ale podejmowanie dobrych decyzji.
