AI napisało kod. A ty wiesz, co właśnie wdrożyłeś?

Czy programista, który nie czyta kodu generowanego przez AI, nadal jest programistą? A może staje się operatorem agentów, który odpowiada za efekt, ale niekoniecznie rozumie jego implementację? To pytanie coraz częściej pojawia się w branży IT. I nie chodzi już tylko o to, czy sztuczna inteligencja zabierze nam pracę.

Inspiracją do tego artykułu był post Kamila Brzezińskiego na Facebooku, w którym przywołuje podejście Roberta C. Martina, znanego jako Uncle Bob, do kodu generowanego przez AI. Dyskusja pod postem pokazała, że programistów nurtują trzy kwestie: czy można ufać kodowi, którego nie czytamy, czy automatyzacja rzeczywiście zwiększa produktywność i jakie kompetencje będą najważniejsze w zmieniającym się zawodzie.

Koniec ręcznego kodowania czy koniec programowania?

David Heinemeier Hansson, twórca Ruby on Rails, podczas Rails World 2026 mówił o zmianie roli programisty: od osoby, która przede wszystkim pisze kod, do twórcy, który doprowadza pomysły do postaci działających produktów.

To istotna różnica. AI potrafi wygenerować funkcję, endpoint czy znaczną część aplikacji. Nie oznacza to jednak, że automatycznie rozwiązuje właściwy problem, uwzględnia ograniczenia systemu i nie wprowadza regresji.

Pisanie kodu to tylko część inżynierii oprogramowania. Pozostają analiza wymagań, projektowanie architektury, bezpieczeństwo, testowanie i utrzymanie. Jeśli generowanie kodu staje się tańsze, te obszary nie znikają. Mogą wręcz zyskiwać na znaczeniu.

„Nie czytam każdej linijki kodu” — czy to już problem?

Jednym z ciekawszych wątków dyskusji jest podejście przypisywane Robertowi C. Martinowi, autorowi Clean Code. Zamiast ręcznie analizować każdą linijkę wygenerowaną przez agenta, stawia on na rozbudowane zabezpieczenia: testy, procedury QA i metryki jakości.

To zrozumiałe. Jeśli agent generuje tysiące linii kodu, ręczne sprawdzanie każdej z nich może stać się wąskim gardłem. Automatyzacja kontroli jakości pozwala wykrywać wiele problemów bez angażowania człowieka w każdą zmianę.

Jest jednak pułapka: testy mogą potwierdzić poprawność implementacji względem błędnych założeń. Jeśli wymagania są niekompletne albo rozwiązanie ma wadliwą architekturę, nawet dobrze przygotowany zestaw testów nie musi ujawnić problemu.

Dlatego trzeba rozróżnić dwie rzeczy: nieczytanie każdej linijki kodu i brak rozumienia tego, co wdrażamy.

Pierwsze może być rozsądnym elementem pracy z agentami. Drugie jest ryzykowne. Nie zawsze musimy ręcznie analizować każdą zmianę, ale powinniśmy rozumieć jej skutki, umieć ocenić rozwiązanie i wiedzieć, kiedy automatyczna weryfikacja nie wystarcza.

W końcu, jeśli agent wprowadzi błąd na produkcję, to nie on będzie tłumaczył się klientowi. Odpowiedzialność pozostaje po stronie ludzi i organizacji wdrażających rozwiązanie.

AI przyspiesza pracę. Zawsze?

Zwolennicy AI wskazują, że skoro kod powstaje szybciej, programiści mogą dostarczać więcej. Tańsze tworzenie oprogramowania może też sprawić, że firmy zaczną realizować projekty, które wcześniej były zbyt kosztowne. Jest jednak pewna pułapka: łatwo pomylić możliwości modelu z rzeczywistym wzrostem produktywności całego procesu developmentu.

W badaniu METR z 2025 roku 16 doświadczonych programistów open source wykonywało 246 zadań w dobrze znanych sobie projektach. Korzystanie z ówczesnych narzędzi AI wydłużyło czas realizacji zadań średnio o 19%. Badanie przeprowadzono jednak od lutego do czerwca 2025 roku, na modelach i narzędziach z tamtego okresu. Nie uwzględniało późniejszych postępów w możliwościach agentów programistycznych.

Pod koniec listopada 2025 roku Anthropic udostępnił Claude Opus 4.5, podkreślając jego możliwości w zakresie inżynierii oprogramowania i pracy agentowej. To przykład szybkiego rozwoju narzędzi, które potrafią realizować bardziej złożone zadania programistyczne, a nie tylko generować pojedyncze fragmenty kodu.

METR w aktualizacji z lutego 2026 roku przyznał, że kolejne pomiary produktywności stały się trudniejsze do interpretacji. Wstępne wyniki sugerowały już przyspieszenie, ale badacze wskazali na istotne problemy metodologiczne, m.in. selekcję uczestników i trudności z wiarygodnym mierzeniem czasu pracy z wieloma agentami. Nie uznali więc tych danych za mocny dowód na konkretną skalę wzrostu produktywności.

Wniosek nie brzmi zatem, że AI spowalnia programistów. Brzmi: wyników badań nad wcześniejszymi narzędziami nie można automatycznie przenosić na nowsze modele, ale sam postęp w benchmarkach również nie dowodzi, że cały proces developmentu jest proporcjonalnie szybszy.

