W ciągu ostatnich dwóch lat, za sprawą narzędzi AI, produkuję wielokrotnie więcej kodu niż kiedykolwiek wcześniej. Jednocześnie mam wrażenie, że programuję mniej. Tworzenie kodu z wykorzystaniem AI ma wiele zalet, ale ma też swoją cenę. O tym, jaką dokładnie, dowiesz się z tego artykułu.

„Nieużywany mięsień zanika”

Wydelegowanie tworzenia kodu do AI powoduje, że jesteśmy w stanie praktycznie całkowicie wyeliminować ręczne pisanie kodu. Nawet drobne poprawki jesteśmy w stanie dopromptować (to, czy zawsze ma to sens, to już temat na inną dyskusję). Pozbawiając się szansy na ręczne pisanie kodu, jednocześnie odbieramy sobie możliwość samodzielnego pogłówkowania nad kodem na tym najniższym poziomie.

Gdy rozpoczynałem naukę programowania, bardzo popularnym sposobem na nabranie wprawy i zrozumienie różnych mechanizmów były różne challenge programistyczne, np. SPOJ, CodeKata czy aplikacje z zadaniami algorytmicznymi typu Codewars. Obecnie, zamiast męczyć się z efektywnym przetworzeniem zbioru danych czy skomplikowanym mapowaniem, wystarczy poprosić agenta o pomoc.

Z punktu widzenia biznesu to świetna sprawa. Zamiast rzeźbić w kodzie przez godzinę i samodzielnie znajdować przypadki do pokrycia, wystarczy opisać specyfikację taska agentowi, a on pokieruje już resztą procesów. Nie jest to jednak świetna sprawa z punktu widzenia biegłości w fachu. Im rzadziej rozwiązujemy problemy samodzielnie, tym większego wysiłku będą wymagać od nas w przyszłości. W moim przypadku samo czytanie kodu znacznie słabiej utrwala wiedzę niż jego samodzielne napisanie. Gdy zaczynałem programować, przeglądałem dziesiątki tutoriali i kursów. Jednak gdy przychodziło do napisania kodu, trafiałem na ścianę. Dopiero przez żmudną praktykę i rozwiązywanie kolejnych problemów zdobywałem biegłość. Z punktu widzenia nauki programowania tworzenie kodu z użyciem LLM-ów, sprowadzające się wyłącznie do pisania promptów, nie różni się zbytnio od staromodnego przepisywania kodu ze Stack Overflow czy tutoriali.

Pisanie kodu z wykorzystaniem LLM-ów często sprowadza się do jego czytania i ewentualnego iterowania poprawek. Brakuje tu samodzielnego zagłębienia się w kod i jego strukturę oraz logikę. Od kiedy wykorzystuję LLM-y do tworzenia kodu, powstaje go drastycznie więcej. Jednak w praktyce czasu na pisanie kodu poświęcam znacznie mniej. Czuję, że niektóre moje umiejętności nieco zardzewiały. Pewne rzeczy robię gorzej lub wolniej. Szczęśliwie jestem świadom tego zjawiska i czas zaoszczędzony na tym, że ktoś tworzy kod za mnie, mogę niekiedy poświęcić na pilnowanie, by nie wypaść z rytmu. Staram się również nie delegować do LLM-ów krytycznego myślenia, analizy i planowania – kompetencji, które od zawsze stanowią fundament naszej pracy.

Słusznie można podnieść argument, że być może już lub za chwilę takie umiejętności nie będą potrzebne. Mam jednak ku temu dwa argumenty.

Po pierwsze, nie ma żadnej gwarancji, że LLM-y będą z nami na zawsze. Być może vendorzy podniosą ceny, by ten biznes w końcu się spinał. Być może bańka AI pęknie i trend się odwróci. Być może trafimy do środowiska pracy, gdzie będą ograniczenia techniczne lub prawne uniemożliwiające korzystanie z LLM-ów. Może również wystąpić awaria, która spowoduje, że tymczasowo LLM-y nie będą dostępne i trzeba będzie programować „po staremu”. Uważam, że programista powinien być w stanie poradzić sobie w warunkach awaryjnych, tak jak ma to miejsce np. u pilotów samolotów:

In the event of electrical failure, the pilot still has emergency instruments as a backup. These instruments either do not require electrical power, or as in the case of many attitude indicators, they are battery equipped.

Pilots flying under visual flight rules (VFR) maneuver their aircraft by reference to the natural horizon, utilizing specific reference points on the aircraft. In order to operate the aircraft in other than VFR weather, with no visual reference to the natural horizon, pilots need to develop additional skills. These skills come from the ability to maneuver the aircraft by reference to flight instruments alone. These flight instruments replicate all the same key elements that a VFR pilot utilizes during a normal flight. The natural horizon is replicated on the attitude indicator by the artificial horizon.

Understanding how each flight instrument operates and what role it plays in controlling the attitude of the aircraft is fundamental in learning attitude instrument flying. When the pilot understands how all the instruments are used in establishing and maintaining a desired aircraft attitude, the pilot is better prepared to control the aircraft should one or more key instruments fail or if the pilot should enter instrument flight conditions.

Instrument Flying Handbook p. 149

Programista, który wie, jak tworzyć i analizować algorytmy, zna język, w którym pracuje, i rozumie architekturę tworzonych rozwiązań, poradzi sobie również bez dostępu do LLM-ów.

Drugim argumentem przemawiającym za tym, by nie delegować pełni tworzenia kodu do LLM-ów, jest to, że projektowanie rozwiązań wymaga krytycznego i analitycznego myślenia. Taka umiejętność jest przydatna również wtedy, gdy projektujemy architekturę, tworzymy specyfikację czy prompty, które wykorzystamy do wygenerowania kodu za pomocą LLM-ów.

Zjawisko „zanikania nieużywanych umiejętności” jest o tyle przerażające, że obecnie wiele fundamentalnych umiejętności znaczy więcej niż kiedykolwiek wcześniej.

Cognitive load

To będzie pewnie 2137 porównanie mózgu programisty do pamięci RAM, dysku czy procesora, które pojawia się na blogu o programowaniu. Ma ono jednak sporo trafności. Tak jak programując, nie chcielibyśmy się nadziać na out of memory, tak w codziennej pracy raczej chcielibyśmy unikać cognitive load. Im większe obciążenie poznawcze, tym trudniej skupić się na obecnym zadaniu i podejmować dobre decyzje.

W „starych dobrych czasach” (tj. zanim upowszechniły się LLM-y) obciążenie poznawcze rosło albo przez dokładanie dodatkowej roboty (wertykalnie), albo przez robienie większej liczby zadań w tym samym czasie (horyzontalnie). Popularyzacja LLM-ów zintensyfikowała zarówno jedno, jak i drugie zjawisko.

Kodu do sprawdzenia jest więcej niż kiedykolwiek wcześniej i nic nie wskazuje na to, żeby ten trend miał szybko wyhamować. Nawet w GitHubie zauważono, że w 2026 roku przy założeniu liniowego wzrostu (co jest dość naiwnym założeniem) ilość kodu wysłanego na serwery GitHuba wzrośnie 14 razy względem roku poprzedniego.

Yup, platform activity is surging. There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won’t.)

GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now… https://t.co/iGsM2j1efO

— Kyle Daigle (@kdaigle) April 3, 2026

Kodu nie tylko powstaje sumarycznie więcej, ale sam rozmiar przeciętnego pull requesta również wzrósł. W jednej z firm przeprowadzono badania, które pokazały, że wykorzystanie AI średnio zwiększyło rozmiar PR-ów 3,5-krotnie, gdzie mediana wyniosła 3,2x.

No matter how I slice the data, it seems that we now deal with tasks that are roughly three times as big as they used to be.

• The average PR size went up from 232 to 817 LoC—a 3.5x increase.
• The median PR size went up from 66 to 210 LoC—a 3.2x increase.
• The percentage of big and large PRs went up from 13% to 33%—a 2.5x increase.

Long story short, our brains process three times as much information per task as they used to. Common sense suggests that the review can’t be as thorough as it was when done in smaller bits.

Pawel Brodzinski – We 3.5x’d Our Pull Requests with AI: Now We Catch Fewer Bugs

