DORA, SPACE, DX Core 4 i pomiar AI, gdy kod piszą agenci

Gdy kod piszą agenci, metryki efektów przetrwają, a metryki aktywności się psują. DORA nadal mierzy dostarczanie: change lead time, change fail rate, failed deployment recovery time i deployment rework rate. Liczba pull requestów, linie kodu i „% kodu z AI” mierzą dziś tanią produkcję agentów. Adopcję AI mierz wykorzystaniem, wpływem i kosztem, a szybkość czytaj obok stabilności.

W zeszłym kwartale agenci trafili do dwunastu zespołów. Dashboard pokazuje więcej zmergowanych pull requestów, więcej zmienionych linii i wykres dostawcy, według którego połowę kodu pisze już AI. W tym samym kwartale kolejki review urosły dwukrotnie, a dwa incydenty wyszły ze zmian, których nikt dokładnie nie przeczytał. Zarząd pyta, czy inwestycja się zwraca, a żadna liczba na ekranie nie odpowiada na to pytanie.

Ta strona jest dla CTO lub VP Engineering, który odpowiada za program pomiaru, dla tech leada, który raportuje za jeden zespół i nie chce zrobić z metryk rankingu, oraz dla członka zarządu, który musi wiedzieć, którym liczbom wierzyć. To kanoniczne miejsce definicji metryk AI na tej stronie: inne artykuły linkują tutaj, zamiast definiować je od nowa.

Co daje ci ta strona o pomiarze

• Tabelę werdyktów: które znane metryki przetrwają przepustowość agentów, które się psują i czego użyć zamiast nich.
• Aktualne definicje pięciu metryk dostarczania DORA, pięciu wymiarów SPACE i czterech wymiarów DX Core 4 wraz z tym, co zmieniają w nich agenci.
• Dziesięć kanonicznych definicji metryk AI, każdą ze wzorem, źródłem danych i pułapką, przed którą chroni.
• Minimalny panel dla zespołu, organizacji inżynierskiej i zarządu, z rytmem przeglądów.
• Kroki instrumentacji dla Claude Code, Codeksa i Cursora, dwa prompty do skopiowania i sekcję o typowych awariach pomiaru.

Które metryki przetrwają, gdy kod piszą agenci?

Metryka przetrwa, jeśli mierzy efekt odczuwalny dla klienta albo operatora. Psuje się, jeśli liczy coś, co agent potrafi dziś wyprodukować hurtowo i prawie za darmo. Tabela to krótka odpowiedź; kolejne sekcje podają definicje.

Metryka	Werdykt	Dlaczego	Czego użyć zamiast niej lub obok
Change lead time (od commita do produkcji)	Przetrwa	Mierzy cały system, łącznie z review i wdrożeniem	Rozbij ją: czas do pierwszego review, czas w review, czas do wdrożenia
Change fail rate	Przetrwa i staje się głównym bezpiecznikiem	Wyłapuje koszt stabilności przy większej liczbie zmian	Porównuj kohorty: zmiany z udziałem agenta i pozostałe
Failed deployment recovery time	Przetrwa	Odtworzenie zależy od rollbacku i obserwowalności, nie od autora kodu	Śledź per usługa
Deployment rework rate	Przetrwa	Nieplanowane wdrożenia po incydentach odsłaniają wolumen niskiej jakości	Łącz z change fail rate
Deployment frequency	Przetrwa z zastrzeżeniem	Więcej małych wdrożeń to dobrze; więcej wdrożeń dużych diffów od agentów już nie	Czytaj razem z rozmiarem PR
Zmergowane pull requesty na inżyniera	Psuje się jako miara sukcesu	Agenci otwierają PR-y hurtowo; liczba rośnie bez względu na wartość	Wskaźnik zaakceptowanych zmian (accepted change rate), koszt zaakceptowanej zmiany
Dodane lub zmienione linie kodu	Psuje się	Agenci generują rozwlekły kod; więcej linii często znaczy gorzej	Nic: przestań raportować to jako wynik
„% kodu napisanego przez AI”	Psuje się jako cel	Opisuje adopcję, nie wartość; rośnie samo	Udział zmergowanych zmian z udziałem agenta, czytany wyłącznie jako wykorzystanie
Wskaźnik akceptacji podpowiedzi	Psuje się dla agentów	Zaprojektowany dla autouzupełniania; sesja agenta nie ma jednej podpowiedzi do przyjęcia	Wskaźnik zaakceptowanych zmian per pętla agenta
Story pointy na sprint	Psuje się	Estymacja rozjeżdża się, gdy agenci zmieniają nakład pracy	Lead time i przepustowość zaakceptowanych zmian
Satysfakcja i zaufanie deweloperów (ankieta)	Przetrwa i zyskuje na znaczeniu	Obciążenie review, zaufanie i obciążenie poznawcze zmieniają się wcześniej niż metryki dostarczania	Kwartalna ankieta ze stałymi pytaniami

