Onboarding i adopcja w zespole, pętla po pętli

Adopcja agentów kodujących w zespole to rozszerzanie jednej sprawdzonej praktyki z kilku inżynierów na cały zespół, jedna pętla naraz. Każda pętla ma właściciela, który wdraża kolegów na jej obecnym poziomie autonomii. Adopcję mierzy się efektywnym użyciem: odsetkiem uprawnionych inżynierów, którzy domykają pętlę na granicy dowodów, gdy awarie zmian zostają na poziomie bazowym (baseline).

Ta strona jest dla tech leada, który prowadzi wdrożenie, i dla CTO, który pyta, czy się udało. Wiosną dałeś dostęp dwunastu inżynierom. Dwóch z nich co tydzień puszcza przez agenta aktualizacje zależności, jeden senior przestał po jednym złym pull requeście, a reszta używa go do podpowiedzi. Na ostatnim retro ktoś powiedział, że wcześni użytkownicy „dowożą dużo szybciej”, i nikt nie umiał powiedzieć, jak to zmierzono ani ile kosztowało to kolejkę review.

Co daje ci wdrożenie pętla po pętli

Regułę wyboru pierwszej pętli, którą zespół przyjmuje, i imiennego właściciela pętli zamiast „sieci championów”.
Wspólny harness, który czyta agent każdego inżyniera, zsynchronizowany między Claude Code, Codex i Cursorem.
Sekwencję onboardingu, która prowadzi jednego inżyniera od dostępu do policzonego ukończenia w dwóch prawdziwych zadaniach.
Osobne reguły rozszerzania pętli na kolejne osoby i wspinania się pętli na następny szczebel drabiny, razem z tym, kto je podpisuje.
Miarę efektywnego użycia z promptem, który liczy ją ze zmergowanych pull requestów, oraz tryby awarii, przez które liczby adopcji kłamią.

Dlaczego adopcja pętlami, a nie według krzywej adopcji?

Samo używanie już nie odróżnia zespołów. Raport DORA 2025 podaje, że „90% of survey respondents report using AI at work” (Google Cloud, 23 września 2025). Centralny wniosek tego samego raportu to powód, żeby przestać liczyć użytkowników: „AI doesn’t fix a team; it amplifies what’s already there”. Zespół, który rozszerza użycie agentów bez testów, limitów review i wspólnego kontekstu, dostaje więcej nieprzejrzanych zmian, a nie więcej dostarczonej wartości.

Poziom należy też do pętli, a nie do osoby ani zespołu. Jedna mapa definiuje pętlę jako powtarzalną klasę zmian z własnym wyzwalaczem, wyrocznią i warunkiem stopu, na przykład aktualizacje zależności, naprawę niestabilnych testów albo pracę nad funkcjami w jednym serwisie. Ten sam inżynier może jednego dnia prowadzić aktualizacje zależności na L4 i integrację z operatorem płatności na L2, i oba poziomy są poprawne.

Przełóż starsze schematy wdrożenia na pętle, a potem je wycofaj:

Wycofany schemat	Co miał załatwić	Co go zastępuje
Krzywa adopcji (championi, wcześni użytkownicy, większość, maruderzy)	Tempo wdrożenia wyznaczane przez ludzi	Rozszerzanie jednej pętli naraz, z właścicielem i listą uprawnionych dla każdej pętli
Wspólna podstawa „Faza 0”	Powstrzymanie rozjazdu konwencji między narzędziami	Wspólny harness opisany niżej, z kryterium wyjścia
Modele według wielkości organizacji (2–10, 10–50, 50+) ze stałymi tygodniami	Rozpisanie kalendarza	Tempo wyznacza liczba pętli i zespołów; przy wielu zespołach projekt pilotażu
Trzy poziomy szkoleń	Nauka funkcji narzędzia według stażu	Podnoszenie kompetencji per przejście po drabinie
Aktywni użytkownicy, sesje dziennie	Dowód adopcji	Efektywne użycie w każdej pętli, z metrykami ochronnymi

Zbuduj jeden wspólny harness, zanim ktokolwiek zacznie onboarding

