Rekrutacja i rozmowy kwalifikacyjne w inżynierii agentowej

Rekrutacja do inżynierii agentowej polega na rozmowach, w których kandydat korzysta z agenta kodującego, a ocenia się to, czego agent nie dostarczy: specyfikację, według której inny inżynier zbudowałby zmianę, plan weryfikacji wyłapujący błędny wynik i osąd przy code review pull requesta napisanego przez agenta. Rubryki z kotwicami behawioralnymi (opisanymi poziomami zachowań), wypełniane niezależnie, zapewniają porównywalność kandydatów.

Twój proces rekrutacyjny nadal zakazuje narzędzi AI. W zeszłym kwartale przyjął osobę, która czysto rozwiązała zadanie na tablicy. Trzy miesiące później ta osoba merguje pull requesty agentów szybciej niż ktokolwiek w zespole i zatwierdziła jeden, którego jedyny test sprawdzał wartość zwracaną przez jego własny mock. Ta strona jest dla CTO, który ustala zasady rekrutacji, i dla tech leada, który prowadzi rozmowy.

Co daje ci ten proces rekrutacji

Profil roli: co się zmienia, a co zostaje, gdy większość kodu piszą agenci
Czteroetapowy proces z dozwolonymi agentami: cztery godziny etapów (4,5 godziny z przerwami), z jednym krótkim segmentem bez agenta
Trzy zadania praktyczne, które zbudujesz na własnym kodzie: zadanie ze specyfikowania, zadanie z agentem i code review PR-a z zasianymi defektami
Rubrykę pięciu wymiarów z kotwicami opisującymi zachowania oraz progi zatrudnienia dla każdego poziomu
Konfigurację środowiska w Claude Code, Codex i Cursorze oraz trzy prompty do budowy zadań
Metryki, które pokazują, czy proces przewiduje wyniki w pracy

Proces zakłada, że twój zespół już tak pracuje: kryteria akceptacji przed uruchomieniem agenta i dowody zamiast czytania linia po linii. Jeśli nie, zacznij od tego.

Dlaczego stary proces rekrutacji mierzy nie to, co trzeba

Klasyczny proces ocenia, jak dobrze kandydat pisze poprawny kod z pamięci, pod presją czasu i w pojedynkę. Dowody na temat tego, jak naprawdę wygląda praca z agentami, wskazują gdzie indziej:

Źródło	Co ustalono
Badanie Anthropic w miejscu pracy, 2025-12-02 (ankieta wśród 132 inżynierów i badaczy, 53 wywiady)	Część inżynierów mówi, że ich praca przesunęła się w „70%+ to being a code reviewer/reviser rather than a net-new code writer” (w ponad 70% w stronę przeglądania i poprawiania kodu zamiast pisania nowego). Raport nazywa „paradoks nadzoru”: nadzór nad agentami wymaga umiejętności, które nadmierne delegowanie osłabia.
Badanie Anthropic o kształtowaniu umiejętności, 2026-01-29 (randomizowane, 52 inżynierów, w większości juniorów)	Grupa z AI uzyskała w quizie średnio 50%, grupa pisząca ręcznie 67%, a największa różnica dotyczyła debugowania. Osoby, które zadawały pytania koncepcyjne albo prosiły o wyjaśnienie wygenerowanego kodu, uzyskały średnio co najmniej 65%.
Raport telemetryczny Faros AI, kwiecień 2026 (22 000 programistów)	Mediana czasu w code review wzrosła o 441,5% (ostatnia weryfikacja 2026-08-28).
Raport DORA, 2025-09-23	„90% of survey respondents report using AI at work” (90% ankietowanych korzysta z AI w pracy).

Code review i nadzór to dziś rdzeń pracy i nadal opierają się na podstawach, a prawie każdy kandydat już pracuje z AI, więc zakaz sprawdza nieznane mu warunki. Dopuszczenie agentów przy starej ocenie („czy kod działał po 60 minutach?”) mierzy agenta. Dopuść agentów i oceniaj decyzje człowieka: co zbudować, jak udowodnić, że działa, i co odrzucić.

Jak zmienia się profil roli inżyniera

