Twój warsztat i kariera, gdy kod piszą agenci

Gdy większość kodu piszą agenci, na wartości zyskują specyfikacja, projektowanie weryfikacji, architektura i smak. Pamięć składni i pisanie boilerplate’u to umiejętności, które możesz odpuścić; najwyraźniej słabnie debugowanie bez pomocy (największa luka w badaniu Anthropic ze stycznia 2026 roku). Badanie Anthropic na własnych inżynierach nazywa tę pułapkę „paradoksem nadzoru”: nadzór nad agentem wymaga tych samych umiejętności, które intensywne delegowanie osłabia.

W zeszłym miesiącu zmergowałeś 30 pull requestów i prawie żadnego nie napisałeś sam. Formularz oceny rocznej wciąż pyta, co zbudowałeś, a właśnie przyszedł incydent w module, którego od marca żaden człowiek nie przeczytał w całości. Ta strona jest dla programistów, którzy chcą uczciwej odpowiedzi na pytanie „czym jest teraz mój warsztat”, i dla tech leadów, którzy muszą na nie odpowiedzieć innym.

Co ta strona daje twojemu warsztatowi i karierze

• Tabelę umiejętności, które zyskują, i tych, które słabną, z zewnętrznym źródłem przy każdym twierdzeniu.
• Wyjaśnienie „paradoksu nadzoru” i nawyki pracy, które jedyne dostępne badanie kontrolowane łączy z zachowaniem tego, czego się uczysz.
• Konfigurację trybu nauki w Claude Code, Codex i Cursorze.
• Plan portfolio na każdy poziom drabiny autonomii: co utrzymywać w formie, co oddać agentowi i jakie dowody zbierać.
• Jednostronicowy plan umiejętności do skopiowania i cztery prompty, które zamieniają twoją historię w gicie w te dowody.
• Testy, które pokazują, czy twoje umiejętności się trzymają, oraz listę tego, czego żadne źródło jeszcze nie mówi.

Co mówią dowody o umiejętnościach, gdy kod piszą agenci

Bezpośrednio na to pytanie odpowiadają dwa badania. Oba pochodzą od Anthropic, czyli dostawcy modeli, więc czytaj je jako badania dostawcy o własnym produkcie i własnych pracownikach. Gdy powstawała ta strona, nie było dostępnego niezależnego badania o porównywalnej skali i metodzie.

Badanie wewnętrzne 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 opublikowali 2 grudnia 2025 roku Saffron Huang i współautorzy. Większość ankietowanych deklarowała, że może „w pełni delegować” (ang. fully delegate) tylko 0–20% swojej pracy. Jeden z inżynierów opisał, że jego praca przesunęła się „w ponad 70%” w stronę recenzowania i poprawiania kodu zamiast pisania nowego. Część osób obawiała się, że ich umiejętności zanikają w miarę delegowania, i że tracą „uboczną” naukę, która zachodzi przy ręcznym rozwiązywaniu problemów. Raport nazywa to ryzyko wprost:

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

Czyli: skuteczna praca z Claude wymaga nadzoru, a nadzór wymaga tych samych umiejętności programistycznych, które mogą zanikać przy nadużywaniu AI. Starszy inżynier z tego samego badania wyjaśnił, dlaczego jego chroni staż: używa AI głównie tam, gdzie wie, jak odpowiedź powinna wyglądać, a tę zdolność zbudował, programując „na trudniej”. Jego zdaniem junior musiałby włożyć dużo świadomego wysiłku, żeby dalej się rozwijać, zamiast bezrefleksyjnie przyjmować wynik modelu. Wszystko to są deklaracje pracowników jednej firmy, którzy używają jej własnych narzędzi.

Badanie kształtowania umiejętności. 29 stycznia 2026 roku Judy Hanwen Shen i Alex Tamkin opublikowali randomizowane badanie z udziałem 52 głównie początkujących inżynierów. Każdy uczył się Trio, pythonowej biblioteki do programowania asynchronicznego, budując dwie funkcje. Grupa z asystentem AI uzyskała w teście kontrolnym średnio 50%, a grupa pisząca 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 luka dotyczyła pytań o debugowanie. Autorzy sami wskazują ograniczenie: test mierzył zrozumienie tuż po zadaniu, a badanie nie rozstrzyga, czy przekłada się to na umiejętności w dłuższym okresie.

