Deweloperzy, którzy zaczęli korzystać z GitHub Copilot, ChatGPT lub Cursor, często opisują tę samą fazę miodowego miesiąca. Zadania, które kiedyś zajmowały dwie godziny, teraz trwają dwadzieścia minut. Boilerplate znika za pomocą klawisza tab. Wkrótce jednak na forach i kanałach Slack zaczyna pojawiać się cichsza skarga: wyczerpanie. Narzędzie pisze kod, ale coś w tym procesie wciąż cię wyczerpuje. Problem nie leży w samym kodzie. Leży w pracy związanej z jego przyswajaniem.

Wąskie gardło, na które nikt nie był przygotowany

Przez dziesięciolecia ograniczeniem w inżynierii oprogramowania była prędkość pisania. Niezależnie od tego, jak szybko myślałeś, twoje palce i wiedza o składni wyznaczały sufit. Asystenci AI zburzyli ten sufit. Potrafią wygenerować setki linii w wielu plikach, zanim skończysz czytać pierwszy blok. Taka prędkość brzmi jak wolność, ale tworzy nieoczekiwany zator. Nagle najwolniejszą częścią procesu staje się twoja zdolność do czytania, rozumienia i weryfikowania tego, co właśnie pojawiło się na ekranie. Stałeś się pełnoetatowym recenzentem kodu we własnym projekcie, z tą różnicą, że autorem jest algorytm, który nigdy nie śpi i nigdy się nie męczy.

To odwrócenie charakteru pracy zmienia strukturę sesji kodowania. Zamiast przełączać się między tworzeniem a lekką weryfikacją, utykasz w trybie przedłużonej walidacji. A walidacja to nie pasywne czytanie. To aktywna analiza podszyta podejrzliwością. Każda nazwa zmiennej, każdy warunek brzegowy i każde polecenie importu musi przejść przez mentalny filtr, ponieważ AI nie ponosi żadnej odpowiedzialności za skutki swoich działań. Nie obudzą cię o 3 rano, gdy proces produkcyjny ulegnie awarii.

Dlaczego Twój mózg uderza w ścianę

Zmęczenie to nie lenistwo. To przewidywalne zderzenie lawinowej produkcji z ograniczoną przepustowością ludzkiego umysłu.

Przeciążenie objętością. Typowa sugestia AI może zawierać pełny komponent React, jego logikę stylizacji, funkcje pomocnicze i testy jednostkowe – wszystko za jednym zamachem. Twoja pamięć robocza może pomieścić tylko określoną ilość informacji naraz. Gdy ekran wypełnia się dziesiątkami nowych linii, twój mózg musi albo skompresować je do abstrakcyjnych wzorców, albo skanować je sekwencyjnie. Obie strategie pochłaniają uwagę. Po przejrzeniu kilku takich bloków pojawia się mentalny odpowiednik zakwasów mięśniowych. Czytasz, ale przestajesz naprawdę rozumieć.

Luka zaufania. Kod wygenerowany przez AI wygląda wiarygodnie. Wcięcia są idealne. Nazwy zmiennych są sensowne. Komentarze pojawiają się nawet w odpowiednich miejscach. Ale wiarygodność to nie to samo co poprawność. Kod może używać przestarzałego API, pomijać przypadki brzegowe związane z wartościami null lub wprowadzać subtelną podatność na SQL injection. Ponieważ wiesz, że to może się zdarzyć, nie możesz czytać powierzchownie. Musisz sprawdzać każde polecenie return i każdą gałąź logiki z czujnością godną audytu bezpieczeństwa. Taki poziom skrupulatności, utrzymywany przez wiele godzin, jest kosztowny poznawczo. To ten sam powód, dla którego pracownicy ochrony na lotniskach pracują w krótkich zmianach: długotrwała czujność szybko spada.

Niedopasowanie przepływu pracy. Większość środowisk programistycznych i procesów zespołowych wciąż zakłada ludzki rytm „napisz, potem przetestuj”. Baza kodu rośnie w ludzkim tempie, a przeglądy kodu odbywają się w zaplanowanych blokach. Gdy AI zostaje wtłoczone w ten proces, przepływ ulega przerwaniu. Generujesz dwadzieścia linii, zatrzymujesz się, aby zweryfikować, prosisz o poprawkę, weryfikujesz ponownie, przechodzisz do następnej funkcji i tracisz wątek szerszej architektury. Ciągłe przełączanie kontekstu między kreatywnym generowaniem a sceptyczną walidacją generuje tarcie. Twoje IDE zostało zaprojektowane dla autorów, a nie dla redaktorów pracujących pod nieustanną presją czasu.

Pętla wyczerpania

Te czynniki zasilają cykl, który pogarsza się wraz z upływem dnia.

Asystent w kilka sekund wypluwa implementację nowej funkcjonalności. Ty spędzasz następnie piętnaście minut na śledzeniu importów, sprawdzaniu kompatybilności typów i przeprowadzaniu mentalnych symulacji przypadków brzegowych. Przy trzeciej lub czwartej rundzie twoja koncentracja słabnie. Zaczynasz akceptować fragmenty kodu, które „wyglądają w większości poprawnie”. Błędy przemykają niezauważone. Aby to zrekompensować, zwalniasz, co niweluje prędkość, którą zyskałeś na początku. Kończysz dzień z większą ilością surowego kodu niż zwykle, ale z mniejszą pewnością co do jego jakości i z bólem głowy, który sugeruje, że pracowałeś ciężej, a nie mądrzej.

Kiedy szybkość staje się niebezpieczna

Jeśli ten wzorzec utrwali się jako rutyna, szkody wykraczają poza jeden gorszy wieczór.

Wypalenie przychodzi po cichu. Objawia się jako niechęć przy otwieraniu projektu lub niezdolność do patrzenia na kolejny blok kodu z pastelowym podświetleniem bez irytacji. Gdy główne narzędzie, które miało ci pomagać, staje się głównym źródłem zmęczenia, pojawia się frustracja.

Istnieje również problem zaniku umiejętności. Mięsień przekładania intencji na składnię słabnie, gdy przestajesz to robić. Możesz wciąż dobrze projektować architektury systemów, ale płynność na poziomie szczegółów — wiedza o tym, dlaczego dana struktura pętli wydaje się niewłaściwa, czy pamiętanie, jak konkretna biblioteka zachowuje się pod obciążeniem — zanika, gdy warstwa autouzupełniania zajmuje się detalami. Z czasem ryzykujesz, że staniesz się pasywnym kuratorem, a nie aktywnym inżynierem.

Najbardziej bezpośrednim zagrożeniem jest jednak niechlujne wdrażanie. Pod presją utrzymania tempa pracy i wyczerpani godzinami czytania wyników generowanych przez maszynę, programiści czasami wdrażają kod, którego nie zweryfikowali w pełni.