Review to infrastruktura. Wasze wdrożenie AI zapomniało ją zbudować.

Adopcja AI podwoiła ilość kodu, który produkujemy. Nikt nie zabudżetował czytania. Telemetria z 22 000 developerów pokazuje, ile to kosztuje i co naprawdę znaczy traktować review jak infrastrukturę.

Narzędzia AI są u nas obowiązkowe na tyle długo, że nikt w zespole nie nazywa ich już nowością. Po prostu tak się teraz pracuje: opisz, wygeneruj, popraw, wypchnij. Wdrożenie przyszło z góry, krzywa adopcji zrobiła to, co krzywe adopcji robią zawsze, i w którymś momencie cała ta rewolucja przestała być eksperymentem, a stała się meblem.

W zeszłym miesiącu w końcu usiadłem i zadałem sobie pytanie, co te narzędzia tak naprawdę zmieniły. Nie na demach. Nie na slajdach vendora. W moim kalendarzu.

I oto, co znalazłem. Kiedyś w moich dniach było budowanie. Sesje architektoniczne, prawdziwy kod, od czasu do czasu głębokie zanurzenie w problem, na który nikt inny nie miał czasu. Teraz moje dni to review, weryfikacja, review, weryfikacja. Nie dlatego, że ktoś przydzielił mi więcej review. Czytania nie przydzielono nikomu. I właśnie o to chodzi. Narzędzia wjechały z pełną pompą: szkolenia, budżet na licencje, dashboardy adopcji. Czytanie nie wjechało nigdzie. Po prostu spadło na tego, kto trzyma poprzeczkę jakości.

A jednostki czytania zrobiły się cięższe, kiedy nikt nie patrzył. Pull request miał kiedyś dwadzieścia, może trzydzieści plików. Dziś regularnie otwieram dwa razy większe. Czyste, spójne, w całości wygenerowane. I wciąż błędne w sposób, którego szukanie trwa dłużej, niż trwało wyprodukowanie tego kodu. Kod przychodzi szybciej niż kiedykolwiek, wygląda na skończony, a każdy z tych skończenie wyglądających plików to obietnica, którą ktoś musi sprawdzić.

Przez jakiś czas trzymałem to w szufladce „przejściowe". Niezręczny środkowy etap transformacji, który sam się ułoży. Potem trafiłem na branżowe liczby i przestałem myśleć, że to problem ze mną. Albo że przejściowy.

Rachunek przyszedł, z wyszczególnieniem pozycji

Faros AI zbiera telemetrię dokładnie w tej sprawie. Nie ankiety, nie opinie, tylko zmierzone dane z prawdziwych organizacji inżynierskich. Dwa raporty, dwa lata, jeden wzorzec, który robi się coraz wyraźniejszy.

Raport z 2025 przeanalizował telemetrię 10 000 developerów w 1 255 zespołach. Główny wniosek był paradoksem: zespoły z wysoką adopcją AI mergowały o 98% więcej pull requestów i kończyły więcej zadań, a metryki dostarczania na poziomie firmy stały w miejscu. Deployment frequency, lead time, change failure rate: płasko. To gdzie się podziały zyski? Raport pokazuje przeciek. Czas review w górę o 91%. Średni rozmiar PR-a w górę o 154%. Produktywność była prawdziwa na poziomie jednostki i została wchłonięta na poziomie systemu, głównie przez proces review, którego nikt nie przeskalował, żeby ją przyjąć.

Dane z 2025 dało się jeszcze czytać optymistycznie. Koszty przejścia. Zespoły się uczą. Dajmy im rok.

Edycja 2026 dała im rok, podwoiła próbę do 22 000 developerów w ponad 4 000 zespołów i obraz wyostrzył się w obie strony naraz. Zyski w przepustowości w końcu stały się widoczne na poziomie firmy: epiki ukończone na developera w górę o 66%, przepustowość zadań o 34%. AI naprawdę przesuwa dziś roadmapy, nie tylko liczniki tasków. Ta część obietnicy doleciała.

Rachunek też. Mediana czasu spędzonego w review: w górę o 441%. Pięć razy dłużej niż wcześniej, wobec „zaledwie" 91% rok wcześniej. Bugi na developera: w górę o 54%. Incydenty produkcyjne na pull request: mniej więcej trzykrotnie więcej. I liczba, o której nie mogę przestać myśleć: o 31% więcej pull requestów merguje się dziś bez żadnego review.

