Ściana 10%: Dlaczego produktywność AI osiąga plateau

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

Ta liczba utrzymuje się na stałym poziomie od trzech kolejnych kwartałów.^{1 2} Adopcja rosła. Objętość kodu rosła. Narzędzia się poprawiały. Zyski — nie. Laura Tacho, CTO w DX, ujęła to wprost: „To naprawdę problem zarządzania. Szum medialny sprawiał, ż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 widziały, jak AI wzmacnia ich istniejące atuty. Organizacje ze słabymi praktykami widziały, jak AI wzmacnia ich istniejące dysfunkcje. Te same narzędzia. Przeciwne wyniki. Raport konkludował: „Główną rolą AI w rozwoju oprogramowania jest rola wzmacniacza. Potęguje mocne strony wysoko wydajnych organizacji i dysfunkcje tych, które mają problemy.”⁴

Ściana nie jest problemem modelu. Jest problemem infrastruktury. Lepsze modele nie przebiją się przez ścianę zbudowaną z brakującej weryfikacji, brakującego kontekstu i brakującego nadzoru. Towarzyszące temu wpisowi posty 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. Poniższy wpis wyjaśnia, dlaczego te systemy istnieją.

TL;DR

121 000 programistów zbadanych, 92,6% adopcji, produktywność utknęła na 10%. Trzy przyczyny źródłowe wyjaśniają ten sufit: głód kontekstu (AI zgaduje bez wiedzy o projekcie), próżnia weryfikacyjna (kod jest dostarczany szybciej, niż recenzja się adaptuje) i luka w nadzorze (AI omija standardy, które ludzie egzekwują). DORA ustaliło, że AI wzmacnia zarówno mocne strony, jak i dysfunkcje, w zależności od otaczającej infrastruktury.⁴ Przebicie się wymaga infrastruktury wokół AI, nie lepszego AI. Wpis dokumentuje jedną próbę N=1 budowy takiej infrastruktury, z konkretnymi liczbami z systemu obsługującego 84 hooki, 43 umiejętności i 19 agentów.

Co mówią badania

Zbiór danych DX obejmuje 4,2 miliona programistów obserwowanych między listopadem 2025 a lutym 2026, z detalicznym 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.⁷ Sufit adopcji jest bliski.

Historia produktywności utknęła. DX zmierzyło średnio cztery godziny oszczędności tygodniowo, bez zmian w porównaniu z 3,6 godziny z poprzedniego kwartału.^{1 2} Kod generowany przez AI wzrósł z 22% do 26,9% scalonego kodu, ale dodatkowa objętość nie przełożyła się na dodatkowy wynik.^{1 2} Laura Tacho wskazała na matematykę: programiści spędzają mniej więcej 20% czasu na pisaniu kodu. 10% poprawa na 20% dnia pracy to 2% poprawa ogółem. „Szybkość pisania nigdy nie była wąskim gardłem.”⁸

Krytyczny jest ostatni wiersz. Raport DORA z 2024 zbadał 39 000 specjalistów i stwierdził, że na każde 25% wzrostu adopcji AI przepustowość dostarczania spadała szacunkowo o 1,5%, a stabilność dostarczania o 7,2%.⁵ Raport DORA z 2025 wykazał, że relacja AI-przepustowość przesunęła się z negatywnej korelacji zaobserwowanej w 2024 na pozytywną, ale stabilność dostarczania pozostała negatywnie powiązana z adopcją AI.⁴ Adopcja AI nadal korelowała ze zwiększoną niestabilnością, nawet gdy przepustowość się poprawiała.

Rozbieżność ma większe znaczenie niż średnie. METR zbadało 16 doświadczonych programistów open-source pracujących nad 246 prawdziwymi problemami repozytoriów i stwierdziło, że z narzędziami AI pracowali o 19% dłużej niż bez nich.⁹ Randomizowane badanie kontrolowane Google z udziałem 96 inżynierów wykazało 21% przyspieszenie, ale wynik nie był istotny statystycznie (95% CI przecinało zero).¹⁰

McKinsey stwierdził zyski rzędu 35-50% przy prostych zadaniach, ale poniżej 10% przy zadaniach o wysokiej złożoności, a młodsi programiści używający AI byli o 7-10% wolniejsi w badaniu obejmującym 40 własnych programistów.¹¹ Wzorzec: AI przyspiesza te części programowania, które nigdy nie były wąskim gardłem.

Firmy, które przebiły się przez ścianę, nie używały lepszych modeli. Zbudowały infrastrukturę, która wyłapywała to, co modele pomijały.

Dlaczego ściana istnieje

Trzy przyczyny źródłowe wyjaśniają plateau. Każda działa niezależnie. Razem tworzą sufit, którego lepsze modele nie są w stanie 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 projektu, 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 pasują do prawdopodobnych konwencji, 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 z 1 255 zespołów i stwierdziło, że pull requesty wspomagane przez AI są o 154% większe od tych bez wspomagania.¹² Większe PR-y niosą większą powierzchnię dla błędów zależnych od kontekstu. AI generuje kod z pewnością siebie. Kod się kompiluje. Kod nie uwzględnia ograniczenia udokumentowanego na stronie Confluence, której AI nigdy nie widziało.

To zachowanie nie jest problemem halucynacji w sensie bezpieczeństwa modelu. Model działa dokładnie zgodnie z projektem: 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 weryfikacyjna

AI generuje kod szybciej, niż istniejące procesy recenzji mogą go wchłonąć. Faros stwierdził, że PR-y wspomagane przez AI są recenzowane o 91% dłużej.¹² Programiści realizują o 21% więcej zadań i scalają o 98% więcej pull requestów, ale pipeline recenzji jest przystosowany do ludzkiej prędkości.¹²

Badanie Stanford dotyczące niebezpiecznego kodu skwantyfikowało wymiar bezpieczeństwa. Badacze dali 47 programistom zadania kodowania z pomocą AI i bez niej. Grupa wspomagana przez AI pisała niebezpieczne rozwiązania częściej 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 pomocy AI częściej wierzyli, że napisali bezpieczny kod, nawet gdy tak nie było.¹³ Połączenie szybszego wytwarzania i wyższej fałszywej pewności tworzy lukę weryfikacyjną, której manualna recenzja nie jest w stanie zamknąć na skalę.

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

Luka w nadzorze

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

Badacze McKinsey przypisali spowolnienie młodszych programistów luce między wygenerowanym kodem a kontekstem organizacyjnym. Młodsi programiści nie mają osądu, 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. Narzędzie wygenerowane przez AI jednego programisty duplikuje istniejący moduł innego programisty. Dwa endpointy wygenerowane przez AI używają różnych formatów błędów dla tego samego API. Migracje wygenerowane przez AI stosują inną konwencję nazewnictwa niż standard zespołu. Każde naruszenie jest małe. Efekt kumulatywny to baza kodu, która odchodzi od własnych konwencji szybciej, niż recenzja jest w stanie to skorygować.

Jak wygląda druga strona

Odkrycie DORA opisuje dwie populacje używające identycznych narzędzi. Organizacje z silnymi praktykami widziały, jak AI wzmacnia ich mocne strony. Organizacje ze słabymi praktykami widziały, jak AI wzmacnia ich dysfunkcje.⁴ 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 mapuje łańcuch od problemu do rozwiązania, z jedną konkretną implementacją z systemu, który zbudowałem i udokumentowałem w towarzyszących wpisach. Przykład to jedna próba z konkretnymi liczbami, nie uniwersalna recepta.

Wstrzykiwanie kontekstu rozwiązuje głód, zapewniając, że model otrzymuje informacje specyficzne dla projektu przy każdym prompcie. Hook dispatchera uruchamia dziewięć sekwencyjnych handlerów, które wstrzykują aktualną datę, branch Git, katalog roboczy, konwencje projektu, kontekst aktywnego zadania i ograniczenia architektoniczne. Model otrzymuje 200-400 tokenów kontekstu zakotwiczają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ż otrzymał rzeczywiste ścieżki.¹⁵

Niezależna weryfikacja rozwiązuje próżnię, usuwając ludzi z wąskiego gardła weryfikacji przy rutynowych kontrolach. Autonomiczna pętla rozwojowa (udokumentowana w Anatomy of a Claw) generuje kod, uruchamia pełny zestaw testów i przekazuje wyniki trzem agentom recenzenckim, którzy działają niezależnie. Agent implementacyjny nigdy nie recenzuje własnego wyniku. Separacja odzwierciedla odkrycie, że grupa wspomagana przez AI w badaniu Stanford była bardziej pewna niebezpiecznego kodu: samoweryfikacja jest zawodna, niezależnie od tego, czy autorem jest człowiek, czy sztuczna inteligencja.¹³

Zautomatyzowany nadzór rozwiązuje lukę, kodując standardy zespołu jako wykonywalne kontrole. The Fabrication Firewall klasyfikuje każdą akcję wychodzącą jako lokalną, współdzieloną lub zewnętrzną, odraczając publikację zewnętrzną do recenzji ludzkiej. Bramki jakości blokują raporty zakończenia, które używają języka unikowego („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 na własnej bazie kodu: 4 518 fragmentów kodu zindeksowanych do wyszukiwania semantycznego, 49 746 fragmentów vault w 15 800 plikach do trwałej pamięci i zestaw testów, który uruchamia się automatycznie przed zgłoszeniem zakończenia jakiejkolwiek zmiany.¹⁵ Te liczby opisują infrastrukturę jednego programisty. Nie mogą udowodnić, że podejście się uogólnia. Mogą zademonstrować, że ściana jest przenikalna przy odpowiednich narzędziach po drugiej stronie.

Współczynnik nadzoru

System hooków opisany w Anatomy of a Claw zawiera 84 hooki. Zweryfikowane zliczenie dzieli je według funkcji: 35 hooków osądowych, które decydują, czy coś powinno się zdarzyć, 44 hooki automatyzacyjne, które wykonują z góry określone akcje, i 5 hooków narzędziowych (dispatchery, zarządzanie stanem). Współczynnik nadzoru wynosi 4:5. Na początku wynosił 1:6.¹⁵

Początkowy współczynnik odzwierciedla to, co większość zespołów buduje najpierw: automatyzację. Wstrzyknij kontekst. Zapisz metryki. Sformatuj wynik. Zaloguj użycie. Te hooki wychwytują te 10%, które każdy uzyskuje. Automatyzują mechaniczne części programowania, które były już częściowo zautomatyzowane przed AI. Dane DX potwierdzają to: cztery zaoszczędzone godziny tygodniowo pochodzą z generowania kodu i redukcji szablonowego kodu — zadań, które już były najszybszą częścią cyklu rozwojowego.¹

Przesunięcie w kierunku hooków osądowych odzwierciedla, skąd pochodzą dodatkowe zyski.

Ankieta McKinsey z 2025 obejmująca blisko 300 spółek giełdowych wykazała, że najlepsi osiągnęli poprawę produktywności o 16-30% i poprawę jakości o 31-45%.¹⁶ Organizacje te miały 80-100% adopcję wśród programistów połączoną z integracją organizacyjną. Czynnikiem wyróżniającym nie był wskaźnik adopcji (który koreluje z 10% zyskami w każdym przypadku), lecz infrastruktura i procesy zbudowane wokół tej adopcji.

Ujęcie Laury Tacho stosuje się tutaj: „Jestem sceptyczna wobec obietnic jakiejkolwiek technologii poprawy wydajności bez zaadresowania tych podstawowych ograniczeń.”³ Podstawowe ograniczenia to ograniczenia osądu. Czy ten kod spełnia nasze standardy? Czy ta zmiana psuje coś dalej w procesie? Czy ten wynik zawiera fabrykację? Hooki automatyzacyjne nie mogą odpowiedzieć na te pytania. Hooki osądowe mogą — niedoskonale — kodując kryteria, które doświadczeni programiści stosują mentalnie.

Współczynnik nie osiągnął jeszcze parytetu. System nadal automatyzuje więcej, niż nadzoruje. Sam brak równowagi jest diagnostyczny: każda warstwa orkiestracji, w której hooki automatyzacyjne przewyższają liczebnie hooki osądowe, ma pole do poprawy.

Co faktycznie trzeba zbudować

System opisany w towarzyszących wpisach ma 84 hooki, 43 umiejętności, 19 agentów i 15 000 linii infrastruktury.¹⁵ Nie potrzeba 15 000 linii. Potrzeba trzech rzeczy.

Jeden hook wstrzykiwania kontekstu. Pięć linii basha, które wstrzykują aktualną datę, branch i katalog roboczy do każdego promptu AI. Wstrzyknięcie eliminuje całą kategorię halucynacji: model przestaje wymyślać ścieżki plików i nazwy branchy, ponieważ ma prawdziwe.

#!/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)"

Jedna bramka jakości. Piętnaście linii, które wyszukują w raportach zakończenia język unikowy. Jeśli agent mówi „powinno działać” zamiast cytować wyniki testów, bramka blokuje. Bramka rozwiązuje próżnię weryfikacyjną w najtańszym możliwym punkcie 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

Jeden niezależny runner testów. Hook, 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 codziennej pracy. Jeśli AI halucynuje ścieżki plików, najpierw zbuduj hook kontekstowy. Jeśli AI dostarcza nieprzetestowany kod, najpierw zbuduj runner testów. Jeśli AI pisze „gotowe” bez dowodów, najpierw zbuduj bramkę jakości.

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

Ściana jest realna. Jest też konkretna. Głód kontekstu, próżnia weryfikacyjna i luka w nadzorze to problemy inżynieryjne z inżynieryjnymi rozwiązaniami. Modele będą się dalej poprawiać. Ściana utrzyma się na 10% dla każdego zespołu, który traktuje AI jako generator kodu zamiast systemu wymagającego infrastruktury do nadzorowania jego wyników.

Kluczowe wnioski

Dla indywidualnych programistów. Zacznij od jednego hooka wstrzykiwania kontekstu. Pięć linii basha wstrzykujących datę, branch i katalog roboczy eliminuje całą kategorię halucynacji AI. Ściana zaczyna pękać, gdy model zna rzeczywiste ścieżki plików zamiast je zgadywać.

Dla liderów zespołów. Zmierz swój współczynnik nadzoru: ile hooków AI weryfikuje wyniki w porównaniu z automatyzacją zadań. Jeśli hooki automatyzacyjne przewyższają liczebnie hooki osądowe, zespół przechwytuje jedynie pierwsze 10%. Dane DX potwierdzają, że cztery zaoszczędzone godziny tygodniowo pochodzą z generowania kodu — zadań, które już były najszybszą częścią cyklu rozwojowego.¹

Dla inżynierów platformowych. Zbuduj warstwę weryfikacji przed skalowaniem adopcji AI. DORA ustaliło, że organizacje wdrażające AI bez infrastruktury inżynieryjnej widziały wzrost niestabilności wraz z adopcją.^{4 5} Trzy przyczyny źródłowe mapują się na trzy rozwiązania infrastrukturalne. Zacznij od tego, które powoduje największe tarcie w pipeline.

Źródła