Pilotaż, który czegoś dowodzi

Pilotaż, który czegoś dowodzi o agentach AI do kodowania, porównuje kohortę testową z dobraną kohortą kontrolną w tych samych 4–8 tygodniach, na tle punktu odniesienia z systemu kontroli wersji, CI i systemu incydentów. Nazywa czynniki zakłócające, z góry ustala liczebność próby i zobowiązuje się do spisanej reguły decyzyjnej, więc o budżecie decyduje wynik, a nie najgłośniejsza opinia.

Zespół ochotników dostał licencje sześć tygodni temu. Mówi, że jest „dużo szybszy”, liczba pull requestów na osobę wzrosła, a recenzent z innego zespołu twierdzi, że tym zmianom trudniej zaufać. Nikt nie potrafi powiedzieć, czy dostarczanie się poprawiło, a spotkanie budżetowe CTO jest za miesiąc.

Co daje ten projekt pilotażu

Cztery schematy pilotażu, kryteria doboru kohort i rejestr dziewięciu czynników zakłócających
Obliczenie liczebności próby, które powtórzysz na własnym punkcie odniesienia
Regułę decyzyjną i jednostronicową kartę, które podpisujesz przed pierwszym tygodniem
Oznaczanie kohort w Claude Code, Codeksie i Cursorze oraz dwa prompty: wariancja punktu odniesienia i audyt projektu przed startem

Pilotaż zasila business case: business case prosi o eksperyment, a ta strona sprawia, że eksperyment jest wart swojego kosztu. Zakłada, że definicje metryk masz już wybrane według przewodnika po frameworkach metryk.

Dlaczego większość pilotaży agentów AI niczego nie dowodzi

Typowy pilotaż daje licencje ochotnikom, po miesiącu pyta ich, czy czują się szybsi, i liczy pull requesty. Każdy z tych wyborów osobno sprawia, że wyniku nie da się zinterpretować:

Źródło	Co pokazuje	Co to znaczy dla twojego pilotażu
Randomizowane badanie METR, 2025-07-10 (16 doświadczonych programistów open source, 246 zadań)	Zadania z AI trwały o 19% dłużej (przedział od +2% do +39%), a programiści nadal uważali, że AI przyspieszyło ich o 20% („still believed AI had sped them up by 20%”).	Ankieta mierzy przekonanie, nie szybkość. Mierz z systemów.
Badanie uzupełniające METR, 2026-02-24	Oszacowania punktowe wypadają na korzyść AI (ok. 18% i 4% mniej czasu w dwóch kohortach), ale oba przedziały przecinają zero. METR pisze, że nowe wyniki są obciążone silniejszą selekcją („subject to increased selection”), a pomiar czasu zadania jest niewiarygodny u programistów, którzy używają kilku agentów AI jednocześnie („who use multiple AI agents concurrently”).	To, kto trafia do pilotażu, zmienia odpowiedź; pomiar czasu na zadanie psują równolegli agenci.
Raport DORA 2025, 2025-09-23	„A positive relationship between AI adoption on both software delivery throughput and product performance” oraz „a negative relationship with software delivery stability”.	Licz jakość w tym samym oknie co przepustowość.
Raport telemetryczny Faros AI, kwiecień 2026 (22 000 programistów, ponad 4000 zespołów)	Zadania na programistę +33,7%, a jednocześnie błędy na programistę +54% i mediana czasu w review +441,5%.	Wydajność może rosnąć, gdy dostarczanie się pogarsza. Metryki ochronne nie są opcjonalne.

Na jakie pytanie ma odpowiedzieć pilotaż?

Zapisz jedno pytanie, jedną populację i jedną metrykę główną. Pilotaż, który próbuje odpowiedzieć na pytanie „czy AI jest dla nas dobre?”, nie odpowiada na nic.

Nazwij interwencję precyzyjnie, bo kohorta kontrolna niemal na pewno już używa AI (DORA 2025: 90% ankietowanych używa AI w pracy). Testujesz konkretną konfigurację na tle obecnej praktyki, a nie „AI kontra brak AI”:

