Artykuły

Szybciej, wolniej, a może po prostu inaczej – czyli co naprawdę mierzą badania o AI

27 października 2026

Maciej Walczak

Spis treści

Grafika z napisem „Szybciej czy wolniej? AI vs badania”. Po lewej programista przy laptopie z uniesionymi pięściami, nad nim prędkościomierz z wychyloną igłą, rakieta i lampa wypuszczająca wstęgę kodu. Po prawej stoper z czerwoną strefą, chwiejny stos kart pull requestów i zestresowana osoba z lupą, obok dwa okna z kodem i przyciskiem „Copy”. Pośrodku wagi z zegarem i znakiem kodu, w tle krzywa hype’u, rentgen klatki piersiowej i siatka kropek z liczbą 151.

W ostatnich wpisach o AI było sporo moich wrażeń. W Programista w czasach AI pisałem o tym, jak zmienia się nasza praca, w Vibe Coder vs Software Engineer – nowa wojna światów? o dwóch podejściach do kodowania z AI, a w Spec Driven Development jako inżynierska odpowiedź na „vibe coding” o tym, jak zapanować nad chaosem. Wszystko z mojej perspektywy – a perspektywa jednego programisty, nawet bardzo zaangażowanego, to jeszcze nie dane.

Impulsem do tego wpisu był zalew filmów i materiałów o wpływie AI na pracę programistów. Część jest słaba, ale część opiera się na prawdziwych badaniach – i to właśnie one interesowały mnie najbardziej: jakie wnioski da się z nich wyciągnąć?

Dlatego tym razem swoje spostrzeżenia odkładam na bok – nie są jeszcze na tyle miarodajne – i robię coś innego. Zebrałem w jednym miejscu to, co mówią badania, raporty i ludzie, którzy pracowali w skali większej niż jedno biurko. Przejrzałem kilka badań oraz 4 filmy z YouTube – od opisu kontrolowanego eksperymentu po keynote z konferencji. I okazało się, że wyniki wyglądają na sprzeczne: jedni mówią, że AI przyspiesza pracę o połowę, inni, że spowalnia. Zobaczmy, czy da się to jakoś pogodzić.

Komu tu wierzyć?

Zanim przejdziemy do liczb, jedna uwaga o tym, skąd one pochodzą. W internecie krążą statystyki, które brzmią świetnie, a po sprawdzeniu okazują się dość mgliste. W jednym z filmów usłyszałem, że programiści „czują się o 55% szybsi, a w rzeczywistości są o 19% wolniejsi”. Żadnego źródła w filmie nie podano. Po sprawdzeniu: 19% to wynik badania METR, o którym za chwilę, ale tam uczestnicy szacowali swoje przyspieszenie na ok. 20% – a skąd te 55%, nie udało mi się ustalić. Dlatego zasada jest prosta: liczba bez źródła to nie fakt, tylko ciekawostka.

W tym wpisie źródła podzieliłem na 3 grupy:

eksperymenty z losowym przydziałem – najmocniejsze dowody, ale zwykle małe i dotyczące konkretnej sytuacji
dane z repozytoriów i zespołów – duże próby, ale to tylko korelacje, a raporty często publikują firmy, które same sprzedają narzędzia związane z tematem
doświadczenia praktyków – cenne, ale to opinie, nie pomiary

Będę zaznaczał, z której grupy pochodzi dany głos – dzięki temu łatwiej ocenić, ile waży.

Czy AI naprawdę przyspiesza?

Zacznijmy od najgłośniejszego badania, czyli METR z lipca 2025. W badaniu wzięło udział 16 doświadczonych programistów open source – pracowali na własnych, dobrze znanych i dojrzałych repozytoriach. W sumie dostali 246 zadań, a każde z nich losowo przydzielano do wersji „z AI” albo „bez AI”. Wynik? Przy AI zadania trwały średnio ok. 19% dłużej. Najciekawsze jest jednak co innego: przed pracą uczestnicy spodziewali się przyspieszenia o ok. 24%, a po jej zakończeniu nadal szacowali, że byli o ok. 20% szybsi. Odczucie i pomiar rozjechały się więc w przeciwne strony.

Autorzy sami podkreślają ograniczenia: mała próba, bardzo dobra znajomość repozytoriów przez uczestników i narzędzia z początku 2025 roku – a te od tamtej pory się zmieniły. Nie wolno więc tego wyniku traktować jako wyroku dla całej branży.

Teraz druga strona – badanie, którego współautorem jest Dave Farley: 151 uczestników, w tym 95% zawodowych programistów. W pierwszej fazie dodawali oni funkcję do dość nieprzyjemnego, pełnego błędów kodu aplikacji w Javie – część z AI, część bez. Z AI uczestnicy kończyli o ok. 30% szybciej (mediana), a ci, którzy używali AI regularnie – o ok. 56%. Tylko że ta faza nie miała losowego przydziału, a zadanie dotyczyło obcego kodu, nie własnego, znanego od lat repozytorium.

Widzicie, o co chodzi? To nie są sprzeczne wyniki, tylko odpowiedzi na różne pytania. U METR doświadczeni ludzie pracowali na własnym podwórku, które znają na pamięć – możliwe, że AI miało im tam niewiele do zaoferowania. U Farleya – nowa funkcja w cudzym kodzie, gdzie, jak podejrzewam, AI łatwiej pomaga się rozeznać. Ktoś powie: no dobra, ale które jest prawdziwe? Możliwe, że oba – każdy w swoich warunkach. Jak zwykle odpowiedź brzmi: to zależy 🙂

A jakość kodu – gorsza czy po prostu inna?

Przyspieszenie to jedno. Ale co dzieje się z kodem później?

Tu zaczyna się część z danych obserwacyjnych i od razu ostrzeżenie: autorami wszystkich trzech raportów poniżej są firmy, które sprzedają narzędzia dla zespołów programistycznych (analitykę, ocenę jakości kodu, review), więc mają w tym swój interes. Kierunek jest jednak dość spójny:

GitClear przejrzał 211 mln zmienionych linii kodu z lat 2020–2024. W 2024 roku liczba bloków z co najmniej 5 zduplikowanymi liniami wzrosła 8-krotnie, a linii „przeniesionych” (czyli sygnału refaktoryzacji) ubyło o ok. 40%. Po raz pierwszy skopiowanego kodu było więcej niż przeniesionego
CodeRabbit porównał 470 pull requestów z open source (320 z udziałem AI, 150 bez) – w tych z AI średnio 10,83 problemu na PR, w pozostałych 6,45. Próba jest niewielka, a udział AI autorzy rozpoznawali po śladach w PR-ach, bez pewności
Faros AI zebrał dane z ponad 10 tys. programistów w 1255 zespołach – przy wysokim użyciu AI zespoły zamykały o 21% więcej zadań i scalały o 98% więcej pull requestów
- to samo badanie: pull requesty większe o 154%, czas review dłuższy o 91%, o 9% więcej błędów na programistę, a na poziomie całej firmy nie widać poprawy

Czyli ci, którzy sprzedają narzędzia do pilnowania jakości, mają interes w tym, żeby problem było widać. Liczby warto znać, tylko z odrobiną soli 🙂

Brzmi niepokojąco? Zanim ktoś odłoży AI do szuflady – druga faza badania Farleya. Tam kolejni programiści, bez AI i bez wiedzy, skąd kod pochodzi, rozwijali rozwiązania z pierwszej fazy. Tym razem był losowy przydział. I co? Nie wykryto istotnych różnic ani w czasie dalszej pracy, ani w jakości kodu. Analiza statystyczna sugeruje, że ewentualne poprawy są co najwyżej niewielkie i bardzo niepewne. Trzeba też dodać, że uczestników rekrutowano głównie wśród widzów kanału Farleya – czyli ludzi, którzy być może i tak pracują lepiej niż przeciętnie. Sam o tym mówi.

Wychodzi więc tak: jedyny znany mi kontrolowany eksperyment, który sprawdzał utrzymywalność, nie znalazł katastrofy. Dane obserwacyjne natomiast sugerują, że dzieje się coś niedobrego: rośnie duplikacja, pull requesty są większe, a review trwa dłużej.

Tu wchodzi na scenę Kent Beck – głos praktyka, nie badanie. To ten od TDD i Extreme Programming, który od ok. 18 miesięcy koduje z AI codziennie i wcale nie jest przeciwnikiem. Beck ma na to własne określenie: „features vs futures”. Każda wdrożona funkcja zjada część przyszłych możliwości zmian. Dawniej dojście do systemu, którego nie da się już ruszyć bez psucia czegoś innego, zajmowało 100 osobom 10 lat. Dziś – według niego – jedna osoba robi to w tydzień.

To też jest „wzrost produktywności”, tylko nie taki, o jaki nam chodziło. Jego rada: po każdej skończonej funkcji nie pędzić do następnej, tylko odbudować to, co „spaliliśmy” – refaktoryzacja, usunięcie duplikacji, uproszczenie. Postęp, konsolidacja, postęp, konsolidacja.

Beck zwraca też uwagę na coś, co zna chyba każdy, kto z AI pracował: AI jest świetne w pisaniu kodu „wiarygodnego”, czyli takiego, który wygląda dobrze, ale niekoniecznie działa. A miarą nie powinny być linie kodu czy liczba pull requestów. Program o 200 000 linii nie jest 10 razy lepszy niż ten o 20 000 – liczba linii to najłatwiejsza do zmierzenia metryka i zarazem najmniej istotna.

Gdzie przeniosło się wąskie gardło?

Jeśli wierzyć Faros, mimo większej liczby scalanych pull requestów nie widać poprawy wyników całej firmy. Gdzieś więc musi być korek. Wygląda na to, że jest nim weryfikacja.

Axel Molist prowadzi 20-osobowy zespół programistów i opisuje to na swoim przykładzie. Senior spędził 3 dni na przeglądzie pull requestów juniora, który pracował z Claude Code – tysiące linii, aplikacja działała, ale senior przyznał, że nie przeczytał całości, bo się nie dało. Seniorzy w jego zespole tonęli w review, a juniorzy – według niego – dostarczali kod znacznie szybciej niż wcześniej. Molist wprost mówi, że wąskie gardło przesunęło się z pisania na decyzje, weryfikację i precyzyjne opisanie intencji. To oczywiście jeden zespół i jedna opowieść, bez danych – ale zgadza się z tym, co widać w liczbach z Faros (+91% czasu review).

Przy okazji Molist powołuje się na retreat, który zorganizowali Martin Fowler i Thoughtworks w lutym 2026. W raporcie z tego spotkania jest myśl, którą warto zapamiętać: jakość inżynierska nie znika, gdy kod pisze AI – przenosi się do specyfikacji, testów, ograniczeń i zarządzania ryzykiem. Są tam też otwarte pytania, na które nikt jeszcze nie zna odpowiedzi. Na przykład: czy zyski z produktywności nie są zjadane przez spadek stabilności, bo zmiany są większe i trudniej je ogarnąć?

Specyfikacja – ratunek czy waterfall?

Skoro rygor przenosi się „w górę”, to naturalnie pada pytanie o specyfikacje. I tu wracamy do wpisu o Spec Driven Development, w którym przyznałem, że mam wątpliwości co do „specyfikacji kontra rzeczywistość”.

Molist i raport Thoughtworks mówią w skrócie: rygor, który kiedyś stosowaliśmy po napisaniu kodu, trzeba zastosować przed nim – w wymaganiach, w opisie stanów, w testach. Raport dodaje przy tym konkret, który mi się spodobał: TDD chroni przed sytuacją, w której agent pisze test potwierdzający własny błędny kod. Testu napisanego wcześniej nie da się tak łatwo „oszukać”.

Beck patrzy na to z drugiej strony. Jego zdaniem pomysł, że wystarczy napisać dość dobry opis, a AI wygeneruje dobre oprogramowanie, to w gruncie rzeczy waterfall – czyli podejście, które już raz nie zadziałało, bo późniejsze decyzje zawsze dostarczają wiedzy, której nie było na początku. Dla małej aplikacji jednorazowe wygenerowanie jest według Becka w porządku. Dla długo żyjącego systemu z ogromną bazą użytkowników – nie, bo trzeba będzie to zmieniać, migrować dane i utrzymywać ciągłość. Złe doświadczenia ma też z procesem w pełni agentowym, bez człowieka w pętli – bez feedbacku taki proces zawsze zjeżdża z torów.

Czy to znaczy, że się kłócą? Nie do końca. Zgadzają się co do tego, że bez testów nie da się ufać kodowi od AI. Różnią się akcentem: Molist i Thoughtworks mówią o rygorze przed kodem, a Beck o iteracji i feedbacku. Ja – jak już pisałem – uważam, że obie strony mają argumenty, a najlepiej sprawdzić to na własnej skórze.

A cały ten hype?

Na koniec trochę dystansu, za który odpowiada Richard Campbell. To wieloletni prelegent NDC i prowadzący podcasty, który w swoim keynote sceptycznie podchodzi do całego szumu wokół AI. Radzi między innymi: na początku miesiąca zapisz obietnice firm AI, a miesiąc później porównaj. Jego obserwacja: to w zasadzie te same obietnice. Dobrze o tym pamiętać, gdy czytamy kolejne „rewolucyjne” zapowiedzi.

Mnie najbardziej zapadł w pamięć jego przykład z radiologami. Jak opowiada Campbell, w 2016 roku Geoffrey Hinton, jeden z ojców współczesnych sieci neuronowych, przepowiadał, że radiologia jako zawód zniknie. Stało się odwrotnie: automatyzacja skróciła czas analizy obrazów, więc lekarze zaczęli zlecać więcej badań obrazowych, a popyt na radiologów wzrósł. Czy tak będzie z programistami? Nie wiem – i raczej nikt jeszcze nie wie. Ale to dobra przestroga przed przekonaniem, że każda praca zniknie w 2 lata. Campbell kończy zresztą myślą, że naszą pracą nigdy nie było pisanie kodu, tylko rozwiązywanie problemów ludzi.

Reszty jego prezentacji – o bańce inwestycyjnej i data center – tu nie przywołuję: to opinie, a w nagraniu nie padają źródła.

No dobrze, ale co z tego wynika?

Po przejrzeniu tego wszystkiego widzę kilka wspólnych mianowników. Pamiętajcie, że to moje wnioski z cudzych źródeł, a nie z własnych pomiarów 🙂

Przyspieszenie zależy od kontekstu – AI potrafi skrócić czas pierwszej wersji (obserwacje z badania Farleya), ale w dobrze znanym własnym repozytorium efekt bywa ujemny – jak pokazał METR
Wąskie gardło przenosi się na weryfikację – zgadzają się w tym Faros, Molist i Thoughtworks. Jedyny znany mi kontrolowany eksperyment nie wykazał pogorszenia utrzymywalności, ale dane obserwacyjne sugerują, że bez dyscypliny jakość i czas review cierpią
Mierzmy efekt, nie wysiłek – linie kodu, liczba PR-ów czy liczba uruchomionych agentów to miary wysiłku, nie wartości (Beck). Testy są przy tym kluczowe – zgadzają się w tym nawet ci, którzy spierają się o specyfikacje

Narzędzia zmieniają się szybciej, niż publikuje się badania – METR badał te z początku 2025 roku, a dziś mamy koniec 2026. Każdy z tych wyników traktuję więc jako zdjęcie z przeszłości, a nie wyrok.

Co dalej?

Własne obserwacje zostawiam na później. Właśnie tworzę projekt metodą Spec Driven Development – opiszę go i udostępnię niedługo, a wtedy zestawię swoje doświadczenia z tym, co tu przeczytaliście. Może się okazać, że u mnie wyjdzie zupełnie inaczej i będzie ciekawie…

A co z Waszą praktyką? Czujecie, że dzięki AI pracujecie szybciej – a może macie na to jakieś liczby? Dajcie znać w komentarzach, zwłaszcza jeśli review w Waszym zespole robi się wąskim gardłem. Ciekawe, czy u Was liczby zgadzają się z tym, co tu opisałem 🙂