Pomiar rzeczywistego efektu AI w zespole inżynierskim: protokół, który przyjmą zarząd i zespół

Kto skorzysta z tego przewodnika.

• CTO i wiceprezesi ds. inżynierii, którzy muszą pokazać zarządowi, czy budżet na narzędzia AI cokolwiek zmienił, liczbą, której umieją bronić
• Szefowie inżynierii, których zespół już się spiera, czy zrobiło się lepiej, czy gorzej, bez danych, które zaakceptowałaby którakolwiek strona
• Menedżerowie inżynierii, którym polecono wprowadzić miary produktywności i którzy wiedzą, co dzieje się z zespołem, gdy miara jest liczona dla poszczególnych osób
• Zespoły platformowe i zespoły od środowiska pracy programistów, które są właścicielami CI, repozytorium i systemu zgłoszeń i będą prowadzić pomiar po przekazaniu

Dlaczego szybsze zamykanie zgłoszeń nie jest dowodem

Krótszy czas zamykania zgłoszeń nie pokazuje kosztu późniejszych poprawek ani pracy recenzentów. Nie mówi, czy zmiana została poprawiona po scaleniu, czy recenzent spędził czas, który zaoszczędził autor, ani czy następna zmiana w tym samym pliku trwała dłużej. Raport DORA 2025, oparty na odpowiedziach ankietowych prawie 5 000 specjalistów z branży, wykazał dodatnią zależność między adopcją AI a przepustowością dostarczania oprogramowania i, w tych samych danych, ujemną zależność ze stabilnością dostarczania. Według samego raportu przyspieszenie odsłania słabości dalej w procesie, gdy brakuje systemów kontrolnych, testów automatycznych, dobrej praktyki kontroli wersji i szybkiej informacji zwrotnej, które wchłonęłyby dodatkowy wolumen zmian.

Liczba przepustowości sama w sobie to pół wyniku. Raport DORA o zwrocie z inwestycji z kwietnia 2026 wycenia drugą połowę na poglądowym modelu: w jego przykładowym kalkulatorze dla organizacji inżynierskiej z 500 osobami wskaźnik nieudanych zmian, który po adopcji rośnie z 5% do 6%, pokazuje się jako ujemny wpływ przestojów rzędu 344 000 USD. Ta liczba to przykład obliczeniowy z założeniami tego modelu (500 osób, przyjęty koszt przestoju), nie pomiar żadnej firmy. Jest tu przytoczona z jednego powodu: w tym modelu ruch o jeden punkt w mierze stabilności wystarczył, żeby skasować widoczny zysk w tempie.

Spór wewnątrz zespołów ma ten sam kształt. W dyskusjach praktyków z 2026 roku na ten temat chodzi o to, czy kod za zamkniętym zgłoszeniem jest gorszy i czy presja na utrzymanie tempa powstrzymuje kogokolwiek przed sprawdzeniem. Bez protokołu obie strony mają rację. Raport pokazuje zmianę wyników oraz granice przypisania jej asystentom AI.

Co pokazują badania nad efektami AI

Opublikowane badania mierzą różne rzeczy różnymi metodami: dwa to eksperymenty z randomizacją, jedno to ankieta przekrojowa. Ich wyniki dają się porównać dopiero wtedy, gdy widać sposób uzyskania każdego z nich. Tabela wymienia badania, o których zarząd najprawdopodobniej słyszał. Żadne z nich nie zmierzyło waszego zespołu.

Projekt pomiaru

Protokół, który przyjmą zarząd i zespół, ma pięć części. Każda istnieje dlatego, że bez niej konkretne badanie zawiodło. Wszystko poniżej liczy się z historii gita, logów CI i systemu zgłoszeń; zakres zależy od tego, co te systemy przechowują, a sprawdzamy to w pierwszym tygodniu. Nie jest potrzebna żadna platforma komercyjna, a panel wskaźnika akceptacji od dostawcy nie jest danymi wejściowymi.

