Jak mentorować juniorów w świecie AI — cztery etapy, których nie warto pomijać

Część 3 z 3 — seria o mentorowaniu juniorów w erze AI

W pierwszej części pisałem, że AI nie zabiło juniorów. Zabrało im raczej pas startowy — ten bezpieczny czas, w którym mogli być wolniejsi, próbować, mylić się i spokojnie dochodzić do rozwiązań.

W drugiej części przeszedłem przez rzeczy, których AI nie uczy: czytania kodu, którego samemu się nie napisało, debugowania czyjegoś toku rozumowania, wyczucia, kiedy „działa” naprawdę oznacza „jest gotowe”, a kiedy tylko „tym razem się udało”.

Ta część jest praktyczna. Skoro tego pasa startowego już nie ma, a AI nie zastąpi tego, czego juniorzy wcześniej uczyli się po drodze, to co właściwie mamy robić?

To jest model, którego używam dziś z juniorami w swoim zespole. Cztery etapy. Po kolei. Bez przeskakiwania.

Etap 1 — AI wyłączone

Pierwsze kilka tygodni. Bez Copilota. Bez Claude’a. Bez AI w IDE.

To nie jest żadne „hartowanie” juniora ani sentyment do starych czasów. Chodzi o zbudowanie jednej konkretnej rzeczy: intuicji.

Kiedy AI jest włączone od pierwszego dnia, junior nie buduje własnego punktu odniesienia. Nie wie, jak „normalnie” wygląda praca w danej bazie kodu. Nie wie, które wzorce są stylem zespołu, a które przypadkowym naleciałościem. Nie wie też, jak wygląda naprawdę trudny problem, bo każdy problem dostaje podobnie szybką odpowiedź.

Bez takiego punktu odniesienia kolejne etapy się rozsypują — bo junior nie ma z czym porównać tego, co wygeneruje AI.

Kilka tygodni wystarczy. Celem nie jest pełna samodzielność. Celem jest to, żeby junior miał już własne doświadczenie, do którego może się później odwołać.

Etap 2 — AI jako rubber duck

Teraz AI wraca — ale tylko do wyjaśniania, nie do generowania.

Dozwolone prompty wyglądają tak:

„Wyjaśnij, dlaczego to działa.”
„Co robi ten wzorzec w tym miejscu?”
„Przeprowadź mnie przez tę funkcję krok po kroku.”

Zakazane prompty wyglądają tak:

„Napisz mi funkcję, która…”
„Zaimplementuj…”
„Wygeneruj…”

Ten etap ćwiczy bardzo konkretny nawyk: używanie AI do zrozumienia, a nie do omijania myślenia. Junior nadal pisze kod samodzielnie. AI staje się takim niestrudzonym seniorem, którego można zapytać o wszystko, o każdej porze, bez poczucia, że zadaje się głupie pytanie.

To też moment, w którym junior uczy się, że AI potrafi bardzo pewnie wyjaśniać rzeczy błędnie. Lepiej złapać to wcześnie — kiedy junior nadal pisze kod ręcznie — niż później, kiedy AI zacznie już nie tylko tłumaczyć, ale też produkować rozwiązania.

Etap 3 — AI jako współpracownik

Teraz generowanie jest dozwolone. Ale z jedną zasadą: każdy wynik trzeba skrytykować, zanim trafi dalej.

Nie chodzi o „czy testy przechodzą”. Nie chodzi o „czy wygląda dobrze”. Junior musi umieć powiedzieć:

„To działa, ale jest złe, bo X.”
„To jest poprawne, ale nie pasuje do naszego sposobu pisania kodu, bo Y.”
„To rozwiązuje niewłaściwy problem — tak naprawdę potrzebujemy Z.”

Jeśli junior nie potrafi powiedzieć nic konkretnego o tym, co dostał od AI, to tego nie wypuszcza. Wraca do prompta albo pyta kogoś z zespołu.

To jest miejsce, w którym wiele zespołów się wykłada — przeskakują z etapu pierwszego od razu tutaj. Bez wcześniejszego etapu „rubber duck” junior nie ma języka, żeby sensownie ocenić wynik AI. Po prostu akceptuje albo odrzuca odpowiedź na wyczucie.

Etap 4 — AI jako narzędzie produktywności

Dopiero teraz pełne używanie AI zaczyna mieć sens. Boilerplate, refaktoryzacje, szkielety rozwiązań, mechaniczne zmiany — niech AI to robi.

Na tym etapie junior ma już:

własne wyczucie tego, jak działa i jak wygląda dana baza kodu (etap 1),
nawyk używania AI do rozumienia, a nie tylko do produkowania kodu (etap 2),
język i sposób myślenia potrzebne do oceniania wyników AI (etap 3).

Teraz może przyspieszyć, nie gubiąc kontekstu. Zauważa, kiedy AI halucynuje. Wyłapuje zły wzorzec, zanim rozleje się po kodzie. Używa AI tak, jak robi to senior — jako dźwigni, a nie jako protezy.

To jest etap, od którego wszyscy chcieliby zacząć. Problem w tym, że działa dopiero wtedy, gdy trzy poprzednie etapy dały juniorowi coś, wobec czego może ten wynik AI ocenić.

Ile powinien trwać każdy etap?

Często słyszę to pytanie. Uczciwa odpowiedź brzmi: to zależy od juniora, bazy kodu i tego, co dana osoba dowozi.

Ale orientacyjnie wygląda to tak:

Etap 1: 2–4 tygodnie
Etap 2: 4–6 tygodni
Etap 3: 2–3 miesiące
Etap 4: stale, już jako normalny sposób pracy

Dokładne liczby są mniej ważne niż kolejność. Największym problemem nie jest tempo, tylko przeskakiwanie etapów.

Ile to kosztuje?

Ten model jest wolniejszy niż podejście „dajmy juniorowi Copilota od pierwszego dnia”. Wyraźnie wolniejszy w pierwszym kwartale. Pewnie też wolniejszy w drugim.

Ale zakład jest taki, że około dziewiątego miesiąca masz inżyniera, który naprawdę potrafi dobrze używać AI — a nie kogoś, kto wygląda produktywnie na papierze, ale nie umie rozpoznać, kiedy jego własny kod jest zły.

Jako tech lead to Ty musisz podjąć ten zakład. Nikt wyżej nie przyjdzie i nie powie Ci, żebyś celowo zwolnił juniora.

Ta seria zaczęła się od problemu: juniorzy trafili do innej gry niż my kiedyś — bez bezpiecznego pasa startowego, na którym mogli spokojnie się uczyć.

Kończy się wyborem. Tego pasa już nie ma. Możemy udawać, że nic się nie zmieniło, i wypuszczać juniorów, którzy nie potrafią myśleć bez AI. Albo możemy zbudować nowy pas startowy — krótszy, bardziej świadomy i taki, który działa z AI, a nie obok niego.

To nie byłaby porażka juniorów. To byłaby porażka mentorowania, jeśli tego nie zrobimy.