Rozwój juniorów, gdy kod piszą agenci

Rozwój junior developerów w zespole, w którym kod piszą agenci, polega na zastąpieniu praktyki, którą kiedyś dawało pisanie kodu, praktyką celową: ręcznym debugowaniem, code review zmian agenta jako nauką i pisaniem specyfikacji, które senior sprawdza przed uruchomieniem agenta. Bez takiego planu juniorzy szybko dowożą, ale nie budują osądu potrzebnego do nadzorowania agentów.

Najnowsza osoba w twoim zespole zmergowała w pierwszym miesiącu 14 pull requestów, więcej niż ktokolwiek inny. Potem na stagingu nie zadziałało ponowienie płatności i okazało się, że nie potrafi powiedzieć, co robi jej własna zmiana, bo napisał ją agent, a testy były zielone. Senior, który kiedyś odpowiadał na jej pytania, zauważył, że przestała je zadawać. Ta strona jest dla tech leada, który ma z juniora zrobić seniora, oraz dla CTO i zarządu, którzy decydują, czy w ogóle dalej zatrudniać juniorów.

Co daje plan rozwoju juniorów w zespole pracującym z agentami

Dowody na temat juniorów i agentów, z datami i ograniczeniami, żebyś mógł obronić plan przed sceptycznym przełożonym.
Cztery praktyki, które zastępują to, czego kiedyś uczyło pisanie kodu, oraz dowody, które lider sprawdza przy każdej z nich.
Konfigurację do nauki w Claude Code, Codex i Cursorze oraz cztery prompty do skopiowania.
Format cotygodniowej sesji code review nastawionej na naukę i pętlę przeglądu specyfikacji, którą uruchomisz od następnego sprintu.
Plan na 90 dni dla nowego juniora i cztery miary rozwoju, które nie są liczbą pull requestów.
Tabelę decyzyjną dla CTO i zarządu na temat ryzyka dla ścieżki talentów, gdy firma nie zatrudnia juniorów.

Co mówią dowody o juniorach i agentach kodujących?

Bezpośrednio o juniorach mówią dwa źródła. Oba pochodzą od Anthropic, dostawcy modeli, który bada własny produkt i własnych pracowników, więc tak je czytaj. W chwili pisania tej strony nie znaleźliśmy niezależnego badania o porównywalnym projekcie.

Badanie w miejscu pracy. W sierpniu 2025 roku Anthropic przeprowadził ankietę wśród 132 swoich inżynierów i badaczy oraz 53 pogłębione wywiady. Wyniki opublikowano 2 grudnia 2025 roku. Jeden z seniorów powiedział: „It’s been sad that more junior people don’t come to me with questions as often, though they definitely get their questions answered more effectively and learn faster” (szkoda, że juniorzy rzadziej przychodzą z pytaniami, choć dostają odpowiedzi skuteczniej i uczą się szybciej). Raport nazywa ryzyko, które się za tym kryje, „paradoksem nadzoru” (ang. paradox of supervision):

„effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from AI overuse.”

Czyli: skuteczne korzystanie z Claude wymaga nadzoru, a nadzór wymaga właśnie tych umiejętności programistycznych, które mogą zanikać przy nadużywaniu AI. Inny senior wyjaśnił, skąd wziął się jego osąd: „I developed that ability by doing SWE ‘the hard way’” (wyrobiłem to, robiąc inżynierię oprogramowania „na piechotę”). Jego zdaniem na początku kariery wymagałoby to „a lot of deliberate effort”, czyli dużo celowego wysiłku. To deklaracje pracowników jednej firmy.

