Agent AI do kodowania: gdzie przenieśliśmy goulot?

Nasza kolejka supportu oczyszczała zgłoszenia w dziewięć minut, potem czekały cztery godziny, zanim jakakolwiek osoba ich dotknęła. Dokładnie tę samą historię widzisz teraz na zespołach inżynieryjnych, gdy pojawia się agent AI do kodowania: kod powstaje w minuty, potem stoi w kolejce. Jeśli właśnie wdrożyłeś agenta AI i throughput w Twoim zespole prawie się nie zmienił, nie znaleźliśmy złego narzędzia. Znaleźliśmy prawdziwe ograniczenie: i nie znajduje się tam, gdzie myśleliśmy.

To jest użyteczny sposób czytania tego, co dzieje się teraz na zespołach inżynieryjnych. Agent AI do kodowania (oprogramowanie planujące, piszące i często testujące zmiany kodu przy minimalnym promptingu, w przeciwieństwie do autokomplementu) eliminuje opór na etapie pisania. Ale pisanie rzadko było poste limitant na potoku oprogramowania. Zwykle były nimi review, CI i wdrożenie. Przyspiesz coś, co nie ogranicza system, a nie dostaniesz więcej gotowej pracy. Dostaniesz większą kolejkę przed tym, co przychodzi dalej.

Gdzie przesunęła się wąska szyja po wprowadzeniu agenta AI?

Dwa zbiory danych branżowych z 2026 roku wskazują w tym samym kierunku. W raporcie CircleCI "State of Software Delivery", przepustowość gałęzi feature na medianowym zespole wzrosła o 15% rok do roku, ale przepustowość main-branch: liczba zmian faktycznie trafiających na produkcję: spadła o 7% w tym samym okresie (CircleCI, 2026 State of Software Delivery). Więcej pracy wchodzi na początek linii, mniej wychodzi na koniec.

Oddzielnie, w badaniu deweloperów GitLab opisanym przez InfoQ, 85% respondentów zgodziło się, że AI przesunęło goulot z pisania kodu na jego review i walidację, a 79% stwierdziło, że ogólny proces dostarczania nie nadąża za szybkością kodowania (InfoQ, AI coding outpaces governance). To nie jest luka w narzędziach. To ograniczenie, które przesunęło się i nikt nie remierzył linii.

Little's Law nie obchodzi, że kod powstał szybciej

Little's Law mówi Ci, dlaczego się tak dzieje, i nie dotyczy to tylko oprogramowania. To ta sama matematyka za kolejką w centrum fulfillmentu lub procesem wypisania ze szpitala:

WIP = Throughput × Cycle Time

WIP to prace w toku: wszystko, co siedzi w Twoim potoku teraz (otwarte PR-y, zgłoszenia w review, zamówienia zebrane ale nie spakowane). Throughput to ukończone jednostki na jednostkę czasu. Cycle Time to jak długo jedna jednostka trwa od początku do końca.

Przyspieszenie generowania kodu bez zmiany zdolności review oznacza, że wciskasz więcej jednostek na godzinę na etap, którego przepustowość się nie zmieniła. WIP musi gdzieś trafić. Piętrzy się jako zaległość otwartych PR-ów, rosnąca kolejka merge lub reviewerzy przeglądający diffy szybciej i łapiący mniej. Żaden z nich nie jest darmowy. Pull request czekający trzy dodatkowe dni nie kosztuje nic, kosztuje kontekst: autor poszedł dalej, reviewer musi przeładować całą zmianę, i przepracowanie staje się bardziej kosztowne im dłużej czeka.

Gdzie jeszcze pojawia się "agent AI do kodowania"

Warte rozróżnienia dwie rzeczy, które się łączy pod "agentem AI do kodowania". Niektóre narzędzia są wąsko zbudowane do pisania i modyfikowania kodu źródłowego w repo. Inne to agenty ogólnego przeznaczenia, które zawierają tryb pisania kodu obok badań, przeglądania i generowania dokumentów.