Praca nie kurczy się do „promptowania”: przesuwa się z produkowania kodu na jego specyfikowanie i rozstrzyganie, czy jest poprawny, co opisuje strona o zadaniach, które zostają przy człowieku. Przepisz profil roli przed rozmową.

Wymiar	Co ocenia nowy proces	Co pozostaje obowiązkowe
Specyfikacja	Zamienia mglistą prośbę w testowalne kryteria; nazywa brakujące decyzje	Najpierw pytanie produktowe
Projekt weryfikacji	Wybiera dowody, które nie przejdą przy błędnej implementacji; rozpoznaje słabe testy	Rozumienie, co test sprawdza
Kierowanie agentem	Daje kontekst, dzieli pracę, koryguje agenta, weryfikuje przed „gotowe”	Wiedza, kiedy pisać kod samodzielnie
Osąd przy code review	Znajduje i szereguje istotne defekty w pull requeście agenta	Uważne czytanie tam, gdzie ryzyko jest wysokie
Podstawy	Debugowanie od hipotezy, wyjaśnianie kodu bez agenta	Jedno i drugie, na każdym poziomie

Skopiuj poniższy akapit do ogłoszeń o pracę, żeby kandydaci wiedzieli, co sprawdza proces.

## Jak pracujemy i jak rekrutujemy
Nasi inżynierowie wykonują większość implementacji z agentami kodującymi
(Claude Code, Codex albo Cursor). Praca polega na decydowaniu, co zbudować,
udowadnianiu, że działa, i sprawdzaniu tego, co tworzą agenci. Na rozmowach
możesz korzystać z wybranego agenta na każdym etapie poza jednym,
15-minutowym segmentem debugowania. Oceniamy twoje kryteria akceptacji,
plan weryfikacji i wnioski z code review, a nie to, jak szybko pojawia się kod.

Czteroetapowy proces rekrutacji z dozwolonymi agentami

Każdy etap sprawdza jeden lub dwa wymiary rubryki. Każdy kandydat na danym poziomie dostaje te same zadania, narzędzia do wyboru i czas.

Zadanie ze specyfikowania, 45 minut, agent dozwolony. Zamiana prośby produktowej w kryteria akceptacji, listę tego, co poza zakresem, i plan weryfikacji; może być zadaniem domowym z limitem czasu. Sprawdza: specyfikację, projekt weryfikacji.
Zadanie z agentem, 90 minut, na żywo, we własnym narzędziu kandydata. Mała zmiana w przygotowanym repozytorium, a osoba prowadząca obserwuje. Sprawdza: kierowanie agentem, projekt weryfikacji.
Zadanie z code review, 45 minut, agent dozwolony. Code review pull requesta agenta z zasianymi defektami i werdykt. Sprawdza: osąd przy code review.
Projekt weryfikacji i podstawy, 60 minut. 45 minut o tym, jak bezpiecznie wdrożyć ryzykowną zmianę bez czytania każdej linii, potem 15 minut debugowania bez agenta. Sprawdza: projekt weryfikacji, podstawy.

Wyślij kandydatowi format tydzień wcześniej: które etapy dopuszczają agenta, jakie narzędzia są na maszynie i że transkrypt trafia do dokumentacji rozmowy. Juniorom daj 30 minut etapu 4 na debugowanie; na poziomie staff zastąp połowę etapu 2 przeglądem samego harnessu.

Etap 1: zaprojektuj zadanie ze specyfikowania

Użyj realistycznej prośby, w której celowo brakuje dwóch decyzji. Dla produktu subskrypcyjnego:

„Klienci na planach rocznych powinni móc wstrzymać subskrypcję na maksymalnie trzy miesiące. W czasie wstrzymania nie powinniśmy ich obciążać. Support ciągle dostaje takie prośby, więc chcielibyśmy to mieć w tym kwartale.”

Ukryte decyzje: jak często klient może wstrzymać subskrypcję i co dzieje się z datą odnowienia. Mocny kandydat pyta o nie albo zapisuje je jako założenia.

Co kandydat oddaje:

Kryteria akceptacji w formacie Zakładając/Gdy/Wtedy (Given/When/Then) z konkretnymi wartościami („Zakładając plan roczny odnawiany 2027-03-01, gdy klient 2026-11-01 wstrzymuje go na 90 dni, wtedy odnowienie przesuwa się na 2027-05-30”)
Zakres wyłączony
Test dowodzący każdego kryterium i wskazanie, które testy chronić przed edycją przez agenta

Poziomy różnią się przypadkami brzegowymi, nie liczbą kryteriów: granicą (wstrzymanie na dokładnie 90 dni i na 91), współbieżnością (wstrzymanie w trakcie pobierania opłaty za odnowienie), awarią (dostawca płatności nie odpowiada w połowie operacji) i strefami czasowymi. Agent w kilka sekund napisze kryteria dla ścieżki pozytywnej, więc nagradzaj przypadki brzegowe i plan weryfikacji.

Etap 2: zbuduj zadanie z agentem

Zbuduj repozytorium zadania raz i używaj go przez rok. Potrzebuje:

Małej usługi, która wygląda na prawdziwą. Kilka tysięcy linii, zestaw testów i jedno polecenie uruchamiające kontrole, na przykład npm test.
Zadania, które agent może zrobić wiarygodnie źle. Umieść pułapkę w domenie: granicę dat, idempotencję przy ponowieniu albo regułę autoryzacji. Pierwsze podejście agenta powinno przejść istniejące testy i mimo to być błędne.
Jednego słabego istniejącego testu, który przechodzi niezależnie od kodu.
Braku pliku z instrukcjami. Nie dodawaj CLAUDE.md ani AGENTS.md: to, jak kandydat daje agentowi kontekst, jest częścią sygnału.

Osoba prowadząca odpowiada tylko na pytania produktowe i za każdym razem zapisuje to samo według tego szablonu:

# Notatki z etapu 2: <id kandydata>, <data>, narzędzie: <Claude Code | Codex | Cursor>

## Przed pierwszym uruchomieniem agenta (znacznik czasu)
Kontekst dany agentowi: pliki, ograniczenia, kryteria akceptacji?
Plan zlecony lub napisany przed kodem?

## W trakcie
Kiedy kandydat zatrzymał lub skorygował agenta i dlaczego:
Twierdzenia agenta przyjęte bez sprawdzenia (zacytuj):
Twierdzenia agenta sprawdzone i w jaki sposób:

## Przed „gotowe”
Dowody przygotowane przez kandydata: uruchomione testy, nowe testy, sprawdzenie ręczne
Czy znalazł słaby istniejący test? Czy znalazł pułapkę w zadaniu?

## Dowody do rubryki (jedna linia na wymiar, jeszcze bez oceny)
Kierowanie agentem:
Projekt weryfikacji:

Dwóch kandydatów kończy po 70 minutach. Pierwszy przyjmuje od agenta „all tests pass”. Drugi pyta, dlaczego ponowienie nie może obciążyć klienta dwa razy, widzi, że nic tego nie testuje, pisze ten test i patrzy, jak nie przechodzi. Tylko drugi wykonał pracę.

Przygotuj środowisko rozmowy w Claude Code, Codex i Cursorze

Używaj jednorazowej maszyny lub kontenera dla każdego kandydata: bez firmowych poświadczeń, wewnętrznych repozytoriów i osobistej konfiguracji, z ruchem wychodzącym ograniczonym do dostawcy modelu i waszego rejestru pakietów. Przypnij model, żeby kandydaci trafiali na tego samego agenta; aktualne modele domyślne są w przeglądzie modeli. To jednorazowa maszyna sprawia, że zwykły tryb uprawnień kandydata jest bezpieczny. W każdym narzędziu różni się to, jak uruchamiasz sesję i zachowujesz jej zapis.

Utwórz świeżego użytkownika systemu z pustym katalogiem ~/.claude, sklonuj repozytorium zadania i uruchom sesję ze znanym identyfikatorem, żeby potem znaleźć jej transkrypt (sprawdzone na Claude Code 2.1.283):

# Terminal na jednorazowej maszynie, w repozytorium zadania
SESSION_ID=$(uuidgen)
claude --model claude-opus-5-5 --session-id "$SESSION_ID" -n "interview-cand-17-stage2"