Badanie kształtowania umiejętności. 29 stycznia 2026 roku Judy Hanwen Shen i Alex Tamkin opublikowali badanie randomizowane z udziałem 52 inżynierów, w większości juniorów, którzy uczyli się nowej biblioteki w Pythonie. Grupa korzystająca z asystenta AI uzyskała w quizie sprawdzającym zrozumienie średnio 50%, a grupa pisząca kod ręcznie 67%. Grupa z AI skończyła około dwóch minut szybciej, ale ta różnica nie była istotna statystycznie. Największa różnica dotyczyła pytań o debugowanie. Najlepiej wypadły osoby, które zadawały wyłącznie pytania koncepcyjne, albo generowały kod, a potem dopytywały, jak działa. Najgorzej te, które oddały agentowi całe pisanie kodu albo zdały się na niego przy debugowaniu. Autorzy sami zaznaczają, że próba była mała, a quiz mierzył zrozumienie tuż po zadaniu, a nie umiejętności długoterminowe.

Praktyczny wniosek dla lidera: dostęp do agenta nie blokuje nauki juniora, ale nieustrukturyzowane delegowanie już tak. Plan poniżej nadaje mu strukturę. Twój warsztat i kariera, gdy kod piszą agenci omawia te same dowody z perspektywy pojedynczego developera.

Cztery praktyki, które zastępują to, czego uczyło pisanie kodu

Juniorzy uczyli się dawniej, pisząc kod, który nie działał, a potem go debugując. Gdy kod pisze agent, ta pętla znika, chyba że odbudujesz ją celowo. Każda z poniższych praktyk odbudowuje jej fragment i każda zostawia artefakt, który lider sprawdzi w kilka minut, bez czytania diffów juniora.

Praktyka	Co robi junior	Co robi agent	Dowód, który sprawdza lider
Praktyka ręczna	Debuguje od własnej hipotezy; raz w tygodniu rozwiązuje zadanie bez agenta	Nic w trakcie; potem porównuje swoją odpowiedź	Dziennik kata: czas, błędy i czy hipoteza była trafna
Code review jako nauka	Przewiduje zmianę, robi review pull requestu agenta i wyjaśnia go własnymi słowami	Pisze zmianę, potem ocenia wyjaśnienie na tle kodu	Liczba pominięć w wyjaśnieniach tygodniowo, na znanych modułach
Pisanie specyfikacji	Pisze kryteria akceptacji przed każdym zadaniem dla agenta	Implementuje według kryteriów i raportuje, które przechodzą	Odsetek zgodności ze specyfikacją za pierwszym podejściem i uwagi seniora do specyfikacji
Własna kontrola automatyczna	Raz w miesiącu dodaje automatyczną kontrolę, której agent nie może edytować	Proponuje kandydatów na podstawie niedawnych defektów	Zmergowane kontrole i defekty, które każda z nich od tego czasu wyłapała

Kolejność ma znaczenie. Praktyka ręczna i code review jako nauka są pierwsze, bo junior nie napisze użytecznej specyfikacji dla systemu, którego jeszcze nie potrafi wyjaśnić. Pisanie specyfikacji zaczyna się w drugim miesiącu, a własna kontrola automatyczna w trzecim.

Co junior nadal ćwiczy ręcznie

Te rzeczy zostają bez agenta. Wpisz je do planu sprintu jako nazwane pozycje, a nie dobre intencje:

Najpierw debuguj, potem deleguj. Gdy test nie przechodzi, junior zapisuje hipotezę i przez 15 minut ją sprawdza, zanim odda błąd agentowi. W badaniu kształtowania umiejętności to właśnie debugowanie dało największą różnicę.
Jedno zadanie tygodniowo bez agenta. Wybierz mały, prawdziwy ticket na 60–90 minut w module, za który junior odpowiada. Bez agenta, z seniorem dostępnym do pytań.
Wyjaśnienie przed zatwierdzeniem. Zanim junior oznaczy swój pull request napisany przez agenta jako gotowy, wyjaśnia zmianę bez otwartego diffu.
Przeczytanie jednego modułu od początku do końca. Raz w miesiącu junior czyta moduł, który agent często zmienia, i pisze pół strony notatki o przepływie danych i trybach awarii.

