Teza, że programowanie z użyciem AI może zatrzymać rozwój eksperckości, jest niewygodna dla obu stron. Nie mówi, że agenci kodujący są bezużyteczni, ani że trzeba wrócić do ręcznego pisania szablonów. Pyta praktycznie: co dzieje się z osądem inżynierskim, gdy firmy używają Claude Code, Cursor, Codex, narzędzi typu Copilot, Gemini CLI czy OpenCode i oddają agentom część pracy, na której wcześniej uczono się fachu?

Programista między agentem AI, architekturą, testami i review

Iskrą była dyskusja Hacker News wokół eseju Larsa Faye “AI Coding will Prevent Expertise”. Chodzi o utratę tarcia poznawczego: debugowania, czytania dokumentacji, błędów, rozumienia ograniczeń. Temat zadziałał, bo wiele zespołów już to widzi. AI produkuje więcej kodu, ticketów, notatek projektowych i komentarzy review, niż ludzie są w stanie spokojnie zrozumieć.

Co jest trafne

Faye opisuje paradoks sprawnego orkiestratora. Najwięcej zyskują doświadczeni inżynierowie, bo potrafią kwestionować agenta. Widzą złą abstrakcję, zmyślone API, ukryty koszt migracji albo zmianę trudną w utrzymaniu. Zadają lepsze pytania, bo mają intuicję dobrej odpowiedzi.

Problem dotyczy nauki. Początkujący dostają narzędzia wymagające eksperckiego sterowania, zanim zbudują eksperckie odruchy. Agent może sprawić, że wyglądają na produktywnych, ale ukryć brak modeli mentalnych: przepływu danych, granic systemu, wartości testów i kosztu utrzymania.

To nie nostalgia za cierpieniem. Część tarcia była stratą czasu, ale część była praktyką. Jeśli AI usuwa obie warstwy, firma może zyskać widoczną szybkość i stracić trwałe zrozumienie.

Dlaczego dyskusja była żywa

Jedna strona porównuje AI do kompilatorów, IDE, autouzupełniania i Stack Overflow. Każde narzędzie usuwało ręczną pracę. Druga odpowiada, że AI może usuwać nie tylko pisanie, lecz także rozumowanie. Kompilator nie daje gotowej architektury; Stack Overflow dawał fragmenty. Agent potrafi dać diff, wyjaśnienie i testy w jednym przebiegu.

Obie strony mają częściowo rację. Usuwanie pracy o niskiej wartości jest dobre. Usuwanie pętli informacji zwrotnej jest ryzykowne. Pytanie brzmi, jakie pętle zespół zachowa: czytanie diffów, jawny projekt, sensowne testy i ludzką odpowiedzialność.

Pułapka firmowa

Firmy łatwo mierzą adopcję przez wolumen: więcej pull requestów, szybciej zamknięte tickety, więcej testów. To ma sens tylko z sygnałami jakości. Zespół może wygenerować więcej kodu, niż zdoła przeczytać i utrzymać. Wtedy produktywność zamienia się w dług zrozumienia.

Szkodliwy jest komunikat: ręczne kodowanie znaczy, że jesteś wolny. Wypycha on czynności chroniące produkt: kwestionowanie wymagań, czytanie diffu, analizę przypadków brzegowych, odrzucanie zbyt szerokich zmian i pytanie, czy funkcja jest potrzebna.

AI zwiększa też szum wokół pracy. Tickety są dłuższe, notatki projektowe liczniejsze, narzędzia review bardziej gadatliwe. Zespół filtruje artefakty brzmiące precyzyjnie, lecz nie zawsze oparte na realnej decyzji.

Juniorzy potrzebują praktyki

Senior używa agenta jak cierpliwego partnera, bo umie się z nim spierać. Junior może używać go jak maszyny odpowiedzi. Różnica wynika z bazy wiedzy.

Zdrowy proces wymaga, aby agent najpierw wyjaśniał: opisał system, ograniczenia, opcje, pytania i ważne testy. Dopiero potem powinien pisać kod. Agent ma być tutorem i recenzentem, nie automatem do patchy.

Zespoły powinny zachować ćwiczenia bez AI: debugowanie, czytanie obcego kodu, małe funkcje od zera, obrona projektu na review. To trening osądu potrzebnego do oceny odpowiedzi agenta.

AI może uczyć

Dobrze użyta AI przyspiesza naukę. Może opisać legacy module, porównać podejścia do bazy danych, zaproponować testy albo skrytykować refaktoryzację. To lepsze niż ciche utknięcie.

Różnica jest w poleceniu. “Napisz funkcję” daje wynik. “Wyjaśnij system, zadaj pytania, pokaż alternatywy i ryzyka” daje zrozumienie. Podobnie w analizie, prawie, marketingu i support: AI produkuje szybciej, niż ludzie walidują. Bez wiedzy domenowej elegancka odpowiedź staje się ryzykiem.

Czytać cały kod?

Argument Adama Tornhilla o kontrolowaniu maszyny niepewności równoważy debatę. Może nie trzeba czytać każdej linii tak samo. Inżynieria ufa bibliotekom, kompilatorom i bazom danych.

Ale selektywne zaufanie wymaga granic: kontraktów, testów, obserwowalności, małego zasięgu skutków i znanych inwariantów architektury. Ktoś musi wiedzieć, które inwarianty są ważne. Zielone testy nie wystarczą, jeśli nikt nie umie wyjaśnić bezpieczeństwa zmiany.

Review powinno zależeć od ryzyka. Zmiana UI to nie logowanie, płatności, migracje, współbieżność ani security. Kod z AI nie wymaga magicznej podejrzliwości, lecz właściciela.

Auto mode i zasady

Dyskusja o Claude Code auto mode pokazuje stawkę. Mniej potwierdzeń jest wygodne, ale im rzadziej agent pyta, tym ważniejszy jest wcześniejszy sandbox. Trzeba określić katalogi, komendy, zależności, migracje, CI, pliki generowane i progi akceptacji człowieka.

Autonomia bez polityki staje się zaufaniem z przemęczenia. Dobry proces zaczyna się od rozpoznania, planu, pytań, zgody na ryzykowne akcje i małych diffów.

Zasady praktyczne

Każda zmiana z pomocą AI potrzebuje ludzkiego właściciela, który wyjaśni cel, ryzyko i rollback. Poważniejsze zadania wymagają krótkiej notatki projektowej: zakres, testy, migracja, ryzyko operacyjne. Duże niewidoczne refaktoryzacje powinny być rzadkie.

Testy są obowiązkowe, ale nie zastępują review. Trzeba szukać zmyślonych API, zbędnych abstrakcji, nowych zależności, ukrytych zmian stanu i kodu, którego autor nie potrafi wyjaśnić. Ćwiczenia bez AI utrzymują debugowanie, czytanie i projektowanie.

Metryki powinny obejmować błędy produkcyjne, rollbacki, obciążenie review, utrzymywalność i czas zrozumienia zmiany. Jeśli rośnie liczba PR, dług i incydenty, wdrożenie nie działa.

Dojrzała odpowiedź

Nie chodzi o zakaz agentów. To problem zarządzania inżynierią. Agenci są silni, gdy zmniejszają mechaniczną pracę i poszerzają eksplorację. Są groźni, gdy zastępują osąd o architekturze, ryzyku i utrzymaniu. Programista może pisać mniej surowego kodu, ale nadal musi rozumieć systemy i odpowiedzialność.