Czy uczyć się programowania w 2026? List od kogoś, kto dziesięć lat temu wchodził do zawodu, który w międzyczasie stał się innym zawodem

Pierwszy dzień

Jeśli to czytasz, pewnie masz w głowie dwie sprzeczne rzeczy naraz: że AI zabiera pracę programistom i że to wciąż jeden z lepszych zawodów, jakie można sobie wybrać. Obie są trochę prawdziwe. Nie będę Ci mówił, która bardziej. Opowiem Ci, jak to wyglądało u mnie — bo wchodziłem do tego zawodu dziesięć lat temu, a zawód w międzyczasie stał się innym zawodem. Nazwa ta sama, praca inna.

Mój pierwszy dzień w pracy biurowej mnie stresował. Wszystko puściło dopiero, kiedy usiadłem przy swoim pierwszym stanowisku. Miałem mentora — bardzo ludzkiego, empatycznego i jednocześnie koksa w programowaniu. Taka kombinacja zdarza się rzadziej, niż powinna, i dziś wiem, ile mu zawdzięczam.

Pierwsze zaskoczenie przyszło szybko: nie potrafiłem tak łatwo, jak mi się wydawało, postawić sobie środowiska do pracy na nowym komputerze. Zanim napisałem pierwszą linijkę kodu, minęło kilka dni. Nie godzin — dni. Dziś to byłaby godzina czy dwie z agentem. Wtedy to była udręka.

Piszę o tym nie dlatego, że to zabawna anegdota. Piszę, bo Twój dzisiejszy strach — „nie dam rady, wszyscy inni wiedzą więcej” — jest dokładnie tym, co czułem przy tamtym biurku.

Trzy miesiące i jedno zdanie

Bałem się, że nie jestem gotowy. I miałem powody: uczyłem się programowania zaledwie trzy miesiące, od zera. Nie miałem o tym większego pojęcia.

To, co miałem, to trzy rzeczy. Bardzo dobrze skonstruowany plan — oparty na researchu rynku pracy, nie na tym, co akurat było modne. Otwarty umysł. I ogrom motywacji, która pozwalała mi nie myśleć o przeciwnościach, tylko po prostu działać.

Z tych trzech rzeczy wzięły się trzy miesiące pilnej nauki i jeden działający projekt, który pokazałem na rozmowie. Zapamiętaj te trzy rzeczy, bo wrócę do nich na końcu. Rynek od tamtej pory przeszedł transformację, a ja uważam, że one są niezmiennie cenne.

Strach się nie spełnił. Nie dlatego, że wiedziałem wystarczająco dużo — nie wiedziałem. Traciłem masę czasu na obsługę narzędzi, których nie rozumiałem; docker compose był dla mnie wtedy czarną magią, a dziś to coś, czego nawet nie zauważam i bez czego nie wyobrażam sobie pracy. Strach się nie spełnił, bo ten zawód jest specyficzny: nie wygrywa w nim to, co wiesz. Wygrywa umiejętność nieustannego przyswajania nowych tematów, logiczne myślenie i otwarta głowa.

To jedno zdanie, które chciałbym, żeby zostało Ci z tego listu, nawet jeśli reszta się zatrze.

Jak AI zmieniło moją pracę

Do niedawna wszystko wyglądało tak, jak sobie wyobrażasz. Pisałem cały kod ręcznie. Testowałem ręcznie. Szukałem przyczyn błędów ręcznie. To była wciągająca praca i byłem w niej coraz lepszy. Do momentu, aż wszystko się zmieniło.

Kiedy po raz pierwszy odpaliłem w konsoli Claude Code — wtedy jeszcze w wersji beta — wystarczyło mi kilka dni zabawy, żeby otworzyły mi się oczy: czasy, w których pracuję, przejdą gigantyczną zmianę. Na początku byłem pewien, że odkryłem złotego graala. Kilka tygodni później pisałem w tym pierwszy projekt dla klienta.

I tu zaczyna się część, której w większości wpisów o AI nie przeczytasz.

Projekt trafił do testów na prawdziwych użytkownikach — pracownikach firmy klienta, bo to było narzędzie dla nich. Klient zgodził się na to świadomie, jako eksperyment. I eksperyment pokazał, jak wcześnie byliśmy w tej rewolucji.

Główna pętla aplikacji była fatalnie poplątana. Model, dostając instrukcje, plątał ją jeszcze bardziej. Wyglądało to tak: klient przekazuje od użytkowników, co nie działa. Ja przekazuję to modelowi, razem z tym, jak naprawić. Model naprawia jedno, a psuje drugie. I od początku. Klient się denerwował, ja też. Ping-pong trwał dniami, może tygodniami.