• Punkt odniesienia sprzed wdrożenia. Dwanaście tygodni historii przed pierwszą licencją, dla każdej miary, która będzie raportowana później, odtworzonych z gita i CI, jeśli nikt nie zebrał ich na bieżąco. Pomiar bez stanu sprzed wdrożenia nie ma z czym się porównać poza wrażeniem.
• Miary w parach. Każda miara tempa jest raportowana obok miary stabilności z tego samego okna i tych samych repozytoriów: czas realizacji zmiany obok czasu do pierwszej poprawki po scaleniu (liczonego w oknie 30 dni, razem z udziałem zmian bez poprawki, bo sam dłuższy czas może znaczyć zarówno stabilniejszy kod, jak i późniejsze wykrywanie błędów); scalone pull requesty na tydzień obok udziału scaleń, po których w ciągu 30 dni nastąpił revert albo hotfix; częstość wdrożeń obok wskaźnika nieudanych zmian. Para może poruszyć się w przeciwne strony i to właśnie jest ustalenie.
• Okno dość długie, żeby objąć dołek. Osiem do dwunastu tygodni po wdrożeniu, bo pierwsze tygodnie każdej zmiany narzędzi niosą koszt nauki, który migawka z czterech tygodni odczyta jako porażkę albo, wzięta późno, jako czysty zysk.
• Grupa porównawcza zespołami, nie ochotnikami. Tam, gdzie organizacja wdraża falami, zespoły, które jeszcze czekają, są grupą porównawczą, po sprawdzeniu podobieństwa zespołów, zadań i wcześniejszych trendów oraz z zapisanym ograniczeniem nielosowego przydziału. Tam, gdzie nie może, porównaniem jest własny punkt odniesienia tego samego 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 wycofują.
• Krótka lista tego, czego się nie liczy. Linie kodu, liczba commitów, liczba otwartych pull requestów i wskaźnik akceptacji podpowiedzi asystenta są wyłączone jako samodzielne wyniki, bo narzędzie zawyża każdą z tych liczb bez żadnej zmiany w tym, co trafia do użytkowników. Scalone pull requesty na tydzień wchodzą tylko w parze z udziałem revertów i hotfixów; reszta zostaje w danych jako mianowniki.

Miary dla poszczególnych osób i dlaczego psują pomiar

Najszybszy sposób na utratę pomiaru to publikacja wyników dla poszczególnych osób. Ramy SPACE (Forsgren i in., ACM Queue 2021) formułują zasadę: produktywności programisty nie da się uchwycić jedną miarą ani poziomem aktywności pojedynczej osoby. Ranking inżynierów według użycia asystenta albo wskaźnika akceptacji szybko zamienia miarę w cel. Ludzie uruchamiają narzędzie, żeby było widać, że go używają, przyjmują podpowiedzi, które inaczej by przepisali, a liczba rośnie, podczas gdy to, co miała reprezentować, przestaje się ruszać. Pracodawcy zaczęli już uwzględniać indywidualne użycie AI w ocenach okresowych, jak podał The Register w listopadzie 2025, a wątki praktyków po takich ogłoszeniach szczegółowo opisują opór, który to wywołuje.

Dane o zaufaniu tłumaczą ten opór. Ankieta Stack Overflow 2025 zebrała 49 009 odpowiedzi. Na pytanie o frustracje odpowiedziało 31 476 osób i 66% z nich wskazało wynik AI, który jest prawie dobry, ale nie do końca; to najczęstsza odpowiedź. 45,2% stwierdziło, że debugowanie kodu napisanego przez AI zajmuje więcej czasu. Na pytanie o zaufanie odpowiedziały 33 244 osoby, a 3,1% z nich zdecydowanie ufa dokładności wyników AI. Zespół, któremu każe się używać narzędzia częściej i który jest z tego rozliczany, jest proszony o ignorowanie tego, co obserwuje codziennie. Dlatego protokół agreguje na poziomie zespołu, trzyma nazwiska poza każdym panelem, traktuje dane o użyciu jako mianownik zamiast wyniku i zbiera własną ocenę zespołu w anonimowej ankiecie przeprowadzanej przed wdrożeniem i ponownie na końcu okna.

