Adopcja w zespole — mierz skuteczne użycie workflow

Adopcja w zespole, tak jak ocenia ją pytanie Q1 CTO Scorecard, to odsetek uprawnionych inżynierów, którzy doprowadzają zatwierdzony workflow AI do jego granicy dowodowej, zestawiony z miarami zaakceptowanego wyniku, jakości i kontroli. Kupione licencje, logowania i liczba promptów mierzą aktywność, nie adopcję. Maksymalny wynik wymaga dowodów ukończenia, zaakceptowanego wyniku, jakości i kontroli, zmierzonych względem baseline’u.

Ta strona jest dla tech leada, który prowadzi przegląd adopcji, i dla CTO, który odpowiada na Q1. Sytuacja: dział finansów pyta, dlaczego 120 licencji kosztuje tyle, ile kosztuje, dashboard administratora pokazuje, że 87% inżynierów otworzyło narzędzie w zeszłym tygodniu, a nikt nie potrafi powiedzieć, czy dzięki temu choć jeden workflow stał się szybszy albo bezpieczniejszy. Samo „87% aktywnych” nie daje ani jednego punktu.

Co dostajesz z tej strony o adopcji

• Tabelę punktacji Q1 z dowodami, których wymaga każda odpowiedź.
• Szablon karty adopcji, który definiuje uprawnienia, ukończenie i guardraile dla jednego workflow — gotowy do wypełnienia.
• Czterowarstwowy lejek adopcji ze wzorem i źródłem danych dla każdej warstwy.
• Informację, skąd pochodzą dane każdej warstwy w Claude Code, Codex i Cursorze.
• Taksonomię tarcia, która zamienia nieudane przebiegi w najmniejszą możliwą poprawkę.
• Trzy prompty do skopiowania, regułę decyzyjną i tryby awarii, które zamieniają adopcję w teatr.

Jak CTO Scorecard Q1 punktuje adopcję w zespole?

Scorecard pyta: „Jak szeroko i skutecznie zespół inżynierski używa zatwierdzonych workflow AI?” i punktuje cztery odpowiedzi.

Punkty	Odpowiedź	Dowód, który ją uzasadnia
0	Nie wiem	Brak.
1	Niemierzone eksperymenty kilku early adopters	Anegdoty, kanał na Slacku, indywidualne rozliczenia wydatków.
2	Mierzone użycie zatwierdzonych workflow, ale jeszcze bez dowodu zaakceptowanych wyników	Dashboard sesji albo aktywnych użytkowników dla każdego zatwierdzonego workflow.
3	Szerokie użycie przez uprawniony zespół z dowodami ukończenia workflow, zaakceptowanego wyniku, jakości i kontroli	Karta adopcji dla każdego workflow, wskaźnik ukończenia względem stałego mianownika, accepted change rate i follow-up fix rate względem baseline’u oraz przejrzane zdarzenia kontrolne.

Kluczowy jest przeskok z poziomu 2 na 3. Poziom 2 liczy tych, którzy zaczęli; poziom 3 pokazuje, że ukończona praca została zaakceptowana i nie kosztowała jakości ani kontroli.

Dlaczego liczba licencji i odsetek użycia wprowadzają w błąd?

Samo użycie nie odróżnia już zespołów od siebie. Raport DORA 2025 podaje, że „90% of survey respondents report using AI at work” (Google Cloud, 2025-09-23). Wysoki odsetek aktywnych użytkowników to norma w branży, a nie osiągnięcie.

Główny wniosek tego samego raportu tłumaczy, dlaczego użycie niewiele mówi o wartości: „AI doesn’t fix a team; it amplifies what’s already there”. Zespół ze słabymi testami i wolnym review, który masowo wdroży agentów, dostaje więcej nieprzejrzanych zmian, a nie więcej dostarczonej pracy. Adopcja nabiera znaczenia dopiero wtedy, gdy łączysz ją z wynikiem, dla którego workflow istnieje.

Metryka użycia nie ma też filtra uprawnień. Inżynier utrzymujący krytyczny dla bezpieczeństwa moduł firmware’u, który unika workflow agentowego niezatwierdzonego przez politykę dla tego kodu, zachowuje się poprawnie. Liczenie go jako „nieadoptującego” popycha ludzi w stronę niebezpiecznego użycia.

Zdefiniuj adopcję dla jednego workflow, zanim zaczniesz liczyć