Badanie pokazuje też, jak uczestnicy korzystali z asystenta. Najgorzej wypadły osoby, które oddały mu całe pisanie kodu albo polegały na nim przy debugowaniu. Najlepiej wypadły osoby, które zadawały pytania koncepcyjne albo generowały kod, a potem dopytywały, żeby go zrozumieć. Wniosek nie brzmi „AI cię osłabia”. Brzmi: to, jak delegujesz, decyduje o tym, co zachowujesz.

Które umiejętności zyskują, gdy kod piszą agenci?

Te cztery umiejętności są tym cenniejsze, im więcej kodu piszą agenci. Każda decyduje albo o tym, co agent zbuduje, albo o tym, czy jego wynikowi można ufać. Strona co zostaje człowiekowi opisuje je jako odpowiedzialności, a ta sekcja jako umiejętności, które ćwiczysz.

Umiejętność	Jak wygląda w praktyce	Dlaczego zyskuje (źródło)	Jak ją ćwiczyć w tym miesiącu
Specyfikacja	Zamiana intencji w kryteria akceptacji i warunek stopu, których agent nie odczyta źle	Karpathy: „You are in charge of the spec and plan” (podsumowanie Sequoia Ascent, 30 kwietnia 2026). Programista na Poziomie 4 u Shapiro pisze specyfikację i sprawdza, czy testy przechodzą (styczeń 2026)	Przed każdym zadaniem dla agenta zapisz kryteria akceptacji, a potem licz, jak często wynik spełnił je za pierwszym razem
Projektowanie weryfikacji	Wybór wyroczni, która rozstrzyga „gotowe”, i trzymanie jej poza zasięgiem agenta	Sonar, styczeń 2026: 96% programistów nie ufa w pełni kodowi wygenerowanemu przez AI, a tylko 48% zawsze go weryfikuje przed commitem. Ta luka to właśnie ta umiejętność	Do każdej funkcji napisz jedno sprawdzenie, którego agent nie może edytować, i przeczytaj, jak silna jest twoja wyrocznia
Architektura	Granice, kierunek zależności i to, co może się zmienić bez decyzji człowieka	DORA 2025: zespoły z luźno powiązaną architekturą i szybkimi pętlami informacji zwrotnej widzą korzyści, a zespoły ograniczone ściśle powiązanymi systemami i wolnymi procesami widzą niewielkie albo żadne	Raz w tygodniu zapisz jedną decyzję architektoniczną jako plik, który agent czyta
Smak	Dostrzeżenie, że działająca implementacja jest niewłaściwa	Karpathy: „You still have to be in charge of aesthetics, judgment, taste, and oversight”. SlopCodeBench (marzec 2026) zmierzył „erozję strukturalną”, gdy agenci rozbudowują własne rozwiązania, czyli degradację, której zielony zestaw testów nie zgłasza	Raz w tygodniu odrzuć jeden zielony wynik agenta ze względów projektowych i zapisz dlaczego

Nad wszystkimi czterema stoi piąta umiejętność: działający model systemu w twojej głowie. Inżynier z badania Anthropic, który bał się ją stracić, opisał to tak: kiedy sam debugujesz trudny problem, czytasz dokumentację i kod, które nie są bezpośrednio potrzebne do rozwiązania, ale przez cały ten czas budujesz model działania systemu. Każda umiejętność z tabeli zależy od tego modelu, a intensywne delegowanie zabiera go jako pierwszy.

Które umiejętności słabną i które możesz odpuścić?

Nie wszystko, co słabnie, jest stratą. Uczciwy podział przebiega między umiejętnościami, które agent wykonuje teraz lepiej i taniej, a umiejętnościami, które tylko wyglądają na pisanie kodu.

