Zespół: prowadzenie zespołu, który dowozi z agentami
Aby prowadzić zespół pracujący z agentami, zamień konfigurację w system zespołu, a nie nawyk jednego entuzjasty: wdrażaj repozytorium po repozytorium, utrzymuj jeden wersjonowany harness, napraw bramki review przed dodaniem równoległych agentów i powierz seniorom odpowiedzialność za te bramki. Każda sekcja tego przeglądu wskazuje pytania ze scorecardu tech leada, na które odpowiada.
Właśnie dostałeś zgodę na wdrożenie agentów u wszystkich ośmiu inżynierów w zespole. Każdy z nich używa już innego narzędzia z prywatnymi ustawieniami, CI sprawdza tylko lint, a nikt nie ustalił, kto przegląda to, co otwiera agent. Musisz zdecydować, co ustandaryzować najpierw. Te strony podają kolejność działań i sposób, by sprawdzić, czy zadziałała.
Od czego tech lead powinien zacząć?
Dział zatytułowany „Od czego tech lead powinien zacząć?”Najpierw wypełnij scorecard tech leada (25 pytań, około ośmiu minut). Klucz odpowiedzi prowadzi od każdego pytania do jego strony i mówi, jakie dowody są potrzebne do odpowiedzi za 3 punkty. Jeśli nie masz jeszcze wyniku, zacznij od objawu, który widzisz:
| Co widzisz w zespole | Zacznij od | Pytania ze scorecardu |
|---|---|---|
| Każdy konfiguruje swojego agenta inaczej | Wspólne reguły agentów · Onboarding developera | 1–4 |
| Pull requesty agentów czekają na review całymi dniami | Kolejka code review | 6 (14, 15 pokrewne) |
Wiarygodnie wyglądający, ale błędny kod trafia do main | Pakiet dowodów | 7 (5, 8 pokrewne) |
| Agenci dostają zadania, których nie mogą skończyć ani zweryfikować | Jak przygotować backlog dla agentów | 17 |
| Seniorzy sprawdzają wszystko ponownie albo się wycofują | Sceptycy i seniorzy | 12 |
| Użycie jest nierówne i nikt nie wie dlaczego | Mapa adopcji | 9–11 |
| Juniorzy dostarczają kod, którego nie potrafią wyjaśnić | Podnoszenie kompetencji zespołu · Rozwój juniorów (pokrewne) | 18 |
Adopcja: od jednego repozytorium pilotażowego do całego zespołu
Dział zatytułowany „Adopcja: od jednego repozytorium pilotażowego do całego zespołu”Wdrożenie przebiega repozytorium po repozytorium: pilotaż, osobę odpowiedzialną za wsparcie i kryterium wyjścia spisane przed startem. Te strony odpowiadają na pytania 4 i 9–11.
Przegląd sekcji o adopcji prowadzi też do przewodników dla zespołów, które przechodzą z innego narzędzia.
Wspólny harness: jedna konfiguracja zamiast ośmiu prywatnych
Dział zatytułowany „Wspólny harness: jedna konfiguracja zamiast ośmiu prywatnych”Harness to wspólny rdzeń instrukcji (AGENTS.md z cienkimi adapterami, np. CLAUDE.md i Rules w Cursorze), skille, hooki i serwery MCP, które ładuje każdy agent w zespole. Żyje w repozytorium i zmienia się wyłącznie przez pull requesty. Te strony odpowiadają na pytania 1–3, 16 i 20 i omawiają Claude Code, Codex i Cursor obok siebie.
Code review i przepływ pracy: pull requesty mają płynąć, a nie być zatwierdzane w ciemno
Dział zatytułowany „Code review i przepływ pracy: pull requesty mają płynąć, a nie być zatwierdzane w ciemno”Agenci zwiększają tempo napływu pull requestów, a przepustowość review zostaje taka sama. Napraw bramki jakości, zanim dołożysz równoległych agentów, bo inaczej recenzenci zaczną akceptować bez patrzenia. Te strony odpowiadają na pytania 5–8, 14, 15 i 17; klucz odpowiedzi wskazuje drugą stronę dla każdego z nich.
Ludzie: sceptycy, seniorzy, juniorzy i bycie na bieżąco
Dział zatytułowany „Ludzie: sceptycy, seniorzy, juniorzy i bycie na bieżąco”Narzędzia zmieniają się co tydzień, a to ludzie decydują, czy system się utrzyma. Te strony odpowiadają na pytania 12, 18, 19 i 21.
Pytania 13 i 22–25 (własność i budżet narzędzi, koszty, sekrety, czego agentom nie wolno dotykać, na jakich narzędziach się standaryzujecie) należą do poziomu organizacji. Ich strony wymienia klucz odpowiedzi; większość jest w sekcji Organizacja inżynierii, a polityka narzędzi i bezpieczeństwo MCP są w przewodniku po scorecardzie CTO.
Skąd wiesz, że system zespołu działa, bez czytania każdego diffa?
Dział zatytułowany „Skąd wiesz, że system zespołu działa, bez czytania każdego diffa?”Wymagaj artefaktów, nie zapewnień. Każdy scalony pull request agenta ma dołączony pakiet dowodów: kryteria akceptacji, testy, które ich dowodzą, i wymagane kontrole CI, które przeszły. Branch protection wymusza te same bramki na każdym pull requeście, niezależnie od tego, kto lub co go napisał. Strona Czytanie dowodów zamiast kodu wyjaśnia, dlaczego to zastępuje review linijka po linijce.
Potem co miesiąc patrz na trzy liczby: czas w review, change failure rate (odsetek wdrożeń, które powodują awarię na produkcji) i odsetek losowo czytanych pull requestów, w których człowiek znalazł coś, co bramki przepuściły. Tech lead jest właścicielem bramek, a wskazany inżynier odpowiada za dowody każdej pętli (powtarzalnej klasy zmian z własnym wyzwalaczem, wyrocznią i warunkiem stopu). Potraktuj to jako umowę zespołu i zapisz ją w repozytorium obok AGENTS.md:
Zastąp N limitem WIP dla całego zespołu, który udźwignie przepustowość review; strona o kolejce code review pokazuje, jak go wyznaczyć. Umowa zostaje po angielsku, bo trafia do repozytorium obok reguł czytanych przez agentów.
Co się psuje, gdy zespół wdraża agentów?
Dział zatytułowany „Co się psuje, gdy zespół wdraża agentów?”- Agenci wzmacniają słabe bramki jakości. Raport DORA 2025 (Google Cloud, 23 września 2025) ujmuje to wprost: „AI doesn’t fix a team; it amplifies what’s already there” (AI nie naprawia zespołu, tylko wzmacnia to, co już w nim jest). Naprawa: zamroź dokładanie równoległości, napraw pytania 5–8, dopiero potem podnieś limit.
- Harness się rozjechał. Każdy developer dostroił prywatną konfigurację i agenci nie zgadzają się już co do konwencji. Naprawa: scal prywatne reguły ze wspólnym plikiem w jednym pull requeście po review i kieruj tą samą drogą każdą kolejną zmianę.
- Zaufanie wyprzedziło dowody. Zespół pominął review w pętli ze słabymi testami i defekt uciekł na produkcję. Naprawa: cofnij tę pętlę o jeden etap, tak jak opisuje strona o transferze zaufania, i wzmocnij jej testy, zanim ruszysz dalej.
- Seniorów ominięto. Wskaźniki adopcji wyglądają dobrze, a seniorzy po cichu sprawdzają wszystko ponownie. Naprawa: powierz im odpowiedzialność za bramki i reguły.