Pomiar realnego efektu AI w zespole inżynierskim: protokół, który obroni się przed zarządem i przed zespołem

Dla kogo jest ten przewodnik.

• CTO i wiceprezesi ds. inżynierii, którzy mają pokazać zarządowi, czy budżet na narzędzia AI cokolwiek zmienił, i potrzebują liczby, której będą bronić
• Szefowie inżynierii, w których zespole trwa już spór, czy jest lepiej, czy gorzej, a żadna ze stron nie ma danych, które druga by przyjęła
• Kierownicy inżynierii, którym polecono wprowadzić metryki produktywności i którzy wiedzą, co dzieje się z zespołem, gdy metryka jest per osoba
• Zespoły platformowe i developer experience, które mają CI, repozytorium i system zgłoszeń pod opieką i po przekazaniu będą prowadzić pomiar same

Dlaczego szybsze zamykanie ticketów nie jest dowodem

Ticket zamknięty szybciej mówi tyle, że ticket zamknął się szybciej. Nie mówi, czy zmiana została przerobiona po scaleniu, czy recenzent zużył czas, który autor zaoszczędził, ani czy kolejna zmiana w tym samym pliku zajęła dłużej, bo pierwsza dołożyła gałąź zamiast użyć istniejącej. Raport DORA 2025, oparty na odpowiedziach blisko 5 000 specjalistów technologicznych, wykazał dodatni związek między wdrożeniem AI a przepustowością dostarczania oraz, w tych samych danych, ujemny związek ze stabilnością dostarczania. Autorzy raportu czytają to tak: przyspieszenie odsłania słabości dalej w procesie, gdy mechanizmy kontrolne, testy automatyczne, dojrzała praktyka pracy z repozytorium i szybka informacja zwrotna, nie są w stanie przyjąć większej liczby zmian.

Liczba o przepustowości bez pary to pół wyniku. Raport DORA o zwrocie z AI z kwietnia 2026 wycenia drugą połowę na modelu poglądowym: w przykładowym kalkulatorze dla organizacji inżynierskiej liczącej 500 osób wzrost odsetka nieudanych zmian z 5% do 6% po wdrożeniu pokazuje się jako ujemny wpływ przestojów o wartości 344 000 USD. To przykład liczbowy, a nie pomiar żadnej firmy, i jest tu cytowany z jednego powodu: pokazuje, że przesunięcie metryki stabilności o jeden punkt wystarcza, żeby skasować widoczny zysk na tempie.

Spór wewnątrz zespołów ma ten sam kształt. W największych dyskusjach praktyków z 2026 roku na ten temat kłótnia toczy się o to, czy kod za zamkniętym ticketem jest gorszy i czy presja na tempo jest tym, co powstrzymuje kogokolwiek przed sprawdzeniem. Bez protokołu obie strony mają rację, a rozstrzyga dopiero pomiar.

Co naprawdę zmierzyły eksperymenty kontrolowane

Opublikowane badania są ze sobą sprzeczne, a sprzeczność staje się pouczająca, gdy widać metodę za każdą liczbą. Tabela zbiera badania, o których zarząd najprawdopodobniej słyszał, razem z populacją, projektem i wynikiem, który każde z nich mierzyło. Żadne z nich nie mierzyło waszego zespołu.

Projekt pomiaru

Protokół, który przetrwa i zarząd, i zespół, ma pięć części, a każda z nich istnieje dlatego, że konkretne badanie bez niej poległo. Wszystko poniżej liczy się z historii gita, logów CI i systemu zgłoszeń. Komercyjna platforma nie jest potrzebna, a panel akceptacji podpowiedzi od dostawcy narzędzia nie jest danymi wejściowymi.