Co może pójść nie tak i co z tym robimy.

1. 1
   Punkt odniesienia wzięty po rozpoczęciu wdrożenia

   Licencje poszły 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, 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 punkt odniesienia z historii gita i CI dla dwunastu tygodni przed datą pierwszej licencji, osobno dla każdego repozytorium. Reguły wyłączeń ustalamy przed analizą: oznaczamy każdy tydzień z zamrożeniem wydań albo urlopami, żeby dało się go wyłączyć symetrycznie z obu okien, a incydenty, które mogą być skutkiem mierzonych zmian, zostają w danych. Tam, gdzie data wdrożenia różni się między zespołami, każdy zespół dostaje własny punkt odniesienia. Potem sprawdzamy, że zapytania o punkt odniesienia zwracają te same wartości, gdy uruchamia je wasz zespół platformowy.

   Co zostaje u was: arkusz punktu odniesienia dla każdego zespołu i repozytorium, z zapytaniami, kalendarzem wyłączeń i datą licencji, do której każdy punkt jest zakotwiczony
2. 2
   Przepustowość raportowana bez pary ze stabilnością

   Panel pokazuje czas realizacji i scalone pull requesty na tydzień, oba lepsze. Poprawek po scaleniu, revertów i czasu do pierwszej poprawki na nim nie ma, bo nikt o nie nie prosił, a panel dostawcy narzędzia ich nie ma. Dane DORA mówią, że koszt dodatkowego wolumenu zmian pojawia się w stabilności, więc panel pokazuje dokładnie tę połowę, która nie może pójść źle.

   Co z tym robimy

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

   Co zostaje u was: tabela miar w parach z obiema połowami dla każdego zespołu i okna oraz zapytania, które ją tworzą
3. 3
   Grupą porównawczą jest ten, kto się zgłosił

   Pilotaż był otwarty dla każdego chętnego, więc zmierzone osoby to te, które najwięcej oczekiwały od narzędzia, na zadaniach, które same wybrały. Aktualizacja METR z lutego 2026 nazywa dokładnie tę usterkę: programiści odmawiali pracy bez AI, a 30-50% wstrzymało zadania, które bez AI zapowiadały się wolno. Grupa zmierzona i grupa porównawcza różnią się nastawieniem i strukturą zadań, zanim narzędzie cokolwiek zrobi.

   Co z tym robimy

   Przydzielamy zespołami i repozytoriami według fal wdrożenia, które organizacja już ma. Zapisujemy, kto odmówił i dlaczego. Tam, gdzie nie ma struktury fal, porównujemy ten sam zespół z jego własnym punktem odniesienia i wpisujemy to ograniczenie do raportu w pierwszym akapicie, nie w przypisie. Porównujemy podobne zadania dopasowane po typie zgłoszenia i repozytorium oraz raportujemy strukturę zadań w obu grupach, żeby zmiana tego, co ludzie wybrali do pracy, nie uszła za przyspieszenie.

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

   Najłatwiej dostępna liczba to ile każda osoba używała asystenta, więc ona trafia na slajd. Zespół szybko zaczyna optymalizować pod nią: podpowiedzi są przyjmowane, a potem przepisywane, sesje otwierane i zostawiane uruchomione. Linia użycia rośnie, linie wyniku nie, a raport stwierdza, że adopcja jest wysoka, a efekt w toku. Tymczasem inżynierowie, których uszeregowano, przestają współpracować z jakimkolwiek przyszłym pomiarem.

   Co z tym robimy

   Dane o użyciu raportujemy osobno, jako kontekst na poziomie zespołu, nigdy jako wynik. Usuwamy z panelu każdy widok dla poszczególnych osób, zanim zostanie udostępniony. Anonimowa ankieta pyta zespół, gdzie narzędzie pomogło, a gdzie kosztowało czas. 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, regułami dostępu i kwestionariuszem ankiety oraz wyniki ankiety z obu rund
