Umów rozmowę
Artykuł · AI-DLC i wytwarzanie oprogramowania

Jak mierzyć produktywność programistów z AI: co działa, co myli

Produktywność programistów z AI mierz w zespole przed wdrożeniem i po nim: czas dostarczania, stabilność, koszt. Odczucia mylą: w badaniu METR programiści czuli zysk 20%, a zadania trwały 19% dłużej.

Dla: CTO, VP Engineering, szefowie zespołów, finanse IT · Stan na 02.11.2026 · Autor: Karol Krawczyk

Czy AI przyspiesza programistów według badań METR i Microsoftu?

Badania wpływu AI na produktywność programistów dają wyniki o przeciwnych znakach, a różnice mogą wynikać z tego, kogo i co mierzono. Dwie serie badań z losowym przydziałem warto znać z nazwy, bo mają silniejszy projekt niż ankiety i dane dostawców.

METR w 2025 roku zbadał 16 doświadczonych programistów przy 246 zadaniach w dużych projektach open source, które znali od lat. Z dostępem do AI zadania trwały o 19% dłużej (przedział ufności od +2% do +39%). Ten sam zespół opublikował w lutym 2026 aktualizację z końca 2025 roku: 57 programistów, ponad 800 zadań. Dziesięć osób z pierwszego badania było o 18% szybszych (od -38% do +9%), nowo zrekrutowani o 4% (od -15% do +9%). Oba przedziały obejmują zero. METR nazywa te dane bardzo słabym dowodem wzrostu i podejrzewa zaniżenie, bo część programistów nie chciała pracować bez AI i odmawiała udziału albo wycofywała zadania.

Po drugiej stronie jest praca Cui i współautorów, w wersji z czerwca 2025: trzy eksperymenty w Microsoft, Accenture i anonimowej firmie z listy Fortune 100, obejmujące 4867 programistów. Dostęp do GitHub Copilot dał 26,08% więcej ukończonych zadań, mierzonych tygodniową liczbą pull requestów, z dużym błędem standardowym 10,3%. Autorzy opisują każdy eksperyment jako zaszumiony. Najwięcej zyskali mniej doświadczeni. Tu mierzono ukończone zadania w firmach, tam czas doświadczonych opiekunów własnych projektów. Żadnego z tych wyników nie można podstawić do arkusza z oszczędnościami dla swojej firmy.

Znaczenie ma też rodzaj pracy. InfoQ 11 maja 2026, omawiając raport DORA o zwrocie, cytuje badania Stanfordu: 35 do 40% zysku przy prostych nowych zadaniach i 10% lub mniej przy złożonym starym kodzie. Firma z dużym systemem legacy nie powinna przyjmować wyników z zadań greenfield, a METR w 2025 roku zastrzegł wprost, że jego wynik nie obejmuje mniej doświadczonych osób ani nieznanych baz kodu.

Dlaczego ankieta nie wystarczy do pomiaru produktywności z AI

W badaniu METR z 2025 roku programiści spodziewali się przyspieszenia o 24%, a po zakończeniu oceniali je na 20%, choć pomiar pokazał spowolnienie. Pod tym kątem trzeba czytać duże ankiety. W raporcie DORA 2025, według wpisu Google Cloud opartym na niemal 5000 odpowiedzi, ponad 80% uważa, że AI zwiększyło ich produktywność. W Stack Overflow 2025 około 69% użytkowników agentów zgadza się ze zdaniem, że agenci zwiększyli ich produktywność, a wstęp tej samej strony podaje 52% dla szerszej grupy. Strona o AI w wydaniu 2026 nie ma pytania o produktywność.

Ankiety dobrze wykrywają tarcia. Około 66% badanych przez Stack Overflow w 2025 roku narzekało na rozwiązania AI, które są prawie dobre, a 45,2% stwierdziło, że debugowanie kodu z AI zajmuje więcej czasu. Takie pytania warto zadawać co kwartał, bo pokazują, gdzie się traci czas. Nie nadają się natomiast do uzasadnienia wydatków.

Dlaczego dashboard GitHub Copilot nie mierzy zysku z AI

Metryki GitHub Copilot pokazują adopcję, aktywność, generowany kod i cykl życia pull requestów, w tym medianę czasu do scalenia. Linie kodu GitHub sam nazywa widokiem kierunkowym i radzi szukać wzorców zamiast patrzeć na jedną liczbę. Dane mają luki: czat na GitHub.com nie jest liczony, a przy zablokowanej telemetrii część szczegółów jest pusta. To dobre źródło do pytania "kto używa", słabe do pytania "co firma z tego ma".

Więcej kodu może oznaczać więcej pracy po stronie recenzentów i utrzymania. DORA w tekście z 10 marca 2026 odradza opieranie się na liniach kodu, a ta sama organizacja stwierdza, że adopcja AI wiąże się ze wzrostem przepustowości i spadkiem stabilności dostarczania. Anthropic podał 9 marca 2026, że ilość kodu na inżyniera wzrosła u nich o 200% w ciągu roku. To informacja o produkcji kodu, której bez danych o błędach i wartości nie da się przełożyć na zysk. Do tego dochodzi prawo Goodharta: DORA ostrzega, że ogólne cele liczbowe zachęcają zespoły do oszukiwania wskaźników. Dlatego metryk AI nie wolno wiązać z oceną pracownika.

Metryki przy wdrożeniu AI w zespole programistów

Forsgren i współautorzy w pracy o modelu SPACE z 2021 roku zauważyli, że produktywności programistów nie da się zmierzyć jedną metryką. Dla decyzji o AI wystarczy krótki zestaw na poziomie zespołu i usługi, liczony tak samo przed wdrożeniem i po nim:

  • Przepustowość według DORA: czas od commita do wdrożenia, częstotliwość wdrożeń, czas odzyskiwania po nieudanym wdrożeniu.
  • Niestabilność według DORA: odsetek wdrożeń wymagających natychmiastowej interwencji i odsetek nieplanowanych wdrożeń wywołanych incydentem.
  • Przegląd: czas oczekiwania na pierwszego recenzenta, wielkość zmiany i część poprawek po przeglądzie.
  • Koszt: wydatki na licencje i kredyty AI w przeliczeniu na wdrożoną zmianę.
  • Doświadczenie zespołu: krótka ankieta o tarciach, bez pytania o procent oszczędzonego czasu.

Jak zmierzyć wpływ AI na produktywność w firmie?

Pomiar wpływu AI w firmie wymaga najpierw punktu odniesienia, czyli kilku miesięcy danych sprzed zmiany. Jeśli narzędzia są już wdrożone, zostaje porównanie z własnym trendem przed rozszerzeniem użycia agentów. Dobrym rozwiązaniem jest wdrażanie falami: część zespołów dostaje dostęp lub nowy zakres wcześniej, a reszta jest grupą porównawczą. Tak działały eksperymenty w Microsoft i Accenture, prowadzone w ramach zwykłych operacji firm.

Pierwsze miesiące mogą wyglądać gorzej. Raport DORA o zwrocie z inwestycji, w omówieniu InfoQ z maja 2026, zapowiada przejściowy spadek produktywności z powodu nauki, sprawdzania kodu i dostosowania testów. Jego wyliczenie dla hipotetycznej firmy z 500 inżynierami (39% ROI, zwrot po około 8 miesiącach) jest przykładem modelowym, nie pomiarem. Warto też przejąć wnioski z problemów METR: przy kilku równoległych agentach ręczne rejestrowanie czasu przestało być wiarygodne, a programiści zmieniali dobór zadań. Pomiar z systemów, nie z deklaracji, omija oba kłopoty, choć wymaga kontroli, czy miks zadań się nie przesunął.

Wyniki czyta się parami. Krótszy czas dostarczania przy rosnącym odsetku nieudanych wdrożeń oznacza, że część zysku wraca jako poprawki. Szybsze scalanie przy dłuższym oczekiwaniu na recenzenta oznacza przesunięcie kolejki. Ten sam przykład DORA, znany tu tylko z omówienia InfoQ, pokazuje skalę: założony wzrost odsetka nieudanych zmian z 5% do 6% obniża wynik o 344 tys. dolarów, ale zostawia bilans na plusie. Model zależy więc od założeń, które firma powinna podstawić z własnych danych.

Kiedy nie liczyć ROI z narzędzi AI dla programistów

ROI z AI nie warto liczyć w małym zespole, bo efekt trudno tam odróżnić od szumu. METR w aktualizacji z lutego 2026, mając 57 osób i ponad 800 zadań, nie wyszedł poza niepewność, więc zespół dziesięcioosobowy po kwartale zobaczy pewnie głównie szum, zwłaszcza gdy równolegle zmienił się produkt albo skład. To wniosek tego tekstu, nie obliczenie mocy statystycznej. Tam lepiej śledzić kilka wskaźników stabilności i kosztów i nie deklarować procentów. Podobnie w firmie bez spójnych danych o wdrożeniach: najpierw trzeba zbudować pomiar, a potem dyskutować o jego wyniku.

Co zrobić w firmie

  1. Zbierz dane DORA z systemów CI/CD i repozytorium dla kilku ostatnich miesięcy, osobno dla każdej usługi
  2. Dodaj czas oczekiwania na przegląd, wielkość zmiany oraz koszt AI na wdrożoną zmianę
  3. Wdrażaj agentów falami, zostawiając zespoły porównawcze na ustalony czas
  4. Prowadź kwartalną ankietę o tarciach, bez pytań o procent zaoszczędzonego czasu
  5. Rozliczaj zespoły, nie osoby, i nie wiąż tych metryk z ocenami pracowników
  6. Po pierwszych dwóch kwartałach oceniaj przepustowość razem ze stabilnością i dopiero wtedy decyduj o rozszerzeniu

Powiązane materiały

Źródła

Chcesz przełożyć to na swój zespół?

Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.

Umów rozmowęOferta dla firm

Więcej: AI-DLC i wytwarzanie oprogramowania

← Wszystkie artykuły