Paradoks produktywności: AI przyspiesza pisanie kodu i spowalnia dowożenie

W lipcu 2025 organizacja METR opublikowała wynik, który nie pasował do żadnej ze stron sporu o AI w programowaniu. Szesnastu doświadczonych deweloperów open source rozwiązywało 246 realnych zadań w repozytoriach, które znali średnio od pięciu lat. Każde zadanie losowo przydzielano do jednego z dwóch trybów: z narzędziami AI albo bez.

Z AI pracowali 19% wolniej. Zapytani po fakcie, oszacowali, że AI przyspieszyło ich o 20%.

Ta blisko czterdziestopunktowa przepaść między odczuciem a pomiarem jest tematem tego tekstu. Nie samo spowolnienie, bo to akurat się zdezaktualizowało, o czym za chwilę. Chodzi o to, że tam, gdzie ta przepaść się otwiera, budżet na narzędzia rozjeżdża się z wynikiem w produkcji.

Co zmierzyło METR i jak ten wynik się zestarzał

Zacznijmy od uczciwego opisania badania, bo krąży ono po LinkedInie w wersji „nauka udowodniła, że AI nie działa”. Nie to zostało udowodnione, a od publikacji minął rok.

Był to randomizowany eksperyment kontrolowany, czyli najmocniejszy dostępny projekt badawczy. Był też bardzo konkretny: dojrzałe repozytoria, deweloperzy z ogromną wiedzą kontekstową o kodzie, narzędzia dostępne między lutym a czerwcem 2025, mała próba. Sami autorzy pisali, że spodziewali się przyspieszenia.

Co z tego zostaje, a co nie:

• Zostaje najważniejsze: intuicja programisty jest bezużytecznym miernikiem wydajności. Ludzie pomylili się co do własnej pracy o kilkadziesiąt punktów procentowych i nie zauważyli tego. Ankieta „czy AI Wam pomaga?” nie mierzy niczego poza samopoczuciem, i to jest wniosek niezależny od tego, w którą stronę wypadł znak.
• Zostaje obserwacja, że w kodzie, który dobrze znasz, koszt weryfikacji cudzej propozycji bywa wysoki. Zmienia się jego wysokość, nie istnienie.
• Nie zostaje teza „AI spowalnia doświadczonych programistów”. Na narzędziach z 2026 roku nie ma dla niej podstaw.
• Nigdy nie wynikało nic o nowym kodzie, nieznanym stosie ani zadaniach szablonowych. Tego badanie nie sprawdzało w żadnej edycji.

Jest w tym lekcja meta, ważniejsza od samych liczb. Badania o AI starzeją się w tempie kwartałów. Zanim wstawisz jakiekolwiek do prezentacji, sprawdź, czy autorzy nie dopisali aktualizacji. METR dopisał.

Co się w tym czasie stało z kodem

METR mierzyło czas. GitClear mierzy, co zostaje w repozytorium. Ich raport z 2026 roku obejmuje 623 miliony zmian z lat 2023–2026 i pokazuje spójny obraz.

Kod kopiowany („copy/paste”) 2022 9,4% 2026 15,7%

Reszta sygnałów idzie w tę samą stronę:

Dwie rzeczy trzeba tu powiedzieć uczciwie. Po pierwsze, GitClear sprzedaje narzędzie do analityki kodu, więc raport pokazujący problem z jakością kodu leży w jego interesie. Metodologia jest opisana, a dane są duże, ale to nie jest niezależna instytucja badawcza. Po drugie, są to dane obserwacyjne, nie eksperyment. W latach 2023–2026 zmieniło się w branży więcej niż tylko dostępność asystentów, a raport nie rozdziela tych wpływów.

Nie napiszę więc, że trzy raporty pokazują to samo, bo nie pokazują. GitClear mierzy strukturę zmian w repozytoriach, DORA korelacje między adopcją a stabilnością dostarczania, Stack Overflow deklarowane frustracje. To trzy różne zjawiska i żadne z nich nie dowodzi przyczyny. Zbieżność kierunku jest przesłanką, żeby sprawdzić to u siebie, a nie dowodem.

DORA: rośnie przepustowość, rośnie niestabilność

Raport DORA jest szczególnie pouczający, bo jego wnioski zmieniły się między edycjami. Warto wiedzieć, którą się cytuje.

Uwaga na słowa: DORA raportuje zależności statystyczne, nie wpływ. W 2024 wyższa adopcja AI wiązała się ze spadkiem obu wskaźników. W 2025, przy 90% respondentów używających AI, związek z przepustowością przeszedł na plus i zespoły faktycznie wypuszczają więcej. Związek z niestabilnością został ujemny: więcej nieudanych zmian, więcej poprawek po wdrożeniu, dłuższy czas na przywrócenie działania.

Wniosek DORA mieści się w jednym zdaniu i warto go zapamiętać. AI jest wzmacniaczem, nie rozwiązaniem. W organizacji z dobrą obserwowalnością i sensownymi bramkami jakości podkręca to, co działa. W organizacji bez nich podkręca chaos, tyle że szybciej.

Dlaczego to się dzieje

Mechanizm nie jest tajemniczy i nie ma w nim nic o „głupich modelach”. Składają się na niego cztery przyczyny natury ekonomicznej.

Wygenerowanie nowego bloku jest tańsze niż zrozumienie istniejącego. Żeby użyć funkcji, która już jest w repo, muszę ją znaleźć, przeczytać i sprawdzić, czy pasuje. Żeby dostać nową, muszę napisać dwa zdania. Model nie widzi tej asymetrii. Widzi ją tylko architektura, a ta nie ma głosu w momencie pisania.

Przepustowość code review nie wzrosła. Kod generuje się kilka razy szybciej, a liczba osób zdolnych go ocenić jest ta sama. Kolejka rośnie, a wraz z nią pokusa, żeby przepuścić „wygląda sensownie”.

Wynik prawie poprawny kosztuje najwięcej. W ankiecie Stack Overflow 2025 największą frustracją 66% deweloperów były rozwiązania AI „prawie dobre, ale nie do końca”. Kolejne 45% wskazało, że debugowanie kodu z AI zajmuje więcej czasu. Oba pytania miały po ponad 31 tysięcy odpowiedzi. Zaufanie jest przy tym niskie: wysokie deklaruje 3,1% badanych, a 84% korzysta z narzędzi AI albo planuje zacząć.

Bezpieczeństwo nie jest domyślne. W teście Veracode obejmującym ponad 100 modeli 45% wygenerowanych próbek wprowadzało podatność z OWASP Top 10. W Javie odsetek nieudanych zadań sięgnął 72%. Model optymalizuje działanie funkcji, nie odporność na atak, o ile nie każesz mu wprost.

Złóż to razem. Szybciej powstaje więcej kodu, który jest trudniejszy do przejrzenia, częściej duplikuje istniejące rozwiązania i rzadziej bywa refaktoryzowany. Rachunek nie przychodzi w sprincie, w którym kod powstał, tylko wtedy, gdy ktoś musi ten kod zmienić albo naprawić.

Co z tym zrobić

Żadna z poniższych rzeczy nie wymaga nowego narzędzia ani budżetu. Wymagają decyzji. Progi liczbowe, które podaję, to moje reguły kciuka z warsztatów, nie wartości z badań. Traktuj je jak punkt wyjścia do kalibracji u siebie.

1. Przestań mierzyć produktywność liczbą linii i liczbą PR-ów. Zacznij mierzyć code churn w oknie 14 dni, udział zduplikowanych bloków i udział zmian dotykających kodu starszego niż rok. Pierwsze dwa policzysz z samego gita. To wskaźniki, które reagują na problem, zanim zrobi się drogi.
2. Ustaw twardy limit rozmiaru zmiany. DORA od lat pokazuje związek małych zmian z lepszą stabilnością, a AI popycha diffy w drugą stronę. 400 zmienionych linii to sensowny próg alarmowy. Powyżej wymagaj podziału albo drugiego recenzenta.
3. Wprowadź zasadę: pilot weryfikuje kurs. Autor PR-a odpowiada za kod tak samo, jakby napisał każdą linię sam. „Copilot to wygenerował” nie jest wyjaśnieniem incydentu. Brzmi banalnie, dopóki nie zapiszesz tego w definition of done.
4. Każ modelowi refaktoryzować, nie tylko dopisywać. Odruchowo prosimy: „napisz funkcję walidującą NIP”. Lepiej działa polecenie: „w tym repo jest już walidacja NIP-u. Znajdź ją, oceń, czy pokrywa mój przypadek, i albo jej użyj, albo uzasadnij, dlaczego potrzebna jest nowa”. To jedna z niewielu zmian w promptowaniu, którą realnie widać w statystykach repozytorium.
5. Dołóż do CI bramki, których człowiek nie musi pilnować. Detektor duplikatów z progiem na przyrost, blokada spadku pokrycia testami w zmienionych plikach, reguła lintera na puste bloki catch. Trzy konfiguracje, nie projekt.
6. Rozdziel dwa tryby pracy. Nowy serwis, prototyp, skrypt migracyjny: tu AI daje duże przyspieszenie i mało ryzyka. Krytyczny moduł utrzymywany latami: tu koszt weryfikacji rośnie i warto go policzyć, zanim się założy oszczędność. Nie ma wstydu w powiedzeniu zespołowi, że w tym repozytorium używamy AI tylko do czytania i testów.

Jedno zdanie na koniec

Problemem nie jest to, że modele piszą słaby kod. Piszą coraz lepszy. Problemem jest to, że przyspieszyliśmy jeden etap procesu i zostawiliśmy resztę bez zmian. Recenzja, testy, refaktoryzacja i obserwowalność pracują z tą samą przepustowością co w 2022 roku, a wejście do nich zwiększyło się kilkukrotnie.

To jest wąskie gardło, które trzeba rozszerzyć. I jest to robota inżynierska, nie zakupowa.