Twój zespół wypuszcza kod szybciej niż kiedykolwiek. Wykresy velocity sprintu rosną w górę i w prawo. Pull requesty — paczki zmian w kodzie proponowane do review — przelatują przez zatwierdzanie jak po maśle. PM chwali narzędzia AI do kodowania. Wszyscy kiwają głowami. Życie jest piękne.

Tylko że tickety z bugami rosną. Reverty — cofanie zmian, bo coś rozwaliły — zdarzają się coraz częściej. Backlog puchnie. Nikt nie łączy kropek, bo dashboard mówi, że miażdżycie.

30 marca 2026 roku zespół badaczy z Singapore Management University opublikował największe w historii badanie empiryczne jakości kodu generowanego przez AI. Przeanalizowali 304 362 zweryfikowane commity napisane przez AI (zmiany w kodzie, co do których potwierdzono, że pochodzą z narzędzi AI) w 6 275 repozytoriach na GitHubie, obejmując pięć głównych narzędzi: GitHub Copilot, Claude, Cursor, Gemini i Devin. Okres: od stycznia 2024 do października 2025.

To, co znaleźli, powinno nieco przygasić wasze velocity party.

W tych repozytoriach badacze zidentyfikowali 484 606 odrębnych problemów. Z tego 89% stanowiły code smelle — wzorce, które działają dziś, ale gnią jutro. Prawie 6% to bugi runtime'owe. A 5,1% to podatności bezpieczeństwa. Między 15% a 29% commitów AI wprowadzało co najmniej jeden problem, w zależności od narzędzia. Gemini na szczycie z 28,7%. Copilot z wynikiem 17,3% — lepiej, ale to wciąż co szósty commit przychodzący z bagażem.

Ale najlepsze: 24,2% tych problemów wprowadzonych przez AI wciąż żyło w najnowszej wersji kodu. Problemy bezpieczeństwa miały wskaźnik przeżywalności 41,1% — najwyższy ze wszystkich kategorii. Do lutego 2026 badanie śledziło ponad 110 000 żywych problemów, które AI tam wsadziło, a ludzie nigdy nie posprzątali. Badacze powiedzieli wprost: asystenci AI naprawiają mniej więcej tyle code smelli, ile tworzą, ale 'tworzą więcej bugów i problemów bezpieczeństwa niż rozwiązują".

Dzień wcześniej, 29 marca, Exceeds AI opublikowało dane benchmarkowe, które pokazują, dlaczego to ma znaczenie na poziomie organizacji. Ich analiza stawia bezpieczny stosunek kodu AI na poziomie 25–40% całkowitego outputu — zakres, w którym zespoły widzą realne 10–15% wzrostu produktywności bez tonięcia w poprawkach. Obecna średnia globalna? 41–42%. Już za linią. Zespoły powyżej 40% kodu AI wykazują 20–25% wyższe wskaźniki przeróbek. A oto paradoks produktywności, który powinien spędzać sen z powiek każdemu engineering managerowi: developerzy czują się 20% szybsi, ale faktycznie mierzą 19% wolniej, gdy doliczysz overhead review, debugowanie i poprawki.

Subiektywne poczucie prędkości rośnie. Rzeczywista przepustowość spada. Dashboard kłamie.

6 kwietnia badaczka Margaret-Anne Storey z University of Victoria nadała temu problemowi nazwę w nowym artykule. Nazywa to 'Cognitive Debt" — erozja wspólnego zrozumienia w zespole. Kiedy AI generuje kod szybciej, niż developerzy są w stanie go zrozumieć, zespół traci zdolność do bezpiecznej modyfikacji własnego systemu. To nie jest tylko dług techniczny (bałagan w kodzie, który kiedyś ogarniesz). To dług wiedzy — nikt już do końca nie rozumie, co codebase robi.

Nic z tego nie oznacza, że powinieneś przestać używać narzędzi AI do kodowania. Wzrost produktywności jest realny, a dżinn nie wróci do butelki. Ale pytanie, które twój zespół powinien sobie zadawać, to nie 'ile kodu AI może za nas napisać?" Tylko 'ile kodu generowanego przez AI nasz proces review i pokrycie testami jest w stanie udźwignąć, zanim wszystko się posypie?"

Velocity zawsze było metryką próżności — liczbą, która wygląda imponująco, ale nie mówi, czy budujesz coś solidnego. Teraz, bez mianownika jakości, to metryka niebezpieczna. Twój wykres sprintu rośnie w górę i w prawo. Liczba bugów też. Ten sam wykres. Inna historia.