Genspark to drugi typ: "Super Agent" bez kodu, który może przeglądać sieć, generować slajdy czy dokumenty i pisać oraz uruchamiać kod z jednego prompta. Ta szerokość jest użyteczna dla generalisty, ale to inne narzędzie na inną pracę niż coś specjalnie zbudowanego do życia wewnątrz Twojego potoku CI i otwierania pull requestów względem Twojego rzeczywistego kodu. Dopasuj projekt narzędzia do etapu potoku, który chcesz odblokować, nie odwrotnie.

Manus idzie jeszcze dalej, działając wewnątrz pełnego wirtualnego komputera (przeglądarki, terminala, systemu plików) by planować i wykonywać zadania wieloetapowe od końca do końca i oddać gotowy rezultat. Dla zespołu ops to użyteczny model mentalny nawet poza kodem: agent, który kończy całą jednostkę pracy, a nie tylko najszybszą pod-etap, to ten, który faktycznie przesuwa przepustowość.

PCE: jedyna liczba, która mówi Ci, czy agent pomaga

Process Cycle Efficiency (PCE) to stosunek czasu wartościowego do całkowitego czasu cyklu i to najprawdziwszy sposób sprawdzenia, czy agent AI poprawił Twój potok czy tylko przesunął goulot:

PCE = Value-Added Time / Total Cycle Time

Zanim przyjmiesz agenta AI, zmierz bieżący podział: ile czasu z życia typowej zmiany, od pierwszego commita do merge'a na produkcję, faktycznie trafia na pisanie lub review kodu kontra czekanie w kolejce. Większość zespołów nigdy nie wyciągnęła tej liczby i zaskakuje je wynik. PCE poniżej 25% to norma na potokach oprogramowania, oznaczająca że trzy czwarte całkowitego życia zmiany to czekanie, nie praca.

Zmierz ponownie od 30 do 60 dni po wdrożeniu. Jeśli PCE wzrosło, agent uwolnił rzeczywistą zdolność i Twój zespół jej używa. Jeśli PCE zostało na tym samym poziomie lub spadło, agent przyspieszył już szybki etap i dodatkowy output siedzi w kolejce, niewidoczny aż ktoś zsumuje otwarte PR-y w piątek. To dokładnie ten rodzaj odczytu, gdzie warstwa analizy AI zarabia sobie miejsce: niewystarczy wiedzieć że PCE się poruszyło, potrzebujesz weryfiktu na którym etapie pochłonął się różnicę, i to czyta się szybciej z automatycznego podziału niż z kogoś patrząc na tablicę Kanban.

Trzy znaki, że review, nie agent, jest Twoim poste limitant

Kilka wzorów pojawia się konsekwentnie raz zespoły zaczynają mierzyć zamiast zakładać:

• Liczba otwartych PR-ów wzrasta gdy liczba merge'y zostaje płaska. Więcej jednostek wchodzi na linię, tyle samo wychodzi. Klasyczne piętrowanie WIP przed niezmienionym ograniczeniem.

• Średni rozmiar PR rośnie. Agent AI generujący całą feature w jednym przebiegu produkuje większe diffy niż człowiek pisący przyrostowo. Większe diffy zabierają dłużej by review na PR, co zmniejsza przepustowość reviewera nawet jeśli headcount i prędkość review na linię zostają stałe.

• Czas do pierwszego review wspina się szybciej niż czas do merge'a po zatwierdzeniu. Jeśli czekanie jest głównie przed że ktoś zacznie patrzeć, to problem z kolejkowaniem (nie dość zdolności review, lub review-y nie są priorytetyzowane), nie problem z jakością review.

Zaden z nich nie wymaga egzotycznego narzędzia do śledzenia. Cotygodniowe wyciągnięcie z API hosta gita, wykreślone względem tygodnia gdy wdrożyłeś agenta, wystarczy by zobaczyć kształt przesunięcia.

Co kolejka supportu robi dobrze, co potoki inżynieryjne zwykle przegapią

