Metryki DORA psują się w erze AI: dlaczego szybkość wydawania przestaje być dowodem jakości

Cztery metryki DORA, czyli częstotliwość wdrożeń, czas realizacji zmiany, odsetek nieudanych zmian i czas przywrócenia usługi, przez dekadę były najlepszym dostępnym skrótem do oceny dojrzałości inżynierskiej zespołu. Ich siła brała się z jednego założenia: żeby wdrażać częściej i szybciej, trzeba mieć uporządkowany proces, testy i automatyzację. Generatywna AI właśnie rozerwała to założenie na pół, bo pozwala przyspieszyć bez porządkowania czegokolwiek. Ten artykuł pokazuje, co dokładnie się psuje, które z czterech metryk nadal są wiarygodne, i co dołożyć, żeby pomiar znowu mówił o zespole, a nie o narzędziu.

Dlaczego metryki DORA nigdy nie miały być czytane osobno

Czwórka metryk dzieli się na dwie pary, które trzeba czytać razem. Częstotliwość wdrożeń i czas realizacji zmiany mierzą tempo. Odsetek nieudanych zmian i czas przywrócenia usługi mierzą stabilność. Cała wartość tego zestawu polega na napięciu między parami: łatwo przyspieszyć kosztem stabilności i łatwo ustabilizować się kosztem tempa, a sztuka polega na poprawianiu obu naraz.

Zespół, który patrzy wyłącznie na tempo, po kilku miesiącach ma świetne wykresy i coraz więcej nocnych telefonów. Zespół, który patrzy wyłącznie na stabilność, wypuszcza raz na kwartał i nazywa to jakością, choć w rzeczywistości kumuluje ryzyko w wielkich paczkach zmian. Dopiero obie pary razem opisują coś, co ma sens biznesowy: zdolność do częstego, bezpiecznego dostarczania wartości.

Co konkretnie psuje w tym układzie sztuczna inteligencja

Najciekawszą odpowiedź na to pytanie dał sam zespół DORA. W badaniu z 2024 roku, na próbie około trzech tysięcy osób, 75,9 procent respondentów deklarowało korzystanie z AI przynajmniej w części obowiązków, a trzy czwarte odnotowało wzrost własnej produktywności. Jednocześnie te same dane pokazały coś, czego nikt nie zamawiał: każde 25 procent wzrostu adopcji AI w organizacji wiązało się ze spadkiem stabilności dostarczania o 7,2 procent i przepustowości o 1,5 procent. Poczucie przyspieszenia rosło, a mierzalna zdolność do bezpiecznego dostarczania spadała.

Mechanizm stojący za tą liczbą jest prosty i dobrze udokumentowany w całej historii badań DORA: AI pozwala wygenerować więcej kodu w krótszym czasie, więc paczki zmian rosną, a większe paczki od lat są najpewniejszym predyktorem mniej stabilnych wdrożeń. Do tego dochodzi drugi efekt, tym razem po stronie przeglądu: kodu do sprawdzenia jest więcej, a czasu na przegląd tyle samo.

Warto dodać uczciwie, że obraz nie jest jednoznaczny i sam się zmienia. W edycji raportu z 2025 roku korelacja między używaniem narzędzi AI a spadkiem przepustowości już się nie utrzymała, natomiast problem ze stabilnością pozostał. Innymi słowy, branża nauczyła się utrzymywać tempo mimo AI, ale nie nauczyła się jeszcze utrzymywać z nim stabilności.

Problem oceny własnej pracy, który dotyka też metryk

Jest jeszcze jeden wynik, który powinien zmienić sposób czytania każdego wykresu produktywności. Organizacja METR przeprowadziła w 2025 roku randomizowany eksperyment: szesnastu doświadczonych programistów open source wykonało 246 zadań w projektach, które znali od lat, losowo z dostępem do narzędzi AI albo bez. Z AI pracowali o 19 procent dłużej. Przed badaniem spodziewali się przyspieszenia o 24 procent, a po jego zakończeniu nadal uważali, że AI przyspieszyło ich o 20 procent.

