Panel metryk AI — mierz zaakceptowane dostarczanie

Poziom 2 Poradnik Zaktualizowano 2026-09-26

Panel metryk AI w pytaniu Q22 CTO Scorecard dostaje pełne trzy punkty za dowolne trzy z sześciu opcji, ale na właściwe pytanie odpowiada tylko zestaw miary jakości, miary przepływu i miary kosztu, raportowanych dla tej samej pracy. Przepustowość i adopcja należą do panelu jako kontekst, nigdy jako dowód, że dostarczanie się poprawiło.

Ta strona jest dla CTO lub VP Engineering, który odpowiedział na Q22 („Co mierzysz w obszarze AI tooling?”), i dla tech leada, który musi te liczby dostarczyć. Typowa sytuacja: dashboard pokazuje wydatki na licencje, pull requesty na dewelopera i aktywnych użytkowników, wszystko rośnie. Potem przegląd incydentu znajduje dwie zmiany napisane przez agenta, których nikt uważnie nie przeczytał, i nikt nie potrafi powiedzieć, czy poprawiło się dostarczanie, czy tylko wolumen. Ta strona pokazuje, które opcje już masz, czego każdej brakuje i jak zamienić je w panel, który przetrwa to pytanie. Kanoniczne definicje metryk są na stronie frameworki metryk; tutaj ich nie powtarzamy.

Co daje ten klucz do Q22

Tabelę, która przypisuje każdą z sześciu opcji Q22 do kanonicznej metryki, w którą powinna się zmienić, i do metryki, z którą trzeba ją zestawić.
Zestaw trzech opcji do raportowania na start, z danymi pokazującymi, dlaczego sama przepustowość wprowadza w błąd.
Szablon karty metryki, który możesz zacommitować do repozytorium jako plik definicji panelu.
Źródła danych o wydatkach i użyciu w Claude Code, Codex i Cursorze.
Dwa prompty do skopiowania, procedurę weryfikacji i typowe sposoby, w jakie panel zaczyna kłamać.

Ile jest wart każdy wybór w Q22 i czego mu brakuje

Q22 to pytanie wielokrotnego wyboru w sekcji „Strategia i ROI” CTO Scorecard: każda opcja daje jeden punkt, maksymalnie trzy. Wynik nie odróżnia zrównoważonego panelu od trzech liczników aktywności. Tabela odróżnia. Znajdź zaznaczone opcje i czytaj wiersz.

Opcja Q22	Punkty	Co mówi sama	Zamień ją w	Raportuj obok
Spend — $/dev/miesiąc	1	Ile kosztują licencje, a nie co za nie kupiono	Koszt zaakceptowanej zmiany ze wszystkimi składnikami z metody ekonomicznej	Wskaźnik zaakceptowanych zmian
Throughput — PR/dev/tydzień	1	Ile wyprodukowali agenci; rośnie niezależnie od wartości	Wskaźnik zaakceptowanych zmian per repozytorium i kohorta, nigdy per inżynier	14-dniowy wskaźnik poprawek
Quality — regression rate, revert rate	1	Czy szybsza praca też się trzyma	Change fail rate kohorty agentowej, 14-dniowy wskaźnik poprawek, defekty na produkcji na 100 zmergowanych zmian	Każdą metrykę szybkości w tym samym widoku
Adoption — % aktywnych użytkowników, średnia liczba sesji	1	Czy ludzie używają narzędzi; liczba sesji to czysta aktywność	Tygodniowo aktywni użytkownicy agentów; liczbę sesji usuń	Wskaźnik zaufania deweloperów
Review-to-merge time	1	Gdzie praca agenta czeka na ludzi	Obciążenie review: mediana i p90 czasu do pierwszego review i czasu w review	Udział review na recenzenta
Cost-per-feature — koszt tokenów per ticket	1	Częściowy koszt jednostkowy bez review, poprawek i CI	Koszt zaakceptowanej zmiany	Change fail rate

Kluczowe jest słowo „zaakceptowana”. Zmiana liczy się jako dostarczona, gdy została zmergowana i nie była wycofana ani poprawiana w ciągu 14 dni. To okno ustala dla całego serwisu strona frameworki metryk. Szybki szkic, który czeka trzy dni na review albo wraca jako revert, nie przyspieszył dostarczania.

Które trzy opcje Q22 tworzą działający panel?

Na start raportuj quality, review-to-merge time i cost-per-feature, każdą przerobioną tak, jak mówi tabela. Razem odpowiadają na trzy pytania osoby, która trzyma budżet: czy to się trzyma, gdzie praca czeka i ile kosztowała każda zaakceptowana zmiana. Przepustowość i adopcję dodaj później jako wiersze kontekstowe, każdą z jej zabezpieczeniem jakości.

Jakość idzie pierwsza, bo przepustowość i jakość potrafią w tej samej organizacji ruszyć w przeciwnych kierunkach. Raport Faros AI „AI Engineering Report 2026” (kwiecień 2026), oparty na dwóch latach telemetrii od 22 000 deweloperów, pokazuje wzrost przepustowości zadań na dewelopera o 33,7%. Te same dane pokazują wzrost liczby błędów na dewelopera o 54% i mediany czasu w review o 441,5%. To telemetria dostawcy z samowybierającej się bazy klientów, a nie badanie kontrolowane, ale pokazuje dokładnie ten wzorzec, którego panel oparty tylko na przepustowości nie zobaczy. DX pokazuje tę samą presję na review z innej strony: mediana rozmiaru pull requesta wzrosła z 44 do 72 linii między lipcem 2025 a czerwcem 2026 (DX, 2026-06-17).

Raport DORA 2025 ujmuje ogólną zasadę w jednym zdaniu: „AI doesn’t fix a team; it amplifies what’s already there” (Google Cloud, 2025-09-23). Panel istnieje po to, by pokazać, co z tych dwóch stało się w twoich zespołach.

Jak postawić panel w cztery tygodnie?

Punkt odniesienia, oznaczanie zmian z udziałem agenta i konfigurację telemetrii krok po kroku opisuje strona frameworki metryk. Tu jest kolejność ich wykonania pod Q22.

Tydzień 1: najpierw zapisz decyzję. Jedno zdanie z datą: „Do 2026-12-31 decydujemy, czy rozszerzyć licencje na agentów z czterech zespołów na wszystkie dwanaście”. Każda metryka w panelu musi móc zmienić tę decyzję; usuń te, które nie mogą.
Tydzień 1: zamroź trzy karty metryk. Zacommituj po jednej karcie na metrykę, według szablonu poniżej, do repozytorium z raportowaniem inżynieryjnym. Zmiana definicji po starcie okresu unieważnia porównanie.
Tydzień 2: oznacz zmiany z udziałem agenta. Użyj atrybucji samego narzędzia tam, gdzie istnieje, a wszędzie indziej checkboxa w szablonie pull requesta, który dodaje etykietę agent-assisted. Wtedy każda metryka dzieli się na dwie kohorty.
Tydzień 3: odtwórz punkt odniesienia. Pobierz co najmniej kwartał historii z gita, platformy kodu i logu wdrożeń dla tych samych repozytoriów. Odtworzony punkt odniesienia oznacz jako odtworzony.
Tydzień 4: zapisz regułę decyzji przed pierwszym raportem. Na przykład: „Rozszerzamy, jeśli p90 czasu w review nie wzrośnie o więcej niż 20%, a 14-dniowy wskaźnik poprawek kohorty agentowej pozostanie w granicach dwóch punktów procentowych od drugiej kohorty”. Progi ustalasz sam; chodzi o to, by miały datę sprzed pierwszego wyniku.
Od tygodnia 4: przeglądaj co miesiąc i adnotuj. Na osi czasu panelu zapisuj każdą zmianę kadrową, nową bramkę, zmianę modelu i zamrożenie wydań, by każdą zmianę metryki dało się powiązać z przyczyną.

Karta metryki do wdrożenia bez zmian

Jeden plik YAML na metrykę trzyma definicję, właściciela i regułę decyzji w systemie kontroli wersji, gdzie każda zmiana przechodzi przez review jak każda inna.

# reporting/ai-panel/review-load.yaml (one file per panel metric)
id: review-load
q22_option: review-time
name: Time to first review and time in review
definition: >
  Median and p90 hours from pull request opened to first review, and from
  first review to merge, for merged pull requests in the period.
unit: hours
source: code host pull request events, read with a read-only token
cohorts: [agent-assisted, other]
segment_by: [repository, risk_class]
paired_with: follow-up-fix-rate-14d
baseline: 2026-Q2, reconstructed from history
cadence: monthly
definition_owner: VP Engineering
pipeline_owner: platform team
missing_data: shown as a gap, never as zero
never_reported: per engineer
decision_rule: >
  Expand agent seats if p90 time in review rises by no more than 20% while the
  agent cohort's 14-day follow-up fix rate stays within 2 percentage points of
  the other cohort.

Skopiuj ją dla dwóch pozostałych metryk i zmień id, q22_option, definition, source oraz paired_with. Linia segment_by: risk_class sprawia, że zmiana w dokumentacji nie uśrednia się z migracją płatności.

Skąd w każdym narzędziu biorą się dane o wydatkach i użyciu?

Opcje quality i review-to-merge time pochodzą z platformy kodu, CI i systemu incydentów, tak samo dla każdego narzędzia. Różnią się tylko dane o wydatkach, koszcie i adopcji. Pełna konfiguracja telemetrii jest na stronach frameworki metryk i obserwowalność agentów.

Per deweloper: /usage w sesji pokazuje koszt sesji, limity planu i aktywność.
Per organizacja: ustaw CLAUDE_CODE_ENABLE_TELEMETRY=1 i zmienne eksportera OTEL_* w zarządzanych ustawieniach (managed settings), a potem czytaj claude_code.cost.usage (USD) z kolektora do karty kosztu.
Kohorty: w planach Team i Enterprise z aplikacją Claude na GitHubie i włączoną analityką GitHub zmergowane pull requesty z przypisanymi liniami dostają etykietę claude-code-assisted. Metryki wkładu (contribution metrics) są w publicznej becie i niedostępne przy Zero Data Retention, więc zostaw checkbox w szablonie jako rezerwę.

Per deweloper: /usage w TUI Codeksa.
Per organizacja: tabela [otel] w ~/.codex/config.toml eksportuje logi, ślady i metryki (metrics_exporter przyjmuje none, statsig, otlp-http lub otlp-grpc; sprawdzone w codex-rs/config/src/types.rs w openai/codex 2026-09-26, CLI 0.157.1). Zgłoszenie w openai/codex (#12913) opisywało, że przebiegi codex exec nie emitowały metryk, więc użycie w CI bierz z rozliczeń API, dopóki nie potwierdzisz danych w kolektorze.
Kohorty: 2026-09-26 nie dało się zweryfikować żadnej etykiety pull requesta (Codex CLI 0.157.1); użyj checkboxa agent-assisted w szablonie.

Per organizacja: panel administracyjny zespołu i eksport rozliczeń zasilają karty wydatków i adopcji. API analityki i śledzenia kodu Cursora nie dało się zweryfikować 2026-09-26 (cursor.com był nieosiągalny), więc przed budową na nich sprawdź limity planu i endpointy w dokumentacji administracyjnej Cursora.
Kohorty: checkbox agent-assisted w szablonie działa w każdym planie.

Szybki szacunek wydatków dla wielu narzędzi z jednej maszyny daje npx ccusage@latest monthly --json: czyta lokalne logi Claude Code, Codeksa i innych agentów (ccusage 20.0.26 w npm, 2026-09-26). Wycenia tokeny po stawkach API, więc przy subskrypcji szacuje wartość użycia, a nie fakturę. Kartę kosztu uzgadniaj z tym, co faktycznie zapłacił dział finansów.

Prompty do skopiowania dla panelu Q22

I am answering CTO Scorecard Q22: "What do you measure for AI tooling?"
The options are: spend ($/dev/month), throughput (PR/dev/week), quality (bug
regression rate, revert rate), adoption (active-user %, session count),
review-to-merge time, and cost-per-feature (token cost per feature ticket).

Read the attached dashboard export and its metric definitions. For each metric:
1. Map it to one Q22 option, or to NONE.
2. Say whether an agent could raise it without improving delivery or quality.
3. Say whether it is paired on the same view with a quality metric (change fail
   rate, revert or follow-up fix rate, escaped defects).
4. Say whether it is split into agent-assisted and other changes, and whether it
   is ever reported per individual engineer (flag that for removal).
5. State the baseline period, or write MISSING.

Then recommend the three metrics to report first: one quality, one flow, one
cost, with the definition change each one needs. Do not invent a number that is
not in the material.

Write three metric card files under reporting/ai-panel/ using this YAML shape:
id, q22_option, name, definition, unit, source, cohorts, segment_by, paired_with,
baseline, cadence, definition_owner, pipeline_owner, missing_data,
never_reported, decision_rule.

The three metrics:
- quality: 14-day follow-up fix rate (merged PRs reverted, or referenced by a
  later fix PR, within 14 days of merge / merged PRs)
- review-time: median and p90 time to first review and time in review
- cost-per-feature: cost per accepted change (all agent spend in the period /
  PRs merged and not reverted or fixed within 14 days)

Inspect this repository's CI config, PR template and labels to fill in `source`
with the real system and label names. Where a source does not exist yet, write
TODO and the smallest step that would create it. Cohorts are always
agent-assisted vs other. Never report per engineer. Leave decision_rule
thresholds as TODO for me to set; do not choose them.

Jak zweryfikować panel, nie ufając dashboardowi?

Nikt nie powinien przeglądać każdego wiersza, żeby zaufać panelowi. Panel jest wiarygodny, gdy co miesiąc przechodzi te kontrole.

Sprawdź próbkę ręcznie. Wylosuj 10 zmergowanych pull requestów i ręcznie zweryfikuj etykietę kohorty, czasy review oraz każde powiązanie z revertem lub poprawką. Więcej niż jedna niezgodność na 10 oznacza błąd w logice ekstrakcji.
Uzgodnij koszt. Karta kosztu zgadza się z tym, co finanse zapłaciły za licencje, użycie i CI. Rozbieżność zwykle oznacza klucz API rozliczany poza raportami samych narzędzi.
Sprawdź parowanie. Żadna liczba szybkości ani przepustowości nie pojawia się w widoku bez partnera jakościowego. Slajd, który łamie tę zasadę, nie trafia do prezentacji.
Pokazuj braki danych. Tydzień bez danych jest rysowany jako luka. Panel, który wypełnia luki zerami, pokazuje poprawę, która nigdy nie nastąpiła.
Nazwij, kto zatwierdza. VP Engineering co miesiąc zatwierdza panel, a właściciel definicji akceptuje każdą zmianę karty metryki przez pull request.

Co sprawia, że panel metryk AI kłamie?

Pull requesty na dewelopera stają się celem. Agenci pozwalają tanio pompować tę liczbę, a za nią rosną kolejki review. Jak to naprawić: usuń przepustowość ze wszystkich celów i ocen okresowych, zastąp ją wskaźnikiem zaakceptowanych zmian per repozytorium i zapisz w statucie panelu, że żadna metryka nie służy do oceny pojedynczych osób.

Liczone są tylko udane przebiegi agenta. Kohorta pomija porzucone sesje, odrzucone pull requesty i reverty, więc kohorta agentowa wygląda lepiej, niż jest. Jak to naprawić: licz od otwartych, a nie zmergowanych pull requestów i wliczaj każdy revert do mianownika.

Cost-per-feature liczy tylko tokeny. Koszt tokenów na ticket wygląda na mały, bo brakuje review, poprawek i CI. Jak to naprawić: przejdź na koszt zaakceptowanej zmiany ze składnikami z metody ekonomicznej, a koszt tokenów raportuj jako jedną linię w jego ramach.

Grupą porównawczą są wcześni użytkownicy. Zespoły, które pierwsze wdrażają agentów, to często najmocniejsze zespoły, więc ich wyniki były lepsze, zanim pojawiły się narzędzia. Jak to naprawić: porównuj każdy zespół z jego własnym punktem odniesienia, zapisz czynnik zakłócający i zanim ogłosisz związek przyczynowy, przeprowadź pilotaż na dopasowanych kohortach.

Panel kończy się na dashboardzie. Liczby są przeglądane i nic się nie zmienia. Jak to naprawić: dołącz datowaną regułę decyzji do każdej karty i omawiaj panel wyłącznie na spotkaniu, na którym zapada decyzja, do której został zbudowany.

Dokąd dalej po Q22

Q22 dostarcza pomiarów; Q23 zamienia je w odpowiedź o ROI, a zestaw dla zarządu w raport kwartalny.

Frameworki metryk Kanoniczne definicje metryk AI, minimalny panel na każdy poziom i instrumentacja per narzędzie.

Q23 · Pomiar ROI Zamień panel w odpowiedź o ROI bez zawyżania przyczynowości.

Projekt pilotażu, który czegoś dowodzi Dopasowane kohorty, rejestr czynników zakłócających i reguła decyzji podpisana z góry.

Raportowanie zarządowi Które z tych liczb trafiają do zarządu i jak często.