Umiejętność	Werdykt	Uzasadnienie
Pamięć składni i biblioteki standardowej	Odpuść	Agent to ma, a bramki wyłapują błędy. Nadal musisz czytać język na tyle dobrze, żeby ocenić diff, który ma znaczenie.
Boilerplate, szkielety i kod klejący	Odpuść	W tej pracy agenci radzą sobie najlepiej. Zachowaj umiejętność wyłapywania zduplikowanego kodu w diffie, bo kopie tanio się generuje i drogo utrzymuje.
Ręczne poznawanie konfiguracji nowego narzędzia	Odpuść większość	Inżynier z badania Anthropic przyznał, że teraz polega na AI, które mówi mu, jak używać nowych narzędzi, i przez to brakuje mu eksperckiej wiedzy. Zachowaj praktyczną głębię dla dwóch–trzech narzędzi, za które odpowiadasz.
Debugowanie od podstaw	Chroń	Największa luka w badaniu kształtowania umiejętności, a najbardziej liczy się w incydentach, gdy poprawka agenta zawiodła już dwa razy.
„Uboczna” nauka z mocowania się z problemem	Chroń celowo	Badanie Anthropic wskazuje jej utratę jako główną obawę. Żadna bramka jej nie zastąpi, więc trzeba ją zaplanować w kalendarzu.
Czytanie każdego diffa linijka po linijce	Zmień formę	To się nie skaluje: Faros AI (kwiecień 2026, 22 000 programistów) zmierzył o 31,3% więcej pull requestów mergowanych bez żadnego review. Zastępuje je czytanie dowodów zamiast kodu, a czytanie kodu zostaje dla zmian wysokiego ryzyka.

Paradoks nadzoru i jak go uniknąć

Paradoks działa jak zapadka: delegowanie osłabia umiejętność sprawdzania tego, co oddałeś, słabsze sprawdzanie to większe zaufanie, a większe zaufanie to jeszcze więcej delegowania. Wyjściem nie jest delegowanie mniej. Wyjściem jest zmiana tego, jak delegujesz, i zaplanowanie praktyki, którą delegowanie zabiera.

Badanie kształtowania umiejętności i badanie Anthropic w miejscu pracy wskazują cztery nawyki:

1. Proś o zrozumienie, nie tylko o wynik. Najwięcej zachowały osoby, które zadawały pytania koncepcyjne albo dopytywały o wygenerowany kod. Zamień to w regułę sesji (robi to konfiguracja poniżej).
2. Przewiduj, zanim przeczytasz. Zanim otworzysz diff agenta, zapisz w dwóch linijkach, czego się spodziewasz. Błędna prognoza wskazuje lukę w twoim modelu systemu, a ta luka jest cenniejsza niż sam diff.
3. Rozwiązuj część problemów ręcznie, celowo. Inżynier z badania Anthropic mówi, że co jakiś czas nie prosi Claude o rozwiązanie, nawet jeśli wie, że ten sobie poradzi, bo to utrzymuje go w formie. Zarezerwuj na to stały termin w kalendarzu, a nie „kiedy będzie czas”.
4. Najpierw debuguj sam, potem deleguj. Gdy coś się sypie, poświęć 15 minut na własną hipotezę, zanim oddasz problem agentowi. Potem porównaj swoją hipotezę z tym, co znalazł agent.

Skonfiguruj tryb nauki w swoim narzędziu

Przepływy pracy się różnią, bo tylko Claude Code ma do tego wbudowany styl. W pozostałych dwóch narzędziach dajesz agentowi ten sam kontrakt jako instrukcję.

Claude Code

Claude Code ma wbudowane style odpowiedzi (output styles) Explanatory i Learning. Badanie kształtowania umiejętności wymienia „Claude Code Learning and Explanatory mode” jako narzędzia, które mają wspierać zrozumienie. W sesji uruchom /output-style (dodane w Claude Code 2.1.269) i wybierz Learning dla kodu albo biblioteki, której się uczysz, lub Explanatory, gdy chcesz uzasadnień bez dodatkowych ćwiczeń. Wracaj do domyślnego stylu przy znajomej pracy, bo dodatkowe wyjaśnienia kosztują tokeny i czas.

Codex

Nie znaleźliśmy wbudowanego trybu nauki ani trybu wyjaśniającego w codex --help ani w codex features list (Codex CLI 0.157.1, sprawdzone 26 września 2026). Wklej kontrakt nauki poniżej na początku sesji. W zespole, w którym juniorzy pracują we wspólnym repozytorium, uzgodnij z tech leadem umieszczenie go w sekcji AGENTS.md, który Codex czyta przed rozpoczęciem pracy. Nie dodawaj go po cichu, bo zmienia sesje każdej osoby w zespole.

Cursor

