Pomiar skuteczności AI: metryki dla zespołów inżynieryjnych

# Jak nie dać się oszukać: obiektywne metryki efektywności AI w rozwoju oprogramowania

Jak nie dać się oszukać: obiektywne metryki efektywności AI w rozwoju oprogramowania

Wprowadzanie narzędzi AI do procesu rozwoju oprogramowania często towarzyszy iluzja wzrostu produktywności. Bez odpowiednich metryk i poziomu bazowego nie odróżnisz rzeczywistego efektu od naturalnego rozwoju zespołu. Omawiamy, które wskaźniki naprawdę działają, jak unikać pułapek i jak case study z 35 inżynierami pokazało, że subiektywne wrażenie +20% zamienia się w obiektywne -19%.

Dlaczego poziom bazowy to warunek konieczny

Typowy błąd przy ocenie AI to brak punktu odniesienia. Zespoły wdrażają narzędzie, a po kwartale zadają pytanie: «Co się zmieniło?» Odpowiedzieć jest niemożliwe, jeśli nie zarejestrowano stanu przed startem.

Do obiektywnej oceny konieczne jest śledzenie czterech grup metryk od samego początku:

• Udział kodu AI w commitach (AI-share): procent linii wygenerowanych przez AI i zaakceptowanych w ostatecznym kodzie. Dane pobiera się z logów Copilot, a nie z git, aby uwzględnić nie tylko zaakceptowany kod, ale i proces (prompty, refaktoring, analiza legacy).
• Czas na zadanie: mierzy się poprzez analizę sesji w Copilot. Model językowy przetwarza dialog developera, określa zadanie i szacuje zużyty czas. To eliminuje subiektywne raporty.
• Metryki DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR — ale z zastrzeżeniami (o nich niżej).
• Tygodniowe ankiety zespołu: anonimowe pytania o zadowolenie z narzędzia i postrzeganie jego użyteczności.

Bez tych danych nie oddzielisz efektu AI od innych czynników: wzrostu zespołu, uproszczenia produktu czy naturalnej poprawy procesów.

Case study: dynamika acceptance rate i rozkład zadań

W projekcie z udziałem 35 inżynierów (18 backend, 13 frontend, 4 QA automation) obserwowaliśmy krzywą U-shaped w acceptance rate:

| Tydzień | Acceptance rate, % |

|---------|---------------------|

| 1 | 6 |

| 2 | 5 |

| 3 | 6 |

| 4 | 4 |

| 5 | 1 |

| 6 | 1 |

| 7 | 20 |

| 8 | 20 |

| 9 | 12 |

| 10 | 9 |

| 11 | 11 |

Minimum na 5-6 tygodniu to sygnał przejścia do skomplikowanych scenariuszy. Skok na 7-8 tygodniu — zespół opanował efektywne wzorce. Ważne: płaska linia acceptance rate (np. 40%) jest gorsza niż krzywa U-shaped. Wskazuje na używanie AI tylko do typowych operacji (dokumentacja, CRUD), a nie do refaktoringu czy projektowania.

Ponadto acceptance rate nie można brać jako KPI developera. Przy ocenie tą metryką rośnie liczba naciśnięć Tab, ale spada jakość kodu.

Rozkład zadań według typów:

• Refaktoring: 28%
• Debugowanie: 26%
• Generowanie nowego kodu: 19%
• Poprawianie błędów: 8%
• Code-review: 5%
• Inne: 14%

Na prostych zadaniach AI daje stabilne przyspieszenie. Na skomplikowanych działa jak «drugi pilot», wymagając udziału developera.

Rzeczywista oszczędność czasu: jak liczyć bez złudzeń

Biznesowi potrzebne są nie procenty, a godziny. Zastosowaliśmy metodę kontrfaktyczną: porównaliśmy czas na podobne zadania przed i po wdrożeniu AI.

Wyniki dla zespołu 35 osób:

• Etap początkowy: 13.5 godziny na developera miesięcznie (86.5 godziny na zespół)
• Faza dojrzała: 27.7 godziny na developera miesięcznie (177.3 godziny na zespół)

Dane z logów Copilot, a nie z git. Git pokazuje udział linii AI w commicie, ale nie odzwierciedla rzeczywistego czasu na zadanie. Oszczędność w godzinach bezpośrednio przekłada się na pieniądze — to zrozumiałe dla dyrektorów finansowych.

W skali 50 inżynierów i 27 700 sugestii miesięcznie zarejestrowaliśmy:

• Acceptance rate: 87% (przy przemysłowej średniej 25-35%)
• Zadowolenie: 87% developerów
• Stałe użytkowanie: 65% developerów

Rozbieżność między «podoba się» (87%) a «stało się nawykiem» (65%) to normalne zjawisko. Aby ją zmniejszyć, integruj AI z rutynowymi zadaniami i śledź rozbieżność tygodniowo.

DORA i AI: ślepe punkty i dodatkowe metryki

Metryki DORA (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) pozostają użyteczne, ale mają ślepe punkty przy użyciu AI:

• DORA nie widzi AI: wzrost Deployment Frequency może wynikać z generowania większej ilości kodu przez AI, ale jednocześnie pogarsza się Change Failure Rate z powodu złożoności rewizji kodu AI. DORA rejestruje liczby, ale nie wyjaśnia przyczyny.
• Wrażliwość na optymalizację: zespół może sztucznie podnosić Deployment Frequency, dzieląc zadania na małe deploje, bez rzeczywistego postępu.

Dla pełnego obrazu dodaj:

• AI-share: udział linii AI w commicie (z logów Copilot). Bez tego nie połączysz wzrostu DORA z AI.
• Code churn rate: procent kodu AI przepisany w ciągu pierwszych 30 dni po mergu. Wysoki acceptance rate przy wysokim churn wskazuje na niską jakość wygenerowanego kodu.
• Complexity-adjusted throughput: przepustowość skorygowana o złożoność zadań. Standardowa metryka DORA Deployment Frequency liczy liczbę depoyów, ale nie złożoność. Na przykład: trzy deploje po 1 story point (razem 3) vs jeden deploje po 5 story points. AI rozwiązujące tylko małe zadania nie poprawia rzeczywistej przepustowości.

Kontrmetyki: równowaga prędkości i jakości

Badanie METR pokazało: subiektywna ocena przyspieszenia +20% zamienia się w obiektywne spadku o 19%. Koszty na prompty, weryfikację i rewizję pochłaniają cały hipotetyczny zysk. Dlatego prędkość bez kontroli jakości wprowadza w błąd.

Porównuj metryki prędkości z kontrmetrami:

| Metryka prędkości | Kontrmetrika |

|---------------------------|----------------------------------------------|

| Acceptance rate | % kodu AI przepisanej przy rewizji |

| Prędkość pisania kodu | Defekty po mergu |

| Liczba wygenerowanych testów | Mutation score (nie coverage) |

| Deployment Frequency | Change Failure Rate |

| Czas cyklu PR | Liczba rund rewizji |

Mutation score jest szczególnie ważny: sprawdza, na ile testy naprawdę łapią błędy. W przeciwieństwie do coverage, które pokazuje pokryty kod, mutation score wprowadza sztuczne błędy (np. zmienia + na -) i sprawdza, czy test je wykrywa. Niski mutation score przy wysokim coverage to znak słabych testów.

Co najważniejsze: kluczowe wnioski

• Rejestruj baseline przed wdrożeniem: bez punktu odniesienia nie udowodnisz efektu AI.
• Mierz czas na zadanie, nie acceptance rate: rzeczywista oszczędność wyraża się w godzinach, nie w procentach.
• Porównuj prędkość i jakość: każda metryka prędkości powinna mieć parę kontrmetrów jakości.
• Uwzględniaj złożoność zadań: Complexity-adjusted throughput pokazuje rzeczywisty postęp, a nie sztuczne windowanie depoyów.
• Nie rób z acceptance rate KPI: prowadzi to do spadku jakości i zniekształcenia danych.

— Editorial Team