Podaj pełny identyfikator modelu, a nie alias opus, który na różnych platformach wskazuje różne modele i zmienia się bez uprzedzenia. claude-opus-5-5 wymaga wersji 2.1.280 lub nowszej, czyli 26 września 2026 roku tylko kanału wydań latest; stable (2.1.274) jeszcze go nie udostępnia. Sesja zapisuje się jako plik JSONL w ~/.claude/projects/, w folderze nazwanym od ścieżki repozytorium: skopiuj go do dokumentacji rozmowy albo otwórz ponownie przez claude --resume "$SESSION_ID" z drugim rekruterem. W zadaniu z code review punktem odniesienia jest /code-review uruchomione w sesji.

Użyj świeżego użytkownika systemu z pustym katalogiem ~/.codex. Przypnij model przez -m i daj agentowi zapisywalny workspace przez profil uprawnień, który w Codex 0.157.1 jest w wersji beta. Nie łącz profilu z --sandbox ani z --approve-for-me: według OpenAI profil i starszy system sandboxa „do not compose”, czyli nie działają razem, a --approve-for-me korzysta ze starszego sandboxa workspace-write. Uruchom sesję tak:

# Terminal na jednorazowej maszynie
codex -m gpt-6-astra -C ~/exercise -c default_permissions=":workspace"

GPT-6 Astra jest domyślnym modelem Codex od CLI 0.153.4; przypięcie go chroni pulę kandydatów przed zmianą modelu domyślnego. Po rozmowie codex resume otwiera listę sesji zapisanych lokalnie. W zadaniu z code review punktem odniesienia jest codex review --base main uruchomione na gałęzi z defektami.

Etap 3: zasiej defekty w zadaniu z code review

Zbuduj jeden pull request napisany przez agenta, z sześcioma defektami różnego rodzaju i pewnym siebie opisem, który twierdzi, że wszystkie testy przechodzą. Kandydat, który znajduje tylko uwagi stylistyczne i przeocza dziurę w autoryzacji, nie przechodzi etapu.

Zasiany defekt	Klasa	Waga
Każdy zalogowany użytkownik może wstrzymać dowolną subskrypcję po ID	Bezpieczeństwo	Krytyczna
Ponowienie webhooka wstrzymuje subskrypcję dwa razy	Logika	Krytyczna
Koniec wstrzymania liczony w lokalnym czasie serwera, o dzień przesunięty dla klientów w UTC+10	Logika	Wysoka
Test jednostkowy sprawdza wartość zwracaną przez własny mock	Luka w testach	Wysoka
Przechwycony błąd zwraca HTTP 200 z pustą treścią	Obsługa błędów	Średnia
Niezwiązana zmiana nazwy w 12 plikach logowania	Zakres	Średnia

Oceniaj werdykt, nie tylko listę. Mocny kandydat odsyła pull request do poprawy, stawia oba defekty krytyczne na początku i proponuje kontrolę, która automatycznie wyłapałaby każdą klasę, na przykład test autoryzacji dla każdego endpointu albo test idempotencji handlera webhooka. Tak wygląda code review PR-a agenta w codziennej pracy.

Najpierw skalibruj zadanie: uruchom swojego agenta do code review na tej gałęzi i zapisz, które zasiane defekty znajduje. Jeśli znajduje wszystkie sześć, zrób defekty subtelniejsze. Poprzeczka dla człowieka to znaleźć to, co przeoczył automatyczny recenzent, w kolejności według konsekwencji.

Etap 4: pytania do rozmowy o projekcie weryfikacji

Zacznij od zmiany z pracy kandydata, a potem przejdź do jednej z waszych:

„Twój agent otworzył pull request na 900 linii, który dotyka rozliczeń. Jakich dowodów potrzebujesz, zanim go zatwierdzisz bez czytania każdej linii?”
„Których testów w tej zmianie agent nie może nigdy edytować i jak byś to wymusił?”
„Agent twierdzi, że migracja jest wstecznie kompatybilna. Jak sprawdzisz to twierdzenie?”
„Kiedy zatrzymałbyś agenta i napisał kod samodzielnie?”