Z perspektywy czasu widzę, co poszło nie tak: proces projektowania był zły od początku, bo nie było jasnego planu na ten projekt, tylko powstawał cegiełka po cegiełce. Model wtedy dużo halucynował. Moje instrukcje były niejasne. Ale wtedy tego nie widziałem. Widziałem tylko, że on tego nie naprawi.

Więc przestałem prosić i zacząłem czytać. Zagłębiłem się w kod, analizowałem go, pisałem poprawki własnoręcznie, tak jak przez wszystkie poprzednie lata. I to był moment zwątpienia — ale też moment, w którym zrozumiałem dwie rzeczy naraz. Po pierwsze: agenta nie można zostawić bez nadzoru, bo narobi dziadostwa. Po drugie: żeby go nadzorować, trzeba mieć doświadczenie i zrozumienie. Tych dziesięć lat nagle nie było balastem. Było jedyną rzeczą, która ratowała projekt.

Potem powstały lepsze modele, a ja postanowiłem dać agentowi drugą szansę. I w końcu zacząłem dostawać to, czego potrzebowałem. Wtedy już byłem pewien, że to tylko kwestia czasu, kiedy wszystko się zmieni. Kiedy inni wątpili, ja korzystałem.

Ręce i głowa zamieniły się miejscami

Dzisiaj moja praca jest głównie koncepcyjna. Kiedyś większość dnia szła w pisanie kodu, a myślenie o tym, co i dlaczego budujemy, działo się w przerwach między jedną linijką a drugą. Teraz jest odwrotnie: większość dnia to decyzje, plan, kryteria, czytanie tego, co zrobiły agenty. Pisanie kodu rękami to margines.

Nie zmieniło się to, za co odpowiadam. Dalej ja decyduję, co znaczy „poprawne”, dalej ja odpowiadam za to, co trafia do klienta. Zmieniło się to, co robię rękami. I jeśli zastanawiasz się, czego się uczyć, to właśnie tu jest odpowiedź: ucz się tej części, która została mi w głowie, nie tej, która poszła w ręce agenta.

Czy warto uczyć się programowania, skoro jest AI?

Teraz będzie niewygodnie, bo nie chcę Cię okłamać.

Wejście do branży jest dziś trudniejsze niż dziesięć lat temu. Nie tylko ja tak czuję: według raportu No Fluff Jobs „Rynek pracy w IT 2025/2026” na juniorów przypada 5,3% ofert, jedna na dwadzieścia, podczas gdy prawie 60% rekrutacji dotyczy seniorów, a około 35% midów. Potrzebny jest ktoś, kto rozumie, co się dzieje — coraz mniej w kodzie, a więcej w jego architekturze. A do tego trzeba albo doświadczenia, albo eksperckiej umiejętności posługiwania się modelami i rozpoznawania, co z tego, co proponują, jest naprawdę dobre. Tak czy inaczej: doświadczenia. A doświadczenia nie da się wygenerować.

Z tych 5% wynika coś, czego żaden kurs Ci nie powie: nie celuj w juniora. Stanowisko junior umiera, bo robotę, którą dawało się juniorowi na naukę, dziś robi agent. Proste zadanie pod nadzorem starszego kolegi? To jest dokładnie opis pracy agenta. Walka o co dwudziestą ofertę z setkami innych osób po kursie jest przegrana na starcie. Co trzecia oferta jest dla mida. Celuj od razu tam: w kogoś, kto bierze zadanie i przynosi działający wynik, a agenty są jego juniorami. Dziesięć lat temu to by było bezczelne. Dziś to jedyne wejście, które jest otwarte, bo mid to nie liczba lat w CV, tylko umiejętność wzięcia odpowiedzialności za wynik. I właśnie tego da się nauczyć na własnych projektach, bez etatu.

Druga niewygodna rzecz: wrzucanie kodu na GitHuba i chwalenie się nim w CV nie ma już sensu. Taki kod da się dziś wygenerować w kilka minut i osoba, która czyta Twoje CV, o tym wie. Nikt nie ma czasu go czytać i w zasadzie nie ma po co, bo wiadomo, że jest napisany poprawnie. Liczy się, czy projekt działa. Portfolio to dziś działająca rzecz, którą da się kliknąć i która ma użytkownika, a nie repozytorium.