Zapamiętywanie składni, boilerplate, scaffolding i sprawdzanie konfiguracji można oddać agentowi od pierwszego dnia. Takie błędy wyłapują bramki jakości, a ćwiczenie tego zabiera czas potrzebny na cztery praktyki.

Skonfiguruj tryb nauki w każdym narzędziu

Claude Code ma wbudowany styl Learning. W Codex (w wersji 0.157.1 go nie znaleźliśmy) i w Cursorze przekazujesz agentowi ten sam kontrakt jako instrukcję.

Claude Code ma oprócz domyślnego cztery wbudowane style odpowiedzi (output styles): Proactive, Concise, Explanatory i Learning. W sesji uruchom /output-style (dodane w Claude Code 2.1.269) i wybierz Learning, gdy junior pracuje w podsystemie, którego się uczy. Explanatory wybierz, gdy chce poznać uzasadnienia bez ćwiczeń. Do ćwiczenia specyfikacji użyj trybu planowania (/plan): agent przygotowuje plan, a edycje są zablokowane do jego zatwierdzenia, więc junior porównuje plan ze swoimi kryteriami akceptacji, zanim powstanie jakikolwiek kod.

W codex --help ani w codex features list nie znaleźliśmy wbudowanego trybu nauki ani trybu wyjaśniającego (Codex CLI 0.157.1, sprawdzone 26 września 2026 roku). Junior wkleja poniższy kontrakt nauki na początku sesji. Do ćwiczenia specyfikacji użyj /plan, a do porównania w sesji code review z następnej sekcji /review albo codex review. Nie wpisuj kontraktu nauki do wspólnego AGENTS.md: Codex czyta ten plik w sesji każdej osoby w zespole, więc kontrakt spowolniłby wszystkich.

I am a junior engineer learning this part of the codebase. Work under these
rules for the whole session:
1. Before writing code, explain your plan in five lines or fewer and name the
   concept in this codebase the plan depends on.
2. When a test fails, do not fix it. Tell me which test failed and ask for my
   hypothesis first. Only after I answer, give yours and compare the two.
3. After each change, ask me one question that checks I understood why it
   works. Wait for my answer and correct me if I am wrong.
4. Leave the final function of the task (10-20 lines) for me to write. Tell me
   what it must do and which tests will check it.
5. At the end, list the three things in this change I should be able to
   explain to a senior without notes.

Prowadź cotygodniowe sesje code review nastawione na naukę

Code review było miejscem, w którym juniorzy uczyli się od seniorów. Gdy większość pull requestów otwierają agenci, junior może przejrzeć znacznie więcej kodu niż kiedyś i uczyć się przy każdym review, o ile ma ono strukturę i kogoś, kto je ocenia. Prowadź tę sesję raz w tygodniu przez 45 minut, z jednym seniorem i maksymalnie trzema juniorami.

Wybierz jeden zmergowany pull request agenta z ostatniego tygodnia, w module, w którym pracują juniorzy. Lepiej taki, który dotyka obsługi błędów albo stanu, niż zmianę nazwy.
Przewidywanie (5 minut). Na podstawie samego ticketu i kryteriów akceptacji każdy junior zapisuje dwie linijki: czego zmiana musi dotknąć i co może pójść nie tak.
Review (15 minut). Każdy junior przegląda diff i zapisuje uwagi, klasyfikując je jako: logika, bezpieczeństwo, wydajność, projekt albo luka w testach.
Porównanie z automatycznym recenzentem (10 minut). Uruchom na tej samej zmianie agenta do review używanego w zespole: /code-review w Claude Code, /review albo codex review w Codex, albo przeczytaj komentarze Bugbota na pull requeście, jeśli zespół używa recenzenta Cursora. Wypisz, co znaleźli juniorzy, a czego nie znalazł agent, i odwrotnie.
Omówienie z seniorem (15 minut). Senior wskazuje najważniejszą uwagę i mówi dlaczego. Sesja kończy się jednym działaniem: nową kontrolą, notatką w dokumentacji modułu albo wprost powiedzianym „nic”.

