Ścieżka tech leada: cały zespół o szczebel wyżej

Ścieżka tech leada to plan czytania dla tech leadów, którzy chcą, żeby z Claude Code, Codeksem albo Cursorem dowoził cały zespół, a nie jeden power user: jedna osoba scala pięć pull requestów od agenta dziennie, dwie odmawiają używania narzędzi, a przegląd kodu najbardziej spowalnia dostarczanie. Obejmuje trzy zadania: standaryzację harnessu, weryfikację i przepustowość przeglądów kodu.

Na czym polega praca tech leada, gdy kod piszą agenci?

Przechodzisz od pisania kodu do projektowania systemu, który decyduje, czy kod trafi na produkcję:

Standaryzuj harness. Harness to wszystko, co zespół współdzieli wokół modelu: plik instrukcji, uprawnienia, serwery MCP, skille i jedno polecenie uruchamiające testy, linter i sprawdzanie typów. Trzymaj go w repozytorium i przeglądaj jak kod.

Odpowiadaj za projekt weryfikacji. Tanie generowanie przesuwa wąskie gardło na sprawdzanie. DORA 2025 (Google Cloud, 23 września 2025) ostrzega, że bez kontroli takich jak mocne testy automatyczne, „wzrost liczby zmian prowadzi do niestabilności” (tłum. własne). Wybierasz testy, funkcje dopasowania (fitness functions) i kryteria akceptacji, które dowodzą poprawności zmiany.

Zarządzaj przepustowością przeglądów kodu. Przegląd kodu to kolejka o stałej przepustowości: Faros AI AI Engineering Report 2026 (kwiecień 2026; 22 000 programistów, telemetria dostawcy) zmierzył wzrost przepustowości zadań o 33,7%, mediany czasu w przeglądzie kodu o 441,5% i incydentów na pull request o 242,7%. Decydujesz, które zmiany ktoś czyta, a które scalasz na podstawie dowodów.

Najpierw punkt odniesienia, na końcu przeniesienie zaufania: przegląd oparty na dowodach bez mocnych testów tylko przesuwa ryzyko.

Ścieżka tech leada krok po kroku

Każdy krok jest oznaczony jako bezpłatny albo dla subskrybentów; trzy kroki drabiny są bezpłatne. Przeczytaj je po kolei, potem pomijaj kroki, których dowód ukończenia zespół już ma.

1 Jedna mapa: drabina autonomii, cykl życia i stacje fabryki Bezpłatne

Dlaczego teraz: Jedna rama dla dojrzałości, procesu i możliwości, zanim zmienisz sposób pracy ośmiu osób.

Gotowe, gdy: Twój zespół umieszczony na mapie, pętla po pętli.
2 Poziom 3: przeglądasz diffy Bezpłatne

Dlaczego teraz: Większość zespołów utyka na poziomie 3; poznaj jego sufit code review, zanim zaplanujesz wyjście ponad niego.

Gotowe, gdy: Zespół wie, ile diffów tygodniowo naprawdę jest w stanie przejrzeć.
3 Czytanie dowodów zamiast kodu Bezpłatne

Dlaczego teraz: Standard, do którego zmierza zespół: najpierw dowody, kod tylko w klasach eskalacji.

Gotowe, gdy: Klasy eskalacji uzgodnione z zespołem.
4 DORA, SPACE, DX Core 4 i pomiar AI, gdy kod piszą agenci Dla subskrybentów

Dlaczego teraz: Ustal punkt odniesienia przed wdrożeniem, inaczej nie pokażesz, co się zmieniło.

Gotowe, gdy: Cztery tygodnie danych bazowych dla metryk, które będziesz raportować.
5 Jak przekonać sceptyków i seniorów Dla subskrybentów

Dlaczego teraz: Odmowa seniorów po cichu ogranicza cały zespół; włącz sceptyków przed wdrożeniem.

Gotowe, gdy: Każdy senior dowiózł z agentem jedną prawdziwą zmianę, w parze z tobą.
6 Mapa adopcji dla jednego repozytorium: przejścia po drabinie pętla po pętli Dla subskrybentów

Dlaczego teraz: Wdrażaj po jednym repozytorium, jako przejścia na drabinie, a nie wielki wybuch.

Gotowe, gdy: Mapa z jednym repozytorium, jedną pętlą i jednym kryterium ukończenia na krok.
7 Jak przygotować repozytorium do pracy agentów Dla subskrybentów

Dlaczego teraz: Agenci wzmacniają to, czym repozytorium już jest; najpierw uczyń je czytelnym i testowalnym.

Gotowe, gdy: Bootstrap jednym poleceniem, szybkie testy i aktualny AGENTS.md.
8 Wspólne reguły agentów — jeden rdzeń, przetestowane adaptery Dla subskrybentów

