Ile naprawdę daje AI w zespole programistycznym? Jak mierzyć zwrot z inwestycji za pomocą metryk DORA

W skrócie Narzędzia AI są już codziennością w większości zespołów programistycznych, a zarządy coraz częściej pytają, co właściwie firma z nich ma. Odpowiedzi zwykle opierają się na danych od dostawców narzędzi, odsetku zaakceptowanych podpowiedzi albo na odczuciach samych programistów. Żadna z tych liczb nie dowodzi korzyści biznesowych. Niezależne badania pokazują wręcz, że programiści mogą mieć wrażenie, że z AI pracują szybciej, choć w rzeczywistości pracują wolniej, a szybsze pisanie kodu nie przekłada się automatycznie na szybsze i stabilniejsze wdrożenia. Wiarygodne wyliczenie zwrotu z inwestycji wymaga punktu odniesienia, kilku dobrze dobranych wskaźników i uczciwego zestawienia korzyści z kosztami. W tym artykule wyjaśniamy, dlaczego popularne liczby wprowadzają w błąd, co mierzyć zamiast nich i jak zorganizować pomiar, który obroni się przed dyrektorem finansowym.

Wrażenie to jeszcze nie wynik

Jeśli zapytać zespół korzystający z asystentów AI, czy pracuje wydajniej, większość odpowie, że tak. Kłopot w tym, że odczuwana wydajność i wydajność zmierzona to dwie różne rzeczy.

W połowie 2025 roku organizacja badawcza METR opublikowała wyniki randomizowanego badania z udziałem doświadczonych programistów open source, którzy pracowali nad dobrze znanymi sobie projektami. Przed badaniem uczestnicy spodziewali się, że dzięki AI będą pracować o 24% szybciej. W praktyce zadania wykonywane z pomocą narzędzi AI zajmowały im średnio o 19% więcej czasu. Co ciekawe, nawet po zakończeniu badania byli przekonani, że pracowali o około 20% szybciej.

Nie oznacza to, że narzędzia AI są bezużyteczne. Badanie dotyczyło konkretnych warunków, a inne analizy wykazywały korzyści w innych sytuacjach. Pokazuje jednak wyraźnie, że odczucia programistów nie są dobrą podstawą decyzji inwestycyjnych. To samo dotyczy liczb, które najczęściej pojawiają się w materiałach dostawców:

• Liczba wygenerowanych linii kodu nie mówi nic o tym, czy kod był potrzebny, poprawny i łatwy w utrzymaniu.
• Odsetek zaakceptowanych podpowiedzi pokazuje, jak często programiści klikają „akceptuj”, a nie to, czy zaakceptowany kod przyniósł jakąkolwiek wartość.
• Udział kodu napisanego przez AI może rosnąć, podczas gdy jakość i tempo wdrożeń spadają.

Szybsze pisanie kodu to nie to samo co szybsze wdrożenia

Pisanie kodu to tylko jeden z etapów, przez które przechodzi zmiana, zanim trafi na produkcję. Czas zajmują też doprecyzowanie wymagań, code review, testy, kontrole bezpieczeństwa, samo wdrożenie i usuwanie awarii. Jeśli AI przyspiesza wyłącznie pisanie kodu, wąskie gardło po prostu przesuwa się w inne miejsce. Osoby robiące code review dostają więcej i większych pull requestów, testy automatyczne nie nadążają, a zmiany czekają w kolejce.

Podobne zjawisko zaobserwował program badawczy DORA prowadzony przez Google. Z raportu za 2024 rok wynika, że większe wykorzystanie AI wiązało się wprawdzie z niewielką poprawą jakości dokumentacji, jakości kodu i tempa code review, ale jednocześnie z szacowanym spadkiem przepustowości wdrożeń o 1,5% i ich stabilności o 7,2% na każde 25% wzrostu wykorzystania AI. Badacze wskazują jedno z możliwych wyjaśnień: AI ułatwia przygotowywanie większych zmian, a duże zmiany trudniej bezpiecznie wdrożyć.

Wniosek nie brzmi więc „zrezygnujmy z AI”, tylko „mierzmy efekty na poziomie całego procesu”, a nie pojedynczych linijek kodu.

Co warto mierzyć

Sensowny model pomiaru obejmuje trzy poziomy: tempo i stabilność wdrożeń, jakość i płynność pracy oraz efekt biznesowy.

Tempo i stabilność wdrożeń: metryki DORA

Cztery metryki DORA stały się najpowszechniej stosowanym sposobem oceny tego, jak sprawnie zespół wprowadza zmiany na produkcję:

• Częstotliwość wdrożeń: jak często zespół wprowadza zmiany na produkcję.
• Czas realizacji zmiany: ile czasu mija od zatwierdzenia zmiany w kodzie do jej wdrożenia.
• Odsetek wdrożeń kończących się awarią: jaka część wdrożeń powoduje problem wymagający naprawy.
• Czas przywrócenia działania: jak szybko zespół przywraca normalną pracę systemu po awarii.

Ich siła polega na równowadze. Dwie metryki mierzą tempo, a dwie stabilność, więc zespół nie może poprawić jednej strony, po cichu poświęcając drugą.

Jakość i płynność pracy

Metryki DORA pokazują efekt, ale nie zawsze jego przyczynę. Kilka dodatkowych wskaźników pomaga zrozumieć, co się dzieje:

Efekt biznesowy

Na koniec wskaźniki trzeba powiązać z tym, co ważne dla firmy: czasem wprowadzenia nowych funkcji na rynek, mocami zespołu uwolnionymi na realizację roadmapy oraz kosztami awarii i poprawek. Właśnie na tym poziomie powstaje wyliczenie zwrotu z inwestycji.

Czego lepiej nie mierzyć

Równie ważne jest to, czego nie mierzyć: wyników poszczególnych programistów, liczby linii kodu ani wykorzystania AI przez konkretne osoby. Wskaźniki indywidualne zachęcają do „poprawiania” statystyk, podkopują zaufanie w zespole i niewiele mówią o jego rzeczywistych wynikach. Szczegółowa analiza pracy poszczególnych osób może też rodzić pytania z zakresu prawa pracy i RODO. Pomiar na poziomie zespołów i całego procesu jest więc nie tylko bardziej miarodajny, ale i prostszy od strony formalnej.

Jak zorganizować wiarygodny pomiar

1. Ustal punkt odniesienia przed wdrożeniem. Zbieraj dane przez co najmniej cztery do ośmiu tygodni, zanim wprowadzisz lub rozszerzysz narzędzia AI. Bez punktu odniesienia każda późniejsza poprawa pozostaje jedynie przypuszczeniem.

2. Zacznij od pilotażu i grupy porównawczej. Wprowadź AI najpierw w jednym lub dwóch zespołach, a podobne zespoły niech pracują tak jak dotąd. Pozwala to oddzielić wpływ AI od sezonowości, zmian organizacyjnych czy zmian w roadmapie.

3. Zbieraj dane automatycznie. System kontroli wersji, pipeline CI/CD i system zgłoszeń zawierają większość potrzebnych informacji. Automatyczne zbieranie danych jest bardziej wiarygodne i mniej obciąża zespół niż ręczne raportowanie. Znacznie ułatwiają to dobrze skonfigurowane pipeline’y CI/CD i uporządkowane utrzymanie środowisk chmurowych.

4. Uwzględnij czas na naukę. Zespoły często na początku pracują wolniej, zanim przyspieszą, bo muszą sprawdzić, w czym AI rzeczywiście pomaga, i dostosować sposób pracy. Wyniki warto oceniać po co najmniej jednym do trzech miesięcy, a nie po pierwszym tygodniu.

5. Połącz dane z opinią zespołu. Krótkie, regularne ankiety dotyczące satysfakcji, obciążenia i zaufania do wyników AI pomagają zrozumieć liczby i wychwycić problemy, zanim pojawią się we wskaźnikach.

6. Zmieniaj sposób pracy, a nie tylko narzędzia. Jeśli wydłuża się code review, pomogą mniejsze pull requesty lub przegląd kodu wspierany przez AI. Jeśli spada stabilność, trzeba wzmocnić testy automatyczne. Pomiar ma sens tylko wtedy, gdy prowadzi do zmian w sposobie pracy zespołu.

Od wskaźników do zwrotu z inwestycji: proste wyliczenie

Wiarygodne wyliczenie zwrotu z inwestycji zestawia realne korzyści z pełnymi kosztami. Poniższy przykład opiera się wyłącznie na przykładowych liczbach i ma jedynie pokazać sposób liczenia.

Firma zatrudnia 20 programistów, a pełny roczny koszt jednej osoby wynosi średnio 300 000 zł, co daje łącznie 6 mln zł rocznie. Po uporządkowanym wdrożeniu AI zmierzony wzrost efektywności netto w całym procesie wynosi 10%. Odpowiada to mocom zespołu o wartości około 600 000 zł rocznie, które można przeznaczyć na realizację roadmapy.

Po stronie kosztów trzeba uwzględnić licencje, program wdrożeniowy i szkolenia, czas poświęcony na przygotowanie procesów i pomiaru oraz ewentualny dodatkowy nakład pracy przy code review. Jeśli w pierwszym roku koszty te wyniosą 150 000 zł, korzyść netto to około 450 000 zł, czyli mniej więcej trzykrotność poniesionych nakładów.

Ważniejsze od konkretnych liczb są dwie zasady. Po pierwsze, liczy się zysk netto: czas zaoszczędzony przy pisaniu kodu, ale stracony na code review lub usuwaniu awarii, się nie liczy. Po drugie, uwolnione moce zespołu mają wartość tylko wtedy, gdy zostaną dobrze wykorzystane, na przykład na szybsze wprowadzenie funkcji z roadmapy albo spłatę długu technologicznego.

Jakie wyniki są realne

Uporządkowane wdrożenie AI rzadko podwaja wydajność zespołu programistycznego, ale może przynieść stałą i mierzalną poprawę. W projektach opisanych na naszej stronie poświęconej wykorzystaniu AI w pracy zespołów programistycznych udało się osiągnąć między innymi:

• skrócenie średniego czasu code review pull requestów o około 20–25%,
• wzrost pokrycia testami automatycznymi o około 15–20 punktów procentowych,
• poprawę częstotliwości wdrożeń o mniej więcej jeden poziom w skali dojrzałości DevOps,
• uwolnienie około 15% mocy zespołu na rozwój nowych funkcji,
• w regulowanym środowisku fintech: wzrost efektywności netto o około 10–15% przy niższym odsetku wdrożeń kończących się awarią i pełnym śladzie audytowym.

Na tle obietnic marketingowych to skromne liczby i właśnie dlatego są wiarygodne. Trwała, dwucyfrowa poprawa potwierdzona danymi z wdrożeń to mocny argument biznesowy.

Wyniki zależą jednak od punktu wyjścia. W dużych systemach legacy o niskim pokryciu testami trudno bezpiecznie czerpać korzyści z AI. W takiej sytuacji AI Refactoring Assessment pomaga ustalić, od czego zacząć modernizację.

Najczęstsze błędy

Zbyt wczesna ocena. Ocenianie AI po dwóch tygodniach mierzy etap nauki, a nie trwały efekt.

Mylenie korzystania z narzędzi z sukcesem. To, że zespół często używa AI, oznacza tylko tyle, że narzędzia są używane, a nie że firma na tym zyskuje.

Pomijanie stabilności. Szybsze wdrożenia okupione większą liczbą awarii to żaden zysk.

Mierzenie pracy poszczególnych osób. Wskaźniki indywidualne zniekształcają zachowania i podkopują zaufanie, bez którego rzetelny pomiar nie jest możliwy.

Brak punktu odniesienia. Bez danych wyjściowych nie da się przekonująco wykazać nawet realnej poprawy.

Bez pomiaru trudno o kolejny budżet

AI w pracy programistów przestaje być eksperymentem, a staje się stałą pozycją w budżecie. Firmy, które potrafią wykazać mierzalną poprawę tempa i stabilności wdrożeń, znacznie łatwiej uzasadnią kolejne inwestycje, a te, które opierają się na wrażeniach, będą napotykać coraz większy sceptycyzm dyrektorów finansowych i zarządów.

Te same pytania zadają inwestorzy. Podczas technicznego due diligence zespół, który może pokazać metryki DORA w ujęciu historycznym i wyjaśnić, jak AI wpłynęła na jego pracę, wyraźnie wyróżnia się na tle zespołu, który potrafi jedynie wymienić używane narzędzia. Jeśli chcesz wprowadzić lub rozszerzyć wykorzystanie AI w swoich zespołach, z jasnym punktem odniesienia i mierzalnymi wynikami, porozmawiajmy o tym, jak nasz program wdrażania AI w pracy zespołów programistycznych zaczyna się od krótkiego pilotażu i modelu pomiaru od pierwszego dnia.