Adopcję mierzysz dla konkretnego workflow, nigdy dla „AI” ogólnie. Dla każdego zatwierdzonego workflow napisz jedną kartę adopcji i opublikuj ją przed początkiem okresu porównawczego. Karta ustala mianownik, więc liczba nie może się rozjechać.

Zatwierdzone narzędzia i workflow pochodzą z twojej polityki narzędzi; zobacz Q2 · Polityka narzędzi.

ADOPTION CARD — repair a failing test with an agent
Workflow owner:      Tech lead, payments team
Approved tools:      Claude Code, Codex, Cursor (per tooling policy v3)
Eligible people:     Engineers on payments and ledger repositories with a managed
                     account and the 90-minute workflow onboarding completed
Eligible tasks:      Failing unit or integration tests in services at risk tier 1–2
Excluded tasks:      Tier-3 services (card data path), flaky-test quarantine decisions
Evidence boundary:   PR merged with the previously failing test green in CI, the
                     change reviewed against the evidence bundle, not reverted or
                     fixed within 14 days
Not completion:      Opening the tool; a session with no PR; a PR closed unmerged
Guardrails:          14-day follow-up fix rate, change fail rate, time to first
                     review, denied tool calls and secret-scanner hits
Baseline:            Same task type, same teams, previous 12 weeks
Review cadence:      Monthly with the team; quarterly in the CTO panel
Decision owner:      VP Engineering

Kartę zostawiamy po angielsku, bo zwykle trafia do tego samego repozytorium co polityka narzędzi. Następnie policz skuteczną adopcję względem tej karty:

skuteczna adopcja = uprawnieni inżynierowie z ≥ 1 ukończeniem na granicy dowodowej w okresie
                    ÷ uprawnieni inżynierowie z dostępem i ukończonym onboardingiem

Granica dowodowa to moment, w którym wynik workflow akceptuje system, a nie osoba, która go uruchomiła: zmergowany PR z zielonymi checkami, zaakceptowany plan, zamknięty rekord incydentu. Wybierz granicę, którą twoje narzędzia już rejestrują, żeby ukończenia liczyć z hostingu kodu i CI, a nie z deklaracji.

Mierz cztery warstwy lejka adopcji

Każda warstwa odpowiada na inne pytanie i każda ma awarię, którą wyłapuje następna.

Warstwa	Pytanie	Metryka	Źródło danych
Dostęp	Czy uprawnione osoby mogą bezpiecznie zacząć?	Uprawnieni inżynierowie z zarządzanym kontem, zaakceptowaną polityką i działającym środowiskiem ÷ uprawnieni inżynierowie	Dostawca tożsamości, konsola administratora
Aktywacja i ukończenie	Czy kończą workflow?	Skuteczna adopcja (wzór powyżej); ukończenia ÷ rozpoczęte sesje tego workflow	Telemetria agenta, etykiety PR, CI
Wynik	Czy ukończona praca jest akceptowana?	Accepted change rate dla PR-ów tego workflow względem kohorty baseline’owej	Hosting kodu, powiązania revertów i poprawek
Guardrail	Czy szkoda jest pod kontrolą?	14-dniowy follow-up fix rate, change fail rate, obciążenie review, zdarzenia kontrolne (odrzucone akcje, zablokowane commity, trafienia skanerów)	Hosting kodu, log wdrożeń, logi hooków i skanerów

Używaj kanonicznych definicji accepted change rate, follow-up fix rate i obciążenia review ze strony o frameworkach metryk inżynierii AI, żeby przegląd adopcji i panel CTO raportowały te same liczby. Każdą warstwę raportuj per zespół albo per repozytorium, nigdy per inżynier.

Skąd pochodzą dane o adopcji w każdym narzędziu

Warstwy wyniku i guardraili pochodzą z hostingu kodu, CI i logu wdrożeń, niezależnie od tego, które narzędzie napisało kod. Od narzędzia zależą tylko aktywacja i znacznik pracy z agentem.

Claude Code

Aktywacja. Claude Code eksportuje metryki OpenTelemetry po ustawieniu CLAUDE_CODE_ENABLE_TELEMETRY=1, w tym claude_code.session.count, claude_code.pull_request.count i claude_code.commit.count. Ustaw zmienne dla wszystkich przez managed settings; pełny blok jest na stronie o telemetrii agentów.