Dowody na ten podział są spójne w niezależnych źródłach:

• DORA 2025 (Google Cloud, 2025-09-23): „we observe a positive relationship between AI adoption on both software delivery throughput and product performance”. I w następnym zdaniu: „AI adoption does continue to have a negative relationship with software delivery stability”. Panel, który pokazuje tylko pierwszą połowę, opowiada połowę historii.
• DX (Justin Reock, 2026-06-17; ostatnio sprawdzone 2026-08-28): mediana rozmiaru pull requesta wzrosła z 44 do 72 linii między lipcem 2025 a czerwcem 2026, w próbie ponad 400 firm. Liczba i rozmiar PR-ów zmieniają się wraz z adopcją agentów, więc są niestabilną jednostką pracy.
• Faros AI, AI Engineering Report 2026 (kwiecień 2026; ostatnio sprawdzone 2026-08-28), telemetria 22 000 deweloperów: przepustowość zadań na dewelopera +33,7% i wskaźnik mergowania PR-ów na dewelopera +16,2%, podczas gdy wdrożenia tygodniowo spadły o 11,7%, incydenty na pull request wzrosły o 242,7%, a mediana czasu w review o 441,5%. Produkcja wzrosła; dostarczanie i stabilność za nią nie poszły.

Co te dowody pokazują, a czego nie

Wszystkie trzy źródła są korelacyjne. Pokazują, co dzieje się z liczbami, gdy rośnie adopcja, a nie że to agenci powodują zmianę. Faros to telemetria dostawcy z bazy jego klientów, a udział kodu AI w danych DX jest deklaratywny. To wystarcza, by zdecydować, którym metrykom ufać, ale nie wystarcza, by prognozować twoje własne wyniki.

Jakie jest dziś pięć metryk dostarczania DORA?

DORA zastąpiła pierwotne cztery kluczowe metryki pięcioma i przeszła ze średniego czasu przywrócenia (MTTR) na failed deployment recovery time. Poniższe definicje pochodzą z przewodnika DORA po metrykach (aktualizacja 2026-01-05, odczytane ze źródeł dora-team/dora.dev 2026-09-26). DORA dzieli je na przepustowość (throughput) i niestabilność (instability).

Grupa	Metryka	Definicja DORA	Co zmieniają agenci
Throughput	Change lead time	„The amount of time it takes for a change to go from committed to version control to deployed in production.”	Czas kodowania maleje; większość lead time to teraz review i zatwierdzanie
Throughput	Deployment frequency	„The number of deployments over a given period or the time between deployments.”	Może spaść nawet przy rosnącej liczbie PR-ów, gdy wąskim gardłem jest review
Throughput	Failed deployment recovery time	„The time it takes to recover from a deployment that fails and requires immediate intervention.”	Bez zmian przy zautomatyzowanym rollbacku; gorzej, gdy nikt nie rozumie zmiany
Instability	Change fail rate	„The ratio of deployments that require immediate intervention following a deployment.”	Pierwsza metryka, która drgnie, gdy wolumen wyprzedzi weryfikację
Instability	Deployment rework rate	„The ratio of deployments that are unplanned but happen as a result of an incident in production.”	Rośnie, gdy zmiany agentów przechodzą testy, które nie sprawdzają zachowania