Dlaczego teraz: Jeden wspólny, wersjonowany rdzeń reguł zamiast ośmiu prywatnych konfiguracji.

Gotowe, gdy: Wspólne reguły w repozytorium, przeglądane jak kod.
9 Jak przygotować backlog dla agentów Dla subskrybentów

Dlaczego teraz: Agenci dobrze radzą sobie z dobrze opisaną pracą; ułóż backlog tak, żeby ją dostawali.

Gotowe, gdy: Szablon zgłoszenia z kryteriami akceptacji i klasą ryzyka.
10 Jak silna jest twoja wyrocznia? Zaufanie do testów, których nie czytałeś Dla subskrybentów

Dlaczego teraz: Ufanie testom, których nie czytałeś, wymaga miary ich siły.

Gotowe, gdy: Wynik mutacyjny albo siły wyroczni dla repozytoriów, których dotykają agenci.
11 Pakiet dowodów: co musi udowodnić pull request agenta Dla subskrybentów

Dlaczego teraz: Zdefiniuj w jednym manifeście, czego musi dowieść każdy pull request agenta.

Gotowe, gdy: Pakiet dowodów wymagany przez CI w pull requestach agentów.
12 Funkcje dopasowania architektury: utrzymywalność bez czytania kodu Dla subskrybentów

Dlaczego teraz: Utrzymywalność sprawdzają funkcje dopasowania, nie czytanie kodu.

Gotowe, gdy: Dwie reguły architektury egzekwowane w CI.
13 Code review PR-a agenta bez czytania każdej linii Dla subskrybentów

Dlaczego teraz: Code review według dowodów i klasy ryzyka, żeby przepustowość code review przestała być wąskim gardłem.

Gotowe, gdy: Krótszy czas code review na pull request agenta przy niezmienionej liczbie przepuszczonych błędów.
14 Kolejka code review, gdy pull requesty otwierają agenci Dla subskrybentów

Dlaczego teraz: Prowadź kolejkę code review jak system, gdy większość pull requestów otwierają agenci.

Gotowe, gdy: Limit pracy w toku i alert wieku kolejki code review.
15 Jak pomóc zespołowi przestać czytać każdy diff Dla subskrybentów

Dlaczego teraz: Świadomie przeprowadź zespół od czytania każdego diffa do zaufania dowodom.

Gotowe, gdy: Jedna klasa ryzyka scalana przez miesiąc wyłącznie na podstawie dowodów, bez incydentu.
16 Rozwój juniorów, gdy kod piszą agenci Dla subskrybentów

Dlaczego teraz: Juniorzy nadal muszą rozwijać osąd, gdy kod piszą agenci.

Gotowe, gdy: Plan rozwoju dla każdego juniora z wbudowanym code review i pracą projektową.

Dalsza lektura

Które pytanie ze scorecardu poprawia każdy krok?

To czterotygodniowy plan: wybierz po jednym wierszu z grup Harness, Weryfikacja i Code review, potem powtórz scorecard. Numeracja według klucza odpowiedzi.

Krok	Pytanie, które poprawia	Dowód ukończenia
Rama: Jedna mapa	Twój poziom	Zespół umieszczony na drabinie
Code review: Poziom 3, przeglądasz diffy	pyt. 6, standardy przeglądu	Znana tygodniowa przepustowość przeglądów
Weryfikacja: Dowody zamiast kodu	pyt. 8, kod wiarygodny, ale błędny	Uzgodnione klasy eskalacji
Punkt odniesienia: Ramy metryk	pyt. 11, pomiar wpływu	Cztery tygodnie danych bazowych
Ludzie: Sceptycy i seniorzy	pyt. 12, sceptycy i seniorzy	Każdy senior dowiózł zmianę z agentem
Harness: Mapa adopcji	pyt. 10, jak przebiegła adopcja	Repozytorium pilotażowe, jedno kryterium
Harness: Repozytorium gotowe na agentów	pyt. 2 i 4, kontekst i onboarding	Bootstrap jednym poleceniem, aktualne instrukcje
Harness: Wspólne reguły agentów	pyt. 1, wspólna konfiguracja agenta	Reguły w repozytorium, przeglądane jak kod
Harness: Backlog gotowy na agentów	pyt. 5, spójna jakość	Szablon zgłoszenia z klasą ryzyka
Weryfikacja: Siła wyroczni	pyt. 8, kod wiarygodny, ale błędny	Wynik testów mutacyjnych kodu agentów
Weryfikacja: Pakiet dowodów	pyt. 7, automatyczne bramki	CI wymaga pakietu
Weryfikacja: Funkcje dopasowania	pyt. 5, spójna jakość	Dwie reguły architektury egzekwowane w CI
Code review: Przegląd PR-ów agentów	pyt. 6 i 15, standardy i pętla PR-ów	Krótszy czas przeglądu, tyle samo przepuszczonych błędów
Code review: Kolejka przeglądów	pyt. 15, pętla PR-ów i scalania	Limit pracy w toku i alert wieku kolejki
Code review: Przeniesienie zaufania	pyt. 24, czego AI nie może dotykać	Jedna klasa ryzyka scalana na dowodach
Ludzie: Juniorzy	pyt. 18, rozwój umiejętności zespołu	Plan rozwoju dla każdego juniora