Code review wielu PR-ów może być trudne, a code review wielu dużych PR-ów z kodem generowanym przez LLM-y potrafi być koszmarnie trudne. Oczywiście, są to dane z jednej organizacji i nie można ich bezpośrednio uogólniać na całą branżę. Pokazują jednak interesujący trend i potwierdzają moje obserwacje.

Zwiększanie obciążenia poznawczego przez równoległe wykonywanie wielu zadań również jest łatwiejsze niż kiedykolwiek. Dla LLM-ów to żaden problem robić na raz kilka zadań. Materiały szkoleniowe i promocyjne często wymieniają to jako istotną zaletę. Technologia obecnie nie stanowi bariery. Bariera pojawia się na poziomie interfejsu białkowego. Badania szacują odsetek ludzi umiejących efektywnie multitaskować na 2,5% ogółu. Istnieje niskie prawdopodobieństwo, że należysz do tej grupy.

Whereas the vast majority of participants showed significant performance decrements in dual-task conditions […], 2.5% of the sample showed absolutely no performance decrements with respect to performing single and dual tasks.

Supertaskers: Profiles in extraordinary multitasking ability

Nadmierny cognitive load, niezależnie od tego, czy wynika z nadmiaru kodu do przetrawienia, czy z multitaskowania, to prosta droga do degradacji zarówno jakości kodu, jak i naszego komfortu psychicznego, a w konsekwencji jakości naszej pracy.

Brak poczucia ownershipu kodu i tego konsekwencje

Problem, który dostrzegam i który realnie rzutuje na dostarczane rozwiązania, to brak poczucia autorstwa tworzonego kodu. Programiści często utożsamiają się z tworzonym przez siebie kodem. Choć może mieć to negatywne konsekwencje, np. podczas review, to całkowite odcięcie się od efektów swojej pracy również nie jest w pełni dobre.

Mimo że zmieniły się jedynie narzędzia, czuję, jakby autorem kodu był ktoś inny.  Teoretycznie sama zmiana narzędzi nie powinna mieć żadnego znaczenia. W praktyce jednak tak nie jest. Czasami łapię się na tym, że nieco luźniej podchodzę do takich aspektów jak czytelność kodu czy testów. Brak przywiązania do kodu i prostota ewentualnej refaktoryzacji sprawiają, że łatwiej zaakceptować mi rozwiązanie, które jest wystarczająco dobre. Czytelność czy spójność implementacji schodzi na dalszy plan. Skupiam się bardziej na tym, by kod faktycznie robił to, co ma robić.

Prostota wygenerowania PR z kilkoma tysiącami linii w ciągu kilku minut powoduje, że pewność tego, co wypychamy, jest mniejsza niż kiedyś. Dawniej, nawet jeśli nasz PR miał czterocyfrową liczbę zmienionych linii, to każdą zmianę wprowadzaliśmy osobiście i robiliśmy to w sposób świadomy. Generując kod za pomocą AI, nie ma takiej konieczności. Przeczytanie kodu, wprowadzenie poprawek (często również za pomocą promptów), sprawdzenie i uruchomienie testów nie dadzą takiego zrozumienia kodu jak jego ręczne napisanie. Nie wierzę, że generując kilka takich PR-ów dziennie czy tygodniowo, jesteśmy w stanie rzetelnie zrozumieć każdy if.

Podobny problem dostrzegam również w trakcie code review. Mając do sprawdzenia wielokrotnie więcej kodu, nie wierzę, że jakość tego review będzie taka, jak wcześniej. Większa ilość kodu wymaga albo obniżenia jakości review albo wydłużenia jego czasu.

Code review robione przez AI również jest mieczem obosiecznym. Jeśli testy generujemy za pomocą AI, code review robi AI, to ryzykujemy złudnym poczuciem, że rozwiązanie jest poprawne. Niestety w moim przypadku, zaskakująco często rozwiązanie, które zatwierdziły 2–3 narzędzia wykorzystujące modele od różnych dostawców, potrafi wyłożyć się na podstawowym przypadku. Gorzej jednak jeśli pojawią się mniej oczywiste błędy, których nie wyłapiemy, czy to z przytłoczenia liczbą zmian do dostarczenia i sprawdzenia, czy złudnie ufając LLM-om.