Sednem jest krok porównania. Junior, który znajduje to, co pominął agent do review, uczy się osądu. Junior, który znajduje tylko to, co agent też znalazł, uczy się być wolniejszym agentem do review i omówienie powinno to nazwać wprost.

A junior engineer will now explain the change in this pull request without
looking at the diff. After they finish, compare the explanation with what the
code actually does. List what they got right, what they missed, and anything
they got wrong, citing file and line for each point. Then ask one question
about a failure mode of this change they did not mention. Do not praise the
explanation; report only the differences. End with a count of missed points
so the result can be logged.

Pisanie specyfikacji jako pętla treningowa

Specyfikacja pokazuje, co junior zrozumiał, zanim powstanie jakikolwiek kod, więc jest najtańszą rzeczą, jaką senior może przejrzeć. Dziesięć minut nad kryteriami akceptacji uczy więcej niż godzina nad gotowym diffem i przenosi uwagę seniora tam, gdzie agenci najbardziej potrzebują ludzi. Kanonicznym przewodnikiem po formacie jest strona Wykonywalne kryteria akceptacji: od historyjki do czerwonego testu.

Junior pisze kryteria dla ticketu: zachowanie w formie Given / When / Then, przypadki brzegowe, to, co nie może się zmienić, polecenie, które dowodzi, że zadanie jest skończone, oraz, jeśli zespół stosuje wykonywalne kryteria, czerwony test.
Senior przegląda specyfikację, nie kod (10 minut). Korzysta z listy kontrolnej poniżej. Zwraca uwagi, a nie przepisaną specyfikację.
Agent pracuje według poprawionej specyfikacji, najpierw w trybie planowania, potem implementuje.
Junior zapisuje wynik pierwszego podejścia: które kryteria przeszły za pierwszym razem, które nie i dlaczego.
Na spotkaniu one-to-one omówcie chybienia. Chybienie z powodu niejasnego kryterium to lekcja o specyfikacji. Chybienie z winy agenta to lekcja o weryfikacji: która kontrola by je wyłapała?

Tę listę kontrolną do kroku 2 możesz przyjąć bez zmian:

## Przegląd specyfikacji (10 minut, senior)
- [ ] Każde kryterium jest obserwowalne: test albo polecenie może je rozstrzygnąć
- [ ] Co najmniej jeden przypadek brzegowy, którego junior nie wziął z ticketu
- [ ] „Nie może się zmienić” wskazuje konkretne pliki, API lub zachowania
- [ ] Polecenie „gotowe” działa w CI, nie tylko na laptopie
- [ ] Podana jest klasa ryzyka (auth, pieniądze, schemat, migracja = senior czyta kod)
- [ ] Jedno pytanie zwrotne do juniora o to, po co istnieje któreś kryterium

Here are the acceptance criteria I wrote for this ticket. Do not implement
anything. Act as a senior reviewer:
1. For each criterion, say whether a test or command could decide it, and if
   not, why not.
2. List up to three edge cases the criteria miss, based on the code in the
   modules this ticket touches. Cite the file for each.
3. Name anything the change could break that the criteria do not protect.
4. Ask me one question about a criterion whose purpose is unclear.
Do not rewrite the criteria for me.

Plan na 90 dni dla nowego juniora w zespole pracującym z agentami

Skopiuj tę tabelę do dokumentu onboardingowego juniora. Każdy miesiąc dodaje praktykę i zachowuje poprzednie.