Gdzie w każdym narzędziu jest wspólny harness?

Konfiguracja zespołu należy do repozytorium, nie do laptopów.

Instrukcje: CLAUDE.md w repozytorium. Claude Code sięga po AGENTS.md od v2.1.277 na kanale latest, a na kanale stable jeszcze nie.
Uprawnienia: wspólny .claude/settings.json, który ignoruje auto i bypassPermissions w defaultMode.
Serwery MCP: claude mcp add --scope project, zapisane w repozytorium.
Code review: /code-review lokalnie i anthropics/claude-code-action@v1 w CI. Sprawdzono na Claude Code 2.1.283, 26 września 2026.

Instrukcje: AGENTS.md, wczytywany dopiero po oznaczeniu repozytorium jako zaufanego (od Codex CLI 0.150.0).
Zabezpieczenia: ograniczenia administracyjne w requirements.toml.
Code review: /review w CLI, @codex review w pull requestach (sprawdzono 28 sierpnia 2026) i openai/codex-action@v1 w CI.
Kontrole headless: codex -a never exec … w runnerze z sandboksem (Codex CLI 0.157.1, sprawdzono 26 września 2026).

Audit this repository as the shared harness for a team of eight engineers using coding agents. Report, without changing any files:
1) which agent instructions files exist (CLAUDE.md, AGENTS.md, project rules) and whether they conflict,
2) the single command that runs tests, lint, and type checks, and how long it takes,
3) which MCP servers and permission settings are checked in versus left to each engineer,
4) what CI checks every pull request, and which checks an agent-authored change could pass while still being wrong.
End with the three gaps that would most change review load, each with the evidence that would show it is closed.

Dlaczego wdrożenie w zespole utyka?

Liczby ciągnie jeden power user. Średnia zespołu potrafi ukryć osoby, które wciąż są na poziomie 1. Jak naprawić: połącz każdą zwlekającą osobę w parę z power userem przy prawdziwym zgłoszeniu.
Po wdrożeniu rośnie czas przeglądu kodu. Jak naprawić: ogranicz otwarte pull requesty agentów i kieruj zmiany według klasy ryzyka, zanim dodasz recenzentów.
Harness się rozjeżdża. Jak naprawić: instrukcje i ustawienia zmieniaj tylko przez pull requesty; prompt audytowy uruchamiaj co miesiąc.
Zaufanie przenosisz, zanim wyrocznia jest wystarczająco silna. Jak naprawić: przywróć tę klasę ryzyka do przeglądu linia po linii, dopóki wyrocznia nie będzie dość silna.

Dokąd dalej jako tech lead

Scorecard tech leada: klucz odpowiedzi Każde pytanie scorecardu przypisane do strony, która je poprawia

Prowadzenie zespołu Wdrożenie, wspólny harness, przeglądy i przepływ oraz ludzie

Ścieżka dewelopera Ścieżka, którą krok po kroku idą twoi programiści

Zacznij tutaj Wybierz inną rolę albo punkt startu

Najczęstsze pytania

Czym jest ścieżka tech leada?

To uporządkowana ścieżka czytania dla tech leadów i szefów zespołów, którzy chcą przenieść wyżej na drabinie autonomii cały zespół, a nie jednego power usera. Zaczyna się od darmowego scorecardu tech leada jako punktu odniesienia, a potem prowadzi przez trzy zadania: standaryzację harnessu, projekt weryfikacji i zarządzanie przepustowością przeglądów kodu. Każdy krok wskazuje pytanie ze scorecardu, które poprawia, i dowód, że zespół może iść dalej.

Dlaczego ścieżka zaczyna się od scorecardu?

Scorecard zajmuje około 8 minut i ocenia zespół w 25 pytaniach. Odpowiedzi pokazują, które kroki zespół już spełnia, a ponowne wypełnienie po czterech tygodniach pokazuje, które sekcje się poprawiły. Klucz odpowiedzi przypisuje każde pytanie do strony, która je poprawia.

Które kroki są darmowe?

Trzy kroki drabiny na początku ścieżki są bezpłatne. Każdy krok jest oznaczony jako bezpłatny albo dla subskrybentów.