Na Boiling Frogs 2026 jedna rozmowa wracała w kółko, niezależnie od stolika i rozmówcy: co się ze mną stanie, skoro AI pisze kod szybciej niż ja jestem w stanie go przeczytać?

Nie chodzi o to, czy AI zabierze nam pracę. To pytanie dla LinkedIna i nagłówków. Chodzi o coś bliższego skóry. Jeżeli programista przestaje pisać kod, czy dalej jest programistą? Jeśli codzienna praca polega na sterowaniu narzędziem, które materializuje moje myśli szybciej niż moje palce kiedykolwiek potrafiły, to co zostaje z mojej tożsamości zawodowej?

Przez dwa dni konferencji układałem sobie odpowiedź na to pytanie. I wyszło mi, że muszę spojrzeć na nowo na to, czym właściwie jest akt programowania. I to zahacza o to, co w tej całej dyskusji jest najtrudniejsze – o emocje.

Kryzys Link to heading

Najpierw trzeba zidentyfikować głęboką, często nieracjonalną i emocjonalną część tego, kim się jest. Dlaczego nazywam siebie programistą? Która dokładnie część moich obowiązków spełnia w wystarczającym stopniu moje własne — czysto intuicyjne — definicje?

Większość z nas pracuje w tym zawodzie nie dla szampana, pieniędzy i sławy, ale przede wszystkim dla “fanu” – dlatego, że akt tworzenia kodu to jest coś, co nas nakręca. Coś w chemii naszych mózgów powoduje że rozwiązanie czasem nawet błahego problemu technicznego i ubranie tego rozwiązania w ciąg poleceń jakiegoś języka programowania, generuje sporą dawkę satysfakcji. Do tej pory ten proces zawsze skutkował tym, że musieliśmy wystukać ten kod sami na klawiaturze naszego komputera. To spowodowało, że utożsamiamy ten fakt z “byciem programistą”. I wszystko było ok, aż nie pojawił się Claude, który może wyręczyć albo wręcz zastąpić nas w tym procesie.

Dlaczego jestem programistą? Link to heading

Odpowiedzi na to pytanie można szukać na dwa sposoby.

Jestem koderem, bo “kodzę”. Jestem programistą, bo stukam w klawisze i tworzę kod, który potem można uruchomić. Ta perspektywa nie pozostawia mi pola manewru. Claude potrafi generować nieskończenie więcej kodu niż ja kiedykolwiek będę w stanie. Jeśli moja tożsamość jako programisty jest ściśle powiązana z klepaniem w klawisze, to nie ma dla mnie ratunku. Prędzej czy później muszę stanąć twarzą w twarz z problemem, że Claude i ja pełnimy tę samą funkcję.

Jestem koderem, bo tworzę. Tworzę algorytm, rozwiązanie problemu, który ma postać “modelu mentalnego” w mojej głowie. Na początku jest on bardzo mglisty, ale wraz z pojawianiem się na ekranie linii kodu zaczynam rozumieć go coraz lepiej. Model ewoluuje w oparciu o feedback loop — nowy kod na ekranie budzi moje neurony w mózgu, wzbudzając procesy, na podstawie których dokonuję korekty modelu i poprawiam kod. Tutaj “kod” to projekcja mojego modelu mentalnego na świat rzeczywisty – implementacja abstrakcyjnego rozwiązania w konkretnym języku.

Ta perspektywa sugeruje, że najważniejszy jest proces twórczy i kontrola nad nim, a nie sama czynność pisania kodu. Nawet jeśli kod generuje Claude, to ja odpowiadam za koncepcję i kontrolę, więc nadal mogę się czuć programistą. Główna funkcja Claude’a to implementacja mojego modelu mentalnego.

Zagrożenia Link to heading

Najgroźniejsze jest to, że przestaniemy rozumieć kod, który “tworzymy”. Zlecanie Claude’owi napisania całego modułu, używając jedynie kilku promptów, w praktyce uniemożliwia zrozumienie kodu, który on wygeneruje. Jest tego po prostu za dużo — a co ważniejsze — nie mamy szansy zbudować naszego mentalnego modelu.