Przeczytaj to ostatnie jeszcze raz. System nie zwolnił, żeby dopasować się do swojej przepustowości weryfikacji. Zrobił to, co przeciążone systemy robią zawsze. Zaczął pomijać krok. Nieprzeczytana sterta to nie metafora. Oni ją zmierzyli.

Jeszcze jeden punkt danych, z zupełnie innego narzędzia: benchmarki LinearB z 2026 pokazują, że PR-y wygenerowane przez AI czekają 4,6 razy dłużej, zanim recenzent w ogóle je otworzy. Po otwarciu review idzie szybciej, ale to czas w kolejce dominuje. Inny instrument, ten sam kształt: generowanie sprintuje, weryfikacja stoi w kolejce.

Trzy źródła, jeden wniosek. To nie jest problem dyscypliny i nie jest to chwilowy wybój. To strukturalna nierównowaga. I pogłębia się.

Dlaczego koszt się skoncentrował, zamiast rozłożyć

Oto mechanizm, prosty na tyle, że aż niewygodny.

Generowanie kodu stało się tanie i rozproszone. Każdy developer z licencją ma w praktyce zespół niezmordowanych maszynistek. Moce produkcyjne skalują się z liczbą wykupionych stanowisk. Da się to załatwić zamówieniem.

Weryfikacja kodu pozostała droga i skoncentrowana. Sprawdzenie, czy kod jest poprawny, kosztuje dokładnie tyle, ile kosztowało zawsze: uwagę, kontekst, osąd. A ten koszt mieszka w małej grupie ludzi. Tych, którzy trzymają architekturę w głowie, znają historię codebase'u i którym powierzono przycisk merge. Moce czytelnicze skalują się z liczbą seniorów. Tego żadnym zamówieniem się nie załatwi.

Więc kiedy wdrożenie mnoży produkcję, nie ruszając weryfikacji, różnica ani nie znika, ani się nie rozkłada. Koncentruje się w najdroższych ludziach w organizacji. Dokładnie ci, których wdrożenie miało pomnożyć, są tymi, których konsumuje. Każda rozsądna indywidualna decyzja (używaj narzędzi, generuj więcej, wysyłaj szybciej) sumuje się do systemu, w którym najrzadszy zasób dźwiga cały nowy ciężar.

Kupiliśmy szybszą drukarkę i nie zatrudniliśmy nikogo do czytania.

Pisałem na początku roku o indywidualnej warstwie tego problemu: dlaczego nasz mózg nie czyta wygenerowanego kodu, dlaczego gładki output wygląda na zrecenzowany, choć nie jest, i dlaczego „wygląda na skończone" traktujemy jak „sprawdzone". Tamten tekst był o psychologii. Ten jest o ekonomii. Nawet zespół idealnie zdyscyplinowanych czytelników uderzy w ścianę, gdy obciążenie czytaniem rośnie pięciokrotnie, a moce czytelnicze stoją. Problemu przepustowości nie naprawi się silną wolą. W pewnym momencie jedyny uczciwy opis sytuacji brzmi tak: weryfikacja stała się kosztem, którego nikt nie wpisał do business case'u AI. Narzędzia są w budżecie. Czytania nie ma nigdzie.

Co tu właściwie znaczy „infrastruktura"

Infrastruktura to rzeczy, które projektuje się, mierzy, budżetuje i którym przypisuje się właściciela, zanim się zapchają. Nikt nie traktuje CI jak heroicznego czynu wykonywanego przez tego, kto akurat poczuł się odpowiedzialny. Nikt nie ogarnia monitoringu produkcji, licząc, że jakiś senior zauważy. Te systemy mają plany przepustowości, dashboardy i kogoś, czyją pracą jest utrzymywać je w zdrowiu.

Review w większości organizacji, jakie widziałem, nie ma nic z tych rzeczy. Jest traktowane jak niewidzialna praca, robiona pomiędzy „prawdziwymi" zadaniami, niemierzona, nieplanowana i obsadzona poczuciem winy. Ten model trzeszczał już wtedy, gdy cały kod pisali ludzie. Przy generowaniu na skalę AI to w ogóle nie jest model. To kolejka bez operatora.

Traktowanie review jak infrastruktury zaczyna się od mierzenia go jak infrastruktury. Cztery liczby, które team lead może zacząć śledzić w tym tygodniu, niczego nie kupując:

Stosunek wygenerowanego do zweryfikowanego. Prawie na pewno wiesz, ile linii produkują wasze narzędzia. Dashboard vendora jest z tego dumny. A wiesz, ile z tych linii człowiek faktycznie przeczytał przed merge? Jeśli umiesz zmierzyć tylko jedną stronę tego ułamka, nie mierzysz produktywności. Mierzysz, jak szybko rośnie nieprzeczytana sterta.

