DevEx, czyli produktywność deweloperów bez liczenia linijek kodu

Zdjęcie: AI, programowanie, kod

Im więcej kodu może dziś powstać w ciągu godziny, tym mniej jego ilość mówi o produktywności zespołu.

To nie jest wyłącznie efekt generatywnej AI. Problem z mierzeniem pracy programistów liczbą commitów, pull requestów, ticketów czy linii kodu był znany znacznie wcześniej. Framework SPACE, opracowany przez badaczy związanych z Microsoftem, GitHubem i University of Victoria, wychodzi właśnie z założenia, iż produktywności inżynierii systemu nie da się sprowadzić do jednej liczby. Obejmuje ona jednocześnie rezultaty pracy, aktywność, współpracę, satysfakcję oraz sprawność przepływu pracy.

Developer Experience, czyli DevEx, rozwija ten sposób myślenia. Zamiast pytać wyłącznie, ile pracy wykonano, pozwala przyjrzeć się warunkom, w których ona powstaje: długości pętli informacji zwrotnej, możliwości pracy bez ciągłych przerw oraz obciążeniu poznawczemu wynikającemu ze złożoności narzędzi, kodu i procesów.

W badaniach dotyczących DevEx deweloperzy dobrze rozumiejący kod, z którym pracują, oceniali własną produktywność o 42 proc. wyżej niż osoby mające z nim problemy. To interesująca zależność, ale nie należy mylić jej z obiektywnie zmierzonym 42-procentowym wzrostem wydajności. Dane opisują percepcję produktywności, nie liczbę dostarczonych funkcji czy czas ich wdrożenia.

Ta różnica staje się coraz ważniejsza wraz z upowszechnieniem AI.

DORA w 2024 roku stwierdziła, iż wzrost wykorzystania AI o 25 proc. był statystycznie związany z poprawą jakości dokumentacji o 7,5 proc., jakości kodu o 3,4 proc. oraz szybkości code review o 3,1 proc. Jednocześnie temu samemu wzrostowi wykorzystania AI towarzyszył szacowany spadek przepustowości procesu dostarczania o 1,5 proc. oraz stabilności o 7,2 proc. Nie był to eksperyment przyczynowy, ale zależności wykryte w danych ankietowych. Pokazują jednak istotne zjawisko: lokalne przyspieszenie pracy nie musi automatycznie przyspieszać całego procesu wytwarzania oprogramowania.

Rok później obraz częściowo się zmienił. DORA 2025 odnotowała już dodatnią zależność między wykorzystaniem AI a throughputem oraz wynikami produktu. przez cały czas utrzymywał się jednak negatywny związek ze stabilnością dostarczania. W badaniu 90 proc. specjalistów technologicznych deklarowało korzystanie z AI, ponad 80 proc. twierdziło, iż zwiększa ono ich produktywność, ale 30 proc. miało niewielkie lub żadne zaufanie do kodu generowanego przez modele.

Warto zatrzymać się właśnie przy słowie „deklarowało”.

Eksperyment METR z 2025 roku dobrze pokazuje, dlaczego samoocena może być zdradliwa. Szesnastu doświadczonych programistów wykonywało 246 rzeczywistych zadań w projektach open source, które znali średnio od około pięciu lat. Zadania losowo wykonywano z możliwością wykorzystania AI lub bez niej. Programiści zakładali wcześniej, iż narzędzia skrócą czas pracy o 24 proc. Po eksperymencie przez cały czas sądzili, iż były szybsze o około 20 proc.

Pomiar pokazał coś przeciwnego: przy wykorzystaniu ówczesnych narzędzi AI potrzebowali średnio 19 proc. więcej czasu.

Nie jest to dowód, iż AI spowalnia rozwój oprogramowania. Próba była niewielka, dotyczyła bardzo doświadczonych osób pracujących nad dobrze znanymi sobie repozytoriami, a narzędzia rozwijają się wyjątkowo szybko. Sam METR w lutym 2026 roku opublikował nowsze dane sugerujące możliwość przyspieszenia pracy, ale zrezygnował z formułowania mocnego wniosku ze względu na rosnący selection bias i problemy z metodologią pomiaru.

Właśnie dlatego DevEx staje się interesujący biznesowo. Nie dlatego, iż dostarcza kolejny syntetyczny wskaźnik produktywności, ale dlatego, iż kieruje uwagę na miejsca, w których rzeczywiście ginie czas.

Może nim być oczekiwanie na build, ręczna konfiguracja środowiska, zbyt wolny code review, nieczytelna architektura, brak dokumentacji albo proces wdrożenia wymagający szeregu działań wykonywanych przez ludzi. To koszty rozproszone po organizacji i dlatego łatwe do przeoczenia.

DORA od lat traktuje lead time, częstotliwość wdrożeń, czas odzyskania po nieudanym wdrożeniu oraz wskaźniki awaryjności jako miary całego systemu dostarczania oprogramowania, a nie produktywności pojedynczego człowieka. Dzisiejszy model obejmuje pięć takich wskaźników i rozdziela przepustowość od niestabilności procesu.

Podobną rolę odgrywają mniej spektakularne elementy. W badaniu DORA z 2021 roku tylko około jednej czwartej respondentów deklarowało dobrą jakość dokumentacji, a zespoły z lepszą dokumentacją miały 2,4 raza większe prawdopodobieństwo osiągania lepszych wyników w obszarze dostarczania systemu i operacji. To zależność obserwacyjna, nie prosta recepta, ale dobrze pokazuje, gdzie mogą kryć się rzeczywiste ograniczenia produktywności.

Generowanie kodu staje się coraz tańsze. Droższe może okazać się wszystko, co następuje później: zrozumienie zmiany, jej weryfikacja, integracja, testowanie i bezpieczne wdrożenie.

Dlatego produktywność zespołów technologicznych coraz mniej przypomina rachunek wykonanej pracy. Bardziej przypomina pomiar sprawności systemu, który zamienia kod w działającą zmianę. I właśnie tam znajduje się różnica między dużą ilością aktywności a rzeczywistą zdolnością organizacji do poruszania się szybciej.