Co to daje? Taki kod jest ryzykowny – nadaje się świetnie na POC, eksperyment w poszukiwaniu konkretnego rozwiązania, “throw away” app. Jeśli natomiast taki kod ma się stać integralną częścią złożonego systemu produkcyjnego, to ryzyko biznesowe jest bardzo wysokie.

Unik Link to heading

W dalszym ciągu niezbędne jest, żeby inżynierowie posiadali mentalny model tego, w jaki sposób ich system działa. Potrzebują to wiedzieć, żeby móc go wdrożyć, utrzymać czy usprawniać. Bo Claude jest ciągle za bardzo zawodny. Wiemy też, że dziś żaden model językowy nie radzi sobie ze złożonymi problemami biznesowymi. Określanie poprawnych granic kontekstów, budowanie modeli wewnątrz nich, określanie odpowiedzialności — to wszystko jest ciągle na poziomie niewystarczającym, aby modele językowe mogły to robić “produkcyjnie”.

Teoria modelu mentalnego Link to heading

Często mówię, że programiści myślą palcami. Że póki programista nie stuka w klawisze, to nie zaczyna analizować problemu na “programistycznym” poziomie. Dlatego zespoły IT często mają problem z estymowaniem złożoności na refinementach. Nie włączają nam się obwody myślowe, które są odpowiedzialne za faktycznie realne procesy analityczne.

Jak pisałem wyżej, bycie programistą to w pewnym sensie umiejętność budowania mentalnego modelu reprezentującego rozwiązanie aktualnie analizowanego problemu. Co ważne, ten model jest budowany iteracyjnie i interaktywnie. Pisząc kod i patrząc na efekt jego działania, jesteśmy w stanie usprawnić nasz model w głowie, a co za tym idzie, poprawić nasz kod, który z kolei powoduje kolejne usprawnienia i przyrosty modelu w głowie. Na końcu otrzymujemy kod, który rozwiązuje problem, a który my dogłębnie rozumiemy.

Jeśli model mentalny buduje się w pętli, to szybkość tej pętli ma znaczenie.

Co jeśli zamiast pisać ten kod wygenerujesz go Claudem? Czy pozwoliłoby ci to przyspieszyć proces budowania mentalnego modelu? Nie mam za tym absolutnie żadnych argumentów natury naukowej. Mam swoje, czysto subiektywne wrażenie że potencjał do budowania tego mentalnego modelu, jest większy niż wydajność z jaką klikamy w klawisze. Mój iteracyjny przyrost zrozumienia problemu i znalezienia rozwiązania jest tak szybki jak pętla: model mentalny -> implementacja -> obserwacja -> wnioski. W związku z tym, jeżeli jestem w stanie jedną część tej pętli przyspieszyć, to możliwe, że zdołam szybciej tą pętlę pokonywać i szybciej dochodzić do rozwiązania.

Efekt Link to heading

Pracuj z Claudem w taki sposób, aby zintensyfikować proces generowania mentalnego modelu, który jest rozwiązaniem twojego problemu biznesowego. Niech on ci pomoże w zbudowaniu tego modelu. Iteruj z nim w niewielkich, ściśle określonych cyklach w taki sposób, abyś ciągle zachował kontrolę nad nim i pełne zrozumienie implementacji, którą on tworzy. I żebyś rozumiał i de facto był dyrygentem w tej orkiestrze, a nie tylko biernym słuchaczem. Tylko wtedy to, co napiszesz, będzie mogło w dalszym ciągu nazywać się “twoim” kodem.

Podsumowanie Link to heading

Na dziś wydaje mi się, że ta ścieżka dalszym ciągu zachowuje rzeczy, na których mi zależy. W takim świecie dalej czuję się programistą. W tym takim bardzo “niskopoziomowym” sensie rozwiązywania problemów za pomocą kodu.

Dzisiaj akt programowania nie musi polegać na stukaniu w klawisze, które faktycznie wypisują na ekranie polecenia języka, ale na budowaniu modelu i precyzowaniu go za pomocą rozmowy z Claudem, a on generuje tę żmudną resztę — kodzi :)