Czas do pierwszego review. Nie łączny czas review. Czas w kolejce. Jak długo PR wisi, zanim ktokolwiek go otworzy? To tu mieszka te 4,6x od LinearB i to jest najwcześniejsza lampka ostrzegawcza. Jeśli czas w kolejce rośnie, a czas samego review stoi, to wasi czytelnicy nie są wolni. Są pełni.

Procent merge bez review. Metryka pominiętego kroku. Faros złapał jej wzrost o 31% przy wysokiej adopcji. Jeśli u was rośnie, wasz proces nie zrobił się szczuplejszy. Zrobił się omijany. Ta liczba powinna być nudna. W momencie, w którym robi się ciekawa, jest incydentem.

Koncentracja recenzentów. Jaka część review ląduje na waszej dwójce najaktywniejszych? Jeśli większość, to nie macie procesu review. Macie dwie osoby podtrzymujące tamę. To zarazem wasz system wczesnego ostrzegania przed wypaleniem, bo tamy nie składają skarg, zanim puszczą.

Żadna z tych liczb nie wymaga nowego toolingu. Wymagają jednej decyzji: czytanie to praca. Praca, którą można planować, mierzyć i za którą można odpowiadać. Nie podatek, który odpowiedzialni płacą w milczeniu.

Warstwa czytania: jak układam swoją

Pomiar mówi ci, że sterta rośnie. Potem potrzebujesz maszynerii, która ją zmniejsza. I tu większość zespołów sięga po oczywisty ruch: „niech AI zrecenzuje AI".

Samo w sobie to ta sama pułapka w innym przebraniu. Pojedynczy uniwersalny bot-recenzent produkuje gładkie, pewne siebie, wiarygodnie brzmiące komentarze. A gładki, pewny siebie, wiarygodnie brzmiący output to jest dokładnie to, co stworzyło problem weryfikacji. Dołożyliście drugą warstwę skończenie wyglądającego tekstu, który ktoś i tak musi ocenić. Jeden czytelnik o nieznanej wiarygodności sprawdzający jednego autora o nieznanej wiarygodności to nie jest system jakości. To echo.

To, co u mnie naprawdę zadziałało, to warstwy, każda z wąskim zadaniem. Automatyczne przebiegi idą przed człowiekiem i każdy sprawdza jedną konkretną rzecz. Nie „czy to dobry kod", tylko konkretne pytania z jasną odpowiedzią tak/nie i małym zakresem. Wąskie kontrole failują głośno i uczciwie, w sposób, w jaki uniwersalny recenzent nie failuje nigdy. Człowiek zostaje tam, gdzie człowieka nie da się zastąpić: logika biznesowa, dopasowanie architektoniczne, decyzja wymagająca osądu. I to człowiek jest właścicielem merge, zawsze. Zadaniem automatyzacji jest sprawić, że kiedy otwieram PR-a, wydaję swoją uwagę na pytania, które mnie potrzebują, a nie na mechaniczną warstwę, którą maszyna już odhaczyła. To zmniejsza stertę. Nie zastępuje czytelnika.

Pełną implementację opisałem osobno: wieloagentowy pipeline, który odpala te przebiegi w CI, i routing modeli, który trzyma jego koszty w ryzach. Nie będę więc budował tego tu od nowa. Konkretne agenty znaczą mniej niż zasada: automatyzacja przed człowiekiem, wąskie ponad ogólne, a merge należy do osoby. Każdy zespół może zbudować swoją wersję z narzędzi, które już ma. Pipeline to szczegół. Warstwa czytania to sedno.

Kto wygra tę fazę

Ostatnie lata nagradzały zespoły, które najszybciej adoptowały generowanie. Ten wyścig się skończył. Generowanie to dziś standard wyposażenia, obowiązkowy odgórnie, wyceniany od stanowiska. Następna faza nagradza coś zupełnie innego: przepustowość weryfikacji. Sufitem tego, jak szybko możecie bezpiecznie dostarczać, nie jest już to, jak szybko produkujecie kod. Jest nim to, jak szybko potraficie wiedzieć, że kod jest poprawny.

Organizacje, które to rozgryzą, zatrzymają te 66%. Prawdziwe, mierzalne zyski w przepustowości, bez płacenia za nie potrojonymi incydentami i nieprzeczytanymi merge'ami. Cała reszta będzie dalej świętować drukarkę.

Zespoły, które wygrają, nie będą tymi z najszybszą drukarką.

Będą tymi, które obsadziły czytelnię.