Wklej kontrakt nauki poniżej na początku czatu z Agentem. Żeby obowiązywał w projekcie na stałe, zapisz go jako Rule, czyli mechanizm Cursora do stałych instrukcji dla agenta. Reguły można współdzielić w zespole, więc prywatną regułę nauki trzymaj poza wspólnym zestawem, chyba że zespół się zgodzi.

Prompt do skopiowania: kontrakt nauki na tę sesję

For this session I am learning this part of the codebase, not just shipping.
Work under these rules:
1. Before you write code, explain your plan in five lines or fewer and name
   the concept in this codebase or library that the plan depends on.
2. After each change, ask me one question that checks I understood why the
   change works. Wait for my answer before you continue, and correct me if I
   am wrong.
3. If a test fails, do not fix it yet. Tell me which test failed and ask me for
   my hypothesis first. Then compare my hypothesis with yours.
4. Leave the final 10-20 line function of the task for me to write. Describe
   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 colleague without notes.

Prompt do skopiowania: sprawdzenie przez wyjaśnienie po zadaniu agenta

I am going to explain the change you just made, without looking at the diff.
After I explain it, compare my explanation with what the code actually does.
List what I got right, what I missed, and anything I got wrong, citing file
and line for each point. Then give me one question about a failure mode of
this change that I did not mention. Do not praise the explanation; only
report the differences.

Plan portfolio na każdy poziom drabiny

Portfolio było kiedyś kodem, który napisałeś. Gdy piszą go agenci, dowody przenoszą się na artefakty, które zdecydowały, co powstało, i udowodniły, że działa. Każdy poziom drabiny dokłada jeden rodzaj artefaktu. Zachowuj wcześniejsze, bo portfolio pokazujące tylko najwyższy poziom wygląda na niesprawdzone.

Poziom drabiny	Utrzymuj w formie ręcznie	Oddaj agentowi	Dowody do portfolio	Sygnał gotowości na kolejny poziom
Poziom 1–2: z asystą i w parze	Debugowanie, czytanie nieznanego kodu, rdzeń głównego języka	Boilerplate, szkielety testów, wyszukiwanie informacji	Notatki z wyjaśnień jednej zmiany agenta tygodniowo; jeden problem tygodniowo rozwiązany ręcznie	Przewidujesz większość diffa agenta, zanim go przeczytasz
Poziom 3: przeglądasz diffy	Ocena w code review, wyłapywanie dryfu projektowego	Implementacja dobrze określonych zadań	Dziennik review: wyłapane defekty, klasa każdego i sprawdzenie, które złapałoby go automatycznie	Większość defektów z dziennika łapie już automatyczne sprawdzenie
Poziom 4: piszesz specyfikacje	Specyfikacja, projekt wyroczni, decyzje architektoniczne	Wielogodzinne przebiegi z warunkiem stopu	Pary specyfikacja–dowód: specyfikacja, kryteria akceptacji, test, który najpierw nie przechodził, i zmergowany wynik; zapisy decyzji architektonicznych	Twoje specyfikacje częściej niż rzadziej wracają poprawne za pierwszym razem, a chybienia uczą cię czegoś nowego
Poziom 5: prowadzisz fabrykę	Smak, decyzja o tym, co może chodzić bez nadzoru, debugowanie incydentów	Całe pętle, łącznie ze stanowiskiem review	Wkład w harness: bramki, funkcje dopasowania (fitness functions) i spisane uzasadnienie każdej pętli bez nadzoru; incydenty, przy których bramka zadziałała	Pętle innych osób działają na twoich bramkach. Poziom 5 nie jest domyślnym celem kariery: Shapiro umieszcza na nim tylko „a handful of people”, w „small teams, less than five people”, a mocne portfolio na Poziomie 4 jest portfolio kompletnym

Skopiuj jednostronicowy plan umiejętności

Zapisz go jako prywatny plik, uzupełnij i przynieś na najbliższe spotkanie one-on-one. To artefakt wyjścia ze ścieżki dewelopera: spisany plan umiejętności, które utrzymasz, i tych, które oddajesz.

# Plan umiejętności: <imię i nazwisko>, <kwartał>

## Obecny poziom drabiny, osobno dla każdej pętli
- Nowe funkcje w <główne repozytorium>: Poziom <n>
- Poprawki błędów: Poziom <n>
- Refaktoryzacje i migracje: Poziom <n>

