Mur 10%: dlaczego produktywność AI osiąga plateau i co pozwala go przebić

DX przebadało 121 000 programistów w 450 firmach. 92,6% korzysta z asystentów kodowania AI co najmniej raz w miesiącu. Kod generowany przez AI stanowi obecnie 26,9% produkcyjnych merge’ów. Programiści deklarują oszczędność około czterech godzin tygodniowo.¹ Produktywność nie przekroczyła 10%.

Ta liczba utrzymuje się na stałym poziomie od trzech kolejnych kwartałów.^{1 2} Adopcja rosła. Wolumen kodu rósł. Narzędzia się doskonaliły. Zyski — nie. Laura Tacho, CTO w DX, ujęła to wprost: „To tak naprawdę problem zarządzania. Szum medialny sprawił, że brzmiało to tak, jakby samo wypróbowanie AI miało automatycznie się opłacić.”³

Raport DORA 2025 ujawnił rozbieżność. Organizacje z silnymi praktykami inżynieryjnymi doświadczyły wzmocnienia istniejących atutów przez AI. Organizacje ze słabymi praktykami doświadczyły wzmocnienia istniejących dysfunkcji. Te same narzędzia. Przeciwne wyniki. Raport konkludował: „Podstawową rolą AI w tworzeniu oprogramowania jest rola wzmacniacza. Potęguje mocne strony organizacji o wysokiej wydajności i dysfunkcje organizacji borykających się z problemami.”⁴

Mur nie jest problemem modelu. Jest problemem infrastruktury. Lepsze modele nie przebiją muru zbudowanego z braku weryfikacji, braku kontekstu i braku nadzoru. Towarzyszące wpisy opisują architekturę: Anatomy of a Claw wyjaśnia warstwę orkiestracji, The Fabrication Firewall wyjaśnia bramkę wyjściową, a Context Is Architecture wyjaśnia system wstrzykiwania kontekstu. Ten wpis wyjaśnia, dlaczego te systemy istnieją.

Podsumowanie

121 000 przebadanych programistów. 92,6% adopcji. Produktywność utknęła na 10%. Mur istnieje, ponieważ AI generuje kod szybciej, niż organizacje są w stanie go zweryfikować, skontekstualizować lub objąć nadzorem. Trzy przyczyny źródłowe: głód kontekstu (AI halucynuje bez wiedzy specyficznej dla projektu), próżnia weryfikacji (kod trafia do produkcji szybciej, niż adaptują się procesy przeglądu) oraz luka w nadzorze (AI omija standardy jakości, które egzekwują ludzie). Przebicie wymaga infrastruktury wokół AI, a nie lepszego AI. Dowody: organizacje, które zbudowały infrastrukturę weryfikacji i nadzoru, zmniejszyły liczbę incydentów o połowę; organizacje, które wdrożyły AI bez infrastruktury, podwoiły ich liczbę.^{4 5} To próba N=1 budowy takiej infrastruktury, udokumentowana konkretnymi liczbami. Nie może dowieść uniwersalności. Może pokazać, jak wygląda druga strona muru.

Co mówią badania

Zbiór danych DX obejmuje 4,2 miliona programistów obserwowanych od listopada 2025 do lutego 2026, z szczegółowym panelem 121 000 programistów z 450 firm.¹ Liczby opowiadają dwie historie.

Historia adopcji jest jednoznaczna. Asystenci kodowania AI osiągnęli niemal powszechną penetrację. DX zmierzyło 92,6% miesięcznej adopcji i około 75% tygodniowego użycia.¹ Ankieta Stack Overflow z 2025 roku wykazała, że 84% programistów używa lub planuje używać narzędzi AI.⁶ JetBrains zmierzył 85% regularnego użycia wśród 24 534 programistów w 194 krajach.⁷ Pułap adopcji jest bliski.

Historia produktywności utknęła w martwym punkcie. DX zmierzyło średnio cztery godziny oszczędności tygodniowo, bez zmian w porównaniu z 3,6 godziny w poprzednim kwartale.^{1 2} Kod generowany przez AI wzrósł z 22% do 26,9% scalonego kodu, ale dodatkowy wolumen nie przełożył się na dodatkową wydajność.^{1 2} Laura Tacho wskazała na matematykę: programiści poświęcają około 20% czasu na pisanie kodu. 10% poprawy na 20% dnia pracy to 2% poprawy ogólnej. „Szybkość pisania nigdy nie była wąskim gardłem.”⁸

Kluczowy jest ostatni wiersz. Raport DORA z 2024 roku objął 39 000 profesjonalistów i wykazał, że na każde 25% wzrostu adopcji AI przepustowość dostarczania spadała o szacowane 1,5%, a stabilność dostarczania o 7,2%.⁵ Raport DORA z 2025 roku stwierdził, że przepustowość się poprawiła (zależność zmieniła się z negatywnej na pozytywną), ale stabilność pozostała ujemna.⁴ Adopcja AI nadal korelowała ze zwiększoną niestabilnością, nawet gdy przepustowość się poprawiła.

Rozbieżność ma większe znaczenie niż średnie. METR zbadał 16 doświadczonych programistów open-source pracujących nad 246 rzeczywistymi problemami w repozytoriach i stwierdził, że z narzędziami AI potrzebowali o 19% więcej czasu niż bez nich.⁹ Randomizowane badanie kontrolowane Google obejmujące 96 inżynierów wykazało 21% przyspieszenie, ale wynik nie był istotny statystycznie (95% CI przecinał zero).¹⁰ McKinsey stwierdził zyski rzędu 35-50% przy prostych zadaniach, ale poniżej 10% przy zadaniach o wysokiej złożoności.¹¹ Wzorzec: AI przyspiesza te elementy programowania, które nigdy nie były wąskim gardłem.

Firmy, które przebiły mur, nie używały lepszych modeli. Zbudowały infrastrukturę, która wyłapywała to, czego modele nie były w stanie wykryć.

Dlaczego mur istnieje

Trzy przyczyny źródłowe wyjaśniają plateau. Każda działa niezależnie. Razem tworzą sufit, którego lepsze modele nie mogą przebić.

Głód kontekstu

Asystenci kodowania AI operują na kodzie widocznym w bieżącym pliku i kontekście, który mieści się w oknie promptu. Nie znają decyzji architektonicznych, kontraktów API, ograniczeń wdrożeniowych ani konwencji nazewnictwa zespołu — chyba że ktoś wstrzyknie te informacje.

Bez kontekstu specyficznego dla projektu model zgaduje. Halucynuje ścieżki plików, które podążają za wiarygodnymi konwencjami, ale nie istnieją. Generuje wywołania API do endpointów, które pasują do typowych wzorców, ale nie do wzorców danego projektu. Sugeruje importy z pakietów, których projekt nie używa.¹²

Faros AI przeanalizowało telemetrię od 10 000 programistów w 1 255 zespołach i stwierdziło, że pull requesty wspomagane AI są o 154% większe niż te bez wspomagania.¹² Większe PR-y niosą większą powierzchnię błędów zależnych od kontekstu. AI generuje kod pewnie. Kod się kompiluje. Kod nie uwzględnia ograniczenia udokumentowanego na stronie Confluence, której AI nigdy nie widział.

To nie jest problem halucynacji w sensie bezpieczeństwa modeli. Model działa dokładnie tak, jak został zaprojektowany: przewiduje prawdopodobny kod na podstawie dostępnego kontekstu. Problem polega na tym, że dostępny kontekst wyklucza większość tego, co ma znaczenie dla poprawności w konkretnej bazie kodu.

Próżnia weryfikacji

AI generuje kod szybciej, niż istniejące procesy przeglądu mogą go wchłonąć. Faros stwierdził, że PR-y wspomagane AI wymagają o 91% więcej czasu na review.¹² Programiści realizują o 21% więcej zadań i scalają o 98% więcej pull requestów, ale pipeline przeglądu obsługuje tempo ludzkie.¹²

Badanie Stanforda dotyczące niebezpiecznego kodu określiło ilościowo wymiar bezpieczeństwa. Badacze dali 47 programistom zadania kodowania z asystentem AI i bez niego. Grupa wspomagana AI częściej pisała niebezpieczne rozwiązania w czterech z pięciu zadań. W zadaniu dotyczącym SQL injection 36% grupy AI napisało podatny kod w porównaniu z 7% grupy kontrolnej. Uczestnicy korzystający z AI częściej wierzyli, że napisali bezpieczny kod, nawet gdy tak nie było.¹³ Połączenie szybszego generowania i wyższej fałszywej pewności tworzy lukę weryfikacyjną, której ręczny przegląd nie może zamknąć na dużą skalę.

GitClear przeanalizował 153 miliony zmienionych linii kodu i stwierdził, że churn kodu (kod przepisywany w ciągu dwóch tygodni od napisania) miał się podwoić w 2024 roku w porównaniu z bazą sprzed ery AI.¹⁴ Wzrost wolumenu generowanego przez narzędzia AI tworzy przeróbki, które częściowo niwelują zyski produktywności. Ankieta Stack Overflow z 2025 roku potwierdza te tarcia: 66% programistów deklaruje, że spędza więcej czasu na naprawianiu „prawie poprawnego” kodu generowanego przez AI.⁶

Luka w nadzorze

Kod generowany przez AI omija mechanizmy nadzoru, które ludzcy programiści zinternalizowali. Doświadczony programista wie, że trzeba sprawdzić przewodnik stylu, uruchomić linter, zaktualizować changelog i powiadomić lidera zespołu o zmianach architektonicznych. Asystent AI generuje rozwiązanie spełniające prompt. Dystans między „kompiluje się i przechodzi testy” a „spełnia standardy organizacyjne” to właśnie nadzór.

Badanie McKinsey z 2023 roku wykazało, że młodsi programiści korzystający z AI byli o 7-10% wolniejsi, a nie szybsi.¹¹ Badacze przypisali to dystansowi między generowanym kodem a kontekstem organizacyjnym. Młodsi programiści nie mają doświadczenia, by ocenić, czy wynik AI spełnia standardy, których jeszcze nie zinternalizowali. Bez infrastruktury nadzoru, która koduje te standardy jako automatyczne kontrole, wynik AI przepływa dalej bez weryfikacji.

Luka w nadzorze kumuluje się w zespołach. Wygenerowana przez AI funkcja pomocnicza jednego programisty duplikuje istniejący moduł innego. Dwa wygenerowane przez AI endpointy używają różnych formatów błędów dla tego samego API. Migracje generowane przez AI stosują inną konwencję nazewnictwa niż standard zespołu. Każde naruszenie jest niewielkie. Skumulowany efekt to baza kodu, która odchodzi od własnych konwencji szybciej, niż przegląd jest w stanie to skorygować.

Jak wygląda druga strona

Odkrycie DORA opisuje dwie populacje używające identycznych narzędzi. Jedna zmniejszyła liczbę incydentów o połowę. Druga ją podwoiła.⁴ Zmienną między nimi nie jest to, jakiego AI używają. Jest nią infrastruktura wokół AI.

Każda przyczyna źródłowa mapuje się na rozwiązanie infrastrukturalne. Poniższa tabela przedstawia łańcuch od problemu do rozwiązania, z jedną konkretną implementacją z systemu, który zbudowałem i udokumentowałem w towarzyszących wpisach. To jedna próba z konkretnymi liczbami, nie uniwersalna recepta.

Wstrzykiwanie kontekstu rozwiązuje problem głodu, zapewniając, że model otrzymuje informacje specyficzne dla projektu przy każdym prompcie. Hook dysponujący uruchamia dziewięć sekwencyjnych handlerów, które wstrzykują bieżącą datę, branch git, katalog roboczy, konwencje projektu, kontekst aktywnego zadania i ograniczenia architektoniczne. Model otrzymuje 200-400 tokenów kontekstu gruntującego przed przetworzeniem zapytania użytkownika. Zmierzone opóźnienie: 200 ms łącznie dla wszystkich dziewięciu hooków. Model przestaje zgadywać ścieżki plików, ponieważ został poinformowany o rzeczywistych ścieżkach.¹⁵

Niezależna weryfikacja rozwiązuje problem próżni, usuwając ludzi z wąskiego gardła weryfikacji przy rutynowych kontrolach. Autonomiczna pętla programistyczna (udokumentowana w Anatomy of a Claw) generuje kod, uruchamia pełen zestaw testów i przekazuje wyniki trzem agentom przeglądu, którzy działają niezależnie. Agent implementujący nigdy nie ocenia własnego wyniku. To odzwierciedla odkrycie, że grupa wspomagana AI w badaniu Stanforda była bardziej pewna niebezpiecznego kodu: autoweryifikacja jest zawodna, niezależnie od tego, czy autorem jest człowiek, czy maszyna.¹³

Automatyczny nadzór rozwiązuje problem luki, kodując standardy zespołu jako wykonywalne kontrole. The Fabrication Firewall klasyfikuje każdą akcję wychodzącą jako lokalną, współdzieloną lub zewnętrzną, delegując publikację zewnętrzną do przeglądu ludzkiego. Bramki jakości blokują raporty ukończenia, które używają języka asekuracyjnego („powinno działać”, „wygląda poprawnie”) zamiast cytowania wyników testów i ścieżek plików. System egzekwuje standardy, które ludzcy programiści stosowaliby, gdyby mieli czas na przegląd każdej linii. Przy prędkości generowania AI — nie mają.¹⁵

Połączony system daje mierzalne wyniki w swojej własnej bazie kodu: 4 518 fragmentów kodu zaindeksowanych do wyszukiwania semantycznego, 49 746 fragmentów w vault obejmującym 15 800 plików jako pamięć trwała, oraz zestaw testów uruchamiany automatycznie przed raportowaniem ukończenia jakiejkolwiek zmiany.¹⁵ Te liczby opisują infrastrukturę jednego programisty. Nie mogą dowieść, że podejście się uogólnia. Mogą pokazać, że mur jest przenikliwy, jeśli po drugiej stronie znajdują się odpowiednie narzędzia.

Wskaźnik nadzoru

System hooków opisany w Anatomy of a Claw zawiera 84 hooki. Zweryfikowane zestawienie dzieli je według funkcji: 35 hooków oceniających, które decydują, czy coś powinno się wydarzyć, i 44 hooki automatyzujące, które wykonują z góry określone akcje. Proporcja wynosi 4:5. Na początku wynosiła 1:6.¹⁵

Początkowa proporcja odzwierciedla to, co większość zespołów buduje najpierw: automatyzację. Wstrzykiwanie kontekstu. Rejestrowanie metryk. Formatowanie wyników. Logowanie użycia. Te hooki wychwytują 10%, które każdy dostaje. Automatyzują mechaniczne aspekty programowania, które były już częściowo zautomatyzowane przed erą AI. Dane DX to potwierdzają: cztery zaoszczędzone godziny tygodniowo pochodzą z generowania kodu i redukcji powtarzalnego kodu — zadań, które były już najszybszą częścią cyklu programistycznego.¹

Przesunięcie w kierunku hooków oceniających odzwierciedla źródło dodatkowych zysków.

Ankieta McKinsey z 2025 roku obejmująca blisko 300 firm wykazała, że najlepsi uzyskali poprawę produktywności o 16-30% i poprawę jakości o 31-45%.¹⁶ Organizacje te miały 80-100% adopcji wśród programistów w połączeniu z integracją organizacyjną. Czynnikiem wyróżniającym nie był wskaźnik adopcji (który koreluje z 10% zyskami w całej populacji), ale infrastruktura i procesy zbudowane wokół tej adopcji.

Ujęcie Laury Tacho ma tu zastosowanie: „Jestem sceptyczna wobec każdej technologii obiecującej poprawę wydajności bez zajęcia się tymi fundamentalnymi ograniczeniami.”³ Fundamentalne ograniczenia to ograniczenia oceny. Czy ten kod spełnia nasze standardy? Czy ta zmiana psuje coś dalej w procesie? Czy ten wynik zawiera fabrykację? Hooki automatyzujące nie mogą odpowiedzieć na te pytania. Hooki oceniające mogą — niedoskonale — kodując kryteria, które doświadczeni programiści stosują mentalnie.

Proporcja nie osiągnęła jeszcze parytetu. System wciąż automatyzuje więcej, niż nadzoruje. To samo w sobie jest diagnostyczne: każda warstwa orkiestracji, w której hooki automatyzujące przewyższają liczbą hooki oceniające, ma przestrzeń do poprawy.

Co tak naprawdę trzeba zbudować

System opisany w towarzyszących wpisach ma 84 hooki, 43 skille, 19 agentów i 15 000 linii infrastruktury. Nie potrzeba 15 000 linii. Potrzeba trzech rzeczy.

Jednego hooka wstrzykiwania kontekstu. Pięć linii bash, które wstrzykują bieżącą datę, branch i katalog roboczy do każdego promptu AI. To eliminuje całą kategorię halucynacji: model przestaje wymyślać ścieżki plików i nazwy branchy, ponieważ dysponuje prawdziwymi.

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

Jednej bramki jakości. Piętnaście linii, które przeszukują raporty ukończenia pod kątem języka asekuracyjnego. Jeśli agent pisze „powinno działać” zamiast cytować wyniki testów, bramka blokuje. To rozwiązuje próżnię weryfikacji przy najniższym możliwym koszcie wejścia.¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

Jednego niezależnego test runnera. Hooka, który uruchamia zestaw testów projektu po każdej zmianie kodu i głośno informuje o niepowodzeniu, gdy testy się psują. Implementacja różni się w zależności od projektu. Zasada nie: agent, który pisze kod, nie może być jedynym sędzią tego kodu.

Zacznij od tego, co najczęściej się psuje w przepływie pracy. Jeśli AI halucynuje ścieżki plików, zbuduj najpierw hook kontekstu. Jeśli AI wypuszcza nieprzetestowany kod, zbuduj najpierw test runner. Jeśli AI pisze „zrobione” bez dowodów, zbuduj najpierw bramkę jakości.

Karpathy opisał ewolucję od vibe coding do inżynierii agentowej: „orkiestrowanie agentów, którzy wykonują [pracę] i pełnienie roli nadzoru.”¹⁷ Trzy powyższe hooki to minimalny realny nadzór. Nie przyniosą 30% zysków. Przesuną z 10% w kierunku 15%, a każdy dodany ujawni kolejne ograniczenie warte zaadresowania.

Mur jest realny. Jest też konkretny. Głód kontekstu, próżnia weryfikacji i luka w nadzorze to problemy inżynieryjne z inżynieryjnymi rozwiązaniami. Modele będą się dalej doskonalić. Mur pozostanie na 10% dla każdego zespołu, który traktuje AI jako generator kodu zamiast systemu wymagającego infrastruktury do nadzorowania swoich wyników.

Źródła