Autorzy zastrzegają, i słusznie, że wynik dotyczy konkretnej grupy w konkretnym momencie i nie dowodzi, że AI spowalnia wszystkich. Ale wniosek metodyczny jest uniwersalny: deklarowana produktywność i mierzona produktywność to dwie różne wielkości, które potrafią wskazywać w przeciwne strony. Trzy czwarte respondentów DORA deklarujących wzrost produktywności to dana o odczuciach, nie o wyniku. Metryki DORA miały być lekarstwem właśnie na takie deklaracje.

Do tego dochodzi obserwacja z ankiety Stack Overflow z 2025 roku, w której na pytania o AI odpowiedziało ponad 33 tysiące programistów. 66 procent wskazuje jako główną frustrację rozwiązania „prawie dobre, ale nie do końca”, a 45,2 procent zgadza się, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu niż napisanie go samemu. Ten czas nie znika. Przesuwa się z pisania na poprawianie, a w metrykach tempa wygląda jak przyspieszenie, dopóki nie spojrzy się na stabilność.

Które metryki nadal działają, a które trzeba czytać inaczej

Dobra wiadomość jest taka, że dwie z czterech metryk nie tracą wiarygodności. Odsetek nieudanych zmian i czas przywrócenia usługi mierzą skutek, a skutkowi jest obojętne, czy kod napisał człowiek, czy model. Awaria na produkcji jest awarią niezależnie od autorstwa. To właśnie dlatego para stabilnościowa staje się dziś ważniejsza niż para tempa, a nie na odwrót.

Co dołożyć do pomiaru, żeby znowu mówił o zespole

Cztery metryki wystarczały, gdy tempo pisania kodu było ograniczone przez człowieka. Gdy przestało być, potrzebne są dwie albo trzy dodatkowe wielkości, które pokazują koszt tego tempa. Wszystkie policzycie z danych, które już macie w Waszym repozytorium i w Waszym systemie zgłoszeń.

Ważne jest przy tym, żeby nowe metryki nie stały się kolejnym wykresem bez właściciela. Każda z tych trzech liczb powinna mieć osobę, która ją czyta raz w tygodniu, i próg, powyżej którego uruchamia rozmowę, a nie tylko komentarz na przeglądzie. Bez tego dokładanie metryk zwiększa jedynie liczbę slajdów, a wykres, którego nikt nie czyta, przestaje być metryką i zostaje tapetą do prezentacji kwartalnej.

Warto też oznaczać w repozytorium zmiany powstałe z istotnym udziałem narzędzia AI. Nie po to, żeby kogokolwiek rozliczać, tylko po to, żeby dało się porównać obie grupy na własnych danych, zamiast opierać się na cudzych raportach. Zespół, który po pół roku widzi, że zmiany z jednej grupy wracają dwa razy częściej, ma argument, którego nie da się podważyć opinią.

Co to zmienia w pracy zespołu testowego

Zespół QA jest w tej układance stroną, która odczuwa skutek najszybciej, a ma najmniejszy wpływ na przyczynę. Jeśli objętość zmian u Was rośnie, a liczba testerów nie, to każde kolejne wydanie jest sprawdzane pobieżniej niż poprzednie, nawet gdy nikt świadomie nie podjął takiej decyzji. Warto nazwać to wprost przy planowaniu, zanim pokaże to odsetek nieudanych zmian. W naszych projektach ten moment poznajemy po jednym sygnale: kolejka zmian czekających na przegląd rośnie szybciej niż cokolwiek innego w narzędziu do śledzenia pracy.

Praktyczna konsekwencja jest taka, że zmienia się rozkład pracy w zespole. Maleje wartość ręcznego sprawdzania rzeczy, które zmieniają się co tydzień, a rośnie wartość trzech innych rzeczy: utrzymania zestawu regresyjnego, który nadąża za tempem zmian, projektowania przypadków brzegowych, których model nie wymyśli, bo nie zna kontekstu biznesowego, oraz przeglądu wygenerowanych testów pod kątem tego, czy naprawdę sprawdzają to, co obiecują w nazwie.

Ta trzecia pozycja jest nowa i bywa niedoceniana. Test wygenerowany automatycznie, który przechodzi, ale nie weryfikuje warunku opisanego w swojej nazwie, jest gorszy niż brak testu, bo zajmuje miejsce w raporcie i buduje fałszywe poczucie pokrycia. Wykrycie takiego przypadku wymaga człowieka, który przeczyta test ze zrozumieniem, i to jest praca, której w metrykach DORA nie widać wcale, a która decyduje o tym, czy para metryk stabilnościowych będzie się trzymać. U naszych klientów właśnie krytyczna lektura wygenerowanych testów okazuje się kompetencją, która najszybciej odróżnia zespół gotowy na to tempo od zespołu, który je tylko deklaruje. Tę umiejętność ćwiczymy między innymi na kursie AI w testowaniu oprogramowania.

Nasza perspektywa

W Quality Island budujemy automatyzację testów i układamy procesy QA, więc patrzymy na te liczby od strony skutków, a nie od strony debaty o narzędziach. Z ponad 450 000 testów automatycznych napisanych dla ponad 100 firm wynika obserwacja, która pasuje do wyników DORA jak ulał: wąskim gardłem nigdy nie było pisanie kodu. Było nim sprawdzenie, czy ten kod nie zepsuł czegoś, co działało wczoraj.

Dlatego przyspieszenie samego pisania, bez zmiany po stronie weryfikacji, nie daje przyspieszenia dostarczania. Daje kolejkę przed tym samym wąskim gardłem, tylko dłuższą. To jest w liczbach DORA widoczne wprost: tempo rośnie, stabilność spada, a suma wychodzi na zero albo poniżej.

Drugi wniosek jest praktyczny. Jeśli w organizacji rośnie udział kodu generowanego przez AI, jedyną inwestycją, która realnie chroni stabilność, jest automatyczna regresja uruchamiana przy każdej zmianie. Ręczny przegląd nie skaluje się do tempa modelu, a testy manualne tym bardziej. Rachunek za to opóźnienie opisaliśmy osobno na Strefie QA w tekście o tym, jak w dużych projektach przestać bać się każdego wdrożenia.

Trzeci wniosek dotyczy zarządu. Metryki DORA weszły do prezentacji zarządczych, bo są proste i porównywalne. W erze AI proste porównanie zaczyna wprowadzać w błąd, więc warto raz przejść z zarządem przez rozróżnienie między tempem a stabilnością, zanim ktoś pochwali się wzrostem częstotliwości wdrożeń jako dowodem jakości. Jak przełożyć takie rzeczy na język finansowy, opisaliśmy w tekście KPI dla zarządu: jak przełożyć wyniki QA na język, który rozumie CFO.

Zanim pochwalicie się wzrostem częstotliwości wdrożeń, odpowiedzcie sobie na trzy pytania. Ile z Waszych zmian wraca na warsztat w ciągu doby od wdrożenia? Kto u Was czyta czas przeglądu na jednostkę zmiany i co się dzieje, gdy ten czas przestaje rosnąć razem z objętością kodu? I czy Wasza regresja nadąża za tempem, w jakim powstaje kod, czy tylko za tempem, w jakim przybywa testerów?

Powiązane na blogu Quality Island

• KPI dla zarządu: jak przełożyć wyniki QA na język, który rozumie CFO
• Jak mierzyć jakość oprogramowania
• Dług technologiczny pożera nawet 40% budżetu IT: gdzie w tym jest testowanie

Pełna lista źródeł

• DORA, Accelerate State of DevOps Report 2024, próba około 3 000 osób, wpływ adopcji AI na przepustowość i stabilność
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 16 programistów, 246 zadań
• Stack Overflow, 2025 Developer Survey, sekcja AI, ponad 33 tysiące odpowiedzi
• Quality Island, dane firmowe: ponad 450 000 napisanych testów automatycznych, ponad 100 firm korzystających z usług lub szkoleń