Wdrożenie agentów kodujących w zespole

Wdrożenie agentów w zespole udaje się, gdy każdy inżynier pracuje na wspólnym harnessie, jednym mierzonym workflow i jednej mapie adopcji repozytorium — a nie wtedy, gdy każdy dostał licencję. Strony tej sekcji idą w tej kolejności: konwersja repozytorium, wybór jednego workflow, onboarding ludzi na ten workflow, przesuwanie pętli w górę mapy adopcji i przeniesienie review z diffów na dowody.

Ten hub jest dla tech leada, który odpowiada za wdrożenie, i dla CTO, który pyta, czy ono działa. Załóżmy, że kupiłeś osiem licencji: trzy osoby używają agentów codziennie, każda z prywatną konfiguracją, dwie zrezygnowały, a kolejka code review urosła. Jeśli dopiero zaczynasz prowadzić wdrożenie agentów, zacznij od ścieżki tech leada.

Której strony o wdrożeniu potrzebujesz?

Twoja sytuacja	Zacznij od
Agent zgaduje komendy budowania, testów i stylu	Playbook konwersji projektu
Inżynierowie mają dostęp, ale mało kto kończy z agentem prawdziwe zadanie	Onboarding i adopcja w zespole
Potrzebujesz planu: co agent może robić w tym repozytorium i od kiedy	Mapa adopcji dla jednego repozytorium
Proces dostarczania zespołu wciąż zakłada, że człowiek pisze każdą linię	Przewodnik transformacji przepływu pracy
Kierownictwo pyta „czy to działa?”, a ty masz tylko liczbę licencji	Mierz skuteczne użycie workflow
Nowe osoby potrzebują dni, żeby wykonać pierwsze bezpieczne zadanie z agentem	Udowodnij jeden bezpieczny workflow onboardingu

W jakiej kolejności przebiega wdrożenie w zespole?

Każdy krok ma warunek wyjścia, od którego zależą kolejne kroki.

1. Przekonwertuj jedno repozytorium. Dodaj do repozytorium plik instrukcji, dokładne komendy budowania i testów oraz wspólne ustawienia. Warunek wyjścia: świeży klon przechodzi typecheck, lint i testy komendami, których używa agent. Zobacz playbook konwersji projektu i jak przygotować repozytorium do pracy agentów.

2. Wybierz jeden workflow i napisz jego kartę adopcji. Wybierz typ zadania, który zespół powtarza co tydzień, na przykład naprawę padających testów. Karta ustala, kto się kwalifikuje, co liczy się jako ukończenie i które wskaźniki ostrzegawcze obserwujesz. Warunek wyjścia: karta jest opublikowana, zanim zacznie się okres porównawczy (skuteczne użycie workflow).

3. Wdróż ludzi w ten workflow. Połącz każdego inżyniera z wewnętrznym ambasadorem (championem) przy jednym prawdziwym zadaniu, które kończy się zmergowanym pull requestem. Warunek wyjścia: każdy inżynier przechodzi próbę onboardingu w ciągu jednego dnia roboczego, a potem merguje jedno prawdziwe zadanie na granicy dowodowej workflow.

4. Przesuwaj pętle w górę mapy adopcji — po jednej. Awansuj pętle na drabinie autonomii tylko z regułą wycofania dla każdego kroku. Warunek wyjścia: dowody z bramki tej pętli widać w Gicie i w CI (mapa adopcji).

5. Przenieś review z diffów na dowody. Gdy bramki pętli się trzymają, sprawdzaj pakiet dowodów zamiast diffu. Warunek wyjścia: spełnione są kryteria wejścia do etapu opisane w transferze zaufania.

Jak wygląda wspólny harness w każdym narzędziu?

Między narzędziami różnią się tylko pliki w repozytorium. Pełna konfiguracja: współpraca w zespole: wspólny kontekst i reguły.

Claude Code

Dodaj do repozytorium CLAUDE.md oraz .claude/settings.json ze wspólnymi uprawnieniami. Claude Code czyta AGENTS.md, gdy projekt nie ma CLAUDE.md, od wersji v2.1.277, na obu kanałach wydań (v2.1.281 na Bedrock, Google Cloud, Microsoft Foundry i bramkach LLM; sprawdzone 2026-10-12). Jeśli repozytorium ma tylko AGENTS.md (dla Codeksa), dodaj do niego także CLAUDE.md, dopóki część zespołu może mieć wersję starszą niż v2.1.277, bo takie wersje nie czytają AGENTS.md. Gdy CLAUDE.md już istnieje, Claude Code przestaje sięgać po AGENTS.md, więc niech dodany CLAUDE.md zawiera jedną linię @AGENTS.md: importuje ona wspólny plik i zespół nadal utrzymuje jeden zestaw konwencji. W CI uruchamiasz te same sprawdzenia bez interfejsu przez claude -p --output-format json.

Codex