Mocne odpowiedzi wymieniają konkretne wyrocznie (testy właściwości, testy kontraktowe, wdrożenie kanarkowe z wyzwalaczem wycofania, chronione testy akceptacyjne) i to, kto zatwierdza. Słabe: „przejrzałbym to uważnie” albo „agent pisze testy”.

Potem przeprowadź 15-minutowy segment debugowania bez agenta: test, który nie przechodzi, stack trace i fragment logu. Oceniaj metodę, nie poprawkę: czy kandydat stawia hipotezę, sprawdza ją najmniejszym eksperymentem i ją koryguje? Badanie o kształtowaniu umiejętności wykazało największą lukę właśnie przy debugowaniu.

Rubryka oceny rozmów w inżynierii agentowej

Każdy rekruter ocenia tylko wymiary swojego etapu, z jedną linią dowodu na ocenę, przed wspólnym omówieniem. Oceny bez dowodu się nie liczą. Na potrzeby zgodności oceniających niech drugi rekruter przysłuchuje się jednemu etapowi u każdego kandydata i ocenia go niezależnie.

Wymiar	1: brak	2: częściowo	3: solidnie	4: wzorcowo
Specyfikacja	Powtarza prośbę; brak testowalnych kryteriów	Kryteria dla ścieżki pozytywnej z konkretnymi wartościami; pomija ukryte decyzje	Nazywa obie ukryte decyzje; obejmuje granice i awarie	Obejmuje też współbieżność i czas; mówi, co jest poza zakresem i dlaczego
Projekt weryfikacji	„Uruchomić testy”	Dodaje testy, ale te przeszłyby przy błędnej implementacji	Dowody, które nie przejdą przy prawdopodobnej błędnej implementacji; znajduje słaby istniejący test	Chroni kluczowe testy przed edycją przez agenta; wskazuje kontrolę, która zastępuje ludzkie czytanie, dla każdego ryzyka
Kierowanie agentem	Wkleja zadanie i przyjmuje wynik	Daje trochę kontekstu; przyjmuje niesprawdzone twierdzenia	Najpierw plan, podaje ograniczenia, zatrzymuje i koryguje przy złym kierunku, weryfikuje przed „gotowe”	Dzieli pracę tak, że każdy krok agenta da się sprawdzić; wie, kiedy napisać kod samodzielnie
Osąd przy code review	Tylko uwagi stylistyczne	Znajduje część defektów, przeocza krytyczny	Znajduje oba defekty krytyczne i stawia je na początku; odsyła PR do poprawy	Proponuje też kontrolę dla każdej klasy defektu i prosi o podział zakresu
Podstawy	Nie potrafi wyjaśnić kodu ani postawić hipotezy	Naprawia metodą prób i błędów	Debuguje od hipotezy i wyjaśnia kod bez agenta	Wyjaśnia przyczynę źródłową i test, który powinien był ją wyłapać

Progi zatrudnienia dla poziomów. Zapisz swoje przed pierwszym kandydatem i nie zmieniaj ich pod konkretną osobę:

Poziom	Minimum w każdym wymiarze	Dodatkowo wymagane
Junior	2	Podstawy 3, a notatki z etapu 2 pokazują, że kandydat zadaje agentowi pytania koncepcyjne
Mid	2	3 w specyfikacji, projekcie weryfikacji i osądzie przy code review
Senior	3	4 w projekcie weryfikacji albo w osądzie przy code review
Staff	3	4 w projekcie weryfikacji i w osądzie przy code review

Próg dla juniorów wynika z badania o kształtowaniu umiejętności: zadawanie pytań koncepcyjnych utrzymywało wysokie zrozumienie, więc tego szukaj u juniora, a nie szybkości.

Prompty do skopiowania przy budowie zadań

Te prompty są dla rekruterów. Uruchamiaj je w repozytorium zadania, nigdy na materiałach kandydatów.

You are preparing an interview exercise. Work only in this repository and do not push anything.