Support i operacje fulfillmentu walczą z tym dokładnym problemem dłużej niż agenty AI do kodowania istnieją, i naprawa generalizuje czysto. Kolejka, która odpowiada na zgłoszenia pierwszego kontaktu w dziewięć minut ale zabiera cztery godziny by dotrzeć do specjalistów nie jest historią resourcingu o specjalistach będących wolni. To sygnał że szybka warstwa jest nad-zasoby względem tego co przychodzi dalej, i że ciągnięcie więcej zgłoszeń na początek nie pomaga dopóki zdolność tylnej warstwy się nie zmieni.

Teamiinżynieryjne ciągle to przeskakują bo code review nie wygląda jak kolejka na dashboardzie tak jak liczy ticket. To PR-y siedące cicho w stanie "waiting for review", łatwe do nie zauważenia aż ktoś pyta dlaczego feature sprzed dwóch tygodni dalej nie wdrożył. Theory of Constraints: idea że całkowity output systemu jest limitowany jego pojedynczym etapem limitującym, nie sumą prędkości każdego etapu: mówi że naprawa nigdy nie jest "make the fast part faster". To znaj rzeczywisty etap limitujący, chrań jego zdolność, i tylko wtedy zadecyduj czy szybka część w ogóle potrzebuje więcej prędkości.

Est drugi, cichszy goulot, który pojawia się kilka miesięcy po tym jak agent AI dostarczył więcej kodu, szybciej: dryfing dokumentacji. Nikt nie zauważa dopóki onboarding nowego inżyniera nie zabiera dwa razy dłużej bo dokumentacja opisuje system, który zmienił się trzy sprinty temu. Platforma docs-as-code jak GitBook, która synchronizuje się z tym samym repo którego agent commita, przynajmniej trzyma papierowy ślad żeby nie jechać dalej za kod sam. Nie naprawia to goulotu review, ale zatrzymuje drugi tworzący się w ciemności.

Czy powinieneś specjalnie spowolnić swój agent AI?

Czasami tak, i to nie jest popularne stanowisko o narzędziu którego wszyscy się ekscytują. Jeśli Twoja zdolność review jest stała przez następne dwa kwartały (headcount zamrożony, reviewerzy już na zdolności), pozwolenie agentowi potrójić szybkość przychodzących PR-ów nie tworzy więcej gotowych, wdrożonych featur. Tworzy dłuższą kolejkę i, na danych CircleCI powyżej, niższy main-branch success rate, bo reviewerzy pod wolumenem łapią mniej.

Honestny ruch w tej sytuacji to wylimit ile agent generuje na cykl, lub bramkuj jego output za pre-review pass (linting, automatyczne sprawdzenia pokrycia testami, polityka mniejszego diffa) przed zanim kiedykolwiek dotrze do human reviewera. To nie jest stanowisko anti-AI. To ta sama logika co nie planowanie więcej jednostek na linię niż Twoja najwolniejsza stacja może absorb.

Jeśli rzeczywisty goulot okaże się reviewer uwagę raczej niż reviewer headcount, agenty workflow zbudowane dla triażu i routingu, jak Lindy AI obsługująca inbox i notification overhead wokół dnia zespołu, mogą uwolnić rzeczywiste godziny review bez dotykania Twojej bazy kodu bezpośrednio. Warte testowania zanim zakładać że naprawa musi być "zatrudnij więcej reviewerów" czy "kup więcej siedzeń agenta".

Gdzie rzeczywiście zainwestować dalej

Zmierz PCE zanim rozszerzysz użycie agenta dalej, nie po. Jeśli wartościowy dodany czas jako udział całkowitego czasu cyklu nie zmienił się od wdrażania, nie kupuj więcej siedzeń agenta jeszcze. Postaw następny budżet na zdolność review, throughput CI, lub automatyzację merge-queue zamiast, cokolwiek dane wskazuje, i zmierz liczbę ponownie za 30 dni.

Jeśli PCE się poprawiło i review utrzymuje tempo, to sygnał by rozszerzyć zakres agenta, nie przed. Mierz najpierw. Zespoły dostające rzeczywiste zyski throughputu z agenta AI do kodowania nie to te, które go przyęły najszybciej. To te, które znalazły swój rzeczywisty etap limitujący i naprawiły zdolność tam zanim pozwoliły szybkiej części biec jeszcze szybciej. Pomiar musi poprzedzić inwestycję.