## Umiejętności, które zyskują: jeden cel na kwartał dla każdej
- Specyfikacja: <np. kryteria akceptacji przed każdym zadaniem; mierzę zgodność za pierwszym razem>
- Projektowanie weryfikacji: <np. jedno sprawdzenie odporne na agenta na każdą funkcję>
- Architektura: <np. jeden zapis decyzji tygodniowo>
- Smak: <np. jeden odrzucony zielony wynik tygodniowo, z zapisanym powodem>

## Chroniona praktyka (terminy w kalendarzu, nie intencje)
- Problem bez pomocy: <dzień, godzina, 60 min>
- Zasada „najpierw sam”: 15 minut własnej hipotezy przed oddaniem błędu agentowi
- Tryb nauki włączony dla: <biblioteka albo podsystem>

## Oddane celowo
- <umiejętność>: oddana, bo pokrywa ją <bramka>

## Dowody zebrane w tym kwartale
- Pary specyfikacja–dowód: <linki>
- Dziennik review albo zaufania: <link>
- Zapisy decyzji: <linki>
- Dodane przeze mnie bramki i sprawdzenia: <linki>

Prompty, które zamieniają twoją historię w dowody

Prompt do skopiowania: dziennik review z ostatnich pull requestów

Read the pull requests I authored or reviewed in this repository over the last
90 days (use git log and the review comments you can access). Produce a table
with one row per defect I caught in an agent-written change: PR, file, the
defect in one line, its class (logic, security, performance, design, test gap),
and the automated check that would have caught it. Add a final column saying
whether that check exists in the repository today. Do not invent defects: if a
comment is ambiguous, leave it out and list it separately.

Prompt do skopiowania: gdzie twój model systemu jest cienki

Look at the modules I changed most over the last 90 days (git log --author).
For each of the top five, ask me three questions a senior engineer on this
codebase should answer without notes: one on data flow, one on a failure mode,
and one on why the current design was chosen. Ask one question at a time and
wait for my answer. At the end, rank the five modules by how well I answered,
and for the weakest one propose a 60-minute exercise I do by hand.

Jak udowodnić, że twoje umiejętności się trzymają?

Twoja ocena własnych umiejętności to najsłabsze dostępne sprawdzenie, więc mierz. W badaniu 16 doświadczonych programistów open source, pracujących nad 246 zgłoszeniami na narzędziach z początku 2025 roku (METR, lipiec 2025), zadania z AI zajmowały o 19% więcej czasu, a mimo to po wszystkim wciąż uważali, że AI przyspieszyło ich o 20%. Używaj sprawdzeń, które dają liczbę albo artefakt:

• Kata bez pomocy, co miesiąc. Rozwiąż jeden problem na czas w głównym języku, bez agenta. Zapisuj czas i liczbę błędów. Stały wzrost to wczesne ostrzeżenie.
• Wynik wyjaśnienia. Po prompcie ze sprawdzeniem przez wyjaśnienie policz punkty, które pominąłeś. Jeśli przy znajomych modułach pominięć przybywa, twój model systemu się zaciera.
• Trafność prognoz. Porównaj dwulinijkową prognozę z faktycznym diffem. Zapisz trafienie albo pudło.
• Zgodność specyfikacji za pierwszym razem. Przy pracy na Poziomie 4 zapisuj, czy pierwszy wynik agenta spełnił twoje kryteria akceptacji. To mierzy twoją umiejętność specyfikowania, a nie model.
• Wyłapane błędy, które stały się sprawdzeniami. Policz wpisy w dzienniku review, które mają już automatyczne sprawdzenie. Ta liczba to zmierzone projektowanie weryfikacji.

Sam kod nie opiera się na twojej samoocenie. Przechodzi przez bramki: testy, typy, lint, pakiet dowodów przy każdym pull requeście i czytanie przez człowieka dla klas zmian wysokiego ryzyka. Tech lead co kwartał przegląda z tobą plan umiejętności i dowody. Ty odpowiadasz za praktykę, a lead zatwierdza poziom, na którym pracujesz w każdej pętli.

Co tech lead powinien zmienić w zespole