Okres	Nowe praktyki	Korzystanie z agenta	Dowód na wyjściu, który zatwierdza lider
Dni 1–30	Praktyka ręczna, wyjaśnianie zmian, cotygodniowa sesja code review nastawiona na naukę	Styl Learning lub kontrakt nauki włączony; małe tickety o niskim ryzyku	Cztery wpisy w dzienniku kata; malejąca liczba pominięć w wyjaśnieniach na module juniora; potrafi przeprowadzić seniora przez jedną ścieżkę żądania od początku do końca
Dni 31–60	Pisanie specyfikacji z przeglądem seniora przy każdym tickecie	Najpierw plan, potem implementacja; nadal bez klas zmian wysokiego ryzyka	Zgodność za pierwszym podejściem zapisana przy każdym tickecie; co najmniej jedno chybienie specyfikacji omówione i zrozumiane
Dni 61–90	Jedna zmergowana kontrola odporna na agenta	Kontrakt nauki tylko dla nowych podsystemów; zwykła praca w pozostałych	Zmergowana kontrola, która wyłapała albo wyłapałaby prawdziwy defekt; pół strony notatki o trybach awarii jednego modułu

Po 90 dniach plan juniora przechodzi w indywidualny plan umiejętności opisany na stronie Twój warsztat i kariera, gdy kod piszą agenci, przeglądany co kwartał.

Search the git history of this repository for a bug fix from the last six
months that came with a regression test. Pick one in the module
<module-the-junior-owns> where the bug was not obvious from the error message.
Create a new branch named kata/<short-name> that reverts only the fix and
keeps the regression test, so the test fails. Write a one-paragraph ticket
describing the symptom a user would report, without naming the cause or the
file. Squash the revert into a single commit titled "kata: <short-name>". Do
not explain the bug in the branch, commit message, or anywhere the junior will
see. Give me the branch name and the ticket text only.

Ten prompt uruchamia senior, nie junior, po podmianie placeholdera na moduł, za który odpowiada junior. Senior zachowuje oryginalny commit z poprawką jako klucz odpowiedzi, a junior rozwiązuje kata bez agenta. Poproś juniora, żeby nie czytał historii gałęzi: commit z revertem zdradza odpowiedź.

Jak sprawdzić, że junior się rozwija, a nie tylko dowozi?

Liczba zmergowanych pull requestów i zmienionych linii mierzy agenta, nie juniora. Zamiast tego stosuj te cztery miary. Junior je zapisuje, a lider przegląda co dwa tygodnie:

Miara	Definicja	Zdrowy kierunek
Pominięcia w wyjaśnieniach	Pominięte lub błędne punkty w ocenionym wyjaśnieniu, na zmianę, w modułach, w których junior już pracował	Spada przez pierwsze 60 dni, potem zostaje niska
Zgodność ze specyfikacją za pierwszym podejściem	Odsetek ticketów, w których pierwszy wynik agenta spełnił wszystkie kryteria akceptacji	Rośnie od 31. dnia; chybienia mają spisany powód
Trend kata	Czas i liczba błędów w cotygodniowym zadaniu bez agenta, w tym samym module	Stały albo lepszy; systematyczny wzrost to wczesny sygnał zaniku umiejętności
Znaleziska zamienione w kontrole	Defekty znalezione przez juniora w review, dla których istnieje już automatyczna kontrola	Co najmniej jedno miesięcznie od 61. dnia

Te miary służą do rozmów rozwojowych, nie do rankingów. Trzymaj je w osobistym pliku juniora i nie umieszczaj na zespołowym dashboardzie. Strona ścieżki kariery i oceny pracy, gdy output jest tani wyjaśnia, dlaczego liczniki outputu zamieniają się w cele.

Sam kod nie zależy od rozwoju juniora. Pull requesty juniora napisane przez agenta przechodzą przez te same bramki co wszystkie inne: testy, typy, lint i pakiet dowodów przy każdym pull requeście. Dwie zasady dotyczą tylko juniorów. Przez pierwsze 90 dni junior nie zatwierdza zmian z klas wysokiego ryzyka (auth, pieniądze, schemat, migracje), a kod takich zmian czyta senior, zgodnie ze stroną czytanie dowodów zamiast kodu. Tech lead zatwierdza dowody na wyjściu z tabeli 90-dniowej, a przełożony juniora zatwierdza poziom, na którym junior pracuje później.

Jakie ryzyko dla ścieżki talentów niesie niezatrudnianie juniorów?

