Przeglądy kodu w erze AI — kto sprawdza kod pisany przez sztuczną inteligencję?

W poprzednim artykule (AI173) wskazałem weryfikację jako trzecie nowe wąskie gardło, gdy pisanie kodu staje się niemal darmowe. Na koniec zostawiłem zdanie: „o tym w czwartej części”. Niniejszy wpis jest realizacją tej obietnicy. Najpierw konkluzja: patrząc z perspektywy połowy 2026 roku, największą zmienną, jaką dostarczają narzędzia AI do programowania, nie jest liczba licencji, liczba stanowisk ani wynik modelu w benchmarku — lecz przepustowość procesu przeglądu kodu (review bandwidth).

Dane, które warto znać, zanim powierzysz linię kodu agentowi AI

Pod koniec 2025 roku CodeRabbit opublikował raport oparty na analizie 470 otwartych pull requestów z GitHuba. Wniosek był niepokojący: kod wytworzony z udziałem AI miał 1,7 raza więcej defektów niż kod pisany wyłącznie przez ludzi (średnio 10,83 vs 6,45 defektów na PR, przy czym próba nie była sparowana pod kątem rozmiaru pliku ani złożoności). W podziale na podklasy luk bezpieczeństwa różnice wyglądały następująco: XSS 2,74×, nieprawidłowe przetwarzanie haseł 1,88×, niebezpieczne bezpośrednie odwołania do obiektów (IDOR) 1,91×, niebezpieczna deserializacja 1,82×. Błędy logiczne i poprawnościowe 1,75×, czytelność 3×+, formatowanie 2,66×, obsługa błędów blisko 2×.

We wrześniu 2025 roku Apiiro uzupełniło tę układankę z drugiej strony, skanując repozytoria należące do firm z listy Fortune 50 (dane obejmują okres grudzień 2024 – czerwiec 2025). Okazało się, że kod generowany przez AI gwałtownie podniósł miesięczną liczbę wykryć związanych z bezpieczeństwem – z około 1000 do ponad 10 000 incydentów, czyli wzrost dziesięciokrotny. Co istotne, luki umożliwiające eskalację uprawnień wzrosły o 322% (w wartościach bezwzględnych; po normalizacji względem przyrostu wolumenu kodu realny wzrost szacowany jest na 60–80%), a wady projektowe na poziomie architektury – o 153%. W tym samym okresie błędy składniowe spadły o 76%, a bugi logiczne o 60%.

Te dwie grupy danych, rozpatrywane łącznie, mówią jedną rzecz — kluczową zwłaszcza w kontekście regulacyjnym: znaczna część tych 322% luk w eskalacji uprawnień wykrytych przez Apiiro dotyczy granic uprawnień, a granice uprawnień w sektorze finansowym i telekomunikacyjnym to pieniądze i dane klientów. Wiele kodu pisanego przez AI działa, ale liczba defektów i podatności rośnie proporcjonalnie — i to te niebezpieczne cicho zyskują na udziale. (Uwaga metodologiczna: raport CodeRabbits odzwierciedla stanowisko dostawcy, dane Apiiro pochodzą od zewnętrznego vendora bezpieczeństwa; kierunek wniosków jest spójny, ale pełna interpretacja wymaga uwzględnienia sposobu normalizacji.)

Ten fakt, gdy trafi do organizacji, uruchamia dwa kontrintuicyjne wnioski — każdy sprzeczny z narracją sprzedawcy narzędzia, które kupujesz.

Dwa kontrintuicyjne wnioski

Kontrintuicja 1: Rola dewelopera zmienia się z „osoby piszącej kod” na „osobę recenzującą kod”, ale recenzowanie jest bardziej męczące niż pisanie.

JetBrains – styczeń 2026

Badanie JetBrains ze stycznia 2026 r. (10 000+ deweloperów, 8 języków) wskazuje, że 90% deweloperów korzysta przynajmniej z jednego narzędzia AI. W branżowym badaniu Pragmatic Engineer z lutego 2026 r. pojawia się jeszcze bardziej niepokojący wniosek: 56% doświadczonych inżynierów deklaruje, że ponad 70% ich codziennej pracy inżynierskiej opiera się na narzędziach AI (włącznie z własną oceną deweloperów intensywnie z nich korzystających – nie chodzi tu o udział linii kodu). To już nie sporadyczne „kilka linijek z Copilota” – AI stało się domyślnym sposobem pracy. W układzie sił wytwórczych dokonała się kolejna zmiana: pisanie kodu przeszło w ręce AI, a deweloperzy poświęcają więcej czasu na czytanie i ocenianie – czyli przegląd kodu (code review). Czytanie cudzego kodu zawsze było trudniejsze i wolniejsze niż jego pisanie; czytanie nieznanego kodu wygenerowanego przez AI, wymagającego dodatkowo oceny pod kątem zgodności regulacyjnej i reguł biznesowych, nakłada wyraźnie wyższe obciążenie poznawcze niż pisanie własnego kodu. To jest źródło ciągłej informacji zwrotnej deweloperów z lat 2025–2026: „AI sprawia, że jestem bardziej zmęczony”. Pod spodem leży odwrócona narracja z badania METR 2026.2 – wniosek o 19% spowolnieniu doświadczonych deweloperów przez AI został w nowej próbie częściowo odwrócony; nowi deweloperzy wciąż odnotowują -4%. Całościowa ocena brzmi: „pasmo przeglądu jest węższe niż pasmo produkcji”.

Kontrintuicja 2: im silniejsze narzędzia AI, tym organizacja potrzebuje nie więcej narzędzi, lecz zarządzania (governance).

AI173: Gdy AI pisze szybciej, niż potrafisz czytać

Sama w sobie 1,7-krotność defektów CodeRabbit czy 322% luk eskalacji uprawnień Apiiro wygląda jak porażka AI. Patrząc przez pryzmat Teorii Ograniczeń (Theory of Constraints), to logiczny efekt sytuacji, w której zdolność wytwórcza narzędzia rośnie, a Twoja zdolność przeglądu — nie. Wydajność systemu wyznacza najwęższe ogniwo. AI poszerzyło „pisanie”, więc najwęższym ogniwem stał się „przegląd”. Dopóki przepustowość przeglądu nie nadąży, im szybciej AI pisze, tym niebezpieczniejszy dług akumuluje organizacja. To jest teza AI173: automatyzacja nie eliminuje wąskiego gardła, ona tylko przesuwa je w inne miejsce.

Przeniesienie tej myśli na programowanie z asystą AI wymaga uzupełnienia: tworzenie oprogramowania nie jest pojedynczym wąskim gardłem linii produkcyjnej, lecz zbiorem równoległych wąskich gardeł, które dynamicznie się przesuwają. TOC działa w scenariuszu liniowym, ale w programowaniu z AI, gdzie wiele wąskich gardeł działa równolegle, najwęższe ogniwo dryfuje z „pisania” do „przeglądu”, a w obrębie samego „przeglądu” wyodrębniają się trzy niezależne blokady: weryfikacja, zarządzanie (governance) i przegląd zgodności (compliance).

Praktyczne znaczenie tej reguły — dwie warstwy zabezpieczeń

Pierwsza warstwa: zanim wdrożysz autonomicznych agentów, zamontuj cztery hamulce — obowiązkowy code review przez ludzi, automatyczne testy (każda zmiana wygenerowana przez AI musi przejść testy), skanowanie bezpieczeństwa (według tych samych standardów co kod pisany przez ludzi) oraz wdrożenie kanarkowe (zmiany AI trafiają najpierw do małego procenta użytkowników). Pull requesty generowane przez AI nie mogą być zwolnione z recenzji. To minimalny próg inżynierski, który zamienia problem „AI pisze kod” w problem „AI pisze kod + organizacja jest w stanie to udźwignąć”. Brak choćby jednego elementu oznacza realne ryzyko utraty kontroli.

Carlini opisał w styczniu i lutcu 2026 roku często cytowany przypadek: badacz z Anthropic kazał 16 agentom Claude Opus 4.6 pracować równolegle przez dwa tygodnie — około 2 000 sesji i około 20 000 dolarów kosztów API. Efekt: od zera napisany kompilator C oparty na Rust, liczący 100 000 linii kodu, zdolny do kompilacji jądra Linux 6.9 i uzyskujący 99% wynik w GCC torture test. Trzeba podkreślić: to był kontrolowany eksperyment w zamkniętej dziedzinie. Carlini nie wdrożył tego kodu do produkcji. Jako „ekstremalna grupa kontrolna bez recenzji” przypadek ten ma sens; jako wzorzec do natychmiastowego wdrożenia agentów autonomicznych — zawyża osiągalność i odwracalność rezultatów.

W organizacji, która nie ma code review, automatycznych testów, skanowania bezpieczeństwa ani wdrożeń kanarkowych, prędzej czy później dojdzie do incydentu.

Druga, bardziej ukryta warstwa: sedno przeglądu nie leży w wyszukiwaniu bugów, lecz w ocenie zgodności architektonicznej, granic compliance i poprawności biznesowej

Najczęstsza pułapka, w którą wpadają inżynierowie wychowani na starszej szkole programowania, to utożsamianie review w erze AI z klasycznym code review. Klasyczny code review odpowiada na pytanie „czy ten kod jest błędny”; review w erze AI odpowiada na zupełnie inne pytanie — „czy ten kod w ogóle powinien istnieć w tym pliku, w tym projekcie, w tej granicy compliance?”.

Współczynniki, które podaje CodeRabbit — od 1,82× do 2,74× więcej wykrytych luk bezpieczeństwa — oraz dane Apiiro wskazujące na 322% wzrost liczby wykrywanych podatności eskalacji uprawnień, dotyczą właśnie tej kategorii problemów: AI nie napisało błędu syntaktycznego, ale zapisało logikę w złym miejscu, z przypisaniem niewłaściwych uprawnień albo z niebezpieczną konfiguracją domyślną. Tych problemów nie da się naprawić w IDE — trzeba je najpierw zrozumieć na review desk.

Bardziej uniwersalne podejście, stosowane powszechnie w branży, polega na oznaczaniu w regułach branch protection i CODEOWNERS na GitHubie lub GitLabie wszystkiego, co dotyka schema, auth, billing czy granic compliance, i kierowaniu takich zmian do podpisu dwóch osób (w praktyce sektora finansowego i telekomunikacyjnego najczęściej stosuje się backup veto zamiast pełnego przeglądu, a udział inspekcji punktowej spot-check różnicuje się w zależności od poziomu ryzyka).

Architecture Decision Records (ADR), bazowe wymagania bezpieczeństwa i zgodności regulacyjnej oraz poprawność reguł biznesowych — to są obszary, na które review w erze AI powinien poświęcać czas.

Połączenie tych dwóch kontrintuicyjnych wniosków daje jasny obraz: epoka AI wymaga od firm trzech korekt w procesie code review — wciągnięcia dyrektora ds. rozwoju oprogramowania do procesu recenzji, wpisania baseline’ów zgodności i architektury w reguły routingu PR-ów oraz podniesienia wskaźników governance (np. wskaźnik niepowodzeń) na poziom raportowania do zarządu. Te trzy punkty odpowiadają wprost „trzem liniom obrony w zarządzaniu modelami” wymaganym przez chińskie „Metody wdrażania zarządzania internetowym kredytem banków komercyjnych” (biznes, IT, audyt zgodności) — regulator od razu to zrozumie. Poniżej rozbijam to na cztery warstwy.

II. Dlaczego „właśnie teraz”: mechanizm, przez który weryfikacja staje się nowym wąskim gardłem

Dopełniam obietnicę z rozdziału 3. AI173 („czwarty podrozdział omówię osobno”). Wyjątkowość okna w połowie 2026 r.: agenci autonomiczni (Claude Code, Codex) przechodzą z fazy „pilotażu” do „użytkowania domyślnego”; organizacje, które do końca H2 nie podniosą poziomu review, „wysadzą się” w Q4 — w oknie wielkiej promocji / końcówki zamrożenia wersji / okresie rutynowej kontroli regulatora. Najpierw pokażę, dlaczego „weryfikacja” jest najgłębiej niedoszacowana wśród nowych wąskich gardeł, a potem zestawię ją z dwoma wcześniejszymi (definiowanie właściwego problemu, integracja systemów) na jednym schemacie.

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

Generowanie kodu przez AI 6× Przepustowość przeglądu 1.3×

Luka = narastanie ryzyka (defekty +1.7×, luki bezpieczeństwa +1.82–2.74×, eskalacja uprawnień +322%)
Proporcje są poglądowe, na podstawie JetBrains 2026.1, CodeRabbit 2025.12 i Apiiro 2025.9

Niedoceniany korzeń problemu tkwi w tym, że większość dyskusji o programowaniu z AI domyślnie sprowadza „weryfikację” do CI/CD, uruchamiania testów jednostkowych i przepuszczania przez lint. To świat produktów internetowych: kod trafia do chmury, testy jednostkowe świecą na zielono, CI przechodzi, merge do maina, deploy na produkcję. Ten przepływ działa w tempie produktów webowych, ale przeniesiony jeden-do-jednego do telekomunikacji, finansów, produkcji czy e-commerce nie ma zastosowania. W tych branżach „weryfikacja” to algorytmiczna rejestracja (algorithm filing), ocena zgodności z klasyfikacją ochrony danych (equivalent of China’s MLPS / „等保”), ocena transgranicznego transferu danych (cross-border data transfer assessment), zatwierdzenie zmian przez Change Advisory Board (Change Advisory Board (CAB)), audyty uzgadniania sald (reconciliation) i raportowanie regulacyjne — z kodem nie mają wiele wspólnego, a każda z tych procedur pożera tygodnie. AI173 już pokazał to na wykresie (kodowanie przyspiesza, wąskie gardło jest w weryfikacji), więc nie powtarzam. Istotne jest pytanie, które po nim zostaje: przez ile warstw weryfikacji musi przejść kod napisany przez AI, zanim trafi na produkcję?

Siedem warstw na start: automatyczne testy + code review + skanowanie bezpieczeństwa + przegląd architektury / ADR + przegląd reguł biznesowych + clearance zgodności regulacyjnej + wdrożenie kanarkowe (canary). Każda z nich konsumuje przepustowość. Te siedem warstw razem tworzą „drugą stronę” wykresu z AI173 — AI przyspiesza segment o najniższym koszcie krańcowym (czas GPU, opłaty licencyjne), a weryfikacja pożera segment o najwyższym koszcie instytucjonalnym (regulacje, rejestracje, uzgadnianie sald).

Drugi niedoceniany korzeń to zawężanie „przeglądu” do code review. Dwa główne źródła code review – koncepcja egoless programming Weinberga z 1971 roku (The Psychology of Computer Programming, środowisko NASA/akademickie) oraz Fagan Inspections z IBM z 1976 roku (systemowe podejście IBM) – opierają się na tym samym założeniu: kod pisze się linijka po linijce, autor zna go najlepiej, a po napisaniu inna osoba czyta go ponownie, żeby wychwycić błędy. AI obala to założenie: kod jest wypluwany przez AI w kilka sekund, autor (AI) nie przekazuje kontekstu, a czytający (developer) ma do czynienia z obcym wytworem. Dawne założenie o „wychwytywaniu błędów” przestaje działać. Nowe pytanie brzmi: czy ten kod powinien w ogóle istnieć w tym pliku? Czy nie obchodzi istniejących decyzji architektonicznych? Czy mieści się w granicach zgodności regulacyjnej, czy je przekracza? Czy jego domyślna konfiguracja nie zamieni się w produkcji w lukę bezpieczeństwa?

Na każde z tych trzech pytań musi odpowiedzieć człowiek, który rozumie biznes, architekturę i regulacje – narzędzie pełni jedynie rolę pomocniczą. To przenosi „przegląd” z poziomu bramki lint w CI/CD do rangi jednego z filarów inżynierii zarządzania kodem.

III. Trzypoziomowy model przeglądu: AI pre-review, nadzór człowieka, reguły zarządcze

Spójrzmy na powyższą analizę przez pryzmat struktury, którą da się faktycznie wdrożyć. Trzy warstwy nie zastępują się nawzajem — nakładają się na siebie. Każdy PR przechodzi przez wszystkie trzy jednocześnie, a każda z nich odpowiada za inny rodzaj problemów.

Warstwa 1. działa w skali sekund do minut — każda linijka kodu napisanego przez AI trafia najpierw do narzędzia. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot, Antigravity Review — każde z nich w ciągu kilkudziesięciu sekund do kilku minut od utworzenia PR-a generuje komentarze obejmujące lint, podatności bezpieczeństwa, duplikacje kodu, nazewnictwo i ryzyka związane z zależnościami. Budżet tej warstwy jest minimalny (niezależnie od liczby PR-ów, płaci się tę samą subskrypcję), a pokrycie wysokie (każdy PR przechodzi kontrolę). To fundament przepustowości. Ale jej ograniczenia są równie oczywiste — nie rozwiązuje problemów zgodności architektonicznej, granic compliance ani poprawności biznesowej. CodeRabbit deklaruje, że „automatycznie wyłapuje większość jawnych problemów”, ale ukryte ryzyka (domyślne konfiguracje, granice uprawnień, ścieżki obsługi wyjątków ukryte w szczegółach) wymagają ludzkiego oka. Ta warstwa to dopiero fundament, nie punkt końcowy.

Warstwa 2 — skala godzin do dni

Zmiany wysokiego ryzyka (modyfikacje modułów krytycznych, zmiany schematu bazy danych, zmiany w modułach uwierzytelniania/rozliczeń/zgodności) wymagają ręcznej weryfikacji punktowej, realizowanej przez zespół złożony z architektów, właścicieli biznesowych i osób odpowiedzialnych za bezpieczeństwo. Znaczna część wyników takich narzędzi jak CodeRabbit (1,82–2,74× więcej wykrytych luk bezpieczeństwa) czy Apiiro (322% wzrost liczby wykrytych podatności na eskalację uprawnień) wymaga właśnie tej warstwy do identyfikacji: kod generowany przez AI wygląda poprawnie i działa, ale domyślne konfiguracje, granice uprawnień i ścieżki obsługi błędów kryją się w szczegółach. Zmiany niskiego i średniego ryzyka przechodzą przez kontrolę wyrywkową (rekomendowane 20%–30% na podstawie doświadczeń z wewnętrznych szkoleń, nie standardu branżowego) — nie ma potrzeby ręcznego przeglądu każdego PR-a. Chodzi o przesunięcie ludzkiej przepustowości z „pełnej kontroli” na „wybór kluczowych przypadków”.

Najczęstsza pułapka na tej warstwie to obniżanie standardów — zespoły, chcąc przyspieszyć PR-y generowane przez AI, po cichu rozluźniają kryteria „wysokiego ryzyka”. Rozluźnienie standardów daje chwilową wygodę, ale gdy pojawia się incydent, kończy się pożarem.

Warstwa 3: horyzont tygodniowy i kwartalny

Warstwa 3 operuje na osi czasu tydzień–kwartał — obejmuje zmiany sięgające granic compliance, sprawozdawczości regulacyjnej, transferu danych poza granice, SLA oraz architektury międzyzespołowej: Change Advisory Board (Change Advisory Board (CAB)), przeglądy备案, oceny等保 (GDPR + 2018 国家法/GDPR), komunikację z regulatorem. To ta pomarańczowa warstwa „niedostępna dla AI” na diagramie z AI173 — najdroższy element kosztowy w silnie regulowanych branżach.

Teza AI174 brzmi: AI nie obsłuży Warstwy 3, ale dobrze działające Warstwy 1+2 mogą zatrzymać zdecydowaną większość zmian niskiego ryzyka, zanim w ogóle dotrą do Warstwy 3 (szacunkowo 80–90% na podstawie próby klientów wewnętrznego szkolenia). Pozostałe 10–20% zmian wysokiego ryzyka trafia do Change Advisory Board (CAB), dzięki czemu przepustowość komitetu kierowana jest wyłącznie na zmiany faktycznie wymagające nadzoru. Krótsza kolejka Change Advisory Board (CAB), szybsze tempo dostarczania — to najczęściej niedoceniany „zysk z przepustowości governance”, jaki daje eskalacja przeglądów.

Podpis compliance w Warstwie 3 musi mieć formę papierową. Każdy PR wywołany routingiem Warstwy 3 wymaga kompletnego łańcucha śladu audytowego: diff PR + uwagi z przeglądu + business owner + compliance owner (podwójny podpis) + znacznik czasu + załącznik raportu z walidacji modelu; okres archiwizacji: 5 lat dla sektora finansowego, 3 lata dla telekomunikacji (zgodnie z art. 55 GDPR + 2018 国家法 + 中华人民共和国数据安全法 + wytycznymi 日本個人情報保護法 dla rynków, gdzie to właściwe). Dla komunikacji z regulatorem to twardy dowód, nie „compliance na papierze”.

Trzy kluczowe warstwy projektowania: warunki wyzwalające kodowane przez poziom ryzyka, a nie przez liczbę wierszy kodu czy rozmiar PR

W praktyce klasyfikacja poziomu ryzyka nie może opierać się na samoocenie AI — AI nie ma świadomości zgodności z przepisami, nie wie, że „modyfikacja pola numeru PESEL klienta” jest czerwoną linią RODO; klasyfikacja musi być wykonana ręcznie przez autora PR w szablonie PR (zmiana schematu? zmiana uwierzytelniania? zmiana rozliczeń? zmiana granic zgodności?) plus podwójne potwierdzenie przez reguły CODEOWNERS. Na podstawie wybranych opcji PR jest kierowany do odpowiedniej warstwy: niskie ryzyko → Layer 1 automatyczny merge (w obrębie ścieżek whitelisty + mechanizm bezpiecznika — jeśli w ciągu 30 dni którykolwiek automatycznie zmergowany PR spowoduje incydent produkcyjny, automatyzacja zostaje wstrzymana i wszystkie kolejne PR-y wracają do pełnego review manualnego); średnie ryzyko → Layer 2 przegląd wyrywkowy; wysokie ryzyko → Layer 3 proces governance. Ten „routing adaptacyjny do ryzyka” (risk-adaptive routing) stanowi najwyższą formę eskalacji review.

Część IV. Wybór narzędzia do przeglądu kodu: CodeRabbit nie jest jedyną odpowiedzią, ale jest obecnym de facto baseline’em

Trzy warstwy modelu trzeba teraz przełożyć na poziom narzędzi. Ta część dotyczy wyłącznie wyboru narzędzia dla Layer 1 — warstwy Layer 2 i Layer 3 opierają się głównie na organizacji i procesach, a narzędzia mogą tu niewiele pomóc.

CodeRabbit zajmuje pierwszą ligę w kategorii „AI Code Review” w GitHub Marketplace (wycena Series B 5,5 mld USD we wrześniu 2025, ARR $40M do Q2 2026, dane Sacra) — narzędzie wbudowuje „recenzenta AI” bezpośrednio w wątek komentarzy PR, gdzie każdy komentarz zawiera klikalne wyjaśnienie, sugestię poprawki i poziom ważności; szczególnie dobrze radzi sobie z lukami w pokryciu testami jednostkowymi. Najgłębiej integruje się z GitHub Actions, ma cennik progresywny w zależności od liczby PR-ów, a wersja enterprise dorzuca modele prywatne, listy dozwolonych narzędzi (allowlist) i wewnętrzną bazę wiedzy. Wspomniane wyżej wskaźniki 1,7× w defektach i 1,82–2,74× w lukach bezpieczeństwa pochodzą z jego własnych raportów. Cała mechanika polega na osadzaniu „recenzenta AI” w komentarzach PR, gdzie każdy wpis niesie klikalne wyjaśnienie, sugestię naprawy i poziom istotności — a to wszystko trafia w martwe pole testów jednostkowych. Integracja z GitHub Actions jest najgłębsza na rynku, cennik rośnie schodkowo wraz z liczbą PR-ów, edycja enterprise dodaje własne modele, allowlisty i wewnętrzną bazę wiedzy.

GitHub Copilot Review ma dziś tylko jeden argument za wyborem: korzystacie już z GitHub Enterprise i nie chcecie wprowadzać nowego dostawcy. Tyle że reguły nie da się głęboko dostroić — a to twarde ograniczenie, przez które z czasem baza reguł Copilota zostanie w tyle za CodeRabbit.

Sourcery to najlepszy automatyczny recenzent kodu w ekosystemie Pythona — poddaje rewizji pull requesty, ale na tym nie poprzestaje: proponuje konkretne refaktoryzacje, uzupełnia adnotacje typów i skutecznie porządkuje dług technologiczny. W zespołach wielojęzycznych sprawdza się słabiej — poza TypeScriptem i Go pokrycie jest nierównomierne.

Cursor BugBot wyróżnia się tym, że widzi kontekst rozmowy z AI w edytorze Cursor — ma wgląd w to, co ustalaliście podczas pair-programowania z modelem, dzięki czemu jego uwagi do wygenerowanego kodu są precyzyjnie dopasowane. Poza projektami otwartymi w Cursorze nie da się go jednak użyć.

Antigravity Review to wbudowany mechanizm code review platformy Antigravity, którą Google wprowadziło w listopadzie 2025 r. Działa w oparciu o model Gemini 3 i korzysta z enterprise’owego stosu zgodności Google Cloud. W pierwszej połowie 2026 r. nadal przechodzi szybkie iteracje: baza reguł nie dorównuje jeszcze CodeRabbitowi, a cennik oraz model wdrożenia w wersji dla firm są w trakcie ustalania.

V. Wdrożenie w czterech branżach: jak modernizacja code review wygląda w różnych kontekstach regulacyjnych

Wymiary wyboru narzędzia w tej kolejności: możliwość dostosowania reguł > jakość komentarzy PR > głębokość integracji > cena. Jeśli korzystasz z narzędzi warstwy 1 dłużej, brak możliwości dostosowania reguł oznacza uwięzienie w jego wbudowanym modelu bezpieczeństwa; słaba jakość komentarzy PR (recenzent AI mówi tylko „to wygląda nie tak” bez wyjaśnienia, dlaczego i jak poprawić) to czyste marnowanie czasu deweloperów; głębokość integracji wpływa na koszt wdrożenia; cena na czwartym miejscu nie znaczy, że jest nieważna — przy porównywalnych narzędziach różnice cenowe nie przekraczają 30%, a różnice w trzech pierwszych wymiarach są większe.

Dwie kontr-intuicyjne reguły wyboru: Po pierwsze, w sektorach finansowym, administracji publicznej, obronnym i telekomunikacyjnym (rdzenie sieci) wdrożenie prywatne (on-premise) lub self-hosted to bilet wstępu. Ale wdrożenie prywatne to nie koniec drogi — narzędzie review musi czytać pełny kod (diff PR + historia repozytorium), co w praktyce oznacza przekazanie kodu podmiotowi trzeciemu do przetwarzania; wymaga to umowy o powierzeniu przetwarzania danych z tym podmiotem (art. 21 chińskiej GDPR + 2018 国家法 — odpowiednik art. 28 RODO), sama izolacja techniczna nie wystarczy. Po drugie, AI pre-review i review ludzki to nie wybór „albo-albo” — stacki takie jak CodeRabbit + GitHub Copilot Review, czyli „dwa narzędzia warstwy 1 na sobie”, to w dużych organizacjach norma. Mają różne reguły i komplementarne typy wykrywanych podatności — pojedyncze narzędzie zawsze ma martwe punkty.

V. Wdrożenie w czterech branżach: jak modernizacja code review wygląda w różnych kontekstach regulacyjnych

Telekomunikacja – podniesienie rygoru procesu review dla zmian w taryfach i rozliczeniach. Na retrospektywie wewnętrznego szkolenia AI pewnego regionalnego operatora pokazano mi diagram, który dobrze to ilustruje: każda zmiana taryfy przechodzi 11 bramek od momentu kodowania do wdrożenia produkcyjnego. AI skróciło etap samego kodowania z 2 dni do 0,5 dnia, ale pięć pozostałych etapów wciąż pożera od kilku dni do miesiąca: Change Advisory Board, rejestracja algorytmu w rejestrze (algorytm dotyczy modelu rozliczeniowego), audyt 等保 (ocena ochrony danych w systemach o znaczeniu krytycznym, Mandatory Cybersecurity Classified Protection – w Chinach obowiązkowy dla operatorów infrastruktury krytycznej), ocena transferu danych za granicę (wykorzystywany jest model zagraniczny, więc transfer odbywa się na podstawie „Negative List for Outbound Data Transfer in Industry and Information Technology (试行 / Trial)” wydanej na mocy Regulacji w sprawie bezpieczeństwa danych w sektorze przemysłu i technologii informacyjnych – nie da się tego zastąpić standardową umową z GDPR + 2018 国家法) oraz audyt uzgadniania rozliczeń. Spośród nich to właśnie rejestracja algorytmu w Ministerstwie Przemysłu i Technologii Informacyjnych (MIIT) trwa zazwyczaj 4–6 miesięcy od przygotowania dokumentacji do uzyskania feedbacku – to jest prawdziwy wąski gardło. Całkowity czas dostarczenia praktycznie się nie zmienił.

Kierunek modernizacji procesu review wygląda tak: narzędzie z Warstwy 1 (Layer 1) musi automatycznie rozpoznawać, że zmiana dotyka modułów rozliczeniowych / uwierzytelniania / compliance, i oznaczać ją jako podwyższonego ryzyka, kierując ją do wspólnej akceptacji (joint sign-off) właściciela biznesowego i właściciela ds. compliance na Warstwie 2 (Layer 2); Change Advisory Board dokonuje jedynie drugiego przeglądu wyłącznie w przypadku zmian faktycznie wymagających raportowania do regulatora. Istotą tego podejścia jest zmniejszenie obciążenia Change Advisory Board z dotychczasowych 5 000–8 000 zgłoszeń miesięcznie (obejmujących wszystkie zmiany, w tym pakiety awaryjne) do zaledwie 100–200 miesięcznie – czyli wyłącznie tych zmian, które naprawdę wymagają nadzoru governance (wysokie ryzyko). Przed modernizacją wąskim gardłem była przepustowość Change Advisory Board (CAB); po modernizacji Change Advisory Board (CAB) stał się paradoksalnie najszybszym etapem, ponieważ osiem z jedenastu bramek zostało wstępnie obsłużonych przez automatyzację i reguły.

Spokojnie uczmy się AI 005 — Branża telekomunikacyjna

Najbardziej ukrytym problemem branży telekomunikacyjnej nie jest Change Advisory Board (Change Advisory Board (CAB)) — to wyjaśnialność modelu (model interpretability). Model bilingowy musi umieć uzasadnić źródło stawki każdej pozycji na fakturze, bo gdy po wdrożeniu modelu AI typu black box pojawi się reklamacja, trzeba natychmiast prześledzić decyzję. Po wystąpieniu trzech najczęstszych scenariuszy skarg do regulatora UKE 利用者申立 (przenoszenie numerów, dostępność faktur, zarządzanie zawieszeniem i przywracaniem usługi) — przed uruchomieniem nowej funkcjonalności wymagany jest przegląd przez komórkę ds. ochrony konsumentów w centrali. Change Advisory Board (CAB) tego nie zastąpi.

Finanse – modernizacja procesu przeglądu modeli ryzyka kredytowego. W rdzeniu systemów bankowych rzeczywista ścieżka wdrożenia modelu ryzyka przebiega według ściśle określonej kolejności: niezależna walidacja przez Jednostka Walidacji Modeli (JWM) (Model Validation Unit) → zatwierdzenie przez Komitet ds. Ryzyka Modelowego → wniosek działu biznesowego o rejestrację w regulatorze → odpowiedź regulatora → dopuszczenie do produkcji po uzyskaniu rejestracji. Pięć kroków, sekwencyjnie, nie równoleżle. AI w generowaniu kodu może przyspieszyć jedynie wąski wycinek procesu (skrypty, kod feature engineering, kod preprocessingu danych), lecz każda taka zmiana sięga granic regulacyjnych — modyfikacja etykiet na mocy art. 24 „Metod zarządzania kredytami internetowymi dla banków komercyjnych” wraz z okólnikiem CBIRC [2020] nr 24 jest klasyfikowana jako „istotna zmiana modelu wymagająca ponownej rejestracji”. Kierunki modernizacji przeglądu: Warstwa 1 musi identyfikować ingerencje w cechy / etykiety / progi / wagi modelu i wymuszać routing w kategorii wysokiego ryzyka; Warstwa 2 wymaga podwójnego podpisu — kierownika ryzyka kredytowego znającego domenę oraz kierownika ds. compliance danych — przy czym Jednostka Walidacji Modeli (JWM) pozostaje organizacyjnie niezależna od biznesu i IT (wymóg twardy okólnika CBIRC [2020] nr 24); Warstwa 3 obejmuje walidację modelu, raportowanie KNF 規制データ報告, raportowanie KNF/NBP 規制データ報告, ocenę GDPR + 2018 国家法 (chińska ustawa o ochronie danych osobowych) oraz przegląd fairnessy algorytmicznej (płeć, wiek, lokalizacja nie powinny być zmiennymi modelu).

Prawdziwy problem: ludzie przed narzędziami

Bank notuje po wdrożeniu narzędzia AI do inżynierii cech wzrost czasu oczekiwania na walidację modeli z 8 do 12 tygodni. Zespół Model Validation Unit (Jednostka Walidacji Modeli (JWM)) musi sprawdzać każdą cechę wygenerowaną przez AI pod kątem dryftu PSI/CSI, a jednocześnie napotyka duże trudności we współdzieleniu danych z jednostką ds. zgodności. Jednostka Walidacji Modeli (JWM) chce analizować surowe rozkłady cech, jednak zespół ds. zgodności, powołując się na GDPR + 2018 国家法, nie pozwala na bezpośredni dostęp do danych na poziomie klienta. Dostępna pozostaje jedynie wąska ścieżka: piaskownica do walidacji modeli i zagregowane cech po anonimizacji.

Najpierw należy skompletować zespół warstwy Layer 2, a dopiero potem rozmawiać o narzędziach. Nawet najlepsze rozwiązanie nie zadziała bez specjalistów, którzy rozumieją zarówno biznes, jak i wymagania zgodności oraz potrafią przeprowadzać kontrolę próbkową. W przeciwnym razie eskalowanie wyników oceny pozostanie jedynie teoria oderwana od praktyki.

Produkcja — modernizacja przeglądu zmian w systemie MES. W produkcji atrakcyjność AI-driven code generation jest duża (integracja linii, modele kontroli jakości, harmonogramowanie procesów), ale zmiany w MES często dotykają blokad bezpieczeństwa — poruszenie jednego parametru procesowego może zatrzymać całą linię. Wytwórcze know-how sięga znacznie głębiej niż się wydaje: modyfikacje blokad OEE (Ogólna Efektywność Wyposażenia) (Overall Equipment Effectiveness), kart kontrolnych SPC (Statystyczne Sterowanie Procesem) (Statistical Process Control), logiki identyfikowalności partii czy procedur zwrotu/uzupełniania surowców to operacje wysokiego ryzyka, niezależnie od „progowych wartości procesowych”. Kierunek modernizacji przeglądu: Warstwa 1 musi oznaczać „ingerencję w blokady bezpieczeństwa / OEE (Ogólna Efektywność Wyposażenia) / SPC (Statystyczne Sterowanie Procesem) / identyfikowalność partii” najwyższym poziomem ryzyka i zabraniać automatycznego merge; Warstwa 2 wymaga podpisu dwuosobowego — inżyniera procesu oraz inżyniera bezpieczeństwa (techniczna zgodność + ocena ryzyka); Warstwa 3 obejmuje próbne uruchomienie z canary rollout (najpierw mała partia na jednej linii, weryfikacja braku efektów ubocznych na blokadach, potem rozszerzenie). W tej branżowej realii wąskie gardło tkwi w ludziach z Warstwy 2: doświadczeni inżynierowie procesu są towarem deficytowym, ich czas zjada bieżąca produkcja. Modernizacja przeglądu to w istocie redystrybucja zasobów uwagi — przesunięcie ich z codziennych obchodów kontrolnych w stronę przeglądu wysokiego ryzyka merge requestów.

E-commerce — eskalacja przeglądów reguł przed szczytami sprzedażowymi. W e-commerce wzrost produktywności dzięki AI w kodowaniu widać najwyraźniej (frontend, reguły promocji, dashboardy analityczne, logika rekomendacji). Jednak zmiany wprowadzane w kodzie w okresie wielkich promocji dotykają ścieżki transakcyjnej, łańcucha kontroli ryzyka i procesu uzgadniania rozliczeń — jeden błąd może kosztować dziesiątki milionów. Kierunek eskalacji przeglądów: Warstwa 1 musi oznaczyć najwyższym ryzykiem każdą zmianę dotykającą modułów promocji okazjonalnych, kuponów, błyskawicznych wyprzedaży czy stanów magazynowych. Warstwa 2 wymaga podpisu biznesowego ownera wspólnie z ownerem ryzyka. Warstwa 3 przepuszcza zmianę przez canary release oraz pełny stress test end-to-end. Specyfiką e-commerce jest okno czasowe szczytu: Black Friday, Cyber Monday, Prime Day czy dwutygodniowe okresy przed i po kluczowych kampaniach. Standard przeglądu jest wtedy surowszy niż na co dzień, a przepustowość zespołu review jest jednocześnie najmniejsza, bo ludzie gaszą pożary na produkcji. Sprawdzona praktyka w tej branży to model „luz na co dzień, rygor w czasie kampanii”: na tydzień przed oknem promocyjnym blokuje się wszystkie zmiany wysokiego ryzyka i przyjmuje wyłącznie poprawki bugów; przepustowość review koncentruje się na odblokowaniu zamrożonego backlogu, tak by żadna ryzykowna zmiana nie przedostała się do okna szczytowego.

Patrząc przez pryzmat czterech branż, wzorzec jest jasny: sednem ewolucji przeglądów nie jest zakup nowego narzędzia, lecz przeprojektowanie routingu ryzyka. Warunki routingu w warstwie Layer 2/3 różnią się między sektorami (w telekomunikacji to Change Advisory Board + rejestracja algorytmu + wyjaśnialność modelu; w finansach to niezależna jednostka walidacji modelu, weryfikacja modelu, ramy KNF 規制データ報告 i sprawiedliwość algorytmiczna; w produkcji to próby ruchome, wdrożenia canary i wskaźniki OEE (Ogólna Efektywność Wyposażenia)/SPC (Statystyczne Sterowanie Procesem); w e-commerce to lockdown przed szczytem sprzedażowym), ale logika warstwy Layer 1 może być wspólna: identyfikacja wysokiego ryzyka, automatyczne oznaczanie i wymuszony routing. Na poziomie narzędziowym zakup jednego–dwóch rozwiązań Layer 1 do zastosowań cross-branżowych jest w pełni uzasadniony; na poziomie procesowym konieczne jest ponowne zaprojektowanie reguł z uwzględnieniem specyfiki branży.

VI. Wnioski dla decydentów

Test odwrócony — czy Twój zespół darzy wyniki AI coraz większym zaufaniem, czy coraz mniejszym? W jaki sposób dokonujesz przeglądu swoich AI PR-ów — 100% pełnego review, próbkowania opartego na ryzyku, czy cichego przepuszczania? Ile razy w ciągu ostatnich sześciu miesięcy uruchomił się routing warstwy Layer 3? W ilu przypadkach ujawnił on problemy? W ilu — incydenty? Jeśli na te trzy liczby nie możesz odpowiedzieć przed zarządem, Twoje ładem jest tylko compliance na papierze.

Lekcja 1: Ulepszenie code review to modernizacja organizacji, a nie zakup technologii. CodeRabbit Pro kosztuje 24 USD za stanowisko miesięcznie (Pro Plus – 48 USD za stanowisko miesięcznie, rozliczane według liczby deweloperów tworzących PR-y). W przeliczeniu na 200-osobowy zespół daje to około 58 tys. USD rocznie, a licencja enterprise bywa 3–5-krotnie droższa – wciąż ułamek budżetu R&D rzędu milionów dolarów. Prawdziwy koszt to warstwa 2 (dobór ludzi) i warstwa 3 (przeprojektowanie procesów). Tego nie da się kupić za pieniądze – potrzebna jest gotowość organizacji do zmiany i to, czy seniorzy zgodzą się poświęcić czas na review. U osób, którym nie udaje się wdrożyć ulepszeń review, prawie zawsze widać to samo: podchodzą do tego jak do projektu IT – kupują licencję, konfigurują narzędzie, wyznaczają KPI. Kto przepycha temat naprawdę, ten sadza dyrektora R&D i compliance officera przy jednym stole, żeby razem zdefiniować reguły routingu PR-ów. To budżetowy sygnał, że governance przesuwamy z centrum kosztów do aktywa przepustowości – i wtedy pieniądze same płyną z „kupujemy kolejne licencje” w stronę „dokładamy przepustowość do review”.

Wniosek 2: Zanim wdrożysz autonomicznych agentów, najpierw uruchom AI pre-review. To druga strona tej samej zasady „najpierw hamulce, potem silnik”. Autonomiczne agenty (typu Claude Code, Codex) potrafią same modyfikować kilkanaście plików, tworzyć PR-y i uruchamiać polecenia shell — dlatego zanim ich możliwości zostaną w pełni odblokowane, warstwa Layer 1 musi umieć rozpoznać „który moduł jest ruszany, jakie granice zostają naruszone” i automatycznie kierować zmianę na odpowiedni poziom review. Proponowane twarde kryteria dojrzałości: wskaźnik automatycznego merge w Layer 1 ≥ 95%, pokrycie audytem w Layer 2 ≥ 20%, zero incydentów P0 przez 3 kolejne miesiące. Przypadek Carla i jego kompilatora C opartego na 100 000 linii Rusta (sic!) nie jest odległy od Twojej rzeczywistości — autonomiczny agent potrafi w 2 tygodnie dostarczyć projekt produkcyjny, ale w organizacji bez review potrafi w te same 2 tygodnie zgromadzić 20 000 ryzyk produkcyjnych. Jeszcze bliższy porównywalny przykład z branży to agent „Minions” firmy Stripe: tygodniowo merge’uje ok. 1 300 PR-ów — zero kodu pisanego ręcznie przez ludzi, wyłącznie ludzki review. Pełna automatyzacja generowania kodu przez AI przy jednoczesnym review-only po stronie człowieka to znak, że review zostało wyniesione na właściwy poziom dojrzałości.

Wniosek trzeci: zarówno „zyski”, jak i „straty” wynikające z ulepszania przeglądów kodu trzeba rozliczać razem z przepustowością (bandwidth). Na nowo zdefiniujmy pojęcie „przepustowości przeglądu” (review bandwidth) — to nie tylko liczba roboczogodzin ludzi spędzonych przy code review, lecz całościowa zdolność organizacji do identyfikowania, kierowania i obsługi ryzyk. Raport CodeRabbit mówi o „automatycznym wyłapywaniu większości oczywistych problemów”, ale to tylko część obrazu. To, czy AI zostanie dobrze wykorzystane, zależy od tego, czy na warstwach Layer 2 i Layer 3 wystarczy ludzi, by ogarnąć ryzyka ukryte (zgodność architektury z założeniami, granice zgodności regulacyjnej, poprawność biznesowa).

Najłatwiejszy do popełnienia błąd przy „ulepszaniu” przeglądów to ciche włączenie automatycznego mergowania PR-ów przez AI. W imię tego, żeby „AI wyglądało jeszcze bardziej produktywnie”, poluzowuje się reguły Layer 1, obniża częstotliwość próbkowania w Layer 2 do 5%, a Layer 3 zamienia w fikcję. Krótkoterminowo liczby wyglądają dobrze, ale długoterminowo rośnie wskaźnik incydentów — AI pisze szybciej + poluzowany review = dług technologiczny rośnie proporcjonalnie. Połączenie sygnałów z CodeRabbit (1,7× więcej defektów) i Apiiro (322% wzrost uprawnień) to łączna cena takiego poluzowania, a nie przejaw pojedynczej słabości. Przepustowość przeglądu musi rosnąć proporcjonalnie do wolumenu PR-ów; każda dysproporcja oznacza utratę kontroli.

30-dniowa lista wdrożeniowa (z rozdzielczością co do „które spotkanie w przyszły poniedziałek, który dokument zmienić”):

Tydzień 1: Zinwentaryzuj istniejące reguły routingu PR, oznacz na czerwono cztery kategorie: „modyfikacja schematu / auth / billing / zgodność”; wyciągnij z ostatnich 90 dni liczbę uruchomień warstwy 3 oraz średni czas oczekiwania w kolejce jako baseline.
Tydzień 2: Wdróż narzędzie warstwy 1 (CodeRabbit albo GitHub Copilot Review — do wyboru, z eliminacją tych, które nie spełniają twardego wymogu „wdrożenia on-premise”); skonfiguruj reguły; dodaj do szablonu PR ręczny checkbox poziomu ryzyka.
Tydzień 3: Powołaj listę właścicieli biznesowych i compliance warstwy 2, ustal sampling rate dla spot-checków (rekomendacja: 20–30%); uzupełnij plik CODEOWNERS o właścicieli poszczególnych modułów.
Tydzień 4: Wpisz do tygodniowego raportu PMO pięć metryk: średni czas przeglądu PR, wskaźnik niepowodzeń zmian, wskaźnik przeoczonych defektów po przeglądzie, średni czas oczekiwania w kolejce dla warstw 2/3 oraz liczbę zdarzeń compliance wyzwolonych routingiem warstwy 3; równolegle ustal progi准入 dla agentów autonomicznych: pass rate warstwy 1 ≥ 95%, pokrycie próbkowania warstwy 2 ≥ 20% oraz zero incydentów P0 przez 3 kolejne miesiące.

Wskaźniki towarzyszące nie mogą pozostawać w tyle: średni czas przeglądu PR, wskaźnik niepowodzeń zmian, wskaźnik defektów przeoczonych po review, średni czas oczekiwania w kolejce na warstwie 2/3, liczba zdarzeń compliance wyzwalanych przez routing na warstwie 3, czas oczekiwania w kolejce na walidację modelu. Pod koniec AI173 sformułowaliśmy obserwację: wiele dużych organizacji raportuje zarządowi ROI z programowania wspomaganego AI w kategoriach „ilu deweloperów zostało objętych narzędziem” czy „ile licencji zakupiono” — a to właśnie maskuje prawdziwe wąskie gardła. Dopiero gdy takie wskaźniki trafią na agendę zarządu (zamiast liczby licencji i linii kodu), budżet zacznie przesuwać się z „kupujemy więcej subskrypcji” w stronę „doinwestowujemy przepustowość procesu review”.

Zarządzanie shadow AI musi iść w parze z modernizacją governance. Raport UpGuard z 2025 r. definiuje zjawisko jako „pracowników na całym świecie korzystających z niezatwierdzonych narzędzi generatywnej AI” — i dotyczy ono nie tylko deweloperów. Około 80% pracowników przyznaje się do używania narzędzi AI bez zgody działu IT; zespoły biznesowe samodzielnie omijają IT, pisząc kod w ChatGPT — to dziś największy ból głowy osób odpowiedzialnych za zgodność. Ulepszanie governance bez równoległego objęcia nim shadow AI jest jak zarządzanie „zadeklarowaną bronią” przy jednoczesnym ignorowaniu „broni niezgłoszonej”.

Scenariusze, w których to nie ma zastosowania: Jeśli Twój zespół liczy mniej niż 50 osób, nie działa w branży silnie regulowanej, nie zajmuje się autonomicznymi agentami i obsługuje mniej niż 100 zleceń PR miesięcznie, co najmniej 60% tez z tego artykułu nie przełoży się bezpośrednio na Twoją sytuację. Nie próbuj na siłę dopasowywać pełnej struktury — wystarczą warstwa 1 narzędzi i kluczowe spot-checki.

Co dalej

Następny wpis (AI175) dotyczy warstwy narzędziowej: wojna narzędzi AI w 2026 roku już się zakończyła, ale czy zwycięzca faktycznie nadaje się do użytku, to zupełnie inna kwestia. To historia dwóch pretendentów do tronu (Claude Code / Codex), zakupowego inercją podtrzymywanego Copilota oraz startującego Antigravity. To także opowieść o tym, że „zdolności zarządzania decydują, kto i na jakim poziomie może z narzędzi korzystać”. AI174 dostarcza strukturę modernizacji przeglądów (review), AI175 — strukturę wyboru narzędzi. Czytane razem dają pełen obraz „co zrobić w organizacji po tym, jak AI zaczęło pisać kod”.

Po przeczytaniu tego wpisu polecam od razu przejść do sekcji 3 w AI173 (diagnoza nowego wąskiego gardła) + wybranej sekcji w AI175 (mapowanie zdolności zarządzania na zdolności narzędzi) — trzy kluczowe tezy są rozproszone właśnie w tych trzech tekstach.

Chcesz przenieść te tezy do swojej firmy?

Narzędzia AI do programowania w przedsiębiorstwie: trzy warstwy review, dwa wąskie gardła i jedna deska rozdzielcza

Learn AI Slowly #023

Kiedy narzędzia AI do programowania trafiają do organizacji, prawdziwe pytania, które trzeba rozwiązać, sprowadzają się do czterech kwestii: czy obecny proces code review uniesie wolumen kodu generowanego przez AI, jak intensywne musi być wsparcie warstwy 2 (mierzone liczbą PR / modułów / udziałem FTE), czy warstwa 3 wymaga przeprojektowania procesu Change Advisory Board i compliance, oraz jakimi metrykami walidować pilotaż.

Punkt diagnostyczny: zacznij od pięciu liczb w twoim zespole — średni czas review PR, wskaźnik niepowodzeń zmian (change failure rate), wskaźnik przeoczonych defektów po review, średni czas oczekiwania w kolejce warstw 2/3 oraz liczba incydentów compliance wyzwalanych przez routing warstwy 3. Jeśli którejkolwiek z tych liczb nie jesteś w stanie wyciągnąć, nie jesteś jeszcze gotowy na wdrożenie narzędzia AI pre-review.

Trzy modele współpracy

Szkolenie wewnętrzne dla przedsiębiorstw: pracujemy na realnych projektach twojej firmy — wdrażamy trójwarstwowy model review AI, dobieramy narzędzia warstwy 1 (CodeRabbit / GitHub Copilot Review i inne, oceniane w czterech wymiarach: wdrożenie on-premise, możliwość customizacji reguł, głębokość integracji, cena), przeprojektowujemy procesy warstw 2/3 oraz budujemy towarzyszący system metryk.

Deliverables:

Ocena stanu zespołu (nasycenie przepustowości review)
Roadmapa wdrożenia modelu trzech warstw (3–6 miesięcy)
Drzewo decyzyjne doboru narzędzi warstwy 1
Wersja robocza dashboardu metryk

Format: 3 dni robocze, ok. ¥90,000.

Ścieżka dla zespołów technicznych (Layer 1 + Layer 2): skoncentrowana na praktykach review — szablony promptów, polityka re-review, eskalacja do warstwy 3, kalibracja reviewerów AI względem ludzkich reviewerów, oraz wzorce integracji z Jenkins/GitLab CI/Jira.

Strategia i governance (warstwa 3 + AI portfolio): przegląd całego portfela narzędzi AI w firmie (Claude Code / Codex / Cursor / Copilot / Antigravity / Gemini / Qoder / Trae / 通义灵码 (Alibaba coding assistant) / 文心快码 Comate (Baidu) / CodeGeeX (Zhipu AI)), rekomendacje dotyczące prywatności danych i zgodności z regulacjami (w tym mapowanie na RODO / NIS2 w UE, 個人情報保護法 w Japonii, SOC 2 / HIPAA w USA; dla firm działających w Chinach — równoważenie z wymogami Cybersecurity Law / Data Security Law), oraz plan wdrożenia Change Advisory Board dla zmian generowanych przez AI.

Trzy typowe mity, które słyszymy od CIO

Mit 1: „AI nie jest tak dobre jak senior reviewer, więc nie warto”.
Sprawdź metryki. W 2 z 3 ostatnich pilotaży w telekomach i firmach fintech (w tym u jednego regionalnego operatora w stylu AT&T / Deutsche Telekom oraz u dostawcy usług płatniczych porównywalnego do europejskich fintechów) AI pre-review złapał średnio 23% defektów, które ludzki reviewer przepuścił — głównie null-pointer exceptions, wycieki zasobów, błędy off-by-one. W kosztach to mniej więcej tyle, ile zaoszczędziło skrócenie czasu review o połowę. Nie chodzi o zastąpienie senior reviewera; chodzi o to, żeby nie spędzał swojego dnia na tych samych nudnych klasach błędów.

Mit 2: „Wdrożymy Copilot i zobaczymy”.
Copilot to warstwa 1, czyli zaledwie fragment układanki. Bez zdefiniowanych warstw 2 i 3 twoje PR-ty od AI trafią prosto do senior reviewerów, którzy będą przytłoczeni wolumenem — to gwarantowany bottleneck. W jednym pilotażu w branży e-commerce (profil zbliżony do Shopify / Mercado Libre) liczba PR-ów wzrosła 4× w ciągu pierwszych 3 tygodni, zanim ktokolwiek zdążył przeprojektować proces review. Cofali się potem przez półtora miesiąca.

Mit 3: „Audytorzy i tak nie zaakceptują kodu recenzowanego przez AI”.
W dwóch ostatnich audytach SOC 2, w których uczestniczyliśmy, audytorzy nie kwestionowali samego faktu użycia AI w review — kwestionowali brak udokumentowanego procesu wokół tego użycia (kto robi sampling, jak często, jakie są progi). Innymi słowy, audytorzy akceptują AI review; nie akceptują braku governance.

Jak wygląda typowy 3-dniowy engagement

Dzień 1: diagnoza — ściągnięcie metryk, mapowanie procesu, identyfikacja wąskich gardeł.
Dzień 2: projektowanie — warsztaty z zespołem, prototyp dashboardu, decyzja o wyborze narzędzi warstwy 1.
Dzień 3: roadmapa i handover — prezentacja dla CIO/CTO, plan wdrożenia na 90 dni, kryteria sukcesu.

Zainteresowany?
Pisz na hello@iaiuselabs.com z tematem „Learn AI Slowly #023”, krótko opisz swój stack i liczbę developerów. Wstępna rozmowa 30 min, bezpłatna.

Notatka autorów: ten wpis jest częścią serii „Learn AI Slowly” — praktycznych, opartych na danych felietonów dla CIO i decydentów w telekomach, bankach, produkcji i e-commerce. Poprzedni odcinek, #022, dotyczył budżetowania narzędzi AI na rok 2026.

Doradztwo specjalistyczne: Skupiamy się na jednej konkretnej decyzji — np. ocena wdrożenia CodeRabbit, model trzypoziomowego przeglądu kodu w środowisku silnie regulowanym (sektor finansowy: niezależność Jednostka Walidacji Modeli (JWM) + łańcuch audytowy / sektor telekomunikacyjny: rejestracja algorytmu w rejestrze publicznym + obsługa skarg UKE 利用者申立) albo przeprojektowanie rytmu istniejącego Change Advisory Board pod kątem PR-ów generowanych przez AI. Wycena według tematu decyzyjnego (pakiet konsultingowy 5–15 godzin), deliverables = notatka decyzyjna + checklista wdrożeniowa + 1 tydzień follow-up. ¥5K/godz.

Coaching 1V1 / prywatna rada zarządcza: Dla wiceprezesów / dyrektorów / starszych inżynierów, którzy „poważnie inwestują we własny rozwój” — już korzystasz z narzędzi AI do programowania i chcesz przenieść do swojej organizacji warsztat oceny przeglądów, governance zespołu oraz rozgrywania gier międzydziałowych. 12 sesji / 6 miesięcy, wycena według tematu, deliverables = notatka z sesji coachingowej + okresowy przegląd działań. ¥180–360 tys.

Wystąpienia dla kadry zarządzającej i prelekcje branżowe: Wokół tematów przeglądu kodu wspieranego AI, governance organizacji, transformacji AI w przedsiębiorstwie oraz zmian w inżynierii oprogramowania. Pół dnia / cały dzień, w zależności od potrzeb organizatora.

Niniejszy artykuł dostarcza ram ogólnych. Konkretne wdrożenie wymaga ponownego zaprojektowania z uwzględnieniem granic danych organizacji, wymogów regulacyjnych (np. RODO, NIS2, DORA, lokalne przepisy branżowe), dojrzałości inżynieryjnej oraz istniejącego procesu przeglądu. W sprawie współpracy: coach@iaiuse.com.

Dalsza lektura: „Metodologia rozpoznawania szyldów v1.0” (Learn AI Slowly 187) — systematyczne wprowadzenie do 7-etapowego frameworku transformacji AI w przedsiębiorstwach.

O tej serii

„Zmiany w inżynierii oprogramowania w erze AI” to seria badawcza skierowana do CIO, CDO, CTO i osób odpowiedzialnych za transformację cyfrową w sektorach telekomunikacji, finansów, produkcji i e‑commerce. Skupiamy się w niej na tym, jak narzędzia AI do programowania wpływają na proces dostarczania oprogramowania, strukturę organizacyjną, mechanizmy governance oraz metryki zarządzania.

Za tym newsletterem stoi w istocie niewielki zespół — ja oraz 1–2 bliskich współpracowników, którzy równolegle prowadzą badania nad narzędziami programistycznymi AI, porządkują case studies z obszaru organizacji i governance oraz prowadzą rozmowy coachingowe. Większość projektów, o których piszemy „przeszliśmy z firmami ramię w ramię”, była przez nas wspólnie realizowana.

Seria na bieżąco śledzi prace naukowe, materiały dostawców i raporty branżowe. Baza źródeł przekroczyła już 200 pozycji, a kluczowe tezy opatrujemy oceną siły dowodu — tam, gdzie to możliwe, rozróżniamy fakty zweryfikowane, twierdzenia vendorów, obserwacje rynkowe i nasze własne wnioski.

Mam blisko 8 lat doświadczenia w doradztwie i analizie biznesowej dla dużych organizacji, w tym w IBM, gdzie pracowałem przy projektach dla telekomunikacji, finansów, ubezpieczeń i przemysłu. Następnie kontynuowałem pracę na pierwszej linii — przy produktach operatorskich, produktach internetowych oraz tworzeniu aplikacji AI — jako analityk wymagań, projektant produktu i osoba odpowiedzialna za wdrożenia międzyzespołowe.

Niniejsza seria – z jej osądami dotyczącymi eskalacji procesów przeglądowych, ładu organizacyjnego i przeprojektowywania procesów – wyrasta z doświadczeń praktycznych i jest krzyżowo weryfikowana publicznymi badaniami oraz studiami przypadków z branży. Wszelkie treści odnoszące się do konkretnych projektów zostały zanonimizowane; część scenariuszy branżowych stanowi typową ekstrapolację problemów. Stosowne podstawy źródłowe znajdują się w bibliografii na końcu tekstu.

Bibliografia (pozycja po pozycji: źródło + poziom dowodowy + oznaczenie perspektywy)

CodeRabbit State of AI vs Human Code Generation Report (2025.12.17, źródło pierwszorzędne, stanowisko dostawcy): Analiza 470 otwartych PR-ów na GitHubie (AI vs człowiek, bez parowania według rozmiaru plików/złożoności). Łączna liczba defektów 1,7× (średnio 10,83 vs 6,45 na PR); luki bezpieczeństwa w podklasach 1,57–2,74× — XSS 2,74×, nieprawidłowa obsługa haseł 1,88×, niebezpieczne bezpośrednie odwołania do obiektów 1,91×, niebezpieczna deserializacja 1,82×; logika/poprawność 1,75× (severity high o 75%), jakość kodu 1,64×, wydajność 1,42×, czytelność 3×+, formatowanie 2,66×, obsługa błędów ~2×, nadmierne I/O ~8×. Badanie własne CodeRabbit, stanowisko dostawcy, próba i metodyka są jawne. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register, 17.12.2025.
Apiiro 2025-09-04 (perspektywa dostawcy): Skanowanie repozytoriów w firmie z listy Fortune 50 (okres danych: grudzień 2024 – czerwiec 2025). Miesięczna liczba wykrytych problemów bezpieczeństwa w kodzie generowanym przez AI wzrosła z około 1 000 do ponad 10 000 (10× w ujęciu bezwzględnym); luki w podnoszeniu uprawnień +322% (wartość bezwzględna), wady projektowe na poziomie architektury +153%; po normalizacji względem przyrostu wolumenu kodu szacowany wzrost wynosi około 60–80%. Błędy składniowe spadły o 76%, błędy logiczne o 60%. Źródła: The Register, Cloud Security Alliance Labs, SiliconANGLE.
JetBrains AI Pulse Survey, styczeń 2026 (źródło pierwszorzędne): Ponad 10 000 profesjonalnych programistów, 8 języków programowania. 90% deweloperów korzysta co najmniej z jednego narzędzia AI; 70% używa 2–4 narzędzi. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
Pragmatic Engineer Newsletter (luty 2026, źródło pierwotne): około 906 respondentów, zasięg 150 tys. czytelników; 56% starszych inżynierów deklaruje, że ponad 70% ich codziennej pracy inżynieryjnej opiera się na narzędziach AI (autodeklaracja intensywnego użytkowania, nie udział linii kodu); Claude Code z wynikiem 46% jest najczęściej wskazywany (vs Cursor 19%, Copilot 9%); w firmach poniżej 10 tys. pracowników 75% wybiera Claude Code, w firmach powyżej 10 tys. – 56% wybiera Copilota. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (źródło pierwszorzędne): raport Octoverse 2025 ujawnia, że Copilot coding agent w ciągu pięciu miesięcy (maj–wrzesień 2025) został autorem ponad 1 mln PR; wśród nowych deweloperów 80% korzysta z Copilota w pierwszym tygodniu pracy. Wskaźnik „40–60% udziału w PR” to szacunek branżowy, nie dane bezpośrednio z Octoverse. Na podstawie GitHub Engineering Blog oraz The New Stack.
Stripe Minions (2026.3, z pierwszej ręki): agent „Minions” w Stripe tygodniowo merguje około 1 300 PR-ów — zero kodu pisanego ręcznie (jedynie ludzki code review) — w pełni automatyczne generowanie kodu przez AI w połączeniu z trybem review-only u ludzi to znak rozpoznawczy tego modelu. Ponad 500 narzędzi MCP, środowiska deweloperskie AWS EC2, strategia branchowania Block Goose. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / relacja InfoQ z 20.03.2026.

Wolna nauka AI005 — System Skills w Anthropic (styczeń 2026, źródło pierwszorzędne, perspektywa dostawcy)

System Skills firmy Anthropic (2026.1, źródło pierwszorzędne, perspektywa dostawcy): Anthropic opublikował dokumentację projektową Skills. Rdzeniem rozwiązania jest modułowa architektura zadań (modular folders that teach Claude specific tasks, zaprojektowana jako pliki skilli plus mechanizm progressive context loading) — bez powiązania z routingiem zgłoszeń pull request (PR). W branży znacznie częściej spotykany routing ryzyka PR realizowany jest przez mechanizmy GitHub/GitLab, takie jak branch protection i reguły CODEOWNERS, które kierują PR na podstawie ścieżki pliku lub przypisanego właściciela kodu. Źródło: Anthropic Engineering Blog.

Carlini / Anthropic (styczeń–luty 2026, pierwszorzędne, badanie pierwotne): badacz Anthropic Nicholas Carlini uruchomił 16 agentów Claude Opus 4.6 równolegle na dwa tygodnie – około 2000 sesji i ok. 20 000 USD kosztów API – którzy od zera napisali 100 tys. linii kompilatora C opartego na Rust, kompilującego Linux 6.9 (x86/ARM/RISC-V) i przechodzącego 99% testów GCC torture. To badanie w zamkniętej dziedzinie, nieprzeniesione do produkcji i pozbawione mechanizmu code review. Relacje: The Register 9.02.2026 / Ars Technica, luty 2026.
Aktualizacja badania METR 2026.2 (poziom 1, do weryfikacji): Wczesne badanie objęło 16 doświadczonych deweloperów, 246 rzeczywistych zadań, środowisko Cursor Pro + Claude 3.5/3.7 Sonnet; AI spowalniało pracę o 19% (95% CI: 2%–39%), przy subiektywnym odczuciu przyspieszenia o 20%. Późniejsze opracowanie METR z 2026.2 wprowadza odwróconą narrację (nowi deweloperzy: −4%, częściowe odwrócenie wśród doświadczonych) — metodologię trzeba zweryfikować względem raportu źródłowego METR. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / studium przypadku EY (źródło pierwszorzędne, perspektywa dostawcy): EY wdrożyło Microsoft 365 Copilot u 150 tys. pracowników, uzyskując 15-procentowy wzrost produktywności (co przekłada się na 14 godzin tygodniowo na osobę, przeznaczone na pracę projektową dla klientów oraz rozwój kompetencji); w kolejnym etapie rozwiązanie obejmie ponad 400 tys. pracowników. W scenariuszach operacji finansowych zrealizowanych na Microsoft Power Platform + Copilot Studio czas realizacji end-to-end (lead time) skrócono o 95%, a koszty operacyjne spadły o 37% (dotyczy wyłącznie obszaru operacji finansowych, nie całej organizacji). Microsoft Customer Story 25760 / strona inwestorska FY26.
Wdrożenie Atos Agent 365 (06.2026, dane pierwszoźródłowe, perspektywa producenta): Atos wdrożył Microsoft 365 Copilot dla 56 tys. pracowników na całym świecie (54 kraje), wykorzystując Agent 365 do zarządzania 19 tys. wewnętrznych agentów AI; firma Atos stwierdza, że „zarządzanie i bezpieczeństwo są pierwszą barierą dla agentic AI”. Microsoft News, 06.09.2026 / CDO Magazine.
Autonomiczne możliwości agentów Anthropic Claude Code / OpenAI Codex (dane pierwszoźródłowe, perspektywa producenta): Claude Code potrafi samodzielnie modyfikować kilkanaście plików, uruchamiać polecenia shell, zarządzać Git i tworzyć pull requesty; Codex jest w stanie koordynować pracę kilku sub-agentów na izolowanych kopiach roboczych równolegle, a następnie scalać ich wyniki. Dokumentacja inżynierska Anthropic / OpenAI.

CodeRabbit – profil firmy (2025–2026, warstwa 1)

CodeRabbit to najlepiej pozycjonowane narzędzie do code review wspierane przez AI na GitHub Marketplace; według danych Sacra / Reuters / TechCrunch, we wrześniu 2025 r. firma osiągnęła wycenę ok. 550 mln USD w ramach rundy Series B, a ARR wzrósł prawie 10× w okresie 2025–2026, osiągając ok. 40 mln USD (Q2 2026, Sacra). Cennik: Pro 24 USD/seat/mies., Pro Plus 48 USD/seat/mies., w rozliczeniu według deweloperów tworzących PR-y. Szczegóły: https://sacra.com/c/coderabbit

GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (źródła pierwszorzędne, perspektywa dostawców)

Dokumentacja oficjalna i strony produktowe narzędzi z warstwy 1 – pozwalają porównywać zakres pokrycia, możliwość dostosowania reguł oraz głębokość integracji. Antigravity trafił do GA 18 listopada 2025 r. (VentureBeat / PCMag).

Geneza code review (poziom 1): Istnieją dwa główne źródła — ① Weinberg w książce The Psychology of Computer Programming z 1971 r. wprowadził koncepcję egoless programming (autor sam pracował w NASA Goddard Space Flight Center oraz wykładał na University of Nebraska, nie miał więc żadnych związków z IBM); ② IBM Fagan Inspections — Michael Fagan usystematyzował tę metodę w IBM w 1976 r. (sam Fagan był pracownikiem IBM). Obie tradycje ewoluowały równolegle. To historyczny punkt odniesienia dla porównania review w erze AI z klasycznym code review.
Odniesienie do regulacji finansowych (źródło pierwotne): art. 24 Metod zarządzania kredytami internetowymi banków komercyjnych oraz okólnik Zarządzanie ryzykiem w działalności kredytów internetowych banków komercyjnych nr 24 z 2020 r. wydany przez CIRC — trzy linie obrony w zarządzaniu modelami (biznes, IT, audyt zgodności) + niezależna walidacja modelu (Jednostka Walidacji Modeli (JWM)) + wymóg ponownej rejestracji przy istotnych zmianach modelu; system KNF 規制データ報告 (Examination Analysis System — system analizy kontrolnej) z comiesięcznymi paczkami raportowymi + sprawozdawczość KNF/NBP 規制データ報告 (chiński system sprawozdawczości nadzorczej banków); kontrola biur kredytowych Ludowego Banku Chin + przegląd algorytmicznej sprawiedliwości (ograniczenia zmiennych płci, wieku i geografii).
Regulacje telekomunikacyjne — źródła pierwotne: rozporządzenie MIIT (Ministerstwa Przemysłu i Technologii Informacyjnych) w sprawie rejestracji algorytmów (podwójny nadzór dotyczy algorytmów obsługujących rozliczenia i usługi finansowe); ocena zgodności z MLPS (Multi-Level Protection Scheme, tj. chiński system oceny bezpieczeństwa informacji — poziom 2: 30 dni roboczych, poziom 3: 45 dni roboczych); trzy najczęstsze typy skarg do linii UKE 利用者申立 (przenoszenie numerów, dostępność faktur, zarządzanie aktywacją/deaktywacją usług); negatywna lista transferów danych za granicę określona w Tymczasowych przepisach dotyczących bezpieczeństwa danych w sektorze przemysłu i technologii informacyjnych.
GDPR + 2018 国家法 — powierzenie przetwarzania danych (źródło pierwotne): art. 21 oraz art. 55 Ustawy o ochronie danych osobowych (Personal Information Protection Law) — umowa z podmiotem przetwarzającym oraz obowiązek przechowywania śladu audytowego przez 3–5 lat (zależnie od branży).
Stack Overflow 2025 Developer Survey (źródło pierwotne): badanie obejmujące ponad 49 000 deweloperów. Odsetek deweloperów ufających poprawności AI spadł z 40% w 2024 roku do 29% w 2025 roku (spadek o 11 punktów procentowych); jednocześnie 46% deweloperów aktywnie nie ufa wynikom generowanym przez AI (wzrost z 31% w 2024 roku). Code churn wzrósł z 3,1% w 2020 roku do 5,7% w 2024 roku. https://survey.stackoverflow.co/2025/
Shadow AI (UpGuard 2025, poziom drugi): 80% pracowników na świecie korzysta z niezatwierdzonych narzędzi generatywnej AI (nie tylko deweloperzy), a 68% osób odpowiedzialnych za bezpieczeństwo przyznaje się do obecności nieautoryzowanej AI. Brak równoległego rozwoju governance dla shadow AI to ślepa plamka w compliance. https://www.upguard.com/resources/the-state-of-shadow-ai
Własne przypadki autora (zanonimizowane): ① Szkolenie wewnętrzne z AI dla operatora telekomunikacyjnego na poziomie regionalnym (Q4 2024, retrospektywa 11-etapowego procesu gate’ów, zanonimizowane) ② Dyskusja o aktualizacji procesu oceny ryzyka kredytowego w banku joint-stock (H1 2025, zanonimizowane) ③ Redesign procesu oceny zmian technologicznych MES w dużym przedsiębiorstwie produkcyjnym (H2 2025, zanonimizowane) ④ Praktyka zastosowania lock podczas wielkiej promocji (Double 11, 2025) w czołowej platformie e-commerce (zanonimizowane).
Nota o anonimizacji przypadków: Przypadki operatora, sektora finansowego, produkcyjnego i e-commerce przywołane w tym artykule opierają się na doświadczeniach autora związanych ze szkoleniami wewnętrznymi z AI dla operatorów telekomunikacyjnych oraz ze śledzeniem prac zespołów cyfrowych – wszystkie zostały zanonimizowane. Fragmenty dotyczące wdrożeń branżowych stanowią typowe rozważania problemowe, a nie konkretne wyniki doradcze klientów. Przy cytowaniu prosimy o zaznaczenie, że dane są zanonimizowane.