AI przyspieszyło pisanie kodu, ale zabrało juniorom część zadań, na których kiedyś spokojnie uczyli się podstaw. Ten tekst jest o tym, dlaczego mentoring musi się zmienić — i dlaczego juniorzy potrzebują dziś nie tylko tasków, ale też kalibracji.

Część 1 z 3 — seria o mentorowaniu juniorów w erze AI
Był taki czas, kiedy juniorzy mieli prawo być wolni.
Pisali boilerplate. Budowali proste endpointy CRUD. Dopisywali testy do istniejącego kodu. Robili mechaniczne refaktoryzacje, których nikt inny specjalnie nie chciał ruszać.
To nie były efektowne zadania. Nie trafiały do prezentacji. Nie budowały imponującego portfolio.
Ale miały jedną ogromną wartość: dawały czas.
Czas, żeby się potknąć. Czas, żeby debugować. Czas, żeby zrozumieć framework. Czas, żeby zobaczyć, jak decyzje techniczne naprawdę działają w praktyce — a nie tylko w teorii.
Dzisiaj ta warstwa pracy zaczyna znikać.
I to wcale nie jest wyłącznie dobra wiadomość.
Przez lata wejście do zawodu wyglądało dość przewidywalnie. Pierwsze miesiące juniora w pracy zwykle kręciły się wokół powtarzalnych, względnie bezpiecznych zadań: endpointów, DTO, formularzy, testów, małych poprawek, prostych integracji, refaktoryzacji.
Z perspektywy biznesu — taniej było dać takie zadanie juniorowi niż seniorowi. Z perspektywy juniora — była to szansa, żeby uczyć się podstaw, dowożąc przy tym prawdziwą pracę.
I właśnie to „przy tym” było kluczowe.
Pisząc kolejny prosty endpoint, junior nie tylko produkował kod. Uczył się, gdzie framework zaczyna skrzypieć. Jak czytać błędy. Jak debugować. Jak wygląda dobre API. Dlaczego jeden wzorzec jest lepszy od drugiego. Jak zrozumieć decyzję, którą ktoś podjął rok wcześniej.
To była nieformalna edukacja zaszyta w codziennych zadaniach.
AI ten układ mocno naruszyło.
Copilot, Claude, Cursor i podobne narzędzia generują boilerplate w kilka sekund. CRUD przestaje być „łatwym zadaniem dla juniora”. Coraz częściej jest po prostu komendą wpisaną w oknie chatu.
I tutaj zaczyna się paradoks.
Zadania, na których juniorzy kiedyś uczyli się fachu, znikają — albo tracą dużą część swojej edukacyjnej wartości. Ale sama rola juniora nigdzie nie znika.
Po prostu dziś wchodzi się w nią na trudniejszych zasadach.
Bo jeśli samo wykonanie staje się tańsze, poprzeczka przesuwa się gdzie indziej.
Nie wystarczy już „napisać endpoint”. Trzeba wiedzieć, jaki endpoint w ogóle powinien powstać. Jaki kontrakt ma sens. Jak obsłużyć błędy. Gdzie postawić granicę odpowiedzialności. Czy ta integracja w ogóle powinna wyglądać właśnie w ten sposób.
To są decyzje, do których kiedyś się dorastało.
Po roku oglądania code review. Po dziesiątkach rozmów architektonicznych. Po kilku incydentach produkcyjnych. Po obserwowaniu, jak seniorzy rozkładają problemy na czynniki pierwsze.
Dziś junior ma być blisko tej rozmowy właściwie od początku.
I to jest problem.
Nie dlatego, że juniorzy są gorsi niż kiedyś. Nie są.
Po prostu weszli do innej gry.
A podejmowania decyzji nie da się nauczyć samym generowaniem kodu.
Jest też druga zmiana — moim zdaniem jeszcze ważniejsza.
Dzisiejszy junior musi opanować umiejętność, której wielu seniorów nigdy formalnie nikogo nie uczyło, bo sami łapali ją przez lata praktyki:
kiedy nie ufać AI.
Brzmi prosto. Nie jest proste.
Żeby zauważyć, że AI wygenerowało coś nie tak, trzeba mieć intuicję. Trzeba wiedzieć, jak wygląda kod, który „się kompiluje, ale jest zły”. Trzeba wyczuć, kiedy rozwiązanie jest zbyt generyczne, zbyt kruche albo zwyczajnie nie pasuje do kontekstu systemu.
Senior często widzi to po kilku sekundach.
Junior jeszcze nie.
I trudno mieć do niego o to pretensje.
Problem zaczyna się wtedy, gdy junior traktuje wynik z AI jako punkt końcowy, a nie punkt startowy. Wkleja kod do pull requesta, dostaje komentarze w review, poprawia je i idzie dalej.
W najlepszym przypadku — czegoś się nauczy. W najgorszym — zapamięta tylko, że „senior kazał to zmienić”.
To nie buduje intuicji.
Kiedyś junior pisał zły kod samodzielnie i uczył się, dlaczego był zły. Dzisiaj junior może zaakceptować zły kod wygenerowany przez AI i nadal nie rozumieć, dlaczego ten kod jest zły.
To nie jest ta sama ścieżka nauki.
Dlatego mentorowanie juniora w erze AI nie może już polegać tylko na tym, że dajemy mu zadanie, robimy review i oczekujemy, że „jakoś sam dojdzie”.
To przestaje działać.
Musimy uczyć bardziej świadomie.
Nie tylko: „napisz tę funkcję”. Raczej: „zobaczmy, jakie mamy możliwe podejścia”.
Nie tylko: „AI wygenerowało jakiś kod”. Raczej: „sprawdźmy, w których miejscach ten kod może nas oszukiwać”.
Nie tylko: „popraw pull request”. Raczej: „porozmawiajmy, skąd właściwie bierze się ta poprawka”.
Juniorzy dziś potrzebują nie tylko tasków. Potrzebują kalibracji.
Jak oceniać odpowiedź AI. Jak zadawać właściwe pytania uzupełniające. Jak weryfikować założenia. Jak nie pomylić szybkości z jakością. Jak odróżnić kod poprawny składniowo od kodu, który ma sens architektonicznie.
To zmienia rolę seniorów i tech leadów.
Większość z nas była mentorowana w starym modelu. Uczyliśmy się przez powtarzanie, przez kontakt z kodem, przez obserwowanie bardziej doświadczonych osób przy podejmowaniu decyzji.
Dzisiaj często próbujemy odtworzyć ten sam model, ale środowisko nie jest już takie samo.
Dajemy juniorowi zadanie, które kiedyś uczyło podstaw, i dziwimy się, że nie daje dziś takiego samego efektu.
Bo to zadanie działa już inaczej.
Jeśli junior używa AI, nie wystarczy oceniać wyłącznie końcowego kodu. Musimy też uczyć procesu dochodzenia do rozwiązania.
Może to oznaczać więcej pair programmingu. Może oznaczać wspólne przeglądanie promptów i odpowiedzi AI. Może oznaczać checklisty do weryfikowania wygenerowanego kodu. Może oznaczać zadania projektowane nie tylko pod dowiezienie funkcjonalności, ale też pod budowanie intuicji.
AI może być świetnym narzędziem do nauki.
Ale tylko wtedy, gdy ktoś nauczy juniorów, jak je kwestionować — a dziś prawie nikt tego nie uczy.
Bo junior z 2026 roku nie jest gorszy niż junior z 2019 roku.
Po prostu nie ma już tego samego pasa startowego.
A jeśli branża zabiera juniorom bezpieczną przestrzeń do nauki, musi świadomie zbudować nową.
W przeciwnym razie za kilka lat obudzimy się z pokoleniem programistów, którzy potrafią bardzo szybko generować kod — ale nie wiedzą, kiedy ten kod ma sens.
I to nie będzie porażka juniorów.
To będzie porażka naszego mentorowania.
Następny tekst w serii: czego AI fundamentalnie nie potrafi nauczyć juniora — i dlaczego zmienia to nasze podejście do mentoringu.
Czy ten wpis był pomocny?