Dwie uwagi z przewodnika DORA ważą więcej przy agentach. Po pierwsze, metryki najlepiej sprawdzają się „for measuring one application or service at a time”, więc nie uśredniaj ich po całym portfelu. Po drugie, DORA jako pierwszą pułapkę wymienia „Setting metrics as a goal”: cel w rodzaju „każdy zespół wdraża codziennie” zachęca do oszukiwania metryki, a agent oszuka cel szybciej niż człowiek.

Do oceny gotowości organizacji, a nie wyników dostarczania, DORA publikuje osobny AI Capabilities Model z siedmioma zdolnościami, m.in. pracą w małych partiach i wysokiej jakości platformami wewnętrznymi. Ma on własną samoocenę według modelu DORA AI Capabilities.

Co wnosi framework SPACE?

SPACE to model produktywności deweloperów autorstwa Nicole Forsgren, Margaret-Anne Storey, Chandry Maddili, Toma Zimmermanna, Briana Houcka i Jenny Butler (ACM Queue, luty 2021). Jego główna teza, z abstraktu: produktywności deweloperów „cannot be measured by a single metric or dimension”. Framework nazywa pięć wymiarów: Satisfaction and well-being (satysfakcja i dobrostan), Performance (wyniki), Activity (aktywność), Communication and collaboration (komunikacja i współpraca) oraz Efficiency and flow (efektywność i przepływ).

SPACE przydaje się dziś, bo wyjaśnia, dlaczego jeden wymiar się zepsuł. Agenci pompują Activity (commity, pull requesty, linie), nie ruszając pozostałych, więc każdy panel oparty głównie na aktywności zawyża zysk.

Wymiar SPACE	Jak go mierzyć, gdy w pętli są agenci	Sygnał do obserwowania
Satisfaction and well-being	Kwartalna ankieta: zaufanie do pracy agentów, zmęczenie review, poczucie odpowiedzialności za kod	Zaufanie spada, gdy adopcja rośnie
Performance	Change fail rate, defekty, które uciekły na produkcję, wskaźnik zaakceptowanych zmian	Stabilność zostaje w tyle za przepustowością
Activity	Udział zmergowanych zmian z udziałem agenta, wyłącznie jako kontekst	Jakikolwiek cel ustawiony na tej metryce
Communication and collaboration	Czas do pierwszego review, obciążenie recenzentów na inżyniera	Review skupione na kilku seniorach
Efficiency and flow	Czas w review, przerwy na czekanie, pętle poprawek	Inżynierowie czekają na review, a nie na agentów

Czym jest DX Core 4 i co się w nim psuje?

DX Core 4 to framework firmy DX (Abi Noda i Laura Tacho), który łączy badania DORA, SPACE i developer experience w cztery wymiary: speed, effectiveness, quality i impact. DX proponuje kluczową metrykę dla każdego wymiaru, m.in. diffy (pull requesty) na inżyniera dla szybkości i change failure rate dla jakości. Zamysł jest taki, że cztery wymiary ciągną w przeciwne strony, więc oszukanie jednego widać w innym.

Przy agentach słabym punktem jest metryka szybkości. Liczba diffów na inżyniera rośnie wraz z adopcją niezależnie od wartości, co pokazują dane DX i Faros powyżej. Zachowaj cztery wymiary, a dla szybkości raportuj zaakceptowane zmiany zamiast surowych diffów: pull requesty, które zostały zmergowane i nie zostały wycofane ani poprawione w ciągu 14 dni. Jakość (change failure rate) staje się bezpiecznikiem, który mówi, czy szybkość jest prawdziwa.

Status źródeł dla DX Core 4 i SPACE

Wymiary i nazwy metryk DX Core 4 oraz trzy wymiary opisanego niżej AI Measurement Framework od DX odpowiadają frameworkom opublikowanym przez DX w streszczeniu samej firmy (getdx.com, sprawdzone 2026-09-26 na podstawie wyciągów wtórnych). Nazwy wymiarów SPACE pochodzą z abstraktu artykułu w ACM Queue i ze strony publikacji Microsoft Research. Zanim wpiszesz te nazwy do wewnętrznej polityki, porównaj je z aktualnymi stronami DX.

Gdzie mieści się AI Measurement Framework od DX?