„Czy wspólny harness (Claude Code z naszymi regułami, skillami, bramkami CI i agentem do review) obniża koszt zaakceptowanej zmiany o co najmniej 10% względem obecnej praktyki w zespołach produktowych pracujących w monorepo, bez wzrostu odsetka nieudanych zmian?”

Metrykę główną wybierz według opcji, którą finansuje business case:

Opcja z business case’u	Metryka główna	Metryki ochronne (nie mogą się pogorszyć)
B. Same licencje	Zaakceptowane zmiany na inżyniera tygodniowo	Odsetek nieudanych zmian, poprawki w ciągu 30 dni, mediana czasu review
C. Wspólny harness	Koszt zaakceptowanej zmiany, wszystkie pozycje kosztowe	Odsetek nieudanych zmian, poprawki, czas review, incydenty
D. Pilotaż fabryki na jednej pętli	Odsetek zadań pętli, które przechodzą wyrocznię i zostają zaakceptowane bez poprawek	Defekty, które uciekły z pętli, koszt na zadanie, naruszenia chronionych ścieżek

Zaakceptowana zmiana to zmiana scalona do głównej gałęzi i niewycofana ani nieprzepisana w ciągu 30 dni. Zamroź tę definicję w karcie i tam, gdzie się da, licz na zgłoszenie (ticket): agenci sprawiają, że podzielenie jednej zmiany na pięć pull requestów nic nie kosztuje.

Jak zaprojektować pilotaż krok po kroku

Zapisz pytanie, metrykę główną i metryki ochronne. Tylko jedna metryka główna; wszystko inne to metryka ochronna albo notatka eksploracyjna.
Weź punkt odniesienia z systemów źródłowych. Pobierz ostatnie 8–12 tygodni dla każdego kandydującego zespołu: zaakceptowane zmiany, czas realizacji, odsetek nieudanych zmian, medianę czasu review, poprawki i incydenty. Zapisz wariancję, nie tylko średnią, bo od niej zależy liczebność próby. Pierwszy prompt poniżej liczy z gh czas od otwarcia do scalenia PR, czyli przybliżenie czasu realizacji; jeśli definiujesz czas realizacji od pierwszego commita do produkcji, mierz właśnie to i trzymaj się jednej definicji.
Wybierz schemat i jednostkę przydziału. W większości organizacji: dobrane równoległe kohorty na poziomie zespołów (porównanie w następnej sekcji).
Zbuduj kohorty przez dobór w pary, potem przydziel rzutem monetą. Połącz zespoły w pary według kryteriów doboru, a potem losowo wybierz zespół testowy w każdej parze. To usuwa zarzut „wybraliśmy najlepszy zespół”.
Wypełnij rejestr czynników zakłócających. Dla każdego z dziewięciu czynników poniżej zapisz kontrolę albo powód, dla którego nie ma zastosowania.
Ustal liczebność próby. Wykonaj obliczenie poniżej na wariancji z punktu odniesienia. Jeśli pilotaż nie wykryje efektu, którego potrzebuje business case, zmień projekt teraz, a nie po odczycie wyników.
Spisz i podpisz regułę decyzyjną. Skalujemy, przedłużamy albo kończymy, z progami. CTO podpisuje metryki ochronne, CFO podpisuje definicje kosztów, a wskazany analityk spoza zespołu pilotażowego liczy wynik.
Zinstrumentuj obie kohorty przed pierwszym tygodniem. Oznacz każde uruchomienie agenta kohortą (patrz zakładki poniżej) i sprawdź, czy metryki kohorty kontrolnej trafiają do tych samych dashboardów.
Prowadź pilotaż przez zaplanowane tygodnie, potem odczytaj wynik dwa razy. Odczyt pośredni na koniec pilotażu, końcowy 30 dni później, gdy zamknie się okno poprawek dla ostatnich zmian.