Więcej o moich przemyśleniach o code review w dobie AI przeczytasz w dedykowanym artykule.

Syndrom oszusta

Syndrom oszusta (impostor syndrome) to zjawisko polegające na tym, że ktoś mimo obiektywnych osiągnięć uważa, że nie zasługuje na swój sukces. Osoba ma poczucie, że „oszukuje” innych i prędzej czy później zostanie zdemaskowana jako mniej kompetentna, niż jest postrzegana.

Od kiedy tylko pamiętam, jest to temat powracający regularnie i przewijający się w różnych prezentacjach na konferencjach czy branżowych blogach. Mnie syndrom oszusta również nie ominął. Obecnie za sprawą LLM-ów czuję go równie mocno, jak gdy zaczynałem karierę jako programista. Mam wrażenie, że jest to spowodowane faktem, że coraz mniej kodu powstaje bezpośrednio spod moich palców. Mimo że odpowiadam za rezultat, podświadomie przypisuję autorstwo LLM-om.

Szczególnie zauważam podtyp naturalnego geniusza, eksperta i solisty.

Imposter syndrome can be broken down into several subtypes:

(1) The perfectionist: They believe that competence is defined by perfection and anything less than that is considered failure. They focus on what could have been done better.
(2) Natural genius: They measure their competence by how easily any achievement/success comes to him/her. Hard work/perseverance are viewed negatively, as success should have come more easily.
(3) Superman/Superwoman: They view competence as the ability to juggle multiple things at once and being successful at it all. Falling short in one area is viewed as a total failure.
(4) Expert: They measure competence based on their volume of knowledge/skill. They fear being exposed as inexperienced owing to lack of knowledge.
(5) Soloist: They measure competence by being successful on their own. Having to ask for help is considered a failure.

Imposter Syndrome – Suzanne Feigofsky

Patrząc na to chłodnym okiem, syndrom oszusta wydaje się wręcz niedorzeczny. Umiejętność pracy z LLM-ami przy tworzeniu kodu jest dzisiaj pożądana, a czasami wręcz wymagana. Aby efektywnie wykorzystać te narzędzia, potrzeba wiedzy i umiejętności.

Jednocześnie wykorzystując te narzędzia, czasami czuję, jakbym oszukiwał. To uczucie jest całkowicie nieuzasadnione, a wartość, jaką dostarczam w danej jednostce czasu, dzięki wykorzystaniu LLM-ów istotnie wzrosła. Psychika lubi jednak płatać figle.

Podsumowanie

Problemy z samym kodem generowanym przez AI to niewielki ułamek problemów, które powstały wokół tego tematu. Większość zaobserwowanych przeze mnie problemów dotyczy ludzkich możliwości i ograniczeń. Paradoksalnie, z niektórymi z nich również można walczyć z wykorzystaniem AI. Walka z programowaniem przy użyciu AI to próba zawracania kijem rzeki. Moja smutna konkluzja jest taka, że chcąc nie chcąc musimy się do nowych warunków dostosować. Jednocześnie warto zrobić wszystko, by nie oddać kluczowych kompetencji LLM-om.

Jestem ogromnie ciekaw, jakie Ty widzisz ciemne strony wykorzystania LLM-ów do tworzenia kodu. Koniecznie zostaw komentarz pod artykułem i podziel się swoimi przemyśleniami. Biorę też pod uwagę, że mogę brzmieć jak stary pierdziel narzekający, że „kiedyś to było, teraz to nie ma”. Jeśli tak uważasz, to też daj mi o tym znać w komentarzu.

Źródła i materiały dodatkowe

• Code review w dobie AI
• „Software Fundamentals Matter More Than Ever” — Matt Pocock
• Pawel Brodzinski – We 3.5x’d Our Pull Requests with AI: Now We Catch Fewer Bugs
• Supertaskers: Profiles in extraordinary multitasking ability
• Imposter Syndrome – Suzanne Feigofsky

Zaobserwuj mnie w mediach społecznościowych!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!

Chcesz docenić moją pracę? Postaw mi kawę!