Znacznik. W planach Team i Enterprise, z zainstalowaną aplikacją Claude na GitHubie i włączoną analityką GitHub, zmergowane PR-y z przypisanymi liniami Claude Code dostają etykietę claude-code-assisted. Wyszukiwanie na GitHubie is:pr is:merged label:claude-code-assisted je wylistuje. Contribution metrics są w publicznej becie i nie działają przy Zero Data Retention; tam użyj checkboxa w szablonie PR.

Dashboard analityczny zawiera ranking poszczególnych użytkowników. Trzymaj go z dala od przeglądu adopcji: ranking ocenia ludzi, a Q1 dotyczy workflow.

Codex

Aktywacja. Codex eksportuje logi, trace’y i metryki przez tabelę [otel] w ~/.codex/config.toml. Zostaw log_user_prompt = false, chyba że przegląd prywatności zatwierdził przechowywanie promptów. Zgłoszenie #12913 w openai/codex (obecnie zamknięte) opisywało, że codex exec eksportuje trace’y i logi, ale nie metryki. Zanim policzysz przebiegi z CI, sprawdź na swojej wersji Codeksa, czy docierają do kolektora.

Znacznik. Codex CLI 0.157.1 nie dodaje własnej etykiety PR (sprawdzone 2026-09-26). Użyj checkboxa w szablonie PR i etykiety agent-assisted, tak jak opisuje to strona o oznaczaniu PR-ów AI, a zadanie CI uruchamiające codex exec niech wypycha zmiany na gałęzie nazwane według reguły, którą da się odpytać (np. agent/codex/<ticket>).

Cursor

Aktywacja. Cursor udostępnia adminom dashboard analityczny zespołu i Analytics API; zanim zbudujesz na nich raport, sprawdź aktualne limity planów i endpointy w dokumentacji administracyjnej Cursora.

Znacznik. Użyj checkboxa w szablonie PR i etykiety agent-assisted. Działa w każdym planie i z każdym narzędziem, więc to jedyny znacznik, który możesz porównywać między zespołami.

Prowadź przegląd adopcji po jednym workflow

1. Wybierz workflow, który ma już granicę dowodową. Na początek dobrze sprawdzają się: naprawa padającego testu, planowanie ograniczonej funkcji względem specyfikacji albo review PR względem kryteriów akceptacji. Pomiń workflow, których wyniku nikt nie rejestruje.

2. Napisz i opublikuj kartę adopcji. Uzgodnij uprawnienia i wyłączenia z osobami, które wykonują tę pracę. Zamroź kartę na okres porównawczy; zmiana restartuje okres.

3. Odtwórz baseline. Pobierz z hostingu kodu ostatnie 12 tygodni tego samego typu zadań: liczbę, accepted change rate, follow-up fix rate i czas review. Prompt do baseline’u ze strony o frameworkach metryk napisze skrypt ekstrakcji.

4. Zrób pilotaż z dopasowaną kohortą. Uruchom workflow w dwóch lub trzech zespołach, a porównywalne zespoły niech pracują jak dotąd. Zapisz zespół, poziom ryzyka usługi, wielkość próby i czynniki zakłócające, takie jak reorganizacja czy zamrożenie wydań. Dobór kohort i wielkość próby opisuje strona o projektowaniu pilotażu AI.

5. Sklasyfikuj każdy nieudany albo porzucony przebieg. Użyj tabeli tarcia poniżej i porozmawiaj z pięcioma–ośmioma inżynierami. Zagregowana telemetria pokazuje, gdzie przebiegi się zatrzymują; rozmowy pokazują dlaczego.

6. Napraw najczęstszą klasę tarcia i zmierz ponownie. Zmieniaj jedną rzecz na cykl, żeby efekt dało się przypisać.

7. Zdecyduj według reguły spisanej wcześniej. Rozszerz, zawęź, przeszkol albo zatrzymaj, a decyzję, jej właściciela i datę następnego przeglądu zapisz na karcie adopcji.

Dlaczego inżynierowie zaczynają workflow i go nie kończą?

Większość problemów z adopcją to tarcie, a nie niechęć. Sklasyfikuj każdy nieudany przebieg raz, a potem napraw klasę z największą liczbą przebiegów.