Onboarding się sypie, gdy agent każdego inżyniera czyta inny kontekst. Zanim pierwsza osoba dołączy do pętli, zacommituj jeden plik instrukcji wygenerowany z prawdziwego repozytorium. Playbook konwersji projektu opisuje pełną konfigurację; tu jest minimum.

Uruchom claude w katalogu głównym repozytorium i wklej:

Explore this repository and write a CLAUDE.md at the root. Capture our stack,
the exact install, build, typecheck, lint and test commands, our branch and
PR conventions, and the conventions a new engineer most often gets wrong.
Bullet points only, under 60 lines. Then run each command you listed and
report which pass on the default branch. Finally, list which rules an
automated check could enforce, so they move into CI instead of prose.

W dużym monolicie dopisz „use subagents to survey each top-level directory”, żeby eksploracja nie wyczerpała kontekstu głównej sesji. Claude Code czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md, od v2.1.277 w sesjach first-party i od v2.1.281 na Bedrock, Google Cloud, Foundry, bramkach LLM albo z wyłączoną telemetrią, w obu przypadkach na kanale latest (kanał stable był 26 września 2026 na v2.1.274). Sprawdź kanał swoich inżynierów, zanim zaczniesz na tym polegać.

Codex czyta AGENTS.md, zanim zacznie pracę, a /init w Codex CLI szkicuje ten plik. Zastąp szkic wynikiem tego promptu:

Read this repository and write an AGENTS.md at the root: stack, the exact
install, build, typecheck, lint and test commands, PR conventions, and the
conventions a new contributor would miss. Keep it under 60 lines. Run each
command you listed and report which pass on the default branch. Then list
the conventions stable enough to enforce in CI.

Od Codex CLI 0.150.0 niezaufany projekt nie dostarcza swojego AGENTS.md, więc każdy inżynier raz oznacza repozytorium jako zaufane: akceptuje pytanie o zaufanie przy pierwszym uruchomieniu codex w repozytorium albo dopisuje bezwzględną ścieżkę repozytorium do ~/.codex/config.toml jako [projects."/sciezka/do/repo"] z trust_level = "trusted" (klucz sprawdzony w Codex CLI 0.157.1). Wpisz ten krok na checklistę onboardingu. Żeby potwierdzić, że plik się wczytał, poproś agenta o zacytowanie pierwszej reguły z AGENTS.md.

Otwórz agenta w repozytorium i poproś o szkic Rules projektu z tych samych faktów:

Read the repository structure, package manifest, CI configuration and the
three largest source files. Draft project rules capturing our stack, how
to run tests and lint, our branch and PR conventions, and the three things
a new contributor most often gets wrong. Write imperative rules, not prose,
under 50 lines. Show me the rules before you save them.

Zacommituj Rules razem z repozytorium, żeby agent każdego inżyniera je ładował. Trzymaj jeden rdzeń konwencji i generuj z niego pliki dla poszczególnych narzędzi, tak jak opisują wspólne reguły agentów.

Kryterium wyjścia harnessu jest mechaniczne: świeży klon przechodzi typecheck, lint i testy dokładnie tymi komendami, które wymienia plik instrukcji. Zespoły korzystające z więcej niż jednego narzędzia muszą potem pilnować, żeby pliki się zgadzały.

Compare CLAUDE.md, AGENTS.md and the Cursor project rules committed in this
repository. List every place they disagree about our stack, commands or
conventions, with the file and line for each side. Propose one source of
truth: pick the most complete file, and rewrite the others as thin pointers
to it plus the notes that only apply to that tool. Show me the diffs and
wait for my approval before writing anything.

Uruchamiaj prompt synchronizacji przy każdej zmianie któregoś z plików. Wspólne skille i hooki podlegają tej samej zasadzie: jedna zacommitowana kopia, przeglądana jak kod (wspólne skille).

Którą pętlę zespół przyjmuje jako pierwszą?

Wybierz pętlę, której wynik już ocenia twoja platforma hostingu kodu i CI, żeby ukończenie liczył system, a nie osoba, która je wykonała.