Badanie Anthropic przytacza starszego inżyniera, któremu jest przykro, że juniorzy rzadziej przychodzą z pytaniami, choć dostają odpowiedzi skuteczniej i uczą się szybciej. Pytania, które do ciebie nie docierają, to te, które kiedyś przekazywały osąd. Trzy zmiany przywracają ten kanał bez spowalniania zespołu:

• Pracuj z juniorami w parze nad specyfikacją, nie nad kodem. Przeglądaj kryteria akceptacji juniora przed przebiegiem, a nie tylko diff po nim. Specyfikacja pokazuje, co zrozumiał.
• Uczyń portfolio jednostką oceny. Na spotkaniach one-on-one i w ocenach okresowych proś o pary specyfikacja–dowód, dzienniki review i zapisy decyzji zamiast liczby pull requestów czy linii. Macierz kompetencji opisuje strona ścieżki kariery, gdy output jest tani.
• Chroń czas na praktykę w planie. Tygodniowy termin z trybem nauki i jeden problem bez pomocy kosztują mniej niż jeden incydent, którego nikt w zespole nie umie zdebugować. Strony juniorzy w zespole agentowym i podnoszenie kompetencji zespołu zamieniają to w program nauki.

Co psuje plan rozwoju warsztatu, gdy kod piszą agenci

Przestajesz umieć debugować własny system. Objaw: każda awaria trafia prosto do agenta, a ty nie potrafisz powiedzieć, co zmieniła poprawka. Jak wrócić: przez miesiąc stosuj zasadę „najpierw sam” i uruchom prompt „gdzie twój model systemu jest cienki” na module, w którym był ostatni incydent.

Twoje portfolio pokazuje tylko przepustowość. Liczba zmergowanych pull requestów nic nie mówi o osądzie, a recenzent, który wie, jak tani stał się output, ją zdyskontuje. Jak wrócić: odtwórz dowody z kwartału promptem do dziennika review i do każdego osiągnięcia dołącz parę specyfikacja–dowód.

Tryb nauki zostaje na stałe. Wyjaśnienia przy każdym zadaniu spowalniają zwykłą pracę i zaczynasz je przewijać. Włączaj tryb dla konkretnego podsystemu albo biblioteki i wyłączaj go, gdy wynik wyjaśnień trzyma się wysoko przez miesiąc.

Chronisz niewłaściwe umiejętności. Godziny ćwiczenia składni to godziny odebrane specyfikacji albo projektowaniu wyroczni. Jeśli umiejętność pokrywają agent i bramka, oddaj ją celowo i zapisz, która bramka ją pokrywa.

Pocieszenie zastępuje dowody. „Inżynierowie zawsze będą potrzebni” i „juniorzy są skończeni” to twierdzenia bez źródła. Planuj wokół tego, co możesz zmierzyć we własnej pracy, a każdą prognozę kariery bez wydawcy i daty traktuj jak szum.

Czego żadne źródło jeszcze nie mówi

Żadne badanie dostępne 26 września 2026 roku nie mierzy, co dzieje się z umiejętnościami inżyniera przez lata pracy opartej na agentach. Badanie kształtowania umiejętności mierzyło zrozumienie tuż po zadaniu. Badanie Anthropic w miejscu pracy to deklaracje z jednej firmy. Nie udało się nam pobrać i zweryfikować danych o zatrudnieniu programistów na początku kariery, więc ta strona nie podaje o tym żadnej liczby. Dowody wspierają wniosek węższy, ale bardziej użyteczny: to, jak delegujesz, zmienia to, co zachowujesz, a umiejętności decydujące o tym, co powstaje i czy można temu ufać, to te, których agenci nie przejmują.

Dokąd dalej z twoim warsztatem

Czytanie dowodów zamiast kodu Umiejętność review, która zastępuje czytanie linijka po linijce przy dużym wolumenie.

Co zostaje człowiekowi w inżynierii agentowej Sześć odpowiedzialności stojących za umiejętnościami, które zyskują.

Poziom 4: piszesz specyfikacje Gdzie specyfikacja i warunki stopu stają się codzienną pracą.

Ścieżka dewelopera Pełna ścieżka czytania, którą zamyka ta strona.

Ścieżki kariery i oceny pracy Dla leadów: macierz kompetencji przepisana wokół specyfikacji i weryfikacji.