Klasa tarcia	Sygnał	Najmniejsza poprawka do przetestowania
Dostęp	Zgłoszenia dotyczące konfiguracji środowiska, sesje kończące się na uwierzytelnianiu, brak uprawnień do repozytorium	Pakiet managed config i wcześniej założone konto dla każdego uprawnionego inżyniera
Kontekst	Agent edytuje zły moduł albo ignoruje konwencje	Przetestowany AGENTS.md lub CLAUDE.md dla repozytorium; zobacz wspólne reguły agentów
Umiejętności	Przebiegi zatrzymują się w tym samym kroku u osób nowych w workflow	30-minutowy przykład na własnym repozytorium zespołu; zobacz onboarding deweloperów
Weryfikacja	PR-y się otwierają, ale stoją, bo nikt nie ufa wynikowi	Wymagany pakiet dowodów (evidence bundle) i padający test, który dowodzi poprawki
Niezawodność narzędzia	Timeouty, limity, zepsute serwery MCP	Przypięte wersje, poprawione limity lub kwoty, incydenty rejestrowane przy narzędziu
Kolejka review	Wysokie ukończenie, ale czas do pierwszego review się podwaja	Limit przepustowości review na zespół; zobacz stronę o kolejce review
Nieodpowiednie zadanie	Zadanie jest poza zakresem uprawnionych zadań z karty	Zawęź uprawnione zadania na karcie; to nie jest porażka człowieka

Prompty do przeglądu adopcji

Uruchom je w Claude Code, Codeksie albo Cursorze, mając kartę adopcji i wyeksportowane dane w katalogu roboczym. Dają wersje robocze; podpisuje je właściciel decyzji. Prompty zostają po angielsku, tak jak pliki, na których pracują.

Prompt do skopiowania: szkic karty adopcji

Read our tooling policy (docs/policy/ai-tooling.md) and the list of approved AI workflows in it. For the workflow "repair a failing test with an agent", draft an adoption card with these fields: workflow owner, approved tools, eligible people, eligible tasks, excluded tasks with the reason for each, evidence boundary, what does NOT count as completion, guardrail metrics, baseline window, review cadence and decision owner.

Rules:
- The evidence boundary must be recorded by the code host or CI, not self-reported.
- Do not use logins, sessions, prompt count, seat count or lines of code as completion.
- Exclude any task class the policy marks as restricted, and quote the policy line.
- List every assumption you made as an open question for the workflow owner.

Prompt do skopiowania: klasyfikacja nieudanych i porzuconych przebiegów

The file adoption/runs-2026-09.csv lists runs of the "repair a failing test" workflow with: run id, team, repository, started_at, PR number (may be empty), PR state, CI result, reverted_within_14d, and free-text notes from the engineer.

For every run that did not reach the evidence boundary (merged, CI green, not reverted within 14 days), assign exactly one friction class: access, context, capability, verification, tool reliability, review queue, or unsuitable task. Quote the note or field that justifies the class; mark "unclear" rather than guessing.

Output a table of counts per class and per team, then recommend the single smallest intervention for the largest class and a measurable test of whether it worked by the next monthly review. Do not name or rank individual engineers.

Prompt do skopiowania: rekomendacja „rozszerzyć czy zatrzymać”

Compare the pilot cohort with the baseline cohort for the "repair a failing test" workflow using adoption/pilot.csv and adoption/baseline.csv. Report, per team: eligible engineers, effective adoption, completions, accepted change rate, 14-day follow-up fix rate, median time to first review, and control events (denied tool calls, blocked commits, scanner hits).

State the sample size and every confounder listed in adoption/confounders.md next to the numbers. Then apply this decision rule exactly and say which branch applies: expand if effective adoption is at least 60% and accepted change rate is not below baseline and follow-up fix rate is no more than 2 percentage points above baseline; narrow if effective adoption is at least 60% but accepted change rate is below baseline, follow-up fix rate is more than 2 percentage points above baseline, or any control event was unresolved; retrain if adoption is below 60% and the largest friction class is capability; otherwise stop. Do not recommend anything the rule does not support.

Progi w ostatnim prompcie są przykładowe. Ustal własne przed startem pilotażu i zapisz je na karcie adopcji.

Jak zweryfikować dowody adopcji bez czytania każdego przebiegu?

Nikt nie czyta każdego transkryptu sesji ani każdego PR. Dowody są wiarygodne dzięki temu, jak się je zbiera i próbkuje.

