Znam Pythona. Napisałem 0 linii kodu. Claude Code napisał ich 847. I nie żałuję ani jednej.

Znam Pythona wystarczająco dobrze, żeby napisać aplikację samemu. Postanowiłem tego nie robić.

Przez kilka dni budowałem narzędzie do tworzenia notatek z filmów szkoleniowych. Wideo wchodzi, dokument Word wychodzi. W środku: Whisper transkrybuje audio, Claude API generuje notatki, python-docx formatuje wynik. Napisałem 0 linii kodu. Claude Code napisał ich 847 (i ani razu nie zapytał, czy wymagania są na pewno kompletne, co w projektach z prawdziwymi klientami byłoby nie lada osiągnięciem).

Dobry kucharz, który zamawia pizzę na wieczór, nie zdradza swojego fachu. Liczy, że składniki, godzina gotowania i sprzątanie po sobie kosztują go więcej niż dostawa. Programowanie z AI działa tak samo. Nie chodzi o to, że nie umiesz. Chodzi o to, co zrobisz z czasem, który odzyskujesz.

Ile kosztuje godzina twojego skupienia?

Skupienie to zasób, który się kończy. Nie jak prąd, który możesz dokupić. Bardziej jak bateria w telefonie, ta stara, po 3 latach eksploatacji, zaczynająca dzień z grzecznym 100% i kończąca go z panicznym 8% dokładnie w połowie drogi do domu.

Rano masz pełną zdolność do trudnych decyzji. Po kilku spotkaniach i emailach schodzi do połowy. Wieczorem siedzisz nad kodem i myślisz, że pracujesz. W rzeczywistości patrzysz w ekran i rozważasz, czy zmienna powinna się nazywać data czy result. To jest twoje skupienie. Wydajesz je na nazewnictwo zmiennych.

Napisanie serwera Flask z obsługą Server-Sent Events, kolejką wątków i 6 endpointami REST to 3-4 godziny dobrego kodowania. Albo 25 minut promptowania i godzina przeglądania tego, co Claude wygenerował. Claude nie bierze wolnych dni. Nie ma opinii na temat tego, który framework jest lepszy. Nie zatrzymuje się, żeby sprawdzić LinkedIn w trakcie pisania obsługi błędów.

Te 3-4 godziny skupienia możesz wydać na coś, czego AI nie zrobi. Na zrozumienie problemu. Na decyzję architektoniczną. Na przemyślenie, co aplikacja ma robić i dlaczego. To jest praca, której AI nie zastąpi, bo nie wie, co chcesz osiągnąć, dopóki mu nie powiesz. A jak mu powiesz, zrobi to dokładnie tak jak powiedziałeś. Łącznie ze wszystkimi rzeczami, których nie powiedziałeś, że nie chcesz.

Co Claude Code robi dobrze, a gdzie trzeba za nim sprzątać

Yan Krukau / Pexels

Claude Code jest dobry w rzeczach powtarzalnych i dobrze zdefiniowanych. Serwer Flask z endpointami: 3 minuty. Obsługa pliku .env: automatycznie. Interfejs HTML z drag-and-dropem i paskiem postępu: gotowe, bez szukania w Stack Overflow odpowiedzi z 2017 roku, które i tak zakładają, że używasz jQuery.

Jest mniej dobry w rzeczach specyficznych dla twojego środowiska. Przy integracji Whisper z ffmpeg na Windows, ffmpeg po instalacji przez winget trafia do AppData\Local\Microsoft\WinGet\Packages\ zamiast na PATH systemu. Claude wygenerował kod, który wyglądał poprawnie i działał na moim komputerze. Na laptopie uczestnika kursu: [WinError 2] Nie można odnaleźć pliku. Komunikat błędu pomocnie poinformował, że plik nie istnieje. Nie powiedział gdzie go szukać. Rozwiązałem to, bo rozumiałem dlaczego.

Przeglądasz kod AI nie dlatego, że mu nie ufasz. Dlatego, że to jedyny sposób, żebyś rozumiał, co wdrożyłeś. Piszę o tym dokładniej w artykule o weryfikacji odpowiedzi AI. Dane potwierdzają ten odruch: według ankiety Stack Overflow z 2025 roku, 66% programistów wskazuje "rozwiązania AI, które są prawie dobre, ale nie do końca" jako swoje największe codzienne frustracje. To zarówno skarga, jak i opis stanowiska pracy.

AI nie czyta twoich myśli. Generuje kod na podstawie opisu, który mu dajesz. Im precyzyjniejszy opis, tym mniej sprzątania potem. Umiejętność dobrego promptowania to dziś ważniejsza kompetencja niż znajomość składni języka. I tak jak składni, trzeba się jej nauczyć na własnych błędach, najlepiej w projekcie bez twardego deadline'u.

Kiedy mimo wszystko piszę kod sam

Kindel Media / Pexels

Są 3 sytuacje, w których sięgam po klawiaturę zamiast po prompt. Pierwsza: chcę naprawdę zrozumieć, dlaczego coś działa, nie tylko że działa. Druga: logika biznesowa, która istnieje wyłącznie w mojej głowie i nigdzie nie jest zapisana. Trzecia: naprawiam błąd Claude'a i szybciej jest przepisać 15 linii, niż tłumaczyć AI kontekst, który on i tak zna gorzej ode mnie.

Poza tymi 3 przypadkami: prompt, przegląd, build. Powtórzyć (ewentualnie kawa między powtórzeniami, ale to opcjonalne).

AI nie zastępuje programistów. AI zmienia to, kto może zostać programistą. Ktoś, kto rozumie problem biznesowy i potrafi precyzyjnie opisać, co system ma robić, może teraz zbudować działające oprogramowanie. Klient, dla którego zbudowałem własne narzędzie zamiast pokazywać mu Make.com, generuje treści i decyduje o publikacji sam. Make.com działa w tle. On tego nie widzi i nie potrzebuje widzieć.

Według ankiety Stack Overflow z 2025 roku, 84% programistów korzysta z AI w codziennej pracy. Tylko 29% twierdzi, że im ufa. To interesująca kombinacja: narzędzie, którego używa niemal każdy i któremu ufa niecała jedna trzecia. Zupełnie jak Excel przed odkryciem, że formuła tablicowa robi coś innego niż myślałeś.

Ja też zmieniłem, co robię. Mniej piszę kod. Więcej decyduję, co kod ma robić. Różnica jest większa, niż się wydaje.