Kryterium	Dobra pierwsza pętla	Słaba pierwsza pętla
Wolumen	Co najmniej pięć zmergowanych zmian miesięcznie, żeby 30-dniowe okno zawierało dowody	Migracja raz na kwartał
Wyrocznia	O „gotowe” decyduje test, sprawdzenie typów albo test kontraktowy	„Recenzentowi wygląda dobrze”
Klasa ryzyka	Niska lub średnia: testy, narzędzia wewnętrzne, łatki zależności	Uwierzytelnianie, płatności, migracje schematu na danych produkcyjnych
Zasięg awarii	Jeden serwis, odwracalny przez revert	Wspólne biblioteki importowane przez wszystkie zespoły
Ludzie	Co najmniej dwóch inżynierów robi tę pracę co tydzień	Jeden specjalista zajmuje się tym sam

Naprawa niestabilnych testów, aktualizacje zależności i poprawki padających testów zwykle spełniają wszystkie pięć kryteriów. Zapisz pętlę, jej obecny poziom i właściciela w pliku loops.yaml w repozytorium; mapa adopcji opisuje format rejestru.

Czym zajmuje się właściciel pętli?

Właściciel pętli zastępuje dawnego „championa”: odpowiada za dowody jednej pętli, a nie za ewangelizowanie narzędzia. Wybierz osobę, którą szanują koledzy i która dobrze tłumaczy, a nie najgłośniejszego wczesnego entuzjastę.

Przechodzi pętlę pierwszy i zapisuje problemy we wpisie pętli.
Pracuje w parze z każdym kolegą przy jego pierwszym zadaniu w pętli.
Dba o wspólny harness pętli: instrukcje, skille i listę zadań onboardingowych.
Raportuje zmierzone wyniki na spotkaniach zespołu: ukończenia, zaakceptowane zmiany i awarie, nigdy anegdoty.
Przekazuje tarcia tech leadowi, sklasyfikowane, żeby zespół naprawiał najpierw najczęstszą klasę.

Ogranicz czas wsparcia właściciela i zmieniaj osobę, gdy pętla osiąga kolejny poziom.

Jak nowa osoba dołącza do pętli?

Onboarding to dwa prawdziwe zadania z backlogu, a nie warsztat na zabawkowym projekcie. Kończy się, gdy inżynier liczy się do efektywnego użycia.

Dostęp i polityka. Zarządzane konto, zaakceptowana polityka użycia zespołu i działająca konfiguracja, która czyta wspólny harness. W Codex obejmuje to oznaczenie repozytorium jako zaufanego (akceptacja pytania przy pierwszym uruchomieniu codex w repozytorium). Nikt w pętli nie dostaje poświadczeń produkcyjnych przez agenta.
Przeczytaj pętlę, nie instrukcję narzędzia. Inżynier czyta wpis pętli w loops.yaml i jej kartę adopcji: które zadania się kwalifikują, co liczy się jako ukończenie i które ścieżki są wyłączone.
Pierwsze zadanie, w parze. Właściciel i inżynier biorą jedno kwalifikujące się zadanie z backlogu i wykonują je na obecnym poziomie pętli. Zadanie kończy się na granicy dowodów: zmergowany pull request z zielonymi wymaganymi checkami.
Drugie zadanie, samodzielnie. Inżynier wykonuje drugie kwalifikujące się zadanie sam. Właściciel przegląda pull request tak samo jak każdy inny w tej pętli, nie surowiej.
Policzony. Dopisz inżyniera do eligible.txt z datą zakończenia onboardingu. Wchodzi do mianownika efektywnego użycia tej pętli w każdym oknie, które zaczyna się tego dnia lub później, a do licznika w każdym takim oknie, w którym ma ukończenie. Liczenie od początku okna sprawia, że osoba dołączająca w trakcie nie zaniża wyniku okna, w którym nie mogła niczego ukończyć, a dwa PR z onboardingu nigdy nie liczą się jako ukończenia. Czas onboardingu deweloperów zamienia kroki 1–3 w mierzony scenariusz dla nowych pracowników.

To, czego uczy się nowa osoba, zależy od poziomu pętli, a nie od jej stażu:

Poziom pętli	Co robi nowa osoba	Co człowiek czyta przed merge’em	Co właściciel sprawdza przy pierwszym zadaniu
L2 W parze	Steruje agentem na żywo i odpowiada na prośby o uprawnienia	Nowa osoba czyta każdą edycję na bieżąco	Zadanie nie wyszło poza kwalifikujące się ścieżki
L3 Menedżer review	Uruchamia nienadzorowany przebieg w worktree lub sandboksie, potem przegląda diff	Recenzent czyta każdy diff	Przebieg korzystał ze wspólnego harnessu, a lokalne testy przeszły przed PR
L4 Menedżer specyfikacji	Pisze albo akceptuje specyfikację i kryteria akceptacji, potem czyta pakiet dowodów	Specyfikację i pakiet dowodów; kod tylko w klasach ryzyka wysokiego i krytycznego	Testy i pliki CI są nietknięte, a pakiet zgadza się z kryteriami akceptacji

Read loops.yaml and the open issues exported to issues.json. For the loop
"flaky-test-repair", list the eight open issues that best fit its eligible
tasks. Exclude anything touching auth, payments, schema migrations, secrets,
CI configuration or test fixtures shared by other services. For each issue
give: why it is eligible, the test or check that will decide "done", the
files it will probably touch, and an estimate of small, medium or large.
Order them from the easiest first task for a newcomer to the hardest. Edit
no files.

Najpierw wyeksportuj zgłoszenia poleceniem gh issue list --state open --limit 200 --json number,title,labels,body > issues.json i zmień nazwę pętli na swoją.

Kiedy pętla się rozszerza, a kiedy wspina?

Pętla zmienia się na dwa niezależne sposoby. Rozszerzanie dodaje ludzi na tym samym poziomie. Wspinanie się przesuwa pętlę na kolejny szczebel drabiny. W jednym oknie pomiarowym zmieniaj jedno albo drugie, nigdy oba naraz, bo inaczej nie ustalisz, która zmiana spowodowała awarię.

Zmiana	Idziemy dalej, gdy	Zatrzymujemy lub cofamy, gdy	Kto podpisuje
Rozszerzenie na kolejną grupę inżynierów	Efektywne użycie wśród obecnych uprawnionych jest stabilne przez jedno okno, a poprawki następcze i awarie zmian są na poziomie bazowym lub niżej	Czas do pierwszego review przekracza limit zespołu albo poprawki następcze rosną ponad poziom bazowy	Tech lead
Wspinanie się L2 → L3	Przebiegi kończą się bez nadzoru w izolowanych checkoutach, a recenzenci nadążają z każdym diffem	Recenzenci zaczynają zatwierdzać bez czytania; kolejka review rośnie z tygodnia na tydzień	Tech lead
Wspinanie się L3 → L4	Chronione testy, pakiet dowodów przy każdym PR i zaliczony audyt próbki	PR z próbki zmienił własne testy albo rośnie odsetek revertów w pętli	Tech lead razem z code ownerem odpowiednich ścieżek
Wspinanie się L4 → L5	Klasy niskiego ryzyka mergują się automatycznie według reguły, a ścieżka wycofania zadziałała w ćwiczeniu	Jakikolwiek incydent spowodowany przez pętlę w danym oknie	Tech lead i CTO, który odpowiada za politykę klas ryzyka

Mechanika każdego przejścia (worktree, chronione testy, bramki dowodowe, reguły auto-merge) jest opisana w mapie adopcji. Ludzką stronę przejścia z review diffów na review dowodów opisuje transfer zaufania.

Jak tempo zmienia się wraz z liczbą zespołów?

Układ	Ile pętli zmienia się naraz	Co je koordynuje
Jeden zespół	Jedna pętla rozszerza się albo wspina w danym momencie	Tech lead i jeden właściciel pętli
Kilka squadów na wspólnej bazie kodu	Jedna pętla na squad, każda z własnym właścicielem	Jeden wspólny rdzeń harnessu; wpisy pętli per squad w `loops.yaml`
Wiele zespołów	Pętle pilotażowe w dwóch–trzech zespołach w porównaniu z dopasowanymi zespołami, które pracują po staremu	Podpisana reguła decyzyjna z projektu pilotażu, potem mapa transformacji organizacji

