Metryki AI-native SDLC

Metryki AI-native SDLC łączą na każdym etapie cyklu życia jeden wskaźnik wyprzedzający, który reaguje w ciągu kilku dni od zmiany procesu, z jednym opóźnionym wynikiem jakości lub niezawodności, który nie może się pogorszyć. Oba pochodzą z danych, które zespół już ma: historii gita plików intent.md, spec.md i plan.md, metadanych pull requestów, przebiegów CI, wdrożeń i trackera incydentów.

Twój zespół wdrożył łańcuch artefaktów dwa miesiące temu. Pull requesty mergują się szybciej, tech lead mówi, że review stało się cięższe, a nikt nie potrafi wskazać, który etap zwalnia ani czy jakość się trzyma. Dashboard DORA zmienia się raz na kwartał, czyli o wiele za późno, żeby ci powiedzieć, że specyfikacje są przepisywane w połowie budowania.

Ta strona jest dla dewelopera, który prowadzi AI-native cykl życia w repozytorium, i dla tech leada, który raportuje wyniki jednego zespołu. Opisuje sygnały na poziomie etapów. Definicje organizacyjne, które te sygnały zasilają, takie jak accepted change rate czy koszt zaakceptowanej zmiany, mają jedną kanoniczną stronę: DORA, SPACE, DX Core 4 i pomiar AI.

Co dają metryki na poziomie etapów cyklu

• Tabelę z jednym wskaźnikiem wyprzedzającym i jednym opóźnionym dla każdego etapu i praktyki oraz miejscem, gdzie leżą dane.
• Cztery konwencje w repozytorium, dzięki którym każdą metrykę etapu policzysz git log i API swojego hostingu kodu.
• Tabelę decyzyjną, która zamienia liczby z jednego tygodnia na jedno działanie.
• Trzy prompty do skopiowania: pierwszy pisze skrypt ekstrakcji, drugi diagnozuje tydzień danych, trzeci mierzy, czy plik instrukcji działa.
• Sposób na udowodnienie, że liczby są prawdziwe, oraz błędy, przez które kłamią.

Jak wskaźniki wyprzedzające i opóźnione działają razem?

Wskaźnik wyprzedzający reaguje w ciągu godzin lub dni od zmiany jednej praktyki: zacznij commitować plan.md przed implementacją, a czas od planu do zmergowanego pull requestu przesunie się w tym samym tygodniu. Wskaźnik opóźniony to wynik jakości lub niezawodności, który ujawnia się po tygodniach: poprawki, defekty, które uciekły na produkcję, change fail rate.

Czytaj je zawsze parami, nigdy osobno. Praktyka działa, gdy jej wskaźnik wyprzedzający się poprawia, a opóźniony się utrzymuje albo też poprawia. Argumentem za parowaniem jest raport DORA 2025 (Google Cloud, 2025-09-23), który stwierdził „a positive relationship between AI adoption on both software delivery throughput and product performance”, a w następnym zdaniu: „AI adoption does continue to have a negative relationship with software delivery stability”. Panel, który pokazuje tylko szybkość, przekazuje połowę tego wniosku.

Wskaźnik wyprzedzający	Wskaźnik opóźniony	Co to znaczy	Co zrobić w tym tygodniu
Poprawia się	Utrzymuje się lub poprawia	Praktyka działa	Zostaw ją; zacznij mierzyć następny etap
Poprawia się	Pogarsza się	Automatyzacja ominęła bramkę zamiast przez nią przejść	Wstrzymaj rozszerzanie zakresu agentów na tym etapie; zaostrz sprawdzanie dowodów na bramce
Stoi w miejscu	Utrzymuje się	Praktyka nie jest używana albo dane jej nie widzą	Sprawdź pokrycie znacznikami (patrz sekcja o weryfikacji), zanim obwinisz zespół
Pogarsza się	Poprawia się	Bramka jest szczelna, ale wolna	Zautomatyzuj sprawdzanie dowodów, żeby człowiek czytał wnioski, nie cały artefakt

Który wskaźnik należy do którego etapu cyklu?

Każdy wiersz to jedna praktyka z cyklu życia. Kolumna ze źródłem wskazuje system, który już przechowuje znaczniki czasu, więc żaden z tych wskaźników nie wymaga nowego produktu analitycznego.

