Poniższy artykuł to notatki z prezentacji Yegora Denisov-Blanch ze Stanford University pt. „Does AI Actually Boost Developer Productivity? (100k Devs Study)” Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od autora badania oraz jego zespołu naukowego.

TL;DR

AI zwiększa produktywność developerów średnio o 15-20%, jednak początkowe wrażenie 30-40% wzrostu to złudzenie spowodowane koniecznością naprawiania błędów
Największe korzyści: proste zadania w nowych projektach (30-40%), najmniejsze: złożone projekty w istniejących systemach (0-10%)
Popularne języki jak Python czy JavaScript przynoszą lepsze rezultaty niż niszowe technologie jak COBOL czy Haskell
Rozmiar ma znaczenie: większe bazy kodu = mniejsze korzyści z AI z powodu ograniczeń kontekstu
10% developerów to „ghost engineers” – osoby pobierające pensję, ale praktycznie niepracujące
Wydajność AI spada drastycznie wraz z rozmiarem kontekstu – z 90% do 50% już przy 32k tokenów
Ankiety są bezużyteczne – programiści mylą się w ocenie własnej produktywności o około 30 punktów percentylowych

Wypowiedź Marka Zuckerberga z początku roku wywołała prawdziwe trzęsienie ziemi w świecie technologii. CEO Meta zapowiedział bowiem, że do końca roku zastąpi wszystkich programistów średniego szczebla sztuczną inteligencją. Deklaracja była prawdopodobnie bardziej wizjonerska niż realistyczna, mimo to skutecznie zmobilizowała każdego CTO na świecie do pilnego sprawdzenia, gdzie ich zespół znajduje się w tej „podróży”.

Metodologia największego badania na świecie

Denisov-Blanch wraz ze swoim zespołem ze Stanford prowadzi od trzech lat jedno z największych badań produktywności w inżynierii oprogramowania. Badacze analizują dane z ponad 100 000 programistów z 600+ firm – od startupów po duże korporacje.

W skład zespołu wchodzą między innymi Simon z branży (były CTO unicornu z 700 developerami, który zawsze jako ostatni dowiadywał się o problemach w zespole) oraz profesor Michał Kosiński, specjalista od zachowań człowieka w środowisku cyfrowym. Ten sam, który był sygnalistą afery Cambridge Analytica.

Kluczową przewagą tego badania jest dostęp do prywatnych repozytoriów. W przeciwieństwie do publicznych projektów, gdzie programista może pracować sporadycznie, prywatne repozytorium odzwierciedla rzeczywistą produktywność zespołu.

Badanie ma podwójny charakter: szeregi czasowe (nawet jeśli developer dołącza w 2025, zespół ma dostęp do całej jego historii git) oraz przekrojowe (600+ różnych firm). Dzięki temu można obserwować trendy przez COVID, wprowadzenie AI i inne zmiany na dziesiątkach milionów commitów i miliardach linii kodu.

Dlaczego poprzednie badania mijają się z prawdą

Według Denisov-Blanch, większość dotychczasowych analiz ma trzy fundamentalne ograniczenia:

Błędne metryki – skupiają się na liczbie commitów czy PR-ów, ignorując różny rozmiar zadań. AI często wprowadza nowe zadania polegające na naprawianiu błędów w kodzie, który właśnie wygenerował – to „kręcenie się w kółko”
Sztuczne warunki testowe – eksperymenty A/B na zadaniach w nowych projektach, gdzie developerzy budują coś od zera. AI tam faktycznie dominuje, jednak większość prawdziwej pracy nie polega na pisaniu kodu od podstaw
Ankiety jako źródło danych – programiści mylą się w ocenie własnej produktywności średnio o 30 punktów percentylowych

Ankiety okazały się praktycznie bezużyteczne. W eksperymencie z 43 programistami Denisov-Blanch poprosił każdego o ocenę własnej produktywności względem globalnej mediany w przedziałach co 5% (od 0 do 100%). Tylko jeden na trzech trafił we właściwą ćwiartkę, z kolei wartość predykcyjna była „jak rzucanie monetą”.

Jak mierzyć produktywność – metodologia Stanford

W idealnym świecie każdy kawałek kodu byłby oceniany przez panel 10-15 ekspertów, którzy osobno (nie znając odpowiedzi innych) oceniliby go pod kątem jakości, utrzymywalności i użyteczności. Denisov-Blanch odkrył dwie kluczowe rzeczy: eksperci rzeczywiście się zgadzają między sobą, a taki panel potrafi przewidzieć rzeczywistość.

Problem? To rozwiązanie jest wolne, drogie i niemożliwe do przeskalowania. Dlatego zespół Stanford zbudował model, który automatyzuje ten proces. Model analizuje zmiany w kodzie źródłowym każdego commita i mierzy je na podstawie wielu wymiarów.

Kluczowe założenie: produktywność zespołu to funkcjonalność dostarczanego kodu w czasie, nie liczba linii czy commitów. Metodologia ta pozwala odróżnić nową wartość od tzw. „reworku” – czasu straconego na poprawianie niedawno napisanego kodu. Właśnie ten wskaźnik gwałtownie rośnie po wdrożeniu AI.

Rzeczywisty wpływ AI: 15-20% vs 30-40%

Analiza jednej ze firm wprowadzających AI w zespole 120 programistów pokazuje charakterystyczny wzorzec. We wrześniu, gdy wdrożono narzędzia AI, widać natychmiastowy wzrost objętości kodu.

Szczegółowa analiza rozróżnia jednak dodaną funkcjonalność (zielony), usunięty kod (szary), refaktoryzację (niebieski) i rework (pomarańczowy). Rework to zmiany w bardzo świeżym kodzie – praktycznie zawsze oznacza to marnotrawstwo.

Po wprowadzeniu AI drastycznie wzrasta ilość rework. Programiści czują, że dostarczają więcej, bo jest więcej commitów i aktywności w repozytorium, jednak tradycyjne metryki, takie jak liczba commitów, okazują się mylące, gdyż duża część aktywności to poprawianie błędów wygenerowanych przez samo AI.

W rezultacie Denisov-Blanch szacuje, że AI zwiększa generowanie kodu o 30-40%, ale po odjęciu czasu na naprawianie błędów i problemów, netto produktywność rośnie o 15-20%.

Kiedy AI działa najlepiej, a kiedy najgorzej

Złożoność zadania i dojrzałość projektu

Analiza rozkładu zysków produktywności pokazuje wyraźne wzorce. Ważny szczegół: wykresy zaczynają się od -20%, co oznacza, że AI może faktycznie obniżać produktywność w niektórych przypadkach.

Matrix prezentowany przez Denisov-Blanch (oparty na 136 zespołach z 27 firm):

«GREENFIELD» (nowe projekty):

Proste zadania: 30-40% zysku
Złożone zadania: 10-15% zysku

«BROWNFIELD» (istniejące projekty):

Proste zadania: 15-20% zysku
Złożone zadania: 0-10% zysku

«Greenfield» oznacza pisanie od zera, z kolei «brownfield» to praca z istniejącym kodem. AI radzi sobie doskonale z kodem szablonowym i standardowymi wzorcami, ale ma problemy z kontekstem istniejących systemów.

Popularność języka programowania

AI trenowano głównie na popularnych językach. W rezultacie skuteczność drastycznie różni się między technologiami:

POPULARNE JĘZYKI (wysokie zyski):

Python, JavaScript, Java, TypeScript
Zyski: 10-20% nawet dla złożonych zadań

NISZOWE JĘZYKI (minimalne zyski lub straty):

COBOL, Haskell, Elixir
Mogą obniżać produktywność przez błędne sugestie
Programiści przestają używać AI (pomaga tylko 2/5 razy)
Dotyczy to jedynie 5-10% globalnej pracy developmentu

Denisov-Blanch podkreśla, że większość rzeczywistej pracy programistycznej odbywa się w popularnych językach, gdzie AI przynosi wyraźne korzyści.

Ograniczenia techniczne AI w kodowaniu

Rozmiar bazy kodu vs skuteczność AI

Denisov-Blanch prezentuje teoretyczny wykres na skali logarytmicznej od 1000 do 10 milionów linii kodu. Im większy projekt, tym mniejsze korzyści – spadek jest gwałtowny z każdym rzędem wielkości.

Większość współczesnych projektów to więcej niż 1000 linii kodu. Mimo to im większy projekt, tym mniejsze korzyści z AI przez trzy kluczowe czynniki:

Ograniczenia okna kontekstu – modele mają problem z przetwarzaniem bardzo dużych kontekstów
Gorszy stosunek sygnału do szumu – AI gubi się w złożonych strukturach
Więcej zależności i logiki specyficznej – unikalne rozwiązania domenowe są trudne do zrozumienia

Problem okna kontekstu

Badanie Nolima cytowane przez Denisov-Blanch pokazuje niepokojący trend. Wydajność modeli językowych w zadaniach kodowania spada z 90% do około 50% już przy 32 000 tokenów.

To kluczowe odkrycie, bo modele jak Gemini 1.5 Pro mają okno kontekstu 2 milionów tokenów. Intuicyjnie można by sądzić, że wystarczy „wrzucić” całą bazę kodu i AI będzie działać perfekcyjnie. Rzeczywistość jest jednak brutalna – przy 32k tokenów wydajność już maleje o połowę.

Praktyczne wnioski dla zespołów

AI faktycznie zwiększa produktywność developerów średnio o 15-20%, jednak skuteczność zależy od konkretnego kontekstu. Kluczem jest świadome używanie w odpowiednich scenariuszach.

✅ Używaj AI śmiało, gdy:

Pracujesz nad nowym projektem lub wyizolowanym modułem (greenfield) – tu można oczekiwać 30-40% zysku
Zadanie ma niską złożoność – kod szablonowy, testy jednostkowe, standardowe wzorce
Korzystasz z popularnego języka – Python, JavaScript, Java, TypeScript
Baza kodu jest stosunkowo mała – poniżej kilkuset tysięcy linii i ma niewiele niestandardowych zależności

⚠️ Zachowaj szczególną ostrożność, gdy:

Pracujesz nad dojrzałym, złożonym systemem z wieloletnią historią (brownfield) – zyski mogą być minimalne (0-10%)
Zadanie wymaga głębokiego zrozumienia unikalnej logiki biznesowej
Kodujesz w niszowym języku – COBOL, Haskell, Elixir mogą dać negatywne rezultaty
Baza kodu jest bardzo duża – ponad milion linii kodu z kompleksowymi zależnościami

Szybki test: czy to zadanie dla AI?

Punktuj każdy element 0-2 punkty:

Język popularny (Python/JS/Java = 2pkt, niszowy = 0pkt)
Zadanie proste (kod szablonowy/CRUD = 2pkt, algorytmy = 0pkt)
Nowy kod (nowy projekt = 2pkt, legacy = 0pkt)
Mały kontekst (<10k linii = 2pkt, >100k = 0pkt)

Wynik:

6-8 punktów: AI będzie bardzo pomocne (oczekuj 20-40% zysku)
3-5 punktów: AI może pomóc, ale obserwuj efekty
0-2 punkty: lepiej pisać samodzielnie lub używać AI bardzo ostrożnie

Ghost engineers – ukryty problem branży

Jako kontrowersyjne odkrycie Denisov-Blanch wspomina o zaskakującym wyniku swojego zespołu. Około 10% programistów w ich próbie to „ghost engineers” – ludzie pobierający pensję, ale praktycznie nie wykonujący pracy.

Odkrycie wywołało burzę, a Elon Musk nawet zretweetował wyniki badania. Dla niektórych było to zaskoczenie, dla innych – potwierdzenie podejrzeń. Problem pokazuje szerszy kontekst: mierzenie produktywności w programowaniu to wyzwanie samo w sobie, a AI dodaje kolejną warstwę złożoności.

Gdzie znajdziesz więcej

Wszystkie szczegóły badania oraz aktualne wyniki można znaleźć w portalu badawczym zespołu: softwareengineeringproductivity.stanford.edu

Kluczowy insight

Paradoks malejącego kontekstu AI

Standardowo myślimy: Im większe okno kontekstowe w modelu AI, tym lepiej, bo można dostarczyć więcej informacji i uzyskać idealną odpowiedź. Wszyscy czekają na modele z milionami tokenów kontekstu.

W praktyce okazuje się, że: Wydajność modeli AI w zadaniach programistycznych drastycznie spada wraz ze wzrostem okna kontekstowego – z 90% do 50% już przy 32k tokenów. Model gubi się w szumie informacyjnym i traci zdolność do odnalezienia kluczowego sygnału.

Dlaczego to jest istotne: Obala mit, że przyszłe modele z milionami tokenów kontekstu automatycznie rozwiążą problemy w złożonych projektach. Kluczem do sukcesu jest precyzja, a nie objętość dostarczanych informacji.

Test na jutro: Następnym razem gdy AI da ci słabą odpowiedź na złożone pytanie, zamiast dodawać jeszcze więcej kontekstu (kolejne pliki), spróbuj radykalnie go ograniczyć do jednego, precyzyjnego fragmentu kodu, który jest sednem problemu, i sprawdź czy odpowiedź nie stanie się trafniejsza.

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów i prezentacji. Oryginalne źródło, prezentację Yegora Denisova-Blancha, można znaleźć na YouTube: „Does AI Actually Boost Developer Productivity? (100k Devs Study)„. Więcej o samym badaniu można przeczytać na portalu Stanford University.

Tag: Ghost Engineers

Czy AI rzeczywiście zwiększa produktywność developerów? Największe badanie na świecie #EN231