Który schemat pilotażu pasuje do twojej organizacji?

Schemat	Jak działa przydział	Użyj, gdy	Czego nie zrobi
Dobrane równoległe kohorty (domyślnie)	Zespoły połączone w pary według podobnej pracy; rzut monetą w każdej parze wybiera grupę testową	Masz co najmniej cztery porównywalne zespoły	Nie wykryje małych efektów przy niewielu zespołach; patrz liczebność próby
Wdrożenie schodkowe (stepped wedge)	Każdy zespół dostaje interwencję, w losowej kolejności, co 2–4 tygodnie	Wstrzymanie narzędzia komukolwiek jest politycznie niemożliwe	Nie skończy się szybko
Losowanie na poziomie zadań (jak w METR)	Każde zgłoszenie przed rozpoczęciem pracy jest losowo oznaczane „agenci dozwoleni” albo nie	Chcesz najmocniejszej odpowiedzi przyczynowej dla jednego zespołu	Nie przetrwa równoległych agentów, przy których czas zadania jest niewiarygodny (METR)
Przed i po w jednym zespole	Bez kontroli; porównanie z własnym punktem odniesienia zespołu	Tylko jako uzupełnienie jednego z powyższych	Nie oddzieli narzędzia od sezonu, roadmapy ani reorganizacji

Nigdy nie porównuj ochotników z resztą: entuzjaści różnią się w sposób, którego narzędzie nie spowodowało, i tego dotyczy zastrzeżenie METR z 2026 roku o selekcji.

W pilotażu fabryki na jednej pętli (opcja D) jednostką jest zadanie, nie zespół. Losowo kieruj połowę zadań przychodzących do pętli (na przykład aktualizacji zależności) do agenta działającego bez nadzoru, a połowę do zwykłego procesu, i porównaj akceptację, poprawki oraz koszt na zadanie.

Jak dobrać kohorty

Dobieraj pary według tego, co wpływa na metryki dostarczania silniej niż jakiekolwiek narzędzie, co najmniej według pierwszych czterech wierszy.

Dobieraj według	Dlaczego to ważne	Jak sprawdzić
Baza kodu i język	Pokrycie testami i szybkość buildu decydują, ile agent sam zweryfikuje	To samo repozytorium lub stos; pokrycie w granicach kilku punktów
Rodzaj pracy	Nowe funkcje, utrzymanie i praca przy incydentach zachowują się inaczej	Udział typów zgłoszeń w tygodniach punktu odniesienia
Wielkość zespołu i proporcja seniorów	Seniorzy i juniorzy inaczej przyjmują agentów	Liczba osób i przybliżony podział według stażu
Poziom metryki w punkcie odniesienia	Regresja do średniej sprawia, że najsłabszy zespół i tak wygląda na poprawiony	Metryka główna w tym samym kwartylu
Kalendarz wydań	Zamrożenie przed premierą albo końcówka kwartału przykrywa każdy efekt narzędzia	Brak znanego zamrożenia ani dużej premiery w oknie pilotażu

Które czynniki zakłócające psują pilotaż agentów AI?

Czynnik zakłócający to wszystko poza interwencją, co zmienia metrykę w czasie pilotażu. Wypisz każdy w karcie razem z jego kontrolą.

Czynnik zakłócający	Jak się objawia	Kontrola
Selekcja ochotników	Narzędzie dostaje najbardziej zapalony zespół, który już był najszybszy	Dobrane pary, rzut monetą w każdej parze
Nowość i obserwacja	Wszyscy pracują ciężej, bo wiedzą, że są obserwowani	Powiedz obu kohortom, że są mierzone; oceniaj ostatnie cztery tygodnie
Spadek na starcie	Przepustowość spada w pierwszych tygodniach nauki	Raportuj tygodnie 1–2 osobno; nie przerywaj z powodu samej przepustowości przed 4. tygodniem
Przeciek	Inżynierowie z kontroli używają prywatnych kont AI albo kopiują reguły zespołu testowego	Zapisz obecne narzędzia kontroli; we wspólnym repozytorium dostarczaj harness grupy testowej przez ustawienia zarządzane lub użytkownika (albo plugin) włączone tylko na maszynach grupy testowej, a nie przez pliki zatwierdzone w repozytorium
Zmiana miksu pracy	Inżynierowie z grupy testowej wybierają zgłoszenia pasujące do agentów	Przydzielaj zgłoszenia przez zwykły backlog; zapisuj szacunek wielkości przed rozpoczęciem pracy, jak w METR
Gra metryką	Pull requesty robią się mniejsze i liczniejsze; „zaakceptowana” dostaje nową definicję	Licz na zgłoszenie; zamroź definicje w karcie; analityk jest spoza zespołu
Równoległa zmiana	W trakcie pilotażu dochodzi migracja CI, reorganizacja albo nowy grafik dyżurów	Zamroź inne zmiany procesu w obu kohortach albo zapisuj je z datami
Wspólni recenzenci	Pull requesty od agentów wydłużają wspólną kolejkę review	Trzymaj review wewnątrz kohort albo mierz czas review na recenzenta
Równoległe uruchomienia agentów	Czas na zadanie traci sens, gdy jeden inżynier prowadzi trzech agentów	Mierz na inżyniera tygodniowo i na zaakceptowaną zmianę

Jak duży musi być pilotaż?

Większość pilotaży jest za mała, żeby wykryć efekt, który ogłasza. Standardowy wzór dla dwóch grup, test dwustronny, istotność 5%, moc 80%:

zmiany na kohortę = 15,7 × σ² ÷ δ²

σ to odchylenie standardowe metryki na zmianę, a δ najmniejszy efekt wart wykrycia. Zmiany jednego inżyniera są skorelowane, więc pomnóż wynik przez efekt schematu: 1 + (m − 1) × ICC, gdzie m to liczba zmian na inżyniera w czasie pilotażu, a ICC to udział wariancji przypadający na różnice między inżynierami.

Przykład dla czasu od otwarcia do scalenia PR (przybliżenie czasu realizacji). Dane są ilustracyjne; zastąp je wartościami z pierwszego promptu.

Dane wejściowe (ilustracyjne)	Wartość
σ logarytmu czasu od otwarcia do scalenia na zmianę	1,0
Efekt do wykrycia: czas krótszy o 30%	δ = \|ln 0,7\| ≈ 0,357
Zmiany na kohortę przed uwzględnieniem skupień	15,7 × 1,0 ÷ 0,127 ≈ 124
Zmiany na inżyniera w 8 tygodni (m)	30
ICC między inżynierami	0,1
Efekt schematu	1 + 29 × 0,1 = 3,9
Zmiany na kohortę po uwzględnieniu skupień	124 × 3,9 ≈ 484, czyli około 17 inżynierów na kohortę

Dla efektu 20% te same dane wymagają około 1230 zmian, czyli 41 inżynierów, na kohortę. To arytmetyka stojąca za najczęstszym błędem pilotażu: jeden ośmioosobowy zespół nie wykryje niczego poza dużym efektem.

Gdy liczby się nie mieszczą, zmień projekt:

Dodawaj zespoły, nie tygodnie. Przez skorelowanie zmian więcej inżynierów pomaga dużo bardziej niż więcej tygodni od tych samych osób.
Koryguj o punkt odniesienia. Porównuj każdego inżyniera z jego własnym punktem odniesienia; to usuwa stałe różnice między ludźmi i zmniejsza σ.
Wybierz jednostkę o większym wolumenie. Pętla fabryki z setkami zadań miesięcznie osiąga użyteczną wielkość w cztery tygodnie.
Decyduj na podstawie przedziałów i metryk ochronnych, a nie samej wartości p: metryki ochronne się utrzymały, a przedział ufności przekroczył próg.

Spisz regułę decyzyjną przed pierwszym tygodniem

Reguła decyzyjna zamienia odczyt wyników w działanie, którego nikt nie wynegocjuje na nowo. Dopasuj progi do punktu odniesienia i business case’u.

Wynik	Warunek	Działanie
Skalujemy	Metryka główna poprawia się co najmniej o próg z business case’u (na przykład koszt zaakceptowanej zmiany o 10% niższy niż w kontroli), a żadna metryka ochronna nie została przekroczona w dwóch kolejnych tygodniach	Rozszerz na następną kohortę zespołów, nie na wszystkich
Przedłużamy raz	Metryka główna się poprawia, ale poniżej progu, albo przedział jest za szeroki, żeby zdecydować, a metryki ochronne się utrzymały	Jeszcze cztery tygodnie z tymi samymi kohortami, potem ponownie zastosuj regułę, bez kolejnego przedłużenia
Kończymy	Metryka ochronna stabilności albo chronionych ścieżek przekroczona dwa razy, albo metryka główna bez zmian lub gorsza w odczycie końcowym	Zatrzymaj interwencję i zapisz, czego pilotaż nauczył was o lukach w weryfikacji

Wpisz regułę do karty dosłownie; każde uchylenie przez kierownictwo też trafia do karty, z powodem. Na ten zapis powołuje się raport dla zarządu.

Jak oznaczać uruchomienia pilotażowe w Claude Code, Codeksie i Cursorze

Metryki jakości pochodzą z gita, CI i systemu incydentów, które nie zależą od narzędzia: analityk łączy je z listą kohort. Od narzędzia zależy to, jak uzyskasz koszt i użycie na kohortę, których potrzebuje opcja C.

Claude Code eksportuje metryki OpenTelemetry, w tym claude_code.cost.usage (USD), claude_code.token.usage, claude_code.pull_request.count i claude_code.commit.count. OTEL_RESOURCE_ATTRIBUTES dodaje twoje własne klucze do każdej metryki i zdarzenia, więc etykieta kohorty staje się filtrem w dashboardach. Ustaw ją w pliku managed settings na komputerach inżynierów z grupy testowej:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_RESOURCE_ATTRIBUTES": "pilot.id=harness-2026q4,pilot.cohort=treatment,team.id=payments"
  }
}

Managed settings obowiązują każdego użytkownika, u którego wdrożono plik, więc wdrażaj go tylko na komputery grupy testowej (albo wpisz blok do ~/.claude/settings.json każdego inżyniera). Inżynierom z grupy kontrolnej daj ten sam blok z pilot.cohort=control, żeby obie kohorty trafiały do tych samych dashboardów.

Dwie pułapki, sprawdzone na Claude Code 2.1.283. Claude Code ignoruje zmienne eksportera w pliku .claude/settings.json repozytorium: użyj managed settings albo ~/.claude/settings.json każdego inżyniera. Poza tym wartości w OTEL_RESOURCE_ATTRIBUTES nie mogą zawierać spacji (team.id=payments_core, a nie tekst w cudzysłowie).

W planach Team i Enterprise z zainstalowaną aplikacją GitHub dashboard analityczny oznacza scalone pull requesty z udziałem Claude Code etykietą claude-code-assisted. Metryki wkładu są w publicznej becie i niedostępne przy zero data retention, więc to kontrola krzyżowa, a nie definicja kohorty.

Codex czyta tabelę [otel] z ~/.codex/config.toml. span_attributes dodaje etykietę kohorty do każdego eksportowanego spana i tylko do spanów: nie dotyczy wyjścia metrics_exporter, więc daje ślady na kohortę, a nie koszt na kohortę. Nazwy pól odczytano ze źródła OtelConfigToml na tagu rust-v0.157.1:

[otel]
environment = "prod"
log_user_prompt = false
span_attributes = { "pilot.id" = "harness-2026q4", "pilot.cohort" = "treatment", "team.id" = "payments" }
trace_exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/traces", protocol = "binary" } }

Zużycie tokenów na kohortę zapisuj z codex exec --json, gdzie każde zdarzenie turn.completed zawiera obiekt usage, albo połącz zużycie według użytkownika z listą kohort. Zadanie edytuje pliki, więc potrzebuje sandboxa z prawem zapisu; ten pilotaż standaryzuje się na profilu uprawnień -c default_permissions=":workspace" (beta w Codex 0.157.1; starsze --sandbox workspace-write też działa, ale nie łącz obu):

# Terminal lub CI: jedno zadanie pilotażowe, zużycie dopisane z id zadania i kohortą
codex exec --json -c default_permissions=":workspace" "Fix the failing test in src/billing and stop when npm test passes" \
  | jq -c 'select(.type == "turn.completed") | {task: "BIL-142", cohort: "treatment", usage: .usage}' >> pilot-usage.jsonl

Konfigurację telemetrii szczegółowo opisuje strona o telemetrii agentów.

Prompty i szablony do prowadzenia pilotażu

Work read-only: do not edit, commit or push anything.

For this repository, over the 12 weeks ending today:
1. Run gh pr list --state merged --base main --search "merged:>=YYYY-MM-DD" --limit 1000 --json number,author,createdAt,mergedAt,additions,deletions, with YYYY-MM-DD set to 12 weeks before today. If the result has exactly 1000 pull requests, the limit was hit: say so, raise --limit and run it again until the result is below the limit.
2. For each pull request, compute PR open-to-merge time in hours (createdAt to mergedAt, a proxy for lead time), then its natural log.
3. Report: the number of pull requests, the number of distinct authors, the mean and standard deviation of log open-to-merge time, and the median pull requests per author.
4. Estimate the intraclass correlation (ICC) of log open-to-merge time by author with a one-way random-effects ANOVA. Show the between-author and within-author variance components.
5. Using changes per cohort = 15.7 x sigma^2 / delta^2, times the design effect 1 + (m - 1) x ICC, report the engineers needed per cohort to detect 20% and 30% shorter open-to-merge time over 8 weeks.
6. List every assumption, and every author or pull request you excluded, with the reason.

Read the attached pilot charter. Act as a sceptical analyst who has read METR's 2025 and 2026 developer studies and DORA's 2025 report, and who will have to defend the result to a CFO.

Report, in order of severity:
1. Any way the treatment cohort was chosen that is not random assignment within matched pairs.
2. Each confounder from this list that the charter does not control: volunteer selection, novelty, adoption dip, contamination, work-mix shift, metric gaming, concurrent change, shared reviewers, parallel agent runs.
3. Whether the sample size calculation uses the charter's own baseline variance, and whether the pilot can detect the effect the decision rule needs.
4. Any metric definition that the pilot team could change during the pilot.
5. Any outcome the decision rule does not map to scale, extend or stop.

Quote the sentence each finding refers to. Do not rewrite the charter.

Wypełnij każde pole tej jednostronicowej karty przed pierwszym tygodniem.

# Karta pilotażu: <interwencja> — <id pilotażu>

Pytanie: Czy <interwencja> zmienia <metryka główna> co najmniej o <próg>
względem obecnej praktyki, dla <populacja>, bez pogorszenia <metryki ochronne>?
Business case: <link>   Właściciel decyzji: <imię>   Analityk (spoza zespołu): <imię>

## Projekt
Schemat: dobrane równoległe kohorty | wdrożenie schodkowe | losowanie zadań
Jednostka przydziału: zespół | inżynier | zadanie
Pary i wynik losowania: <zespół A vs zespół B → A testowy>, ...
Tygodnie pilotażu: <start> do <koniec> (4–8 tygodni)   Odczyt końcowy: <koniec + 30 dni>

## Metryki (definicje zamrożone w chwili podpisu)
Główna: <metryka, dokładna definicja, system źródłowy>
Ochronne: odsetek nieudanych zmian | poprawki w ciągu 30 dni | mediana czasu review | incydenty
Zaakceptowana zmiana: scalona do main i niewycofana ani nieprzepisana w ciągu 30 dni

## Punkt odniesienia (ostatnie 8–12 tygodni, na kohortę)
Główna: średnia ___ odch. std. ___   Ochronne: ___

## Liczebność próby
sigma ___  delta ___  ICC ___  m ___  → inżynierów na kohortę ___

## Rejestr czynników zakłócających
| Czynnik | Kontrola | Właściciel |

## Reguła decyzyjna (dosłownie)
Skalujemy, jeśli ___. Przedłużamy raz, jeśli ___. Kończymy, jeśli ___.

## Podpisy
CTO (metryki ochronne) ___  CFO (definicje kosztów) ___  Analityk ___  Data ___

Jak sprawdzić wynik pilotażu

Nikt z zespołu pilotażowego nie ocenia własnego pilotażu.

Punkt odniesienia pochodzi z gita, CI i danych o incydentach sprzed losowania; CFO podpisuje go z definicjami kosztów.
Każda zmiana grupy testowej niesie swoje dowody: zaliczone testy, zapis review i koszt uruchomienia. Format pakietu dowodów pozwala analitykowi sprawdzać próbkę zmian zamiast ufać dashboardowi.
Analityk spoza zespołu liczy metryki według zamrożonych definicji, podaje przedział i stosuje regułę decyzyjną.
Chronione ścieżki (uwierzytelnianie, płatności, schemat, migracje) są wymuszane w CI w obu kohortach.
Odczyt końcowy czeka na zamknięcie 30-dniowego okna poprawek.

Co psuje pilotaże agentów AI i jak to naprawić

Zespołem pilotażowym byli ochotnicy. Wynik zostanie odrzucony jako efekt selekcji, i słusznie. Zachowaj ich jako pierwszy zespół testowy, znajdź dobraną kontrolę i uruchom drugą, losowo przydzieloną falę schodkową.

Odczytem wyników była ankieta. Programiści METR czuli się szybsi, a pomiary pokazały spowolnienie. Odtwórz porównanie z danych gita i CI za te same tygodnie.

Liczba pull requestów na inżyniera wzrosła i pilotaż ogłosił sukces. Przelicz na zgłoszenie z poprawkami i incydentami. Jeśli metryki ochronne się ruszyły, to wzorzec z raportu Faros, a nie sukces.

Zespół kontrolny w połowie przejął reguły grupy testowej. Ustal datę przecieku, przeanalizuj tygodnie sprzed niej, a resztę potraktuj jak wdrożenie schodkowe.

Przepustowość spadła w drugim i trzecim tygodniu, a sponsor chce przerwać. To zaplanowany spadek na starcie. Przerwanie przed 4. tygodniem z powodu samej przepustowości jest poza regułą; przekroczenie metryki ochronnej mieści się w niej.

Wynik mieści się w szumie. Zastosuj gałąź „przedłużamy raz”, dodaj zespoły zamiast tygodni i nie przedłużaj drugi raz.

Dashboardy nie rozdzielają kohort. Przenieś grupę testową na oznaczoną telemetrię opisaną wyżej i do metryki kosztu użyj tylko oznaczonych tygodni.

Co dalej po zaprojektowaniu pilotażu

Business case dla inżynierii agentowej Notatka decyzyjna, którą zasila pilotaż: opcje, pełny koszt, próg rentowności i bramki stopu.

Frameworki metryk, gdy kod piszą agenci DORA, SPACE, DX Core 4 i definicje, które trzeba zamrozić w karcie.

Model operacyjny dla oprogramowania budowanego przez agentów Kolejna decyzja CTO, gdy pilotaż mówi „skalujemy”.

Jak przekonać sceptyków i seniorów Niech seniorzy projektują weryfikację i prowadzą mierzone pilotaże na własnej pracy.

Po decyzji „skalujemy”: mapa drogi wdrożenia w zespole dla repozytoriów, mapa transformacji dla organizacji. Datowane dowody: stan inżynierii agentowej.