• Ukończenie pochodzi z systemów, nie od ludzi. Granica dowodowa to zmergowany PR, zielony przebieg CI albo zamknięty rekord incydentu. Zadeklarowane ukończenie nigdy nie trafia do licznika.
• Mianownik jest zamrożony. Karta adopcji ustala uprawnienia na cały okres porównawczy, a raport pokazuje mianownik obok każdego wskaźnika.
• Próbka jest sprawdzana ręcznie. Co miesiąc właściciel workflow otwiera dziesięć losowych ukończeń i potwierdza, że każde osiągnęło granicę dowodową. Więcej niż jedna niezgodność unieważnia liczbę z danego miesiąca, dopóki zapytanie nie zostanie poprawione.
• Guardraile czytasz obok adopcji. Raport pokazuje follow-up fix rate i zdarzenia kontrolne na tym samym widoku co skuteczną adopcję, więc wzrost jednego nie ukryje spadku drugiego.
• Nazwany właściciel podpisuje decyzję. Właściciel decyzji z karty zapisuje decyzję i datę następnego przeglądu. Dowodem do Q1 jest ten podpisany zapis plus dwa ostatnie raporty miesięczne.
• Telemetria przechodzi przegląd prywatności. Prompty i kod nie są przechowywane, chyba że przegląd to zatwierdził; zobacz prywatność i przetwarzanie danych przez agentów.

Co się psuje, gdy mierzysz adopcję w zespole?

Teatr adopcji. Kierownictwo kupuje licencje dla wszystkich i wprowadza cotygodniowy obowiązek użycia. Aktywność rośnie, a liczba zaakceptowanych zmian nie. Wyjście: wycofaj cel użycia, opublikuj karty adopcji dla dwóch lub trzech workflow i raportuj skuteczną adopcję wyłącznie razem z guardrailami.

Mianownik się przesuwa. W trakcie okresu dochodzą kontraktorzy, nowi pracownicy albo wyłączone zespoły, a wskaźnik skacze, choć nikt nie zmienił zachowania. Wyjście: przelicz okres według zamrożonej karty, a gdy uprawnienia muszą się zmienić, zacznij porównanie od nowa.

Ukończenia są naciągane. Inżynierowie dzielą jedną zmianę na kilka małych PR-ów, żeby podbić liczbę ukończeń. Wyjście: licz ukończenia per zadanie, nie per PR, i obserwuj accepted change rate oraz obciążenie review, które spadają przy sztucznym dzieleniu.

Adopcja zamienia się w inwigilację. Ranking poszczególnych osób trafia do oceny okresowej. Inżynierowie przestają zgłaszać nieudane przebiegi i dane o tarciu przestają spływać. Wyjście: usuń widoki per osoba ze wszystkich raportów adopcji, powiedz to publicznie i odbuduj zaufanie, zanim uwierzysz kolejnej ankiecie. O ludzkiej stronie tego procesu pisze strona o przekonywaniu sceptyków i seniorów.

Telemetria ma dziury. Zero Data Retention wyłącza contribution metrics w Claude Code, a w codex exec zgłaszano lukę w metrykach (#12913, obecnie zamknięte), którą trzeba sprawdzić na swojej wersji. Wskaźnik adopcji po cichu zaniża zespoły CI i zespoły regulowane. Wyjście: dla tych zespołów wróć do znacznika z szablonu PR i odnotuj lukę w raporcie.

Bezpieczne unikanie jest karane. Zespół odrzuca workflow agentowy dla usługi objętej ograniczeniami i zostaje oznaczony jako maruder. Wyjście: przenieś tę klasę zadań do wyłączeń na karcie i doceń zespół za stosowanie polityki.

Dokąd dalej z adopcją w zespole

Udowodnij, że nowy inżynier potrafi ukończyć workflow, a potem wprowadź skuteczną adopcję do panelu CTO obok wyniku i kosztu.

Adopcja w zespole Jak zespół wdraża workflow z agentami, zanim je ocenisz.

Q19 · Onboarding deweloperów Udowodnij, że nowy inżynier bezpiecznie ukończy jeden workflow.

Q23 · ROI toolingu AI Zamień adopcję i guardraile w uzasadnienie ROI na dopasowanych kohortach.

Q22 · Panel metryk AI Zestaw adopcję z zaakceptowanym wynikiem, jakością i kosztem.

Frameworki metryk Kanoniczne definicje i instrumentacja dla każdego narzędzia.

Roadmapa adopcji Kolejność, w jakiej zespół przejmuje workflow z agentami.

Na pozostałe pytania scorecardu odpowiada klucz odpowiedzi CTO Scorecard.