• Linia bazowa przed wdrożeniem. Dwanaście tygodni historii sprzed pierwszej licencji dla każdej metryki, która będzie potem raportowana, odtworzone z gita i CI, jeśli nikt ich wtedy nie zapisał. Pomiar bez punktu wyjścia nie ma z czym się porównać poza wrażeniem.
• Pary metryk. Każda metryka tempa jest raportowana obok metryki stabilności z tego samego okna i tych samych repozytoriów: czas realizacji zmiany obok czasu do pierwszej poprawki po scaleniu; scalone pull requesty tygodniowo obok udziału scaleń, po których w ciągu 30 dni przyszło cofnięcie albo hotfix; częstość wdrożeń obok odsetka nieudanych zmian. Para może iść w przeciwne strony i to właśnie jest wynik.
• Okno na tyle długie, żeby objąć dołek. Osiem do dwunastu tygodni po wdrożeniu, bo pierwsze tygodnie każdej zmiany narzędzia niosą koszt nauki, który czterotygodniowa migawka odczyta jako porażkę, a wzięta później jako czysty zysk.
• Grupa porównawcza zespołami, nie z ochotników. Tam, gdzie organizacja wdraża falami, zespoły czekające na swoją kolej są grupą porównawczą. Tam, gdzie się nie da, porównaniem jest własna linia bazowa zespołu, z ograniczeniem zapisanym w raporcie. Ochotnicy nigdy nie są porównaniem, bo dane METR pokazują, co się dzieje, gdy entuzjaści się zgłaszają, a sceptycy nie.
• Krótka lista tego, czego się nie liczy. Linie kodu, liczba commitów, liczba pull requestów i odsetek zaakceptowanych podpowiedzi są wyłączone jako wyniki, bo narzędzie zawyża każdą z tych wartości bez żadnej zmiany w tym, co trafia do użytkowników. Zostają w danych wyłącznie jako mianowniki.

Metryki per osoba i dlaczego zatruwają pomiar

Najszybszy sposób, żeby stracić pomiar, to opublikować go per osoba. Ramy SPACE (Forsgren i in., ACM Queue 2021) formułują zasadę wprost: produktywności programisty nie da się ująć jedną metryką ani poziomem aktywności pojedynczej osoby. Ranking inżynierów według użycia asystenta albo odsetka przyjętych podpowiedzi zamienia metrykę w cel w ciągu jednego sprintu. Ludzie uruchamiają narzędzie, żeby było widać, że go używają, przyjmują podpowiedzi, które i tak przepiszą, i liczba rośnie, podczas gdy to, co miała reprezentować, stoi w miejscu. Pracodawcy zaczęli już uwzględniać indywidualne użycie AI w ocenach okresowych, o czym The Register pisał w listopadzie 2025, a wątki praktyków, które idą za takimi ogłoszeniami, opisują ze szczegółami opór, jaki to wywołuje.

Opór tłumaczą dane o zaufaniu. W ankiecie Stack Overflow z 2025 roku wśród 48 968 programistów 66% wskazało odpowiedzi AI, które są prawie dobre, ale nie do końca, jako największą frustrację, 45,2% stwierdziło, że debugowanie kodu pisanego przez AI zajmuje więcej czasu, a tylko 3,1% w wysokim stopniu ufa dokładności wyników. Zespół, któremu każe się używać narzędzia więcej i który jest z tego rozliczany, dostaje polecenie ignorowania tego, co obserwuje codziennie. Protokół agreguje więc na poziomie zespołu, trzyma nazwiska poza każdym panelem, traktuje dane o użyciu jako mianownik, a nie wynik, i zbiera ocenę samego zespołu w anonimowej ankiecie przeprowadzanej przed wdrożeniem i ponownie na końcu okna.

Gdzie to się psuje i co z tym robimy.

1. 1
   Linia bazowa wzięta po starcie wdrożenia

   Licencje poszły najpierw do pilotażu, potem do wszystkich, a prośba o pomiar przyszła miesiąc później. Pierwszy punkt danych jest już w dołku nauki albo już za nim, więc porównanie przed i po mierzy rozbieg, a nie narzędzie. Resztę robi sezonowość: zamrożenie wydań albo okres urlopowy w którymkolwiek oknie przesuwa liczby bardziej niż asystent.

   Co z tym robimy

   Odtwarzamy linię bazową z historii gita i CI dla dwunastu tygodni przed datą pierwszej licencji, osobno dla każdego repozytorium, i oznaczamy każdy tydzień z zamrożeniem, incydentem albo urlopami, żeby wyłączyć go z obu okien symetrycznie. Gdy data wdrożenia różni się między zespołami, każdy zespół dostaje własną linię bazową. Potem sprawdzamy, czy zapytania bazowe zwracają te same wartości, gdy uruchamia je wasz zespół platformowy.

   Co zostaje u was: arkusz linii bazowej per zespół i repozytorium, z zapytaniami, kalendarzem wyłączeń i datą licencji, do której każda linia jest przypięta