Read loops.yaml. We are 18 engineers in three squads (payments, web,
platform) on TypeScript, Node and Postgres, and each squad has one loop
owner. Draft a rollout plan that moves one loop per squad per 30-day
window. For each window and squad give: the loop, whether it spreads (more
engineers, same level) or climbs (next level), never both; the eligible
engineers as a count; the go rule and the rollback rule; who signs; and
the top risk. Keep payments below L3 for every loop that touches money
movement. Then list three objections our senior engineers will raise and
the check that would answer each. Edit no files.

Zmień squady, stos technologiczny i liczby na swoje.

Jak mierzyć adopcję bez liczenia licencji?

Mierz efektywne użycie osobno dla każdej pętli, według definicji z mierzenia efektywnego użycia workflow:

efektywne użycie (pętla, okno) = uprawnieni inżynierowie z ≥ 1 ukończeniem na granicy dowodów
                                 ÷ uprawnieni inżynierowie z dostępem i ukończonym onboardingiem

Granica dowodów to zmergowany pull request z zielonymi wymaganymi checkami, którego w ciągu 14 dni nie cofnięto revertem ani nie poprawiano kolejną zmianą. Zestaw tę liczbę z metrykami ochronnymi z ram metryk: 14-dniowym odsetkiem poprawek następczych, wskaźnikiem awarii zmian i czasem do pierwszego review, każdą w porównaniu z poziomem bazowym sprzed wdrożenia dla tego samego typu zadań. Raport DORA 2025 (Google Cloud, 23 września 2025) wyjaśnia, dlaczego metryki ochronne są obowiązkowe: „we observe a positive relationship between AI adoption on both software delivery throughput and product performance”, a w następnym zdaniu: „AI adoption does continue to have a negative relationship with software delivery stability”. Raportuj dla każdej pętli i każdego zespołu, nigdy dla pojedynczych inżynierów.

Żeby liczenie było mechaniczne, oznaczaj każdy pull request etykietą pętli (loop:flaky-test-repair) i etykietą agent-assisted z szablonu PR. Okno to 30 dni kończące się 14 dni temu, więc każde ukończenie miało 14 dni na revert albo poprawkę. Wyeksportuj zmergowane pull requesty z ostatnich 44 dni w terminalu, w katalogu głównym repozytorium:

# GNU date (Linux); na macOS użyj: date -v-44d +%F
SINCE=$(date -d '44 days ago' +%F)
gh pr list --state merged --search "merged:>=$SINCE" --limit 1000 \
  --json number,title,author,labels,mergedAt,body,statusCheckRollup > merged-prs.json

Zapisz poniższy prompt jako prompts/effective-use.txt, wypisz uprawnionych inżynierów w eligible.txt (jeden wiersz login pętla onboarded-RRRR-MM-DD na inżyniera i pętlę, bo każda pętla ma własną listę uprawnionych) i uruchom go w trybie tylko do odczytu:

claude -p "$(cat prompts/effective-use.txt)" --tools "Read" --strict-mcp-config > effective-use.md

--tools "Read" usuwa wszystkie inne wbudowane narzędzia, a --strict-mcp-config pomija serwery MCP projektu, więc sam agent nie ma narzędzia, które edytuje pliki lub uruchamia polecenia. Hooki z plików ustawień nadal się wykonują, więc jeśli projekt definiuje hooki, dodaj --setting-sources user (albo uruchom to na czystym klonie). --setting-sources user nadal wczytuje hooki użytkownika i wtyczek; --safe-mode wyłącza też hooki, wtyczki i serwery MCP (Claude Code 2.1.283).

codex exec -c default_permissions=":read-only" -o effective-use.md "$(cat prompts/effective-use.txt)"

Profil uprawnień :read-only jest w Codex CLI 0.157.1 w wersji beta. Nie łącz go z --sandbox; profile i starszy system sandboksów się nie składają.

Dołącz merged-prs.json i eligible.txt do agenta, wklej prompt, odrzuć każde proponowane polecenie lub edycję i zapisz odpowiedź jako effective-use.md.