AI Measurement Framework od DX (Abi Noda i Laura Tacho) porządkuje pomiar AI w trzy wymiary: utilization (wykorzystanie: czy AI jest używane?), impact (wpływ: czy działa?) i cost (koszt: czy zwrot uzasadnia wydatek?). To najbardziej użyteczna soczewka dla warstwy AI w twoim panelu, bo nie pozwala przedstawiać liczb o wykorzystaniu jako liczb o wpływie.

Nie potrzebujesz do tego nowego frameworka. Zespół badawczy DORA mówi to samo w swoich wskazówkach o frameworkach pomiaru (2025-08-26): „if your overarching goal is the same, you don’t need to change your framework; you can expand your measurements to adapt to changes in technology”. Zostaw DORA albo Core 4 jako warstwę efektów i dodaj poniższe definicje jako warstwę AI.

Kanoniczne definicje metryk AI

Tych dziesięciu definicji używa każda strona tego serwisu. Każdą da się policzyć z gita, platformy do hostowania kodu, CI, systemu incydentów i telemetrii samych agentów. Gdy wzór mówi „z udziałem agenta”, chodzi o zmergowany pull request oznaczony twoim znacznikiem udziału agenta (patrz kroki instrumentacji niżej).

#	Metryka	Wymiar	Definicja i wzór	Źródło danych	Pułapka, przed którą chroni
1	Tygodniowo aktywni użytkownicy agentów	Wykorzystanie	Inżynierowie z co najmniej jedną sesją agenta w tygodniu ÷ inżynierowie z licencją na agenta	Telemetria agenta lub analityka administracyjna	Płacenie za licencje, których nikt nie używa
2	Udział zmergowanych zmian z udziałem agenta	Wykorzystanie	Zmergowane PR-y z udziałem agenta ÷ wszystkie zmergowane PR-y, per repozytorium	Etykiety pull requestów	Zastępuje „% linii napisanych przez AI”, które liczy wolumen
3	Wskaźnik zaakceptowanych zmian (accepted change rate)	Wpływ	PR-y z udziałem agenta zmergowane i niewycofane ani niepoprawione w ciągu 14 dni ÷ otwarte PR-y z udziałem agenta	Platforma kodu, powiązania revertów i poprawek	Liczenie porzuconej lub przerabianej pracy agenta jako dostarczonej
4	Odsetek nieudanych wdrożeń kohorty agentowej	Wpływ	Change fail rate dla wdrożeń zawierających zmiany z udziałem agenta, raportowany obok wskaźnika dla reszty	Log wdrożeń połączony z PR-ami	Uśredniony wskaźnik ukrywający gorszą kohortę agentową
5	14-dniowy wskaźnik poprawek	Wpływ	Zmergowane PR-y, po których w ciągu 14 dni przyszedł revert lub poprawka odwołująca się do nich ÷ zmergowane PR-y	Opisy commitów, powiązania PR-ów	Dług jakościowy, który nigdy nie staje się incydentem produkcyjnym
6	Obciążenie review	Wpływ	Mediana i p90 czasu do pierwszego review i czasu w review oraz liczba review na recenzenta tygodniowo	Platforma kodu	Niezauważone przeniesienie wąskiego gardła na seniorów
7	Defekty produkcyjne na 100 zmergowanych zmian	Wpływ	Błędy produkcyjne przypisane do zmiany ÷ zmergowane zmiany × 100, per kohorta	System incydentów i błędów	Traktowanie zielonego CI jako dowodu poprawności
8	Koszt zaakceptowanej zmiany	Koszt	Wydatki na agentów (licencje, użycie, tokeny) w okresie ÷ zaakceptowane zmiany z udziałem agenta (licznik metryki 3)	Rozliczenia, telemetria agenta	Koszt na token lub licencję, który nic nie mówi o wartości
9	Zysk czasu netto	Koszt	Deklarowane w ankiecie zaoszczędzone godziny na inżyniera tygodniowo minus zmierzone dodatkowe godziny review i poprawek	Ankieta plus platforma kodu	Deklarowane oszczędności przedstawiane jako zmierzone
10	Wskaźnik zaufania deweloperów	Wykorzystanie	Odsetek odpowiedzi 4 lub 5 na „Ufam zmianom przygotowanym przez agenta, które przeszły nasze bramki” (skala pięciostopniowa), kwartalnie	Ankieta	Wymuszanie adopcji szybciej, niż rośnie zaufanie