To, co się liczy, to sposób myślenia i zrozumienie nowego procesu tworzenia oprogramowania. I to, wbrew pozorom, jest dobra wiadomość — bo tego da się nauczyć od zera, bez dziesięciu lat za sobą. Potrzeba praktyki.

Czego się uczyć w 2026, a czego nie

Gdybym dziś zaczynał, spróbowałbym tak:

• Nie bać się tematów, na których się nie znasz. Budowałem projekty w dziedzinach, o których nie miałem pojęcia — i ostatnio już się zdarza, że bez zerknięcia w kod ani razu. Dziś stoją na produkcji — dlatego, że otwarta głowa pozwala szybko przyswoić wiedzę, a doświadczenie projektowe podjąć właściwe decyzje. Z całej tej listy to jest najważniejsze.
• Uczyć się mówić, czego chcesz, tak, żeby dało się sprawdzić, czy to dostałeś. „Zrób logowanie” to życzenie. „Po trzech błędnych hasłach konto blokuje się na kwadrans” to zadanie, bo na pytanie, czy jest zrobione, da się odpowiedzieć tak albo nie. Mój pierwszy projekt z agentem rozsypał się dokładnie na tym: dawałem życzenia, dostawałem zgadywanie. Dziś każde zadanie piszę według jednego szablonu. Powstał dla ludzi, którzy zlecali mi pracę, i okazało się, że agentom służy tak samo.
• Budować własne rzeczy z agentem — jak najwięcej. Nie tutoriale. Coś, co ma użytkownika, choćby jednego, i działa dokładnie tak, jak było w planie. Kierować pracą agenta, dopytywać i dociekać, dlaczego tak, a nie inaczej, jakie są alternatywy, dlaczego ta jest najlepsza.

I czego bym nie robił: nie kupowałbym kursów, które obiecują pracę w trzy miesiące. Wiem, że mi się udało w trzy miesiące, ale nie dzięki kursowi — nie wydałem na naukę ani złotówki. Nie porównywałbym się z ludźmi na LinkedInie, bo tam widać tylko to, co ktoś chciał pokazać. I nie uczyłbym się „pod rekrutację”, bo rekrutacja też się zmienia i za rok będzie sprawdzać co innego.

Jedno zdanie na koniec

Obiecałem wrócić do trzech rzeczy z początku: plan, otwarty umysł, motywacja. Dziesięć lat temu wprowadziły mnie one do branży z trzema miesiącami wiedzy i jednym działającym projektem. Dziś sama wiedza z kursu Cię nie wprowadzi — ale te trzy rzeczy wciąż tak. Zmieniło się tylko to, na co trzeba je skierować. Plan: na to, czego rynek szuka teraz, czyli na rozumienie procesu i architektury, nie na kolejny framework. Otwarty umysł: na dziedziny, w których będziesz budować, bo kod przestał być tą trudną częścią. Motywację: na własne projekty z prawdziwym użytkownikiem, bo to jedyne doświadczenie, którego nie da się wygenerować.

Na koniec wrócę jeszcze do mojego mentora. Dostałem od niego masę wiedzy, która przeprowadziła mnie przez pierwsze dwa lata. Ale ważniejsze było coś innego: poczucie przynależności. Zostałem zaakceptowany przez ludzi z branży. Dostałem empatię i ciekawe historie od kogoś, kto już tam był. Tego nie dostaniesz od żadnego agenta — i dlatego piszę ten list.

Nie obiecuję Ci pracy. Nie wiem, jak będzie wyglądał rynek za rok, bo jest dziś jeszcze bardziej dynamiczny niż dziesięć lat temu. Ale jedno Ci powiem: nie bój się nieznanego i miej otwarty umysł. Wszystko inne da się dostosować po drodze.

Co dalej

Ten list otwiera serię. Napisałem w nim, że wejście jest trudniejsze i że trzeba celować wyżej, więc teraz mam dług: pokazać, jak. Kolejne listy będą o konkretach. Jak zbudować z agentem pierwszą rzecz, która ma użytkownika, i nie skończyć z plątaniną, jaką ja skończyłem przy pierwszym projekcie dla klienta. Jak rozbijać problem na zadania, które agent zrobi dobrze. Jak zdobyć doświadczenie mida, kiedy nikt nie chce dać Ci etatu juniora. Nie wszystko mam już rozpisane i nie będę udawał, że mam.

Dlatego jeśli masz pytanie, na które nie ma tu odpowiedzi — napisz do mnie. Odpiszę, a pytania, które przyjdą, wyznaczą kolejne listy.