Read merged-prs.json (pull requests merged in the last 44 days) and
eligible.txt (one "login loop onboarded-YYYY-MM-DD" line per engineer and
loop, loop without the "loop:" prefix). Use only labels, authors, titles,
bodies, mergedAt and statusCheckRollup in the JSON. Count a PR only if
every check in its statusCheckRollup concluded SUCCESS, NEUTRAL or SKIPPED;
if the rollup is empty, count the PR as "unknown". The window is the 30 days ending 14 days
before today: count only PRs whose mergedAt is at least 14 days before
today. Count an engineer as eligible for a loop only if their onboarded
date is on or before the window start.

For each loop label (labels starting with "loop:"):
1. Completions: window PRs labelled "agent-assisted" whose author is
   eligible for that loop, excluding any PR that a PR merged within the
   next 14 days reverts (title starts with "Revert" and references it) or
   fixes ("fixes #N", "follow-up to #N").
2. Effective use: engineers eligible for that loop with at least one
   completion, divided by the engineers eligible for that loop. Show
   numerator and denominator.
3. Reverts and follow-up fixes: the PRs excluded in step 1, as a count and
   as a share of the loop's agent-assisted window PRs.
4. Engineers eligible for the loop with no completion: a count only, never
   names.

Output one table per loop, then a list of PRs you could not assign to a loop
and why. Write "unknown" for anything the JSON cannot show. Never estimate.
Edit no files.

Żeby sprawdzić wynik, wylosuj trzy ukończenia i trzy wykluczone PR i potwierdź każdy w GitHubie lub innej platformie hostingu kodu. Jeśli choć jeden z sześciu się nie zgadza, popraw etykiety albo prompt, zanim zaraportujesz liczbę.

Ustandaryzuj review, zanim pętla się rozszerzy

Zanim pętla wyjdzie poza pierwszych inżynierów, uzgodnijcie, co sprawdza recenzent, i niech pull request to niesie. Na L3 recenzent wciąż czyta każdy diff; na L4 czyta specyfikację i pakiet dowodów, a kod tylko w klasach ryzyka wysokiego i krytycznego. Najpierw niech zadziała agent review według tego samego standardu: /code-review w Claude Code, /review albo codex review w Codex, albo agent Cursora z dołączonym standardem. Review PR przez agenta opisuje, jak wpiąć go w CI. Merge nadal należy do człowieka.

Read CLAUDE.md or AGENTS.md, loops.yaml, and the 20 most recent merged pull
requests labelled "loop:flaky-test-repair" (exported to loop-prs.json).
Write a review standard for this loop with at most 10 checks a reviewer can
finish in five minutes. Cover the failure modes specific to agent output:
imports or APIs that do not exist, tests that assert the implementation
instead of the requirement, changes to tests or CI configuration, silent
edits to files outside the task, unvalidated input and secrets in code.
For each check, say whether CI could enforce it instead of a person, and
how. Then write a PR-template section that asks the author for the loop
label, the acceptance result and whether an agent wrote the change.
Edit no files.

Każde sprawdzenie, które prompt oznaczy jako wymuszalne, trafia do CI, zanim pętla się rozszerzy. Sprawdzenie, o którym człowiek musi pamiętać, jako pierwsze przestaje być wykonywane.

Co odpowiedzieć, gdy ludzie się sprzeciwiają?

Traktuj każdy zarzut jako lukę w dowodach pętli i zamykaj ją sprawdzeniem, a nie argumentem.