Przy pracy z agentami nadal trzeba uwzględnić przygotowanie kontekstu, weryfikację zmian, poprawianie błędów i integrację z istniejącym systemem. Z drugiej strony, jeśli agent potrafi samodzielnie wykonać większą część zadania, może znacząco ograniczyć nakład pracy.

Kluczowe pytanie brzmi więc nie „czy AI zwiększa produktywność?”, ale w jakich zadaniach, przy jakich narzędziach i jakim kosztem kontroli jakości.

Czy doświadczenie programisty będzie mniej warte?

Jeżeli agent potrafi napisać implementację w kilka minut, łatwo uznać, że doświadczenie programisty traci na znaczeniu. W rzeczywistości część jego wartości przesuwa się na inne etapy pracy.

Doświadczony inżynier potrafi rozpoznać nieprecyzyjne wymagania, ocenić kompromisy architektoniczne i przewidzieć, że pozornie prosta zmiana może naruszyć kontrakt API. Wie też, kiedy rozwiązanie jest niepotrzebnie skomplikowane i kiedy wygenerowany kod wymaga głębszej analizy.

To ważne również dlatego, że AI potrafi generować odpowiedzi i implementacje, które wyglądają przekonująco, ale opierają się na błędnych założeniach. Bez wiedzy technicznej trudno je zakwestionować.

Dlatego znajomość fundamentów nadal ma znaczenie. Nie trzeba ręcznie pisać każdej linijki, ale trzeba rozumieć kod, umieć debugować, czytać cudze rozwiązania i oceniać skutki zmian.

Szczególnie istotne jest to na początku kariery, ale nie dlatego, że AI nie potrafi naprawiać błędów. Potrafi — i często robi to skutecznie. Problem polega na tym, że skuteczne rozwiązanie zadania nie musi oznaczać, że użytkownik zdobył umiejętność samodzielnego rozwiązania podobnego problemu.

Badania nad wykorzystaniem AI w nauce programowania wskazują na tę różnicę. W badaniu opublikowanym w 2026 roku, dotyczącym studentów wykonujących zadania programistyczne, generowanie kompletnych rozwiązań poprawiało wyniki zadań, ale nie przekładało się konsekwentnie na przyrost wiedzy. Z kolei badanie opublikowane w 2025 roku pokazało, że studenci mieli trudności z poprawianiem błędów w kodzie wygenerowanym przez LLM, szczególnie gdy wymagało to rozpoznania subtelnych błędów logicznych.

Nie oznacza to, że początkujący powinni rezygnować z AI. Istotne jest raczej to, jak z niej korzystają. Można wkleić komunikat błędu i poprosić o gotową poprawkę. Można też poprosić o wyjaśnienie przyczyny, wskazanie możliwych rozwiązań i test, który pozwoli sprawdzić, czy problem rzeczywiście został usunięty.

W obu przypadkach aplikacja może zacząć działać. Różnica polega na tym, czy przy okazji użytkownik rozwija umiejętność diagnozowania problemów, czy jedynie przechodzi do kolejnego promptu. W pracy nad prototypem może to nie mieć większego znaczenia. W złożonym systemie, w którym zmiany wpływają na inne komponenty, umiejętność oceny rozwiązania staje się jednak ważną częścią pracy inżyniera.

Programista czy vibe coder?

W dyskusjach o AI pojawia się czasem pomysł rozdzielenia dwóch profesji: programisty, który samodzielnie pisze i rozumie kod, oraz vibe codera, który opisuje oczekiwany efekt i pozwala AI zbudować resztę.

Takie rozróżnienie ma sens, jeśli nie traktujemy go jako prostego podziału na lepszych i gorszych. Budowanie prototypów, automatyzacja pracy czy tworzenie prostych aplikacji bez głębokiej wiedzy programistycznej mogą mieć realną wartość.

Problem pojawia się wtedy, gdy prototyp staje się produkcyjnym systemem, a jego twórca nie potrafi ocenić bezpieczeństwa, niezawodności i kosztów utrzymania.

Z drugiej strony samo ręczne pisanie kodu również nie gwarantuje jakości. Można stworzyć źle zaprojektowany system bez żadnej pomocy AI. Można też korzystać z agentów i nadal podejmować świadome decyzje inżynierskie.

Podział nie przebiega więc między tymi, którzy korzystają z AI, a tymi, którzy jej nie używają. Chodzi o to, czy potrafimy odpowiadać za rezultat, zamiast bezkrytycznie akceptować to, co wygenerowało narzędzie.

Co dalej z pracą w IT?

Nie wiemy jeszcze, jak zmieni się popyt na programistów. Tańsze tworzenie oprogramowania może uruchomić nowe projekty, ale może też sprawić, że część firm będzie realizować dotychczasową pracę mniejszym zespołem. Oba zjawiska mogą zachodzić jednocześnie.

Zamiast zakładać, że AI zabierze wszystkie miejsca pracy albo że automatycznie stworzy ich więcej, warto obserwować, które kompetencje będą zyskiwać na znaczeniu.

Ręczne pisanie powtarzalnego kodu może stać się mniej istotne. Rozumienie systemów, analiza wymagań, architektura, bezpieczeństwo, testowanie i odpowiedzialność za wdrożenie pozostaną kluczowe.

AI może pomóc zbudować oprogramowanie szybciej. Nie zwalnia nas jednak z odpowiedzialności za to, co trafia na produkcję.

Bo najważniejsze pytanie nie brzmi już tylko: „Czy AI potrafi napisać ten kod?”. Brzmi: „Czy rozumiem, co ten kod robi — i czy mogę wziąć za niego odpowiedzialność?”.