Trzy zasady pilnują uczciwości tych definicji:

1. Każdą metrykę szybkości raportuj obok metryki stabilności. Metryka 2 lub 3 nigdy nie pojawia się bez 4 lub 5 na tym samym slajdzie.
2. Porównuj kohorty, nie ludzi. Każdą metrykę wpływu raportuj per repozytorium lub usługa, z podziałem na zmiany z udziałem agenta i pozostałe. Żadnej nie raportuj per inżynier.
3. Ustal okno. Domyślne okno dla metryk 3 i 5 to 14 dni. Zmieniaj je tylko dla całej organizacji i tylko z notką na dashboardzie.

Jaki jest minimalny panel dla każdego poziomu organizacji?

Panelu, który próbuje pokazać wszystko, nikt nie czyta. Zacznij od najmniejszego panelu, który odpowiada na pytanie zadawane na danym poziomie, i dodawaj metryki dopiero wtedy, gdy wymaga tego konkretna decyzja.

Poziom	Na jakie pytanie odpowiada panel	Minimalny panel	Rytm	Właściciel
Zespół (tech lead)	Czy praca agentów bezpiecznie trafia na produkcję i gdzie utyka?	Wskaźnik zaakceptowanych zmian, czas do pierwszego review i czas w review, 14-dniowy wskaźnik poprawek, change fail rate dla usług zespołu	Co tydzień, na retro zespołu	Tech lead
Organizacja inżynierska (CTO, VP Engineering)	Czy system dostarczania się poprawia i czy jakość się trzyma?	Pięć metryk DORA per krytyczna usługa, odsetek nieudanych wdrożeń kohorty agentowej, defekty produkcyjne na 100 zmian, obciążenie review, tygodniowo aktywni użytkownicy agentów, wskaźnik zaufania deweloperów	Co miesiąc	VP Engineering, ze wskazanym właścicielem metryk
Zarząd i rada nadzorcza	Czy inwestycja się zwraca i czy ryzyko jest pod kontrolą?	Trend change lead time, trend change fail rate, koszt zaakceptowanej zmiany, zysk czasu netto z opisaną metodą, incydenty przypisane zmianom agentów	Co kwartał	CTO

Panel zarządu celowo nie zawiera metryk wykorzystania poza kontekstem. „Połowę naszego kodu pisze AI” to zdanie o adopcji; według DX średni udział kodu napisanego przez AI w ponad 400 firmach w II kwartale 2026 wynosił 51,9% (dane deklaratywne, DX, 2026-06-17). Liczba bliska średniej branżowej nie mówi zarządowi nic o zwrocie. Strukturę slajdów dla zarządu opisuje raportowanie inżynierii agentowej do zarządu.

Jak zbudować punkt odniesienia?

Metryka bez punktu odniesienia nie pokaże poprawy. Zbierz co najmniej pełny kwartał warstwy efektów, zanim cokolwiek zmienisz, albo odtwórz go z historii: git, platforma kodu i log wdrożeń zawierają większość potrzebnych danych.

1. Zapisz decyzję, której służy pomiar. Na przykład: „Do 2026-12-31 zdecydować, czy rozszerzyć licencje na agentów z czterech zespołów na wszystkie dwanaście”. We wskazówkach DORA to krok „Decide on why”. Bez niego zbierzesz wszystko i nie zrobisz z tym nic.

2. Odtwórz bazę dla metryk efektów. Wyciągnij pięć metryk DORA per usługa z ostatnich sześciu miesięcy oraz czas do pierwszego review i czas w review. Pierwszy prompt poniżej pozwala zlecić agentowi napisanie skryptu ekstrakcji.

3. Oznaczaj zmiany z udziałem agenta u źródła. Każdy zmergowany pull request potrzebuje znacznika, o który da się zapytać. Użyj atrybucji samego narzędzia tam, gdzie istnieje, a wszędzie indziej checkboksa w szablonie pull requesta, który dodaje etykietę agent-assisted. Szczegóły w zakładkach niżej.