Ta sekcja jest dla CTO i zarządu. Argument wynika z powyższych dowodów, a nie z prognozy. Agenci potrzebują nadzoru. Dobrze nadzorują seniorzy, którzy zbudowali swój osąd, wykonując pracę „na piechotę” (ang. the hard way), jak sami mówią. Firma, która przestaje zatrudniać juniorów, na razie zachowuje obecnych seniorów, ale przestaje wychowywać kolejnych. Ten koszt nie pojawia się w tegorocznym budżecie. Pojawia się później jako zbyt mała liczba osób, które mogą odpowiadać za projekt weryfikacji, decyzje architektoniczne i reagowanie na incydenty, czyli za pracę, której agenci nie przejmują.

Nie udało nam się pobrać i zweryfikować opublikowanych danych o zatrudnieniu developerów na początku kariery, więc ta strona nie podaje żadnej liczby o rynku. Planuj na podstawie własnego zatrudnienia i rotacji, a nie nagłówków.

Opcja	Koszt teraz	Ryzyko później	Kiedy pasuje
Nie zatrudniać juniorów	Najniższy koszt zatrudnienia	Brak wewnętrznej ścieżki do seniora; zależność od rekrutacji seniorów na rynku, na którym każda firma szuka tych samych ludzi	Produkt o krótkim życiu albo zespół, którego za trzy lata nie będzie
Zatrudniać juniorów i pozwolić im swobodnie delegować	Pensja i licencje; od razu wygląda produktywnie	Juniorzy, którzy dowożą, ale nie potrafią nadzorować: wzorzec najsłabszych wyników w badaniu kształtowania umiejętności	Nigdy jako plan; tak dzieje się domyślnie
Zatrudniać juniorów z planem terminowania	Pensja i licencje plus około dwóch–trzech godzin seniora tygodniowo na juniora na przegląd specyfikacji i cotygodniową sesję (przy ok. 10 ticketach tygodniowo na juniora i sesji wspólnej dla trzech juniorów)	Wolniejszy widoczny output przez pierwsze 90 dni	Każdy zespół, który ma utrzymywać swoje systemy przez lata

Liczba godzin seniora w ostatnim wierszu to własny szacunek autorów tej strony na podstawie opisanych formatów (cotygodniowa 45-minutowa sesja wspólna dla maksymalnie trzech juniorów i około 10 minut przeglądu specyfikacji na ticket przy mniej więcej 10 ticketach tygodniowo na juniora), a nie zmierzony benchmark. Przy mniejszej liczbie ticketów albo sesji dla jednego juniora liczba się zmienia. Zmierz ją w swoim zespole w pierwszym miesiącu.

Pytania o juniorów, które warto zadać CTO

Ile osób dołączyło w ostatnich 12 miesiącach na poziomie juniora i jaki jest plan pierwszych 90 dni dla każdej z nich?
Kto przegląda specyfikacje juniorów przed uruchomieniem agentów i ile godzin seniorów tygodniowo to zajmuje?
Które klasy zmian junior może zatwierdzać i gdzie jest to zapisane?
Jakie mamy dowody, że nasi juniorzy potrafią zdebugować incydent produkcyjny bez agenta?
Gdyby odeszło trzech naszych najbardziej doświadczonych inżynierów, kto przejąłby projekt weryfikacji i ile czasu potrzebowałby, żeby być gotowym?

Co idzie nie tak przy rozwoju juniorów w zespole pracującym z agentami

Junior dużo dowozi i nie potrafi niczego wyjaśnić. Objaw to wysoka liczba merge’y i pustka w głowie podczas analizy incydentu. Naprawa: uczyń wyjaśnienie zmiany warunkiem oznaczenia pull requestu jako gotowego i zacznij plan 90-dniowy od pierwszego dnia dla głównego modułu tego juniora.

Seniorzy przestają mentorować, bo na pytania odpowiada agent. Badanie Anthropic opisuje to wprost. Naprawa: przenieś mentoring do przeglądu specyfikacji i cotygodniowej sesji, gdzie czas seniora jest zaplanowany, a pytania juniora dotyczą osądu, nie składni.