Dodaj do repozytorium AGENTS.md; Codex czyta go przed rozpoczęciem pracy. Od Codex CLI 0.150.0 niezaufany projekt nie dostarcza swojego AGENTS.md, więc każdy inżynier raz oznacza repozytorium jako zaufane. W CI codex exec --json zwraca zdarzenia w formacie do przetwarzania maszynowego.

Cursor

Dodaj do repozytorium reguły projektu (Rules), żeby agent każdego inżyniera je wczytywał. Trzymaj jeden rdzeń konwencji i generuj z niego pliki dla poszczególnych narzędzi, tak jak opisują to wspólne reguły agentów. W CI uruchamiasz Cursor CLI w trybie print (-p); Cursor opisuje konfigurację dla GitHub Actions.

Prompt do skopiowania: gotowość repozytorium do wdrożenia

Audit this repository for a team rollout of coding agents. Do not change any files.
Report, as a table with columns item / status (pass, fail, missing) / evidence (file path or command output):
1. Is there a committed instructions file (CLAUDE.md, AGENTS.md, or project rules)? Does it list the exact install, build, typecheck, lint, and test commands?
2. Run each of those commands. Which pass on the default branch?
3. Are there committed shared agent settings (permissions, hooks, MCP servers)? Do any of them contain secrets?
4. Is the default branch protected with required status checks?
5. Which recurring change types appear most often in the last 50 merged pull requests? Name the one best suited as a first agent workflow and explain why.
End with the three fixes that would unblock a rollout, in priority order.

Prompt do skopiowania: szkic karty adopcji dla pierwszego workflow

Using the last 12 weeks of merged pull requests in this repository (list them with `gh pr list --state merged --search "merged:>=YYYY-MM-DD" --limit 1000 --json number,title,labels,mergedAt`, replacing YYYY-MM-DD with the date 12 weeks ago, then read the changed files only for the pull requests you use as evidence with `gh pr view <number> --json files`), draft an adoption card for the workflow "repair a failing test with an agent".
Fill in: workflow owner (leave as TBD), decision owner (leave as TBD), approved tools, eligible people, eligible tasks, excluded tasks (name risky directories you find), evidence boundary (merged PR, required checks green, not reverted or fixed within 14 days), what does not count as completion, guardrail metrics, and the baseline numbers for this task type from the data.
Show the command output you used for each baseline number. Mark any number you could not compute as UNKNOWN instead of estimating it.

Skąd wiesz, że wdrożenie działa, bez czytania każdego diffu?

Mierz workflow, nie licencje. Skuteczna adopcja to odsetek uprawnionych inżynierów, którzy w danym okresie ukończyli workflow na jego granicy dowodowej: zmergowany pull request z zielonymi wymaganymi sprawdzeniami, który w ciągu 14 dni nie został wycofany ani poprawiony.

Zestaw to ze wskaźnikami ostrzegawczymi: odsetkiem poprawek następczych w ciągu 14 dni (14-day follow-up fix rate), odsetkiem nieudanych zmian (change failure rate) i obciążeniem review w porównaniu z bazą sprzed wdrożenia. Kanoniczne definicje są na stronie o frameworkach metryk. Tech lead zatwierdza awans każdej pętli na mapie, a właściciel decyzji wskazany w karcie adopcji zatwierdza całe wdrożenie.

Co blokuje wdrożenie w zespole?

• Licencje bez workflow. Użycie rośnie, a nic poza nim się nie zmienia. Naprawa: zawęź wdrożenie do jednego workflow z opublikowaną kartą adopcji.
• Każdy ma własną konfigurację. Wyniki zależą od osoby. Naprawa: dodaj do repozytorium jeden plik instrukcji i wspólne ustawienia, a potem usuń prywatne kopie.
• Review staje się wąskim gardłem. Agenci otwierają więcej pull requestów, niż ludzie są w stanie przeczytać. Naprawa: limity z kolejki code review; nie podnoś autonomii, dopóki nie ma bramek dowodowych.
• Seniorzy trzymają się z boku. Naprawa: zamiast szkolenia powierz im projektowanie bramek (sceptycy i seniorzy).
• Pilotaż, który niczego nie dowodzi. Bez bazy porównawczej i reguły decyzji wyniki są anegdotami. Zanim zaczniesz skalować, skorzystaj z projektu pilotażu.

Dokąd dalej z wdrożeniem w zespole

Zmiana narzędzia to osobna decyzja: zobacz porównanie narzędzi i przewodniki o przejściu z GitHub Copilota, Devin Desktop (dawniej Windsurf), Codeksa, Cursora lub Claude Code oraz z tradycyjnego IDE.

Mapa adopcji dla jednego repozytorium Następny krok: przesuwaj pętle jednego repozytorium w górę drabiny na podstawie dowodów z bramek.

Zespół: prowadzenie zespołu, który dowozi z agentami Hub nadrzędny: wdrożenie, wspólny harness, review i przepływ pracy oraz ludzie.

Mapa drogi dla organizacji Dla CTO: jak przeskalować to wdrożenie z jednego zespołu na całą organizację.