1. Create a branch named review-exercise from main.
2. Implement the feature in docs/brief-pause.md ("pause an annual subscription for up to 90 days, once per rolling 12 months") in one commit, the way a coding agent would, and deliberately include exactly these defects, each subtle enough to survive a skim:
   a. No ownership check: any authenticated user can pause any subscription by ID.
   b. The webhook handler is not idempotent, so a retry pauses the subscription twice.
   c. The pause end date is computed in server local time, one day off for a customer in UTC+10.
   d. One unit test asserts the value returned by the mock it configured, so it passes whatever the code does.
   e. A caught error returns HTTP 200 with an empty body.
   f. An unrelated rename in src/logging/ that touches 12 files.
3. Write a pull request description in a confident tone that says all tests pass.
4. Write ../answer-key.md, outside the repository, listing each defect with file, line, severity (critical, high, medium) and the automated check that would have caught it.
5. Run npm test and confirm it passes on the branch.

Review the changes on this branch against main as you would review a colleague's pull request.
Report every defect with file, line, class (security, logic, test gap, error handling, scope), severity (critical, high, medium) and a one-line reason.
Give a verdict: approve, request changes or split.
Do not fix anything. Do not open any file outside this repository.

Wklej drugi prompt do dowolnego z trzech narzędzi na gałęzi z defektami. Dla wbudowanego recenzenta Codex uruchom codex review --base main bez promptu: w Codex 0.157.1 --base nie da się połączyć z własnymi instrukcjami. Porównaj wyniki z answer-key.md i zapisz, co agent przeoczył: to ta część sprawdza człowieka.

Turn the ticket below into a spec-writing interview exercise for a mid-level engineer.
Remove every customer name, internal system name, URL and number that could identify our business.

Write two files:
1. candidate-brief.md: the request as a product manager would write it, 5 to 8 sentences, deliberately leaving two decisions unmade that the engineer must ask about or state as assumptions. End with: "Write acceptance criteria, what is out of scope, and how you would prove the change works without reading every line of the implementation. 45 minutes. You may use any coding agent."
2. reference-answer.md, for interviewers only: 8 to 12 acceptance criteria in Given/When/Then form with concrete values, the two hidden decisions, one boundary, one concurrency and one failure case a strong candidate names, and the test that proves each criterion.

Ticket:
PASTE_TICKET_TEXT

Zastąp PASTE_TICKET_TEXT treścią zamkniętego ticketu i sprawdź, czy wynik nie zawiera niczego, co identyfikuje klienta. Jeśli rekrutujesz po polsku, poproś agenta w ostatnim zdaniu promptu o napisanie candidate-brief.md po polsku.

Skąd wiesz, że proces rekrutacji działa

Tech lead, który prowadzi proces, zbiera te dane co kwartał; CTO jest właścicielem rubryki i zatwierdza każdą zmianę progów zatrudnienia.

Metryka	Definicja	Cel na start	Działanie, gdy cel nie jest osiągnięty
Kalibracja na obecnym zespole	Przed pierwszym kandydatem przeprowadź proces na trzech inżynierach, których oceniasz jako mocnych na docelowym poziomie	Wszyscy trzej przechodzą próg	Popraw zadanie albo próg
Zgodność oceniających	Odsetek ocen, w których dwóch rekruterów tego samego etapu różni się najwyżej o jeden punkt	Co najmniej 80%	Przeszkol ponownie na kotwicach z nagranymi przykładami
Rozkład wykrytych zasianych defektów	Dla każdego kandydata: znalezione defekty krytyczne na dwa i wszystkie znalezione na sześć	Rozrzut w całym zakresie, nie same 6/6	Defekty są za łatwe albo zadanie wyciekło; wymień je
Odsetek przejść przez etapy	Odsetek kandydatów, którzy przechodzą każdy etap	Żaden etap nie przepuszcza prawie wszystkich	Ten etap nie różnicuje; usuń go albo przeprojektuj
Wynik po sześciu miesiącach	Na koniec okresu próbnego: ocena przełożonego za code review i specyfikacje wobec wyniku rozmowy	Większość zatrudnionych dorównuje lub przewyższa	Popraw kotwicę, która wprowadziła w błąd
Czas kandydata	Łączna liczba godzin wymaganych od kandydata, z zadaniem domowym	Najwyżej 4,5 godziny, z przerwami	Skracaj, nie wydłużaj