Chroniona praktyka znika jako pierwsza przy deadlinie. Kata i sesje review wypadają w sprincie „na ostatnią chwilę” i już nie wracają. Naprawa: wpisz je do planu sprintu jako tickety z właścicielem, a na retrospektywie niech lider raportuje pominięte sesje.

Styl nauki zostaje włączony na zawsze. Wyjaśnienia przy każdym zadaniu spowalniają dowożenie, a junior zaczyna je przewijać. Naprawa: włączaj styl albo kontrakt nauki per podsystem i wyłączaj, gdy pominięć w wyjaśnieniach jest mało przez miesiąc.

Miary rozwoju zamieniają się w ranking. Gdy czasy kata albo zgodność ze specyfikacją trafiają na wspólny dashboard, juniorzy zaczynają wybierać łatwe tickety. Trzymaj miary w osobistym pliku juniora i omawiaj je tylko na one-to-one.

Junior zatwierdza zmianę wysokiego ryzyka. Migracja albo zmiana w autoryzacji napisana przez agenta przechodzi bramki i junior ją zatwierdza. Naprawa: dopisz zasadę klas ryzyka do szablonu pull requestu i do reguł code owners, żeby te ścieżki wymagały zatwierdzenia seniora.

Dokąd dalej w temacie juniorów

Twój warsztat i kariera, gdy kod piszą agenci Indywidualny plan umiejętności, na który junior przechodzi po 90 dniach.

Wykonywalne kryteria akceptacji: od historyjki do czerwonego testu Format specyfikacji, który juniorzy ćwiczą w pętli treningowej.

Jak przekonać sceptyków i seniorów Seniorzy, którzy prowadzą przegląd specyfikacji i cotygodniowe sesje.

Podnoszenie kompetencji zespołu w inżynierii agentowej Program dla całego zespołu, per poziom drabiny.

Rekrutacja i rozmowy kwalifikacyjne w inżynierii agentowej Procesy rekrutacyjne sprawdzające pisanie specyfikacji i osąd w review.

Ścieżka tech leada Ścieżka czytania, którą zamyka ta strona.

Najczęstsze pytania

Czy junior developerzy powinni korzystać z agentów kodujących?

Tak, ale według planu. W badaniu Anthropic ze stycznia 2026 roku z udziałem 52 inżynierów, w większości juniorów, grupa korzystająca z AI uzyskała w quizie sprawdzającym zrozumienie średnio 50%, a grupa pisząca kod ręcznie 67%. Osoby, które zadawały pytania koncepcyjne albo prosiły o wyjaśnienia, uzyskały jednak średnio co najmniej 65%, blisko grupy piszącej ręcznie. To, jak junior deleguje, decyduje o tym, czego się nauczy.

Co junior developer powinien nadal ćwiczyć ręcznie?

Debugowanie od własnej hipotezy, jedno zadanie tygodniowo bez agenta, wyjaśnienie zmiany agenta bez otwartego diffu i pisanie kryteriów akceptacji przed każdym uruchomieniem agenta. Składnię i boilerplate może oddać agentowi.

Czym jest paradoks nadzoru?

To pojęcie z badania Anthropic z grudnia 2025 roku, przeprowadzonego wśród własnych inżynierów: dobre korzystanie z agenta wymaga nadzoru, a nadzór wymaga umiejętności programistycznych, które intensywne delegowanie może osłabić. Dlatego juniorzy potrzebują celowej praktyki, a nie tylko dostępu do agenta.

Jakie ryzyko niesie niezatrudnianie juniorów?

Agentów nadzorują seniorzy, którzy zbudowali swój osąd, wykonując pracę ręcznie. Zespół, który nie zatrudnia juniorów, przestaje wychowywać kolejne osoby zdolne do nadzoru, a koszt pojawia się po latach jako brak ludzi, którzy mogą odpowiadać za weryfikację, architekturę i incydenty.