39 Punktów Rozjazdu: Dlaczego Myślisz Że AI Cię Przyspiesza (A Nie Przyspiesza)

39 Punktów Rozjazdu: Dlaczego Myślisz Że AI Cię Przyspiesza (A Nie Przyspiesza)

9 min czytania

39 Punktów Rozjazdu

Feature gotowy. Uczucie: dwie godziny, może mniej. Agent AI zrobił boilerplate, wygenerował szkielety testów, podpowiedział logikę retry, którą i tak byś napisał ręcznie. PR zmergowany przed lunchem. Produktywny poranek.

Tyle że time tracker mówił co innego. Trzy godziny czterdzieści minut. Sprawdziłeś po obiedzie, bo byłeś pewien że zobaczysz szybki czas - taki, który pasuje do lekkiego uczucia w klatce “ogarnąłem to.” Liczba nie pasowała. Nawet blisko nie.

Pierwsza myśl: tracker się zepsuł. Nie zepsuł się.

Badanie, które złamało narrację

W połowie 2025 roku METR (Model Evaluation & Threat Research) opublikował jedno z najbardziej rygorystycznych kontrolowanych badań nad produktywnością z AI. Szesnaście doświadczonych developerów open-source wykonało 246 zadań na własnych repozytoriach - projektach, które utrzymywali średnio od pięciu lat. Każde zadanie losowo przydzielano do jednej z dwóch grup: z narzędziami AI albo bez.

Developerzy używali Cursor Pro z Claude 3.5 i 3.7 Sonnet. To nie są zabawki. To narzędzia, po które sięga większość profesjonalnych programistów.

Wynik:

Kiedy developerzy mogli używać narzędzi AI, wykonywali zadania o 19% dłużej. Nie szybciej. Wolniej.

Samo to byłoby warte uwagi. Ale drugie odkrycie sprawia, że badanie naprawdę ma znaczenie.

Przed każdym zadaniem developerzy przewidywali, że AI przyspieszy ich o 24%. Po wykonaniu zadania - po doświadczeniu faktycznego spowolnienia - nadal wierzyli, że AI zrobiło ich o 20% szybszymi. Luka percepcyjna między odczuwaną prędkością a zmierzoną prędkością wyniosła 39 punktów procentowych.

Przeczytaj to jeszcze raz. Developerzy, którzy mierzalnie byli wolniejsi, wierzyli że są szybsi. Po wykonaniu pracy. Po przejściu całego doświadczenia.

Gdzie ucieka czas

Badacze METR nagrywali ekrany. Dane pokazują dokładnie, gdzie parują godziny.

Sesje z AI miały więcej czasu bezczynności. Nie “czekanie na model” - dosłownie zero aktywności. Najprawdopodobniejsze wyjaśnienie: kodowanie z AI wymaga mniej wysiłku poznawczego z minuty na minutę, co ułatwia zoning out albo multitasking. Czuje się lekko. Wysiłek to podstawa ludzkiego szacowania czasu. Mniej wysiłku, mniej odczuwanego czasu. Zegar ma to gdzieś.

Ale prawdziwe pochłaniacze czasu są bardziej konkretne:

Ocenianie sugestii AI. Każda sugestia wymaga ewaluacji. Czy to poprawne? Czy obsługuje edge case? Czy pasuje do istniejących patternów w tym codebase? Każda ewaluacja to mikrodecyzja. Czterdzieści mikrodecyzji na godzinę nie czuje się jak praca. Jest pracą.

Debugowanie kodu AI. Kod wygląda dobrze. Testy przechodzą. Ale coś jest nie tak na granicach warunków, albo obsługa błędów jest subtelnie błędna, albo AI zhallucynował wywołanie API, które nie istnieje. Znalezienie tych bugów trwa dłużej niż znalezienie bugów ludzkich, bo kod nie ma “tells” - nie ma osobistego stylu, nie ma znajomych wzorców błędów do skanowania.

Iterowanie promptów. Pierwsza próba pudłuje. Doprecyzowujesz prompt. Druga próba lepsza, ale wprowadza nowy problem. Poprawiasz i promptujesz jeszcze raz. Trzy iteracje później masz kod, który działa. Mógłbyś napisać go od zera w czasie, który zajęły negocjacje z modelem.

Przełączanie kontekstu. To jest niewidoczne. Za każdym razem kiedy przechodzisz z “myślenia o problemie” do “oceniania co AI myśli o problemie,” płacisz koszt przełączenia poznawczego. Mały za każdym razem. Kumuluje się przez dzień. O szesnastej jesteś mentalnie wyczerpany ale nie potrafisz wyjaśnić dlaczego, bo “przecież prawie nie pisałem kodu.”

Potwierdzenie ze skali enterprise

Jeśli METR był sygnałem akademickim, Faros AI dostarczył potwierdzenie w skali korporacji. Ich badanie analizowało telemetrię z ponad 10 000 developerów w 1255 zespołach inżynieryjnych.

Indywidualne liczby wyglądają świetnie. Developerzy w zespołach z wysoką adopcją AI mergują 98% więcej pull requestów. Obsługują 47% więcej PR-ów dziennie. Zamykają 21% więcej zadań.

Liczby organizacyjne opowiadają inną historię. Kiedy Faros spojrzał na metryki DORA - częstotliwość deployów, lead time, change failure rate, średni czas naprawy - nie było znaczącej korelacji między adopcją AI a lepszymi wynikami dostarczania oprogramowania. Firmy z masowym użyciem AI nie dostarczały szybciej ani bardziej niezawodnie niż te bez niego.

Zyski na poziomie jednostki wyparowywały na poziomie zespołu. Gdzie się podzieliały?

W kolejce do review. Czas review PR-ów wzrósł o 91%. PR-y były 154% większe. Recenzenci tonęli w outputcie generowanym przez AI, który wyglądał wiarygodnie ale wymagał dokładnej inspekcji. Każda godzina, którą developer oszczędził na pisaniu kodu, stała się godziną (albo więcej), którą ktoś inny spędził na recenzji.

To jest prawo Amdahla zastosowane do twojego pipeline’u. Generowanie kodu przyspieszyło. Wszystko dalej w łańcuchu - design review, code review, QA, integracja, deployment - działa z tą samą prędkością. Kiedy jeden etap przyspiesza a reszta stoi w miejscu, nie dostajesz szybszego dostarczania. Dostajesz zator przy następnym wąskim gardle.

Dlaczego nie możesz ufać uczuciu

Każdy polskojęzyczny dev zna to uczucie. Siedzisz na daily, mówisz “wciągnąłem feature w dwie godziny” i czujesz się jak bohater. Nikt nie sprawdza. Nikt nie kwestionuje. W polskiej kulturze programistycznej “ogarniałem” jest walutą - im szybciej, tym więcej szacunku. AI podbija to uczucie, bo produkuje efekty wizualnie szybciej: pliki, funkcje, testy. Czujesz się produktywny. Ale 39 punktów rozjazdu nie znika dlatego, że Twój zespół nie mierzy.

Luka percepcyjna nie jest przypadkiem. To udokumentowane zjawisko poznawcze działające przez kilka kanałów.

Heurystyka wysiłku. Ludzie szacują czas na podstawie wysiłku. Trudne rzeczy czują się długie. Łatwe - krótkie. AI sprawia, że kodowanie czuje się łatwiejsze z minuty na minutę, więc szacujesz że spędziłeś mniej czasu. Zegar nie przejmuje się twoimi odczuciami.

Bias potwierdzenia. Przed rozpoczęciem spodziewałeś się, że AI cię przyspieszy. To oczekiwanie stało się kotwicą. Ocena po zadaniu była zniekształcona w kierunku potwierdzenia kotwicy. Psychologowie nazywają to biasem potwierdzenia. Developerzy nazywają to “intuicją.” Tutaj jest błędna.

Wzmocnienie o zmiennym współczynniku. To jest mechanizm automatu do gry w twoim IDE. Czasem AI trafia sugestią za pierwszym razem. Czasem potrzeba pięciu prób. Wzorzec przerywanej nagrody jest ten sam, który trzyma ludzi przy dźwigni w kasynie. Pamiętasz wygrane. Zapominasz o re-promptach.

Ankieta Stack Overflow 2025 Developer Survey pokazała, że zaufanie do trafności AI spadło do 29%, z 40% rok wcześniej. Ale użycie dalej rosło. Developerzy używają narzędzi więcej, ufając im mniej. To nie jest racjonalne zachowanie. To luka percepcyjna sterująca działaniem.

Metryka, która okłamuje twojego managera

Ten problem nie zostaje na twoim biurku. Wspina się po łańcuchu raportowania.

Twój manager widzi więcej zmergowanych PR-ów. Więcej commitów na sprint. Więcej zamkniętych story pointów. Dashboard wygląda świetnie. Zespół wdrożył AI i “produktywność” poszła w górę.

Ale dashboard mierzy wolumen outputu. Nie mierzy wyników dostarczania. Nie mierzy, czy feature’y faktycznie trafiły na produkcję szybciej. Nie mierzy, czy kod przetrwał pierwszy tydzień na produkcji bez hotfixa.

InfoWorld nazwał to “produkowaniem zobowiązań” (manufacturing liability) - generowaniem kodu, który tworzy więcej pracy downstream niż oszczędza upstream. Kiedy PR-y są 154% większe ale pojemność review nie zmieniła się, nie poruszasz się szybciej. Po prostu generujesz więcej materiału dla wąskiego gardła.

Niebezpieczna cecha luki percepcyjnej jest to, że sama się wzmacnia. Developer czuje się szybki, raportuje że jest szybki. Manager widzi metryki outputu które potwierdzają “szybko.” Zarząd podwaja stawkę na adopcję AI. Nikt nie sprawdza, czy cokolwiek faktycznie wylądowało u użytkownika szybciej albo lepiej.

Co mierzyć zamiast tego

Rozwiązanie to nie rezygnacja z narzędzi AI. Rozwiązanie to przestać ufać odczuciom i zacząć ufać pomiarom. Konkretnie: pomiarom wyników, nie outputu.

Metryki DORA. Częstotliwość deployów. Lead time for changes. Change failure rate. Mean time to recovery. Mierzą, czy oprogramowanie faktycznie dociera do użytkowników szybciej i bardziej niezawodnie. Są odporne na inflację przez AI, bo śledzą cały pipeline, nie tylko etap generowania kodu.

DX Core 4. Nowszy framework, który do wymiaru prędkości dodaje efektywność (developer experience), jakość i wpływ biznesowy. Kluczowy insight: “diffy na inżyniera” to jedna metryka z czterech. Prędkość bez jakości, efektywności i wpływu to tylko ruch.

Czas do produkcji, nie czas do PR. Ile od “zadanie rozpoczęte” do “działa na produkcji”? Jeśli AI ściął twój czas kodowania o 40%, ale czas do produkcji stał w miejscu, zysk wyparował gdzieś w pipeline. Znajdź gdzie.

Change failure rate. Benchmark Opsera 2026 wykazał, że PR-y generowane przez AI mają 32.7% wskaźnik akceptacji versus 84.4% dla kodu pisanego przez ludzi. Jeśli twój change failure rate rośnie po adopcji AI, produkujesz więcej ale dostarczasz mniej. To ujemna produktywność.

Samoocena obciążenia poznawczego. Zapytaj siebie szczerze, co tydzień: “Jak bardzo jestem mentalnie wyczerpany na koniec dnia, 1-10?” Jeśli liczba rośnie a twój “output” też rośnie, palisz paliwo szybciej, nie prowadzisz lepszego silnika.

39 punktów między tobą a rzeczywistością

Niewygodna prawda. Prawdopodobnie przeczytałeś ten artykuł i pomyślałeś: “No tak, ale ja naprawdę jestem szybszy z AI. Moja sytuacja jest inna.”

To mówią 39 punktów rozjazdu.

Developerzy w badaniu METR myśleli tak samo. Mieli pięć lat doświadczenia z tymi codebase’ami. Byli ekspertami. Używali najlepszych narzędzi. Wciąż nie potrafili powiedzieć, że są wolniejsi.

To nie znaczy że narzędzia AI są bezużyteczne. Znaczy, że uczucie produktywności jest niewiarygodne jako sygnał. A niewiarygodne sygnały, pozostawione bez kontroli, napędzają złe decyzje - dla ciebie, twojego zespołu i twojej organizacji.

Fix jest nudny. Mierz wyniki. Śledź czas uczciwie. Porównuj metryki przed-AI i po-AI na wymiarach, które mają znaczenie (prędkość dostarczania, wskaźnik bugów, czas do produkcji), nie na metrykach które dobrze się czują (zmergowane PR-y, commity dziennie, story pointy).

I następnym razem kiedy skończysz feature i pomyślisz “to było szybkie” - sprawdź zegar.

Luka percepcyjna to jeden z sześciu wymiarów, które mierzy framework OnTilt. Pojawia się w skalach “Utrata kontroli” i “Zaabsorbowanie” - wzorcach, w których twoje doświadczenie z narzędziem rozjeżdża się z faktycznym wpływem narzędzia na twoją pracę.

Zrób autorefleksję - 14 pytań, 3 minuty, anonimowo. Nie powie ci czy AI cię przyspiesza. Powie ci, czy zauważyłbyś gdyby nie przyspieszało.

Źródła:

  • METR. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” 16 developerów, 246 zadań, randomizowane badanie kontrolowane. 19% wolniej z AI; 39-punktowa luka percepcyjna. metr.org
  • METR. (2026, 24 lutego). “We are Changing our Developer Productivity Experiment Design.” Aktualizacja dot. biasu selekcyjnego i trudności rekrutacyjnych. metr.org
  • Faros AI. (2026). “The AI Productivity Paradox Research Report.” 10 000+ developerów, 1255 zespołów. 98% więcej PR-ów, płaskie metryki DORA, 91% dłuższe review. faros.ai
  • Opsera. (2026). “AI Coding Impact 2026 Benchmark Report.” Akceptacja PR-ów AI: 32.7% vs ludzkich 84.4%; 4.6x dłuższe oczekiwanie na review; 1.7x więcej bugów. opsera.ai
  • Stack Overflow. (2025). Developer Survey. Zaufanie do trafności AI: 29% (spadek z 40%). stackoverflow.com
  • Noda, A. i Tacho, L. (2025). “DX Core 4.” Zunifikowany framework produktywności developerskiej (prędkość, efektywność, jakość, wpływ). getdx.com

OnTilt to projekt badawczy analizujący wzorce behawioralne w pracy z AI. Quiz to narzędzie autorefleksji, nie instrument diagnostyczny. Więcej na stronie O projekcie.