Asystenci AI a zanikanie manualnych umiejętności programistycznych: atrofia kodu i nowa rekrutacja
Codzienna praca w inżynierii oprogramowania ulega bezprecedensowej transformacji: asystenci AI, którzy jeszcze niedawno służyli głównie do uzupełniania pojedynczych linii kodu, stali się autonomicznymi narzędziami generującymi całe moduły systemów. To przyspieszenie niesie jednak za sobą wyraźny koszt poznawczy. Ciągłe poleganie na podpowiedziach modeli prowadzi do stopniowego zanikania manualnych umiejętności programistycznych, utraty nawyku pisania kodu od zera oraz atrofii pamięci mięśniowej inżynierów. Zamiast aktywnie rozwiązywać problemy na poziomie składni i struktur danych, deweloperzy coraz częściej wchodzą w rolę biernych recenzentów. W odpowiedzi na to zjawisko firmy zaczynają wyznaczać specjalne dni bez asystentów, a liderzy technologiczni, tacy jak Google, gruntownie przebudowują swoje assessmenty rekrutacyjne.
Atrofia składniowa i zjawisko cognitive offloading
Mechanizm stojący za erozją rzemiosła programistycznego określany jest w psychologii poznawczej jako cognitive offloading — zrzucanie wysiłku myślowego na zewnętrzne narzędzie. Gdy każde zapytanie do bazy, funkcja pomocnicza czy schemat obsługi błędów są podsuwane przez model, programista przestaje angażować pamięć roboczą w odtwarzanie składni. Z procesu wytwórczego znika tak zwany tinkering, czyli etap manualnego eksperymentowania, w którym programista metodą prób i błędów buduje intuicję dotyczącą działania bibliotek i kompilatorów.
Konsekwencje tego zjawiska stają się widoczne w momentach awarii. Badania nad procesem przyswajania wiedzy wykazują, że osoby intensywnie posiłkujące się generatywnymi modelami uzyskują nawet o kilkanaście procent niższe wyniki w testach sprawdzających dogłębne zrozumienie kodu niż programiści pracujący manualnie. Najpoważniejszy regres dotyczy umiejętności debugowania: gdy model wygeneruje kod z subtelnym błędem logicznym lub luką bezpieczeństwa, inżynier pozbawiony nawyku analizy krok po kroku ma ogromne trudności ze zlokalizowaniem usterki. Powstaje iluzja wysokiej produktywności, maskująca spadek realnych kompetencji analitycznych.
„Dni bez AI” jako higiena inżynierska i trening fundamentów
Aby zatrzymać degradację tradycyjnych kompetencji, część organizacji decyduje się na świadome ograniczenia technologiczne. Zespoły deweloperskie wprowadzają praktykę określaną jako „dni bez AI” (no-AI days). W wyznaczone dni tygodnia lub w trakcie wybranych sprintów wyłączane są wtyczki autouzupełniania oraz agenci kodujący. Programiści wracają wówczas do pisania kodu całkowicie od zera (from scratch).
Celem takich inicjatyw nie jest technologiczny regres, lecz zachowanie higieny zawodowej i formy intelektualnej. Podobnie jak sportowcy trenują fundamentalne ćwiczenia siłowe, inżynierowie potrzebują regularnego kontaktu z czystym kodem, by utrzymać rozeznanie architektoniczne (discernment) — zdolność do natychmiastowego odróżnienia rozwiązania eleganckiego i skalowalnego od kodu wadliwego. Ręczne pisanie algorytmów i bezpośrednie obcowanie z dokumentacją techniczną zmusza do głębokiego skupienia (deep work), zapobiegając bezrefleksyjnemu akceptowaniu sugestii modeli.
Rygor SDLC, harness i koszty: wnioski z podcastu Patoarchitekci
Problem degradacji rzemiosła oraz odpowiedzialności za tworzone oprogramowanie szczegółowo analizują Łukasz Kałużny i Szymon Warda w podcaście Patoarchitekci. W odcinku „Kto się podpisze pod kodem od AI? - SDLC, koszty i harness” autorzy dedykują segment (00:41:24) zagadnieniu atrofii umiejętności i nowym realiom rekrutacji. Zwracają uwagę, że agenci kodujący nie tyle zepsuli proces wytwórczy, ile obnażyli wieloletnie zaniedbania zespołów, w których code review było fikcją polegającą na automatycznym klikaniu akceptacji.
Odpowiedzią na niedoskonałości generowanego kodu nie może być jednak ślepa wiara w autonomię agenta. Prowadzący podcastu podkreślają konieczność budowy twardego harnessu — sztywnej konfiguracji reguł, bram jakościowych i środowisk efemerycznych, której agent nie zdoła ominąć. Oznacza to powrót do klasycznych, restrykcyjnych praktyk inżynierskich: analizy statycznej za pomocą SonarQube, automatycznych testów architektonicznych oraz podejścia spec-driven development.
Do tego dochodzi twardy rachunek ekonomiczny. W materiale przytoczono konkretne koszty infrastruktury tokenowej: od 200–300 dolarów miesięcznie w przeliczeniu na DevOpsa, przez 500–600 dolarów na developera pracującego przy migracji legacy projektów .NET, aż po 3000 euro miesięcznej prognozy dla czteroosobowego zespołu czy skrajny przypadek 13 tysięcy przepalonych na kredyty Copilota. Z kolei próby ucieczki w pełny self-hosting modeli okazują się mitem finansowym — stacja M5 Max ze 128 GB pamięci osiąga wydajność na poziomie 30-paru tokenów na sekundę, co w realiach komercyjnego wytwarzania oprogramowania stanowi wąskie gardło.
Nowy assessment w Google: od odpytywania ze składni do inżynierii nadzorczej
Zanikanie znaczenia pamięciowej znajomości składni wpłynęło bezpośrednio na metody weryfikacji kandydatów w branży IT. Najbardziej wyrazistym przykładem jest Google, które od stycznia dopuszcza używanie agentów kodujących oraz modelu Gemini w pierwszym etapie rekrutacyjnego assessmentu. W ramach nowej rundy Code Comprehension inżynierowie ubiegający się o role SWE nie muszą już odtwarzać z pamięci algorytmów znanych z platform typu LeetCode na czystej tablicy.
Zamiast tego kandydat otrzymuje gotowy fragment kodu (często 200–500 linii) i narzędzie AI, a komisja weryfikuje tak zwaną biegłość w AI (AI fluency). Ocenie podlega sposób formułowania promptów, umiejętność zdiagnozowania problemów logicznych w wygenerowanym fragmencie, analiza złożoności obliczeniowej oraz walidacja bezpieczeństwa. Rekrutacja przesuwa się więc z mechanicznego klepania składni w stronę myślenia systemowego i inżynierii nadzorczej (supervisory engineering).
Zjawisko to stawia jednak wysokie bariery przed osobami rozpoczynającymi karierę. Współczesny rynek pracy wymusza natychmiastowe wejście na poziom architekta, podczas gdy początkujący inżynierowie mają coraz mniej okazji do wyrobienia intuicji na prostych zadaniach. Zmiany te sprawiają, że budżety firmowe przesuwają się z tradycyjnego onboardingu kadr na narzędzia AI, co dodatkowo komplikuje zdobywanie warsztatu przez młodsze pokolenie. Aby nie stać się zakładnikiem generowanych podpowiedzi, współczesny inżynier musi traktować asystenta wyłącznie jako narzędzie wykonawcze, nieustannie dbając o zachowanie manualnych fundamentów rzemiosła.