4. Włącz telemetrię agentów. Kieruj dane o użyciu i koszcie do tego samego kolektora co dane o dostarczaniu, żeby metryki 1, 8 i 9 pochodziły z jednego miejsca.

5. Zdefiniuj reguły decyzyjne, zanim przyjdą dane. Na przykład: „Rozszerzamy, jeśli lead time spada, odsetek nieudanych wdrożeń kohorty agentowej mieści się w dwóch punktach procentowych od pozostałych, a koszt zaakceptowanej zmiany jest poniżej uzgodnionego progu”. Reguła zapisana wcześniej nie pozwala panelowi zamienić się w poszukiwanie dobrych wiadomości.

6. Przeglądaj w rytmie z tabeli paneli i zapisuj zmiany. Każdą zmianę procesu (nową bramkę, nowy model, reorganizację) zaznacz na osi czasu dashboardu, żeby przesunięcie metryki dało się powiązać z przyczyną. Do ustrukturyzowanej próby użyj pilotażu zaprojektowanego tak, by coś udowodnił.

Oznaczanie zmian z udziałem agenta w każdym narzędziu

Znacznik i telemetria różnią się między narzędziami. Metryki dostarczania już nie: pochodzą z platformy kodu i logu wdrożeń, niezależnie od tego, kto napisał kod.

Claude Code

Atrybucja. W planach Team i Enterprise, z zainstalowaną aplikacją Claude na GitHubie i włączoną analityką GitHub, Claude Code oznacza zmergowane pull requesty zawierające linie napisane z jego pomocą etykietą claude-code-assisted. Do atrybucji liczą się sesje od 21 dni przed do 2 dni po merge’u. Wyszukiwanie na GitHubie is:pr is:merged label:claude-code-assisted je wylistuje, co daje metrykę 2 bez API. Metryki wkładu są w publicznej becie, a linie, które człowiek przepisał w ponad 20%, nie są przypisywane. Nie są też dostępne dla organizacji z włączonym Zero Data Retention; użyj wtedy checkboksa w szablonie pull requesta.

Telemetria. Claude Code eksportuje metryki OpenTelemetry, m.in. claude_code.session.count, claude_code.pull_request.count, claude_code.commit.count, claude_code.cost.usage (USD) i claude_code.token.usage. Ustaw je dla wszystkich przez managed settings:

{
  "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"
  }
}

Żeby sprawdzić konfigurację, poszukaj w backendzie metryki claude_code.session.count po starcie sesji (dokumentacja monitoringu Claude Code, sprawdzona 2026-09-26 dla v2.1.283). Do metryki 8 używaj claude_code.cost.usage; claude_code.lines_of_code.count nie trafia na panel zarządu.

Codex

Atrybucja. Codex nie ma etykiety pull requestów, którą dało się zweryfikować 2026-09-26 (sprawdzone dla Codex CLI 0.157.1). Do metryki 2 użyj checkboksa w szablonie pull requesta i etykiety agent-assisted, a gałęziom tworzonym przez codex exec w CI dodawaj etykietę lub regułę nazewnictwa. Zanim zaufasz metryce 1 lub 8 dla użycia w CI, sprawdź, czy kolektor dostaje dane z uruchomień codex exec: otwarte zgłoszenie w openai/codex opisuje, że uruchomienia nieinteraktywne mogą nie emitować metryk.

Telemetria. Codex eksportuje logi, ślady i metryki przez tabelę [otel] w ~/.codex/config.toml. Eksportery przyjmują wartości none, statsig, otlp-http i otlp-grpc:

[otel]
environment = "prod"
log_user_prompt = false
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }

Nazwy pól pochodzą z OtelConfigToml w źródłach openai/codex (sprawdzone 2026-09-26). Zostaw log_user_prompt = false, dopóki przegląd prywatności nie zatwierdzi przechowywania promptów. Przestrzenie robocze ChatGPT Enterprise mają też dashboard analityczny Codeksa; zanim na nim zbudujesz, potwierdź jego API w dokumentacji administracyjnej OpenAI (nie zweryfikowano tu 2026-09-26).

Cursor

