Definicja paradoksu#

Po wprowadzeniu narzędzi typu Claude Code, Copilot, Cursor — liczba commitów na osobę rośnie o 30–60%, ale Lead Time for Changes często zostaje nieruszony, a Change Failure Rate rośnie o kilka punktów procentowych.

Trzy mechanizmy#

1. Zatory w code review#

Ten sam zespół, który wcześniej generował 8 PR-ów dziennie, generuje 18. Recenzenci pracują w starym tempie — kolejka rośnie liniowo, średni czas oczekiwania na review rośnie wykładniczo.

2. Eksplozja powierzchni testowej#

Auto-wygenerowany kod uruchamia się, ale niekoniecznie przeszedł lokalną weryfikację mentalną autora. CI staje się jedynym filtrem; jeśli jest wolne lub flaky, defekty przechodzą dalej.

3. Spadek własności#

Gdy kod jest „mojego AI, nie mój”, developer mniej chętnie zostaje przy nim na produkcji. MTTR rośnie, bo nikt nie wie, dlaczego coś działało.

Przeciwdziałanie#

AI w pętli review — pierwszy bot oznacza zmiany ryzykowne, sugeruje testy, blokuje commity bez asercji.
Smaller batch size — twardy limit linii w PR (np. 400) wymusza dekompozycję.
Failure budget — CFR ponad 10% zatrzymuje merge na dany dzień.
Authorship rotation — każdy AI-generated PR ma „human reviewer of record” odpowiedzialny przez 14 dni.

Co mierzymy#

Jeśli wprowadzasz AI assistant, ustaw te cztery wskaźniki jednocześnie:

liczba PR / inżynier / tydzień (proxy adopcji),
Lead Time for Changes (proxy zatorów),
CFR (proxy jakości),
MTTR (proxy własności).

Bez tej czwórki rozmowa o „produktywności AI” jest anegdotyczna, a zarząd nie kupi anekdoty.