Zarzut	Luka w dowodach	Co zrobić
„Bez tego jestem szybszy”.	Brak zmierzonego porównania na zadaniach tej osoby	Przeprowadź dopasowany pilotaż na jej własnych zadaniach; sceptycy i seniorzy zawiera dziennik pilotażu i uczciwą lekturę wyników METR
„Kod od agenta jest zły”.	Pętla nie ma wyroczni, której agent nie może edytować	Oddaj seniorowi odpowiedzialność za sprawdzenia pętli; pętla wspina się dopiero, gdy te sprawdzenia trzymają
„On nie rozumie naszej bazy kodu”.	Agent inżyniera nie czyta wspólnego harnessu	Poproś agenta o zacytowanie pierwszej reguły z `CLAUDE.md` albo `AGENTS.md`; jeśli nie potrafi, plik się nie wczytuje. W Codex sprawdź też, czy repozytorium jest zaufane: jego ścieżka ma `trust_level = "trusted"` w `~/.codex/config.toml`
„Obecny sposób pracy działa”.	Nikt nie widział obu sposobów pracy na tym samym zadaniu	Przez jedno okno prowadź stary sposób obok pętli i porównaj oba na metrykach ochronnych
„To mnie zastąpi”.	Brak wypowiedzianej wizji roli	Powiedz, czym staje się praca zespołu: specyfikowaniem i weryfikowaniem zachowania; zobacz warsztat i karierę

Nie narzucaj narzędzia pierwszego dnia. Wymuszona adopcja produkuje sesje, które istnieją po to, żeby zadowolić dashboard, i zaśmieca mianownik efektywnego użycia.

Kiedy adopcja w zespole utyka

Adopcja staje po pierwszych inżynierach. Zwykle brakuje harnessu albo właściciela w każdym squadzie, więc każda nowa osoba zaczyna od zera. Sprawdź kryterium wyjścia harnessu na świeżym klonie i wyznacz jednego właściciela na pętlę.
Konwencje rozjeżdżają się między narzędziami. CLAUDE.md, AGENTS.md i Rules w Cursorze mówią co innego, więc wynik zależy od tego, kto prowadzi. Uruchom prompt synchronizacji, zrób z jednego pliku źródło prawdy i dodaj check w CI, który pada, gdy pliki-wskaźniki zmieniają się bez niego.
Jeden zły PR od agenta podkopuje zaufanie do pętli. Cofnij go revertem, dodaj do CI sprawdzenie, które by go złapało, i wstrzymaj rozszerzanie na jedno okno. Nie wstrzymuj całego zespołu: dowody pozostałych pętli nadal są ważne.
Właściciel pętli zamienia się w helpdesk. Odpowiedzi żyją na czacie, więc pytania się powtarzają. Przenieś każdą powtarzającą się odpowiedź do pliku instrukcji albo wspólnego skilla i zmień właściciela.
Kolejka review rośnie. Rozszerzanie dodało autorów szybciej niż recenzentów. Ustaw zespołowy limit otwartych pull requestów od agentów według limitów kolejki review i wstrzymaj rozszerzanie, aż czas do pierwszego review wróci do poziomu bazowego.
Liczby, których nikt nie zmierzył. „Wydaje się szybciej” albo liczba przyspieszenia, której nikt nie umie prześledzić, upada przy pierwszym „jak to zmierzono?”. Odtwórz 12-tygodniowy poziom bazowy z platformy hostingu kodu i raportuj efektywne użycie z metrykami ochronnymi albo nie raportuj nic.
Rozszerzanie i wspinanie w tym samym oknie. Awarie rosną i nikt nie wie dlaczego. Cofnij wspinanie, zostaw rozszerzenie i od tej pory zmieniaj jedną rzecz na okno.
Materiały szkoleniowe się starzeją. Ucz bramek i dowodów pętli, które zmieniają się wolno, i wyznacz osobę, która śledzi zmiany w narzędziach (nadążanie za zmianami).

Dokąd dalej z adopcją w zespole

Zacznij od hubu wdrożenia zespołowego, jeśli repozytorium nie jest jeszcze przygotowane. Następnym krokiem, gdy pierwsza pętla się rozszerzy, jest mapa adopcji repozytorium.

Mapa adopcji dla jednego repozytorium Przesuwaj pętle repozytorium po drabinie, z dowodami bramki i regułą wycofania dla każdego przejścia.

Mierzenie efektywnego użycia workflow Karta adopcji, czterowarstwowy lejek i dowody do scorecardu stojące za efektywnym użyciem.

Jak pomóc zespołowi przestać czytać każdy diff Review w cieniu, review próbek i review samych dowodów, pętla po pętli.

Podnoszenie kompetencji zespołu w inżynierii agentowej Program dla każdego przejścia po drabinie, zbudowany z kata na twoim własnym repozytorium.