Atrybucja. Cursor dokumentuje zespołowy dashboard analityczny i API w planach Teams i Enterprise oraz, w Enterprise, AI Code Tracking API, które przypisuje linie wygenerowane przez AI do commitów. Aktualne limity planów i endpointy sprawdź w dokumentacji administracyjnej Cursora, zanim na nich zbudujesz (nie zweryfikowano tu 2026-09-26). Checkbox w szablonie pull requesta i etykieta agent-assisted działają niezależnie od planu.

Telemetria. Dashboard administracyjny wykorzystaj do metryki 1 (aktywni użytkownicy), a eksport rozliczeń do metryki 8. Śledzenie AI na poziomie linii zasila wyłącznie wykorzystanie: trzymaj je poza panelami wpływu i zarządu z tego samego powodu co „% kodu napisanego przez AI”.

Checkbox w szablonie pull requesta to jedyny znacznik wspólny dla wszystkich trzech narzędzi. Minimalna wersja dla .github/pull_request_template.md:

## Agent involvement
- [ ] An agent (Claude Code, Codex, Cursor or other) wrote or changed code in this PR
- [ ] A human reviewed the evidence (tests, acceptance criteria), not only the diff

Niewielka GitHub Action albo twój bot do merge’owania zamienia pierwszy checkbox w etykietę agent-assisted, więc metryka nie zależy od czyjejś pamięci.

Prompt do skopiowania: odtworzenie bazy DORA i review

Write a read-only script that reconstructs six months of delivery metrics for this repository, grouped by ISO week. Use `git log` and the GitHub API (via the `GH_TOKEN` environment variable) only; do not write to GitHub.

Compute per week:
- merged PRs, split into two cohorts: labelled `agent-assisted` or `claude-code-assisted` vs all others
- median and p90 time from PR open to first review, and from first review to merge
- median PR size in changed lines, per cohort
- 14-day follow-up fix rate: share of merged PRs that were reverted, or referenced by a later PR whose title starts with "fix", within 14 days of merge
- deployments per week and change lead time, reading deploys from the GitHub Deployments API for the `production` environment

Output a CSV and a one-page Markdown summary. Mark every number that relies on a heuristic (such as the "fix" title rule) and list the heuristics at the top. Do not report any metric per individual engineer. Before finishing, spot-check five PRs by hand against the script's output and show the comparison.

Prompt do skopiowania: audyt dashboardu AI pod kątem metryk na pokaz (vanity metrics)

Here is the list of metrics on our engineering AI dashboard, with their definitions and data sources: [paste the list].

Classify each metric as utilization, impact or cost. For each one, answer:
1. Can an agent raise this number without improving delivery or quality? If yes, explain how.
2. Is it paired on the same view with a stability metric (change fail rate, deployment rework rate, follow-up fix rate or escaped defects)?
3. Is it reported per individual engineer? If so, flag it for removal.
4. Is the baseline period and the comparison cohort stated?

Then propose the smallest replacement panel for our CTO (at most eight metrics), using these definitions: accepted change rate, agent cohort change fail rate, 14-day follow-up fix rate, review load, escaped defects per 100 merged changes, cost per accepted change, net time gain, developer trust score, plus DORA's five delivery metrics. Output a table: metric, keep/replace/remove, reason.

Jak udowodnić, że liczby są prawdziwe?

Program pomiaru potrzebuje własnej weryfikacji, inaczej dashboard staje się najsłabiej sprawdzanym artefaktem w firmie.

• Co miesiąc uzgadniaj dane ze źródłem. Wybierz losowo dziesięć zmergowanych pull requestów i ręcznie sprawdź etykietę, lead time i powiązanie z poprawką. Rozbieżność częstsza niż raz na dziesięć oznacza błąd w logice ekstrakcji, a nie w zespołach.
• Na każdym widoku trzymaj metrykę stabilności. Slajd z metryką 2 lub 3 bez metryki 4 lub 5 nie wychodzi.
• Porównuj kohorty i nazywaj czynniki zakłócające. Agentów często pierwsze wdrażają najmocniejsze zespoły. Przy każdym porównaniu zapisz zespół, usługę i okres i nie wyciągaj wniosków przyczynowych z wykresu „przed i po”.
• Traktuj deklaracje jak hipotezę. W randomizowanym badaniu METR z 2025 roku doświadczeni deweloperzy open source spodziewali się, że AI przyspieszy ich o 24%, a po tym, jak zadania zajęły im o 19% dłużej, nadal uważali, że przyspieszyło ich o 20% (METR, 2025-07-10, narzędzia z początku 2025). Dlatego zysk czasu netto (metryka 9) zawsze odejmuje zmierzony czas review i poprawek.
• Wskaż, kto zatwierdza. VP Engineering co miesiąc zatwierdza panel organizacji, a wskazany właściciel metryk (często w zespole platformowym) odpowiada za definicje. Każda zmiana definicji z tej strony przechodzi przez tę osobę i dostaje datę na dashboardzie.

Potoki telemetrii i dashboardy opisuje szczegółowo obserwowanie agentów w działaniu. Wskaźniki wyprzedzające dla poszczególnych etapów, które zasilają te metryki, znajdziesz w metrykach AI-native SDLC.

Co się psuje, gdy mierzysz inżynierię wspieraną przez AI?

Zespół zaczyna optymalizować liczbę pull requestów. Gdy przepustowość PR-ów trafia do celów lub ocen okresowych, agenci pozwalają ją napompować bez wysiłku. Wyjście: usuń liczbę PR-ów ze wszystkich celów, raportuj wskaźnik zaakceptowanych zmian i zapisz w karcie programu pomiaru, że żadnej metryki z tej strony nie używa się do oceny pojedynczych osób.

„% kodu napisanego przez AI” staje się celem. Nakaz podnoszenia udziału AI nagradza przepychanie pracy przez agentów bez względu na to, czy pasuje. Wyjście: przenieś metrykę do sekcji wykorzystania na dashboardzie, usuń z niej wszelkie cele i zastąp cel celem dotyczącym lead time albo jakości.

Przepustowość rośnie, a stabilność spada. Lead time maleje, a change fail rate i deployment rework rate powoli rosną, czyli dokładnie wzorzec, który DORA opisała za 2025 rok. Wyjście: wstrzymaj rozszerzanie zakresu agentów w dotkniętych usługach, najpierw przeanalizuj awarie kohorty agentowej i wzmocnij bramki, zaczynając od pakietu dowodów, który musi nieść każda zmiana.

Review staje się wąskim gardłem, którego nikt nie mierzy. Zmergowanych pull requestów przybywa, ale czas w review rośnie, a ciężar niesie kilku seniorów. Wyjście: dodaj obciążenie recenzentów do panelu zespołu, ustal budżety rozmiaru PR i zobacz, jak utrzymać ruch w kolejce review.

Atrybucja znika. Ustawienie prywatności albo nowe narzędzie usuwa znacznik agenta i metryka 2 z dnia na dzień spada do zera. Wyjście: zachowaj checkbox w szablonie pull requesta jako znacznik zapasowy i oznaczaj każdy tydzień, w którym zmieniło się źródło znacznika.

Średnie z portfela ukrywają problem. Uśredniony change fail rate z 40 usług wygląda stabilnie, a dwie krytyczne usługi się pogarszają. Wyjście: raportuj metryki DORA per usługa, jak zaleca DORA, i pokazuj na panelu organizacji trzy najsłabsze usługi.

Dokąd dalej z metrykami

Jeśli pomysł mierzenia zaakceptowanych zmian zamiast produkcji jest dla twojego zespołu kierowniczego nowy, zacznij od czytania dowodów zamiast kodu. Potem wybierz stronę dla swojej następnej decyzji.

Samoocena według modelu DORA AI Capabilities Oceń gotowość organizacji w siedmiu zdolnościach AI według DORA.

Pilotaż, który coś udowadnia Zamień te metryki w próbę z bazą, kohortami i regułą decyzyjną.

Ekonomia inżynierii agentowej Połącz koszt zaakceptowanej zmiany z metodą ROI, którą przyjmie dział finansów.

Panel metryk AI Pytanie Q22 z CTO Scorecard: dowody na maksymalny wynik, wymiar kontroli i lista kryteriów akceptacji panelu.