Etap i praktyka	Wskaźnik wyprzedzający	Wskaźnik opóźniony	Gdzie leżą dane
Plan: zapis intent.md	Czas od pierwszej prośby do zacommitowanego intent.md	Odsetek intencji przyjętych do projektowania wobec zamkniętych; edycje intent.md po pierwszym commicie spec.md	Historia gita folderu z intencjami
Design: pisanie spec.md	Czas od commitu intent.md do commitu zaakceptowanego spec.md	Commity spec.md z datą późniejszą niż pierwszy commit plan.md tej samej zmiany (poprawki wymagań)	Git log
Build: tryb planowania, potem implementacja	Odsetek zmian mergowanych po pierwszym przejściu implementacji; czas od akceptacji planu do zmergowanego pull requestu	Cykle poprawek na zmianę; jak często zmergowany diff wciąż zgadza się z listą plików w plan.md	Metadane pull requestów, wyniki przeglądu dryfu
Build: plik instrukcji (CLAUDE.md, AGENTS.md, Rules w Cursorze)	Komentarze w review powtarzające błąd, któremu plik powinien zapobiec	Czas do pierwszego zmergowanego pull requestu nowej osoby w zespole	Komentarze z review; historia gita pliku instrukcji
Build: skills	Czas od akceptacji właściciela polityki do merge’a zaktualizowanego skilla	Uwagi z review powołujące się na tę politykę, których powinno ubywać do zera	Pull requesty w folderze skills
Build: równoległe sesje	Rozpoczęte sesje na inżyniera dziennie (średnia zespołu, nigdy w rozbiciu na osoby) i szczytowa liczba sesji równoległych przy utrzymanym odsetku merge’y po pierwszym przejściu	Zmergowane zmiany na repozytorium na tydzień, czytane obok cykli poprawek	Telemetria agentów; historia pull requestów
Test: pętla feedbacku sesji	Odsetek zmian od agenta, które przechodzą CI za pierwszym razem	Czas w review na pull request; change fail rate	Przebiegi CI; metadane pull requestów
Test: ciągłe ewaluacje	Odsetek zaliczonych ewaluacji po każdej zmianie konfiguracji; czas, w jakim incydent staje się ewaluacją	Regresje złapane w CI wobec złapanych na produkcji	Wyniki zestawu ewaluacji; tracker incydentów
Deploy: review przez agenta	Czas do pierwszego review; odsetek wątków review zamkniętych przez agenta-autora bez commitu człowieka	Defekty i podatności złapane przed merge’em wobec złapanych na produkcji	Hosting kodu; tracker incydentów
Deploy: hooki jako bramki akceptacji	Czas oczekiwania każdej zmiany na każdej bramce	Naruszenia bramek, które docierają na produkcję, przed hookami i po nich	Logi hooków; tracker incydentów
Deploy: CI/CD	Odsetek awarii pipeline’u obsłużonych bez wzywania człowieka	Metryki dostarczania DORA, osobno dla każdej usługi	CI i narzędzia wdrożeniowe
Maintain: zamknięcie pętli	Czas od przekroczenia pasma kontrolnego do intent.md w triażu	Odsetek wykryć, które kończą się zmergowaną poprawką; powtórne incydenty tej samej klasy	Log skryptu detekcji; historia pull requestów
Maintain: planowe skany	Odsetek repozytoriów objętych harmonogramem; czas od wykrycia do poprawki w review	Podatności znalezione przez skan wobec znalezionych na produkcji lub zgłoszonych z zewnątrz	Historia skanów; tracker incydentów

Ostatni wiersz etapu Deploy celowo odsyła do DORA. Pięć metryk dostarczania (change lead time, deployment frequency, failed deployment recovery time, change fail rate i deployment rework rate) definiuje strona o frameworkach metryk, a ta strona ich nie powtarza.

Jak policzyć metryki cyklu z historii gita?

Większość metryk etapów to czas między dwoma commitami albo liczba commitów po określonej dacie. Da się je policzyć tylko wtedy, gdy artefakty trafiają do repozytorium w chwili akceptacji i w przewidywalnym miejscu.

1. Daj każdej zmianie jeden folder. Trzymaj intent.md, spec.md i plan.md danej zmiany razem, na przykład w intent/notifications-digest/. Uwaga o umieszczaniu plików w opisie łańcucha artefaktów omawia monorepo i intencje obejmujące wiele repozytoriów.