2. 2
   Przepustowość raportowana bez pary ze stabilnością

   Panel pokazuje czas realizacji zmiany i scalone pull requesty tygodniowo, oba lepsze. Przeróbek po scaleniu, cofnięć i czasu do pierwszej poprawki na nim nie ma, bo nikt o nie nie poprosił, a panel dostawcy narzędzia ich nie liczy. Dane DORA mówią, że koszt większej liczby zmian pojawia się właśnie w stabilności, więc panel pokazuje dokładnie tę połowę, która nie może wyjść źle.

   Co z tym robimy

   Definiujemy każdą raportowaną parę z góry i liczymy obie połowy z tych samych repozytoriów i tego samego okna: dla każdej scalonej zmiany liczbę dni do kolejnego commita w tych samych liniach, który odwołuje się do błędu, cofnięcia albo hotfixa. Parę raportujemy jako jeden wiersz, żeby zysk na tempie ze stratą na stabilności był widoczny jako jeden wynik, a stratę wyrażamy w godzinach inżynierskich zużytych na poprawki, nie tylko w procentach.

   Co zostaje u was: tabela par metryk z obiema połowami per zespół i okno, razem z zapytaniami, które ją produkują
3. 3
   Grupą porównawczą jest ten, kto się zgłosił

   Pilotaż był otwarty dla chętnych, więc zmierzone zostały osoby, które spodziewały się po narzędziu najwięcej, na zadaniach, które same wybrały. Korekta METR z lutego 2026 nazywa dokładnie ten błąd: programiści odmawiali pracy bez AI, a 30-50% wstrzymywało zadania, które bez AI spodziewali się robić wolno. Grupa mierzona i grupa porównawcza różnią się nastawieniem i doborem zadań, zanim narzędzie cokolwiek zrobi.

   Co z tym robimy

   Przydzielamy zespołami i repozytoriami, korzystając z fal wdrożenia, które organizacja i tak ma, i zapisujemy, kto odmówił i dlaczego. Gdy fal nie ma, porównujemy zespół z jego własną linią bazową i piszemy to ograniczenie w pierwszym akapicie raportu, nie w przypisie. Podobne zadania zestawiamy po typie ticketu i repozytorium, a dobór zadań w obu grupach raportujemy, żeby zmiana tego, co ludzie wybrali do roboty, nie przeszła za przyspieszenie.

   Co zostaje u was: rejestr przydziału z projektem porównania, dziennikiem odmów i tabelą doboru zadań dla obu grup
4. 4
   Użycie staje się metryką

   Najłatwiej dostępna liczba mówi, ile każda osoba używała asystenta, więc to ona trafia na slajd. W ciągu sprintu zespół zaczyna ją optymalizować: podpowiedzi są przyjmowane i zaraz przepisywane, sesje otwierane i zostawiane włączone. Linia użycia rośnie, linie wyników nie, a raport kończy się wnioskiem, że adopcja jest wysoka, a efekt w drodze. W tym czasie inżynierowie, którzy zostali uszeregowani, przestają współpracować przy jakimkolwiek kolejnym pomiarze.

   Co z tym robimy

   Dane o użyciu trzymamy w modelu wyłącznie jako mianownik, tak żeby metryki wyniku dało się czytać na jednostkę użycia asystenta na poziomie zespołu, a każdy widok per osoba usuwamy z panelu, zanim ktokolwiek go zobaczy. Anonimowa ankieta pyta zespół, gdzie narzędzie pomogło, a gdzie kosztowało czas, i te odpowiedzi publikujemy obok liczb. Dostęp do surowych danych jest spisany: kto może je odpytywać, z jaką ziarnistością i czego nigdy się nie eksportuje.

   Co zostaje u was: specyfikacja panelu z poziomem agregacji, zasadami dostępu i kwestionariuszem ankiety, plus wyniki obu rund ankiety
5. 5
   Liczenie tego, co narzędzie zawyża

   Linie kodu, commity i pull requesty rosną, gdy w pętli jest asystent, bo generowanie ich to dokładnie to, co asystent robi. Zliczenie któregokolwiek z nich po wdrożeniu pokazuje wzrost bez związku z tym, co dotarło do użytkowników. Recenzenci w tym czasie przyjmują dodatkowy wolumen, a ich czas w żadnym zliczeniu się nie pojawia.

   Co z tym robimy

   Definiujemy, co liczy się jako zrobione, zanim okno się otworzy: scalona zmiana, która przetrwała 30 dni bez poprawki w tych samych liniach, oraz pozycja z roadmapy zamknięta w stanie akceptacji z waszego systemu zgłoszeń. Dokładamy obciążenie przeglądem na scaloną zmianę jako osobny wiersz, żeby czas, który przesunął się od autora do recenzenta, był widoczny. Potem uruchamiamy te definicje na linii bazowej, żeby potwierdzić, że zachowują się tak samo przed i po.

   Co zostaje u was: arkusz definicji każdej metryki wyniku, z zapytaniem, listą wyłączeń i wierszem obciążenia przeglądem

Co zostaje u was.

• Protokół pomiaru: pytania, pary metryk, okno, projekt porównania, poziom agregacji i lista tego, czego celowo się nie mierzy
• Arkusz linii bazowej per zespół i repozytorium dla dwunastu tygodni przed wdrożeniem, z zapytaniami i kalendarzem wyłączeń
• Panel par metryk zbudowany na waszych danych z gita, CI i systemu zgłoszeń, z agregacją ustawioną na poziomie zespołu i bez widoku per osoba
• Rejestr przydziału: grupy porównawcze zespołami albo falami, dziennik odmów i tabela doboru zadań dla obu grup
• Kwestionariusz i wyniki dwóch anonimowych rund ankiety, przed wdrożeniem i na końcu okna
• Raport po 8-12 tygodniach mówiący, co się zmieniło, ile kosztowało w przeróbkach i obciążeniu przeglądem, czego nie dało się zmierzyć i dlaczego, napisany tak, żeby zarząd i zespół czytali tę samą wersję
• Przekazanie: zapytania, definicje i panel zostają u waszego zespołu platformowego, żeby ten sam pomiar dało się powtórzyć co kwartał

Jak pracujemy.

1. 1
   1. Protokół i linia bazowa

   Ustalamy pytania, na które chcą odpowiedzi zarząd i zespół, wybieramy pary metryk i odtwarzamy linię bazową z historii gita i CI dla dwunastu tygodni przed pierwszą licencją. Jeśli wdrożenie jeszcze nie ruszyło, tu ustalamy też fale i grupy porównawcze.

   Tydzień 1-2
2. 2
   2. Instrumentacja

   Budujemy zapytania do waszych repozytoriów, CI i systemu zgłoszeń, uruchamiamy je na linii bazowej, żeby sprawdzić, jak się zachowują, i stawiamy panel z agregacją na poziomie zespołu i spisanymi zasadami dostępu. Rusza pierwsza runda ankiety.

   Tydzień 2-3
3. 3
   3. Okno pomiaru

   Panel pracuje przez osiem do dwunastu tygodni. Co miesiąc sprawdzamy dane pod kątem luk, zamrożeń i incydentów do oznaczenia i nie raportujemy wyników cząstkowych, bo czterotygodniowa migawka wychodzi albo na porażkę, albo na czysty zysk, zależnie od momentu.

   Tydzień 3-15
4. 4
   4. Raport i przekazanie

   Uruchamiamy drugą rundę ankiety, liczymy każdą parę dla obu okien i obu grup i piszemy raport z ograniczeniami w pierwszym akapicie. Zapytania, definicje i panel przekazujemy waszemu zespołowi platformowemu razem z instrukcją na kolejny kwartał.

   Tydzień 15-16

Pozostałe strony z tej serii.

Gdzie to zamienia się w usługę.

Skąd pochodzą daty i liczby.

• Becker, Rush, Barnes, Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089, lipiec 2025)
• METR, Measuring AI uplift: korekta metodyki i dane z końca 2025 (24 lutego 2026)
• Cui, Demirer, Jaffe, Musolff, Peng, Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers (Management Science, 2026)
• Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development
• DORA, The ROI of AI-assisted Software Development (v.2026.1, kwiecień 2026)
• InfoQ, New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment (maj 2026): poglądowy przykład odsetka nieudanych zmian i kwota 344 000 USD
• Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, The SPACE of Developer Productivity: There's more to it than you think (ACM Queue, 2021)
• Stack Overflow, 2025 Developer Survey, sekcja AI (48 968 respondentów)
• The Register, Devs gripe about having AI shoved down their throats: pracodawcy uwzględniający indywidualne użycie AI w ocenach okresowych (19 listopada 2025)