Wymieniaj repozytorium zadania i PR z zasianymi defektami co najmniej raz w roku, a natychmiast, jeśli kandydat już je widział.

Co psuje rozmowy z dozwolonymi agentami i jak to naprawić

Proces ocenia agenta, a wygrywa szybkość. Wszyscy przechodzą etap 2, notatki mówią „działające rozwiązanie”, a rekruterzy nagradzają tego, kto skończył pierwszy. Naprawa: usuń z omówienia uwagi o czasie ukończenia i oceń ponownie tylko wymiary z rubryki. Jeśli notatki nie zawierają dowodów dotyczących weryfikacji ani kierowania agentem, przeszkol obserwatora na szablonie notatek z etapu 2.

Zadanie z code review jest za łatwe. Kandydat wkleja diff do agenta i dostaje 6/6. Naprawa: skalibruj zadanie jak wyżej i oceniaj werdykt, kolejność oraz zaproponowane kontrole.

Z procesu znikają podstawy. Rezygnacja z segmentu debugowania oznacza zatrudnianie ludzi, którzy nie potrafią nadzorować tego, czego nie umieją wyjaśnić. Naprawa: zachowaj segment bez agenta na każdym poziomie.

Firma przestaje zatrudniać juniorów, bo agenci są tańsi. Po roku nie ma nikogo gotowego do roli recenzenta. Naprawa: utrzymaj ścieżkę dla juniorów z osobnym progiem, połączoną z rozwojem juniorów.

Narzędzie AI zaczyna przesiewać CV albo oceniać transkrypty, zwykle jako funkcja dostawcy. Naprawa: wyłącz je przy podejmowaniu decyzji, wpisz do rejestru systemów AI i zaangażuj prawników przed 2 grudnia 2027 roku.

Zadanie wycieka. Odsetek przejść skacze, a odpowiedzi wyglądają identycznie. Naprawa: przejdź na drugą wersję trzymaną w gotowości.

Co dalej po ustawieniu rekrutacji

Ścieżki kariery i oceny pracy Te same kompetencje jako poziomy i kryteria ocen.

Rozwój juniorów Co juniorzy wciąż ćwiczą ręcznie i jakie jest ryzyko niezatrudniania ich wcale.

Projekt organizacji dla zespołów agentowych Nowe role i dobór wielkości zespołów do przepustowości code review.

Code review PR-a agenta Praktyka code review, którą próbkuje zadanie z etapu 3.

Powiązana praktyka: siła wyroczni w waszych testach i jak seniorzy przejmują odpowiedzialność za weryfikację.

Najczęstsze pytania

Czy kandydaci powinni móc korzystać z agentów kodujących podczas rozmowy?

Tak, na większości etapów. Praca polega dziś także na kierowaniu agentami, więc proces, który ich zakazuje, sprawdza pracę, jakiej zatrudniona osoba nie będzie wykonywać. Zmień to, co oceniasz: specyfikację, plan weryfikacji i osąd w code review, których agent nie dostarczy. Zostaw jeden krótki segment bez agenta na debugowanie i wyjaśnianie kodu.

Co powinna mierzyć rozmowa techniczna z dozwolonym agentem?

Pięć wymiarów: zamianę intencji na testowalne kryteria akceptacji, projektowanie weryfikacji, która wyłapie błędny wynik, kierowanie agentem, znajdowanie istotnych defektów w pull requeście napisanym przez agenta oraz podstawy, takie jak debugowanie oparte na hipotezie bez agenta.

Czy możemy użyć AI do oceny transkryptów rozmów z kandydatami?

Nie do podjęcia decyzji. Ocena kandydatów to obszar z załącznika III AI Act, z obowiązkami dla systemów wysokiego ryzyka od 2 grudnia 2027 roku według podsumowania nowelizacji z 2026 roku przygotowanego przez Gibson Dunn (źródło wtórne), a już dziś rodzi pytania na gruncie RODO. Agent może przygotować zadania i wyciągnąć znaczniki czasu; oceniają przeszkoleni ludzie według rubryki.