5. 5
   Liczenie wyniku, który narzędzie zawyża

   Linie kodu, commity i pull requesty rosną przy korzystaniu z asystenta, bo generowanie ich to właśnie 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 tymczasem wchłaniają dodatkowy wolumen, a ich czas nie pojawia się w żadnym zliczeniu.

   Co z tym robimy

   Definiujemy, co liczy się jako zrobione, zanim otworzy się okno: scalona zmiana, która przetrwała 30 dni bez poprawki w tych samych liniach powiązanej ze zgłoszeniem błędu albo incydentem, oraz pozycja z planu zamknięta w stanie akceptacji z systemu zgłoszeń. Automatyczne rozpoznawanie poprawek ma ograniczenia i raport je wymienia. Dodajemy obciążenie przeglądem na scaloną zmianę jako osobny wiersz, żeby czas, który przesunął się z autora na recenzenta, był widoczny. Potem uruchamiamy definicje na punkcie odniesienia, żeby potwierdzić, że zachowują się tak samo przed i po.

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

Co zostaje u was.

• Protokół pomiaru: pytania, pary miar, okno, projekt porównania, poziom agregacji i lista tego, czego celowo się nie mierzy
• Arkusz punktu odniesienia dla każdego zespołu i repozytorium za dwanaście tygodni przed wdrożeniem, z zapytaniami i kalendarzem wyłączeń
• Panel miar w parach zbudowany na waszych danych z gita, CI i systemu zgłoszeń, z agregacją ustaloną na poziomie zespołu i bez widoku dla poszczególnych osób
• Zapis przydziału: grupy porównawcze zespołami albo falami, dziennik odmów i tabela struktury zadań dla obu grup
• Kwestionariusz ankiety i wyniki z dwóch anonimowych rund, na początku i na końcu okna pomiaru (pierwsza przed wdrożeniem, jeśli jeszcze się nie zaczęło)
• Raport po zamknięciu okna pomiaru mówiący, co się zmieniło, jakim kosztem w poprawkach i obciążeniu przeglądem, czego nie dało się zmierzyć i dlaczego, napisany tak, żeby zarząd i zespół przeczytali 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 punkt odniesienia

   Uzgadniamy pytania, na które chcą odpowiedzi zarząd i zespół, wybieramy pary miar i odtwarzamy punkt odniesienia z historii gita i CI za dwanaście tygodni przed pierwszą licencją. Jeśli wdrożenie jeszcze się nie zaczęło, tu ustalamy też strukturę fal 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 punkcie odniesienia, żeby sprawdzić ich zachowanie, oraz stawiamy panel z agregacją na poziomie zespołu oraz spisanymi regułami dostępu. Przeprowadzamy pierwszą ankietę.

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

   Panel działa przez osiem do dwunastu tygodni. Co miesiąc sprawdzamy dane pod kątem luk, zamrożeń i incydentów do oznaczenia. Nie raportujemy wyników cząstkowych, bo migawka z czterech tygodni czyta się jako porażka albo jako czysty zysk, zależnie od tego, kiedy ją wziąć.

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

   Przeprowadzamy drugą ankietę, liczymy każdą parę dla obu okien i obu grup i piszemy raport z ograniczeniami w pierwszym akapicie. Zapytania, definicje i panel trafiają do waszego zespołu platformowego z instrukcją na następny kwartał.

   Tydzień 15-16

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

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 (49 009 odpowiedzi; odsetki liczone od osób, które odpowiedziały na dane pytanie)
• 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)