2. Commituj artefakt w chwili akceptacji, nie na końcu. Znacznik czasu commitu, który dodaje plik, jest zegarem etapu. spec.md zacommitowany razem z implementacją zeruje czas projektowania i odbiera metryce sens. Squash merge robi to samo po fakcie: skleja commity intent.md, spec.md, plan.md i kodu z gałęzi w jeden commit na main, a git log na main nie odzyska już osobnych znaczników czasu. Jeśli mergujesz przez squash, scalaj każdy zaakceptowany artefakt osobnym małym pull requestem, używaj dla gałęzi zmian merge commitów albo rebase merge, albo czytaj znaczniki czasu commitów z listy commitów pull requestu przez API hostingu kodu (w GitHubie GET /repos/{owner}/{repo}/pulls/{pull_number}/commits), a nie z main.

3. Wpisz identyfikator zmiany do pull requestu. Linia Change: notifications-digest w opisie pull requestu łączy dane z hostingu kodu z folderem artefaktów. Check w CI, który blokuje pull request bez tej linii, pilnuje, żeby połączenie się nie rozsypało.

4. Oznaczaj zmiany od agenta i poprawki. Pull requesty współtworzone przez agenta dostają etykietę (agent-assisted albo, tam gdzie jest włączona, własną etykietę Claude Code claude-code-assisted). Wycofania rób przez git revert, którego komunikat wskazuje wycofany commit. Commity naprawcze niosą trailer Follow-up: #PR z numerem pull requestu, który naprawiają.

Z tymi konwencjami gitowa część tabeli to trzy polecenia uruchamiane w terminalu w katalogu głównym repozytorium:

# Kiedy każdy artefakt trafił pierwszy raz do repozytorium: zegar etapu dla każdej zmiany
# (%cI to data committera, ten sam zegar, który czyta --since)
git log --diff-filter=A --reverse --format='%h %cI' --name-only -- \
  'intent/*/intent.md' 'intent/*/spec.md' 'intent/*/plan.md'

# Poprawki wymagań jednej zmiany: commity spec.md po pierwszym commicie plan.md
CHANGE=notifications-digest
FIRST_PLAN=$(git log --diff-filter=A --format=%H -- "intent/$CHANGE/plan.md" | tail -1)
git log --oneline "$FIRST_PLAN"..HEAD -- "intent/$CHANGE/spec.md"

# Wycofania i poprawki naprzód z ostatnich 30 dni
git log --since=30.days --grep='^This reverts commit' --format='%h %cI %s'
git log --since=30.days --format='%h %(trailers:key=Follow-up,valueonly,separator=%x2C)' | awk 'NF>1'

Wszystkie trzy polecenia czytają datę committera, więc rebase przesuwa zegar commitu na chwilę jego przepisania; licz więc z historii, którą mergujesz, a nie z gałęzi, która wciąż jest rebase’owana. Polecenie o poprawkach liczy tylko commity spec.md, które w historii następują po pierwszym commicie plan.md: edycja spec.md w tym samym commicie, który dodaje plan.md, nie jest poprawką, a zakres $FIRST_PLAN..HEAD ją pomija.

Dane o pull requestach, CI i wdrożeniach pochodzą z API hostingu kodu. Zamiast pisać tę część ręcznie, zleć agentowi napisanie całej ekstrakcji jako jednego skryptu promptem poniżej i zacommituj wynik.

Prompt do skopiowania: skrypt ekstrakcji metryk etapów

Write a read-only script, scripts/lifecycle-metrics.py, that computes our AI-native SDLC stage metrics per ISO week for the last 26 weeks. Do not write to git or to GitHub. Read the GitHub token from the GH_TOKEN environment variable.

Conventions in this repository:
- Each change has a folder intent/<change-id>/ holding intent.md, spec.md and plan.md. The commit that first adds a file is that stage's timestamp. If main is squash-merged, read those commit timestamps from each PR's commit list (GET /repos/{owner}/{repo}/pulls/{pull_number}/commits), not from git log on main.
- Pull requests carry a "Change: <change-id>" line in the description, and agent-assisted ones carry the label agent-assisted or claude-code-assisted.
- Reverts are `git revert` commits; fix-forward commits carry a "Follow-up: #<pr>" trailer.

Compute per week, split into agent-assisted and other pull requests:
1. Design lead time: intent.md commit to spec.md commit (median, p90).
2. Requirements rework: spec.md commits dated after the first plan.md commit, per change.
3. First-pass merge share: merged PRs with no follow-up or revert within 14 days and no more than one review round.
4. Time to first review and time in review (median, p90).
5. First-pass CI success rate: PRs whose first CI run on the first pushed commit passed.
6. Marker coverage: share of merged PRs that have a Change line and share that have an agent label.

Output a CSV with one row per week and metric, and a short Markdown summary. Never group by author. Mark every heuristic (such as "one review round") at the top of the summary. Add unit tests that run the script against a small fixture repository you create in a temp directory, and show the test output. Then spot-check five real PRs by hand against the CSV and show the comparison.

Gdzie każde narzędzie zapisuje dane o sesjach?

Każda metryka etapu z tabeli pochodzi z gita, hostingu kodu, CI i trackera incydentów, więc jest taka sama niezależnie od tego, który agent napisał kod. Od narzędzia zależą tylko dwa wiersze: równoległe sesje i znacznik zmian od agenta. Pełny pomiar, łącznie z kosztami, opisuje strona o frameworkach metryk.

Claude Code

Claude Code eksportuje metryki i zdarzenia OpenTelemetry, gdy telemetria jest włączona. Ustaw ją dla całego zespołu w managed settings. claude_code.session.count liczy rozpoczęte sesje, a nie sesje działające jednocześnie: odczytuj z niej liczbę rozpoczętych sesji na inżyniera dziennie, a równoległość wyprowadzaj z nakładającej się aktywności session.id w eksportowanych zdarzeniach:

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

W planach Team i Enterprise, z zainstalowaną aplikacją Claude dla GitHuba i włączoną analityką GitHuba, zmergowane pull requesty z liniami współtworzonymi przez Claude Code dostają etykietę claude-code-assisted. Metryki wkładu są w publicznej becie i nie działają przy Zero Data Retention; tam używaj własnej etykiety agent-assisted (sprawdzone w dokumentacji analityki Claude Code, 2026-09-26). Przełącznik GitHub analytics w ustawieniach administracyjnych Claude Code włącza Owner.

Codex

Codex eksportuje logi, ślady i metryki przez tabelę [otel] w ~/.codex/config.toml, z eksporterem otlp-http albo otlp-grpc. Zostaw log_user_prompt = false, chyba że przegląd prywatności zgodził się na przechowywanie promptów:

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

exporter wysyła wyłącznie logi, a trace_exporter ślady. Pominięcie metrics_exporter nie oznacza braku metryk: wydania produkcyjne przełączają się wtedy na wbudowany eksporter Statsig, który wysyła metryki użycia do OpenAI (ab.chatgpt.com). Skieruj metrics_exporter na własny kolektor, jak wyżej, albo ustaw go na "none". Ustawienie enabled = false w tabeli [analytics] też wyłącza eksporter metryk, również ten skierowany na twój kolektor. Nazwy pól i to ustawienie domyślne pochodzą z kodu źródłowego Codeksa (OtelConfigToml, OtelConfig::default i core/src/otel_init.rs, sprawdzone 2026-10-02).

W Codex CLI 0.157.1 nie udało się nam potwierdzić żadnej etykiety pull requestów nadawanej przez Codex (stan na 2026-09-26), więc oznaczaj pull requesty od agenta własną etykietą. Zanim zaufasz liczbie sesji z CI, sprawdź, czy kolektor dostaje dane z uruchomień codex exec: zgłoszenie openai/codex#12913 opisywało, że codex exec nie emitował metryk OpenTelemetry (stanu dla 0.157.1 nie potwierdziliśmy, 2026-09-26), więc jeśli metryk z exec brakuje, licz te sesje ze zdarzeń w logach.

Cursor

Cursor udostępnia administratorom zespołów analitykę użycia, ale 2026-10-02 nie udało się nam potwierdzić w źródle pierwotnym, które plany obejmują jego panel analityki i API ani co każde z nich liczy jako kod wygenerowany przez AI. Zanim na nich zbudujesz, sprawdź w dokumentacji administracyjnej Cursora, co obejmuje twój plan, a jako znacznika nadal używaj własnej etykiety agent-assisted.

Kolektor i dashboardy opisuje strona o obserwowaniu agentów; ccusage (npx ccusage@latest) podaje liczbę sesji i koszty z jednej maszyny, bez serwera.

W jakiej kolejności zacząć mierzyć etapy?

Zacznij tam, gdzie dane już istnieją, a efekt jest największy, potem idź w górę cyklu. Zanim zmienisz jakąkolwiek praktykę, odtwórz co najmniej trzy miesiące historii jej wskaźników, żeby pierwszy tydzień po zmianie miał punkt odniesienia.

1. Najpierw Test i Deploy. Odsetek zmian przechodzących CI za pierwszym razem, czas do pierwszego review i czas w review nie wymagają nowych konwencji: CI i hosting kodu już je mają. Pokazują też najczęstsze wąskie gardło, gdy kod piszą agenci, czyli review.

2. Potem Build. Dodaj linię z identyfikatorem zmiany i etykietę agenta, zacznij commitować plan.md. Odsetek merge’y po pierwszym przejściu i cykle poprawek stają się policzalne.

3. Następnie Design i Plan. Gdy intent.md i spec.md trafiają do repozytorium w chwili akceptacji, wypełniają się wiersze czasu projektowania i poprawek wymagań.

4. Na końcu Maintain. Wiersze zamknięcia pętli wymagają najpierw deterministycznego skryptu detekcji i kolejki triażu; przygotowuje je etap Maintain.

5. Przeglądaj co tydzień na retrospektywie. Tech lead przynosi tabelę decyzyjną i dane z jednego tygodnia, a zespół wybiera jeden etap do zmiany. Pierwsze czytanie danych robi prompt poniżej.

Prompt do skopiowania: diagnoza tygodnia metryk cyklu

Read metrics/lifecycle-weekly.csv (the output of scripts/lifecycle-metrics.py) for the last eight weeks.

For each lifecycle stage (Plan, Design, Build, Test, Deploy, Maintain):
1. State whether its leading indicator improved, stayed flat or got worse over the last four weeks compared with the four before, and the same for its lagging indicator. Treat changes smaller than the week-to-week spread of the first four weeks as flat.
2. Apply this rule: leading better and lagging worse means we automated past a gate; leading flat means the play is not in use or not measured; leading worse and lagging better means a slow gate.
3. Check marker coverage first. If fewer than 80% of merged PRs carry a Change line, say that the stage numbers are unreliable and stop there for that stage.

Then name the single stage we should change next, the one concrete change you propose, and which indicator should move within two weeks if it works. Do not mention individual engineers. Quote the CSV rows you relied on.

Prompt do skopiowania: czy plik instrukcji działa?

Use the GitHub API (token in GH_TOKEN, read-only) to collect every review comment on pull requests merged into main in the last 30 days.

Group the comments into recurring mistakes: the same kind of problem raised on at least three different PRs (for example "uses the old API client", "missing tenant check", "test mocks the database"). For each group, show the count, three example PR numbers, and whether CLAUDE.md or AGENTS.md in this repository already has a rule that should have prevented it.

Output a table: mistake, count, covered by an instruction (yes/no, quote the line), proposed new or changed rule. Do not edit any file. Do not name the authors of the PRs or comments.

Skąd wiesz, że metryki cyklu są prawdziwe?

Metryka, której nikt nie sprawdza, staje się najsłabiej zrecenzowanym artefaktem w repozytorium. Cztery kontrole utrzymują te liczby w ryzach bez ręcznego przeglądania danych co tydzień.

• Żadna liczba nie pochodzi od modelu. Skrypt ekstrakcji jest deterministyczny, zacommitowany i ma testy jednostkowe na repozytorium testowym, zgodnie z tą samą zasadą co deterministyczna detekcja. Agenci piszą skrypt i interpretują jego wynik, ale nigdy nie wytwarzają samych liczb.
• Pokazuj pokrycie znacznikami obok każdej metryki. Jeśli identyfikator zmiany ma tylko połowa zmergowanych pull requestów, czas projektowania policzony na ich podstawie opisuje pół zespołu. Wiersz z pokryciem poniżej 80% traktuj jako ostrzeżenie, nie wynik.
• Sprawdzaj ręcznie dziesięć zmian w miesiącu. Wylosuj dziesięć zmergowanych pull requestów i porównaj znaczniki czasu, etykiety i powiązania z poprawkami ze skryptu z historią. Więcej niż jedna niezgodność na dziesięć oznacza błąd w logice ekstrakcji, nie w zespole.
• Trzymaj się reguły par i jednostki. Każdy wskaźnik wyprzedzający pojawia się w tym samym widoku co jego opóźniona para, a każda liczba dotyczy repozytorium lub usługi (średnie zespołu są w porządku), nigdy nie jest widokiem jednego inżyniera.

Tech lead odpowiada za cotygodniowy widok zespołu i zatwierdza każdą zmianę praktyki. Same definicje należą do właściciela metryk w organizacji, wskazanego na stronie o frameworkach metryk; zespół nie zmienia wzoru lokalnie.

Co psuje metryki cyklu i jak to naprawić

Wskaźnik wyprzedzający staje się celem. Ktoś ustala „specyfikacja w jeden dzień” i specyfikacje robią się coraz cieńsze. Na etapie Build rosną wtedy poprawki wymagań. Naprawa: usuń cel, pokazuj czas projektowania wyłącznie obok poprawek wymagań i omawiaj tę parę na retrospektywie.

Artefakty trafiają do repozytorium hurtem. intent.md, spec.md i plan.md lądują w tym samym commicie co kod, więc czas każdego etapu wynosi zero. Naprawa: dodaj check w CI, który blokuje pull request, gdy folder zmiany nie ma plan.md we wcześniejszym commicie, a historię odtwarzaj tylko ze zmian, które je przechodzą.

Squash merge kasuje zegar etapów. Każdy artefakt trafił na gałąź na czas, ale squash złożył je wszystkie w jeden commit na main, więc czas każdego etapu znów wynosi zero, a git log na main tego nie pokaże. Naprawa: scalaj każdy zaakceptowany artefakt osobnym małym pull requestem, przełącz gałęzie zmian na merge commity albo rebase merge, albo niech skrypt ekstrakcji czyta znaczniki czasu commitów z listy commitów każdego pull requestu przez API hostingu kodu zamiast z main.

Poprawki udają nową pracę. Naprawa zeszłotygodniowej zmiany od agenta przychodzi jako nowy pull request z funkcją, bez powiązania, więc odsetek merge’y po pierwszym przejściu wygląda idealnie. Naprawa: dopisz trailer Follow-up: #PR do checklisty review i niech agent recenzujący oznacza poprawki świeżo zmergowanego kodu, które go nie mają.

Rośnie liczba równoległych sesji, a z nią poprawki. Przepustowość wygląda lepiej, ale każda zmiana wymaga więcej rund. Naprawa: ogranicz liczbę równoległych sesji na inżyniera do ostatniego poziomu, przy którym odsetek merge’y po pierwszym przejściu się utrzymywał, i podnoś go dopiero wtedy, gdy poprawi się odsetek zmian przechodzących CI za pierwszym razem.

Ciężar review spada na kilku seniorów. Czas w review rośnie, ale tylko dla pull requestów, które wymagają dwóch konkretnych recenzentów. Naprawa: rozbij czas w review na grupy recenzentów (nie na osoby), ustal limity rozmiaru pull requestów i przeczytaj, jak utrzymać ruch w kolejce review.

Liczby zamieniają się w ranking. Pojawiają się widoki per inżynier i zespół zaczyna optymalizować liczniki. Naprawa: usuń widoki per osoba, zapisz w umowie zespołu, że te metryki opisują proces, i trzymaj ocenę indywidualną z dala od nich.

Dokąd dalej z metrykami cyklu

Jeśli etapy są dla ciebie nowe, zacznij od przeglądu cyklu życia. Gdy sygnały etapów działają, zepnij je z definicjami na poziomie organizacji.

DORA, SPACE, DX Core 4 i pomiar AI Kanoniczne definicje metryk AI i minimalny panel dla każdego poziomu organizacji.

Maintain: zamknij pętlę Zamień przekroczenie metryki w intent.md dzięki deterministycznej detekcji.

Obserwowanie agentów w działaniu Pipeline'y telemetrii i dashboardy dla sesji agentów, kosztów i śladów.

Mapa narzędzi: Claude Code, Cursor i Codex Które możliwości cyklu życia daje dziś każde narzędzie.