Dlaczego zespoły AI wdrażają szybciej i wypuszczają gorsze produkty: problem długu intencji

AI sprawiło, że pisanie kodu stało się niemal bezkosztowe. Decydowanie, co pisać, stało się trudniejsze. Ta luka to dług intencji, który narasta szybciej niż jakikolwiek przestarzały kod.

Garry Tan raportuje wysyłkę 37 000 linii kodu dziennie w pięciu projektach, prowadząc jednocześnie Y Combinator na pełen etat. Inżynierowie Anthropic przez 47 dni cichych regresji w Claude Code nie dostrzegli problemu, który wyszedł na jaw dopiero w publicznym postmortem 23 kwietnia 2026. Obie liczby opisują ten sam problem z przeciwnych stron.

Jeśli zespół pisze więcej kodu niż kiedykolwiek, a efekty wdrożeń są gorsze niż rok temu, dług intencji narasta w czasie rzeczywistym. Dług techniczny był podatkiem za wolne kodowanie. Dług intencji jest podatkiem za wolne decydowanie. Ten artykuł nazywa wąskie gardło, pokazuje, dlaczego warstwy przeglądu i ewaluacji go nie wychwytują, i opisuje cztery działania pozwalające go spłacić.

• AI skompresowało czas kodowania od 30 do 100 razy. Czas podejmowania decyzji skompresowało od 3 do 5 razy. Ta luka to nowe wąskie gardło.

• Dług intencji powstaje przed każdą warstwą przeglądu. Narzędzia AI do recenzji kodu, ewaluacje i agenty QA wykrywają zły kod, ale nie wykrywają dobrze zbudowanej złej rzeczy.

• 47 dni cichych regresji Anthropic w Claude Code to postmortem długu intencji ukryty pod pozorem problemu z ewaluacją. Dryf nie tkwił w kodzie, lecz w tym, na co zespół zwracał uwagę.

• Rozwiązanie ma charakter strukturalny, nie taktyczny. Nie można wdrożyć się z tego problemu. Wychodzi się z niego przez szybsze i wcześniejsze decydowanie.

• webvise traktuje uchwycenie intencji jako właściwy produkt końcowy, a nie jako bezpłatną aktywność przedsprzedażową. Sprawdź, gdzie to ma zastosowanie w Państwa zespole.

Czym jest dług intencji

Dług techniczny to termin, który Ward Cunningham ukuł w 1992 roku, opisując przyszły koszt wyboru szybkiego rozwiązania kosztem czystego. Wymiana miała jasną ekonomię: dostarczało się szybciej, płaciło odsetki w postaci trudniejszego utrzymania w przyszłości, a kapitał tkwił w kodzie jako coś do zrefaktoryzowania przy najbliższej okazji.

Dług intencji ma ten sam kształt. Wymiana to szybszy kod za cenę rozmytych decyzji. Produkt jest gotowy wcześniej, bo AI napisała implementację w 30 minut zamiast trzech dni, a odsetkami jest wszystko, co narasta dalej, gdy zespół nigdy nie ustalił precyzyjnie, jaki powinien być właściwy rezultat.

Brakuje jeszcze odpowiedniego słownictwa, bo ta wymiana jest nowa. Martin Fowler pisał o nazewnictwie i intencji projektowej, zakładając świat, w którym pisanie kodu było kosztownym krokiem, a dopracowanie projektu zwracało się przez zmniejszenie liczby przepisań.

To założenie odwróciło się w 2024 roku. Gdy przepisanie trwa jeden dzień, etap projektowania przestaje się zwracać tak jak dawniej. Zespoły to zauważają i pomijają ten etap, który był miejscem, gdzie intencja stawała się czymś zrozumiałym dla kolejnej osoby.

Dwa wzorce niepowodzeń, które udało mi się zaobserwować osobiście.

Pierwszy: funkcja gotowa w trzy dni, na którą przed erą AI czekano by trzy tygodnie. Działa. Rozwiązuje jednak problem, którego użytkownicy nie mają, bo specyfikacja to wiadomość na Slacku, a wykonawcą był agent Cursor. Koszt budowy był tak niski, że zespół nigdy ponownie nie zapytał, czy w ogóle warto było to budować.

Drugi: starszy inżynier zamyka sześć kierunków produktowych w ciągu jednego roku. Żaden nie upada z powodów technicznych. Każdy umiera na etapie przedsprzedaży, a inżynier wciąż ten etap pomija, bo pisanie kodu sprawia wrażenie bardziej produktywnego. Tym inżynierem byłem ja, a koszt postmortem tamtych sześciu kierunków był wyższy niż jakikolwiek dług techniczny, który kiedykolwiek spłacałem.

Obydwie historie to dług intencji z paragonem w ręku. Większość zespołów inżynierskich nadal próbuje rozwiązać ten problem na poziomie budowania: kolejnym recenzentem, kolejną ewaluacją, kolejnym linterem. Rozwiązanie leży o jedną warstwę wyżej. Jeśli Państwa zespół produkuje podobne paragony, webvise powstało właśnie wokół tego odwrócenia.

Liczby stojące za tą zmianą

Najbardziej czytelne dane z pierwszej ręki na temat tej asymetrii pochodzą z pliku gstack ETHOS Garry'ego Tana, opublikowanego w kwietniu 2026. Tan dostarcza otwartoźródłowy zestaw narzędzi agentowych z Y Combinator i instrumentuje swoje agenty eksplicite podanymi współczynnikami kompresji człowiek kontra AI dla każdego rodzaju zadania.

Warto przeczytać tabelę kolumna po kolumnie. Boilerplate kompresuje się 100x, pisanie testów 50x, praca nad funkcjami 30x. Architektura i badania kompresują się odpowiednio 5x i 3x.

Trzy dolne wiersze to praca nad intencją. Kompresja jest, ale dziesięciokrotnie wolniejsza niż w przypadku trzech górnych. To strukturalne źródło długu intencji: kodowanie jest teraz niemal bezkosztowe, decydowanie nadal drogie.

Ujmując to konkretnie: jeśli zespół poświęcał dawniej 80% dnia inżynierskiego na kod i 20% na decyzje, nowy podział po 30-krotnej kompresji kodu wynosi w przybliżeniu 12% na kod i 88% na decyzje. Większość zespołów zachowała te same zasoby, ten sam rytm spotkań i tę samą strukturę przeglądu, a następnie obserwowała, jak ta druga kolumna się przepełnia.

To przepełnienie jest właśnie tym, jak dług intencji wygląda w praktyce.

Trzy symptomy wskazujące, że już się go dźwiga

Dług intencji jest niewidoczny, dopóki się go nie nazwie. Trzy symptomy pojawiają się w zespołach, z którymi pracuję.

Odruch cięcia zakresu przy pracy o już poniesionych kosztach

Pisze się trzy testy zamiast dziesięciu, pomija dokumentację, 80% uznaje za wystarczające. Ten odruch miał sens, gdy ograniczeniem był czas ludzki. Gdy w pętlę wchodzi AI, kompletna wersja kosztuje tyle samo minut co prowizoryczne rozwiązanie.

Odruch jest teraz myśleniem w kategoriach nieaktualnej rzeczywistości, stosowanym automatycznie. Ceną jest nawyk decyzyjny mówiący, że wdrożenie szybciej jest lepsze niż wdrożenie właściwie, nawet gdy szybsze wdrożenie nie przynosi już żadnych oszczędności czasu.

Więcej przeglądu, mniej decyzji

Elie Steinbock opublikował 20 kwietnia 2026 tezę, w której wskazuje przegląd jako nowe wąskie gardło. Wymienia siedem warstw obrony: od narzędzi AI do recenzji kodu, takich jak Cubic i CodeRabbit, po dedykowane agenty QA i ograniczoną obserwowalność. Zespoły przyjmują kolejne warstwy, a powierzchnia przeglądu pochłania coraz więcej dnia pracy.

Dług intencji powstaje przed wszystkimi tymi narzędziami. Recenzenci AI wykrywają zły kod, ale nie wykrywają złej rzeczy zbudowanej dobrze. Agent QA przechodzący każdy przepływ przy każdym wydaniu powie, że przepływ działa, ale nie powie, czy ten przepływ powinien w ogóle istnieć.

Cichy dryf widoczny dopiero w postmortemach

Anthropic opublikowało 23 kwietnia 2026 postmortem dokumentujący 47 dni cichych regresji w Claude Code. Główna narracja brzmiała: ewaluacje nie wychwytują dryfu. Głębsza warstwa jest taka, że dryf narasta w luce między tym, co zamierzał osiągnąć zespół, a tym, co system faktycznie robił.

Każdy zespół prowadzący tworzenie wspomagane przez AI ma właśnie teraz własne otwarte 47-dniowe okno. Większość dowie się o nim dopiero w postmortem.

Dlaczego przeglądy i ewaluacje go nie wychwytują

Narzędzia do przeglądu odpowiadają na pytanie: czy kod zrobił to, co mówiła specyfikacja? Zestawy ewaluacyjne odpowiadają: czy model zachował się zgodnie z oczekiwaniami ewaluacji? To poprawne, wąskie pytania. Obydwa traktują specyfikację i ewaluację jako punkt odniesienia.

Dług intencji narasta na warstwie powyżej. Koszt tkwi w luce między tym, czego potrzebował klient, co opisywał brief i co uchwyciła specyfikacja. Zanim kod trafi przed narzędzie do przeglądu, specyfikacja zdążyła już zakodować intencję. Recenzent nie może wykryć defektu specyfikacji, może jedynie wskazać defekty implementacji względem wadliwej specyfikacji.

To dokładnie ten sam kształt co dryf Anthropic. Zespół Claude Code miał ewaluacje. Ewaluacje przechodziły.

Dryf tkwił w tym, co mierzyły ewaluacje, w zestawieniu z tym, czego użytkownicy faktycznie doświadczali. Przez 47 dni zielone światła, a prawdziwi użytkownicy trafiają na regresję każdego dnia. Rozwiązaniem jest ściślejsze sprzężenie zwrotne między osobami decydującymi, co mierzyć, a osobami obserwującymi sygnały produkcyjne.

Myślenie zorientowane na wąskie gardło przeglądu traktuje to jako problem narzędziowy. To problem warstwowy. Ten artykuł warto uzupełnić wcześniejszym tekstem o tym, dlaczego oprogramowanie generowane przez AI wciąż wymaga inżynierskiego przeglądu, który stanowi drugą połowę argumentu dotyczącą warstwy budowania. Spłata długu intencji wymaga zadania innego pytania, wcześniej.

Warstwa decyzyjna nie kompresuje się jak kod

Ujęcie Tana wyjaśniające strukturalny charakter tego problemu: smak dostarcza się w rozmowie z agentem. Agent dostarcza kompletność. Człowiek dostarcza kierunek i osąd. Smak nie podlega tej samej krzywej kompresji co kod.

Trzy składniki smaku, których generowanie kodu nie może zastąpić.

Wybór właściwego problemu

Teza Alexa Vacca o oprogramowaniu jako usłudze, opublikowana przez partnera Sequoia Juliena Beka w kwietniu 2026, ujmuje szerszy wymiar tego zagadnienia. Dostawcy oprogramowania sprzedający narzędzie ścigają model w nieskończoność. Firmy, które są właścicielami pracy i używają modelu do jej realizacji, zyskują za każdym razem, gdy model się poprawia.

Ta sama logika obowiązuje wewnątrz zespołów. Inżynierowie wybierający właściwy problem zyskują za każdym razem, gdy model się poprawia. Inżynierowie wykonujący wyłącznie odgórnie zlecone specyfikacje stają się towarem z dnia na dzień.

Wiedzieć, kiedy skończyć

Narzędzia AI nigdy nie mówią, żeby przestać. LLM angażuje się w siedemnaste podejście do tego samego problemu z takim samym entuzjazmem jak w pierwsze, a każda odpowiedź będzie sprawiać wrażenie postępu. Bez zewnętrznego warunku zakończenia pętla działa w nieskończoność.

Doświadczeni inżynierowie narzucali ten warunek przez znudzenie lub wyczerpanie budżetu czasu. Oba ograniczenia są teraz nieskończone. Warunek zakończenia trzeba ustalić eksplicite z góry, przed pierwszym promptem.

Sprzeciw, którego dostarczają starsi inżynierowie

Najtrudniejszym produktem z pierwszej ręki, który wytwarza starszy inżynier, jest sprzeciw: komunikat, że budowana jest zła rzecz, który z wyprzedzeniem unieważnia cały kwartał realizacji. Agenty AI nie wyrażają sprzeciwu. Budują to, o co się je prosi, kompletnie, na krzywej kompresji 100x.

Wdraża się dokładnie to, o co proszono, i dopiero później odkrywa się, że proszono o niewłaściwą rzecz.

Cztery działania spłacające dług intencji

To działania taktyczne. Zakładają, że zespół już nazwał problem i przestał próbować absorbować go na warstwie przeglądu.

Przedsprzedaż przed otwarciem edytora

To działanie, które sam musiałem nauczyć się na nowo w trudny sposób. Przy budowaniu czegokolwiek dla kogoś innego niż siebie, przed napisaniem przez agenta choćby jednej linii, należy uzyskać ustne zobowiązanie, zaliczkę lub list intencyjny.

Ustny entuzjazm, głosy podczas premiery i lista oczekujących bez żadnej stawki to słabe sygnały popytu. Koszt budowania jest tak niski, że jedynym pozostałym filtrem jest gotowość klienta do zapłaty.

Specyfikacja jako trwały artefakt

Przed erą AI specyfikacja była dokumentem roboczym, a kod artefaktem. Po erze AI kod można ponownie wygenerować, to specyfikacja jest tym, co trwa.

Należy pisać specyfikacje, które eksplicite wymieniają klienta, tryby awarii i metrykę sukcesu, i przechowywać je pod kontrolą wersji obok kodu. Gdy specyfikacja się zmienia, ponowne wygenerowanie jest trywialne. Gdy specyfikacja jest błędna, żadna liczba regeneracji projektu nie pomoże.

Przegląd decyzji z dwoma modelami

Pojedynczy LLM może racjonalizować każdy kierunek. Drugi model zaproszony do wyrażenia sprzeciwu wychwytuje połowę złych decyzji. Wzorzec sprawdza się przy przeglądzie kodu, gdzie stosuję Claude plus Codex plus Gemini do wzajemnej weryfikacji każdej dostarczonej funkcji.

Cenniejsze zastosowanie to przegląd decyzji. Należy pokazać dwóm modelom specyfikację, poprosić je o wyrażenie sprzeciwu i rozważyć ten sprzeciw przed przystąpieniem do budowania. Koszt jest pomijalny w zestawieniu z kosztem zbudowania złej rzeczy.

Plik zaniechanych kierunków

Każdy produkt, funkcja lub kampania porzucona przed dostarczeniem trafia do jednego dokumentu wraz z uzasadnieniem. Uzasadnienie ma większe znaczenie niż liczba wpisów. Warto go czytać przed rozpoczęciem czegokolwiek nowego.

Wzorzec powodów, dla których kierunki umierają, to najtańsza dostępna forma spłaty długu intencji, a niemal każdy zespół go pomija. Jeśli chcą Państwo ocenić, gdzie zastosować te działania we własnym zespole, webvise może pomóc.

Wybór partnera webowego w erze AI

Najkosztowniejszy błąd, jaki popełnia zespół w erze AI, to zatrudnienie agencji odpowiedzialnej wyłącznie za warstwę budowania. Budowanie to teraz tania część. Warstwa decyzyjna, co dostarczać, kiedy rezygnować i kim naprawdę jest użytkownik, to miejsce, gdzie tkwi mnożnik.

Większość agencji nadal wycenia budowanie, bo na tym opiera się ich model marżowy. webvise zbudowano wokół odwrócenia tego modelu.

Zlecenia w zakresie automatyzacji AI i aplikacji full-stack rozpoczynają się od sprintu odkrywczego, którego efektem jest pisemna specyfikacja, lista zaniechanych kierunków i przegląd decyzji z dwoma modelami dla każdego zatwierdzonego elementu zakresu. Funkcję można dostarczyć w ciągu jednego dnia. Nie zostanie dostarczona, dopóki zespół nie uzgodni, jak sukces wygląda na produkcji.

Jeśli w tym kwartale dostarczono więcej kodu niż kiedykolwiek, a poczucie oddalenia od działającego produktu jest większe niż pół roku temu, warto zarezerwować rozmowę odkrywczą. Najszybszy sposób na spłatę długu intencji to zatrzymanie jego dalszego narastania.