Git w erze agentów AI: czas przeglądu kodu wydłużył się o 441%

Wdrożenie agentów AI zwiększa wolumen generowanego kodu o 30%, ale brak proporcjonalnych inwestycji w automatyczną weryfikację paraliżuje procesy dostarczania oprogramowania. Badania telemetryczne wykazują, że mimo wyższego przyrostu linii kodu łączna liczba dostarczonych funkcji w systemie Jira nie ulega zmianie. Brak rzetelnej oceny sprawia, że aż 61,38% pull requestów od AI trafia do repozytoriów na GitHubie bez jakiejkolwiek rejestracji przeglądu.

Mechanizm zatoru: dlaczego 30% więcej kodu nie przekłada się na wdrożenia

Masowe wdrożenie agentów programistycznych zwiększa wolumen generowanego kodu, lecz paraliżuje etap weryfikacji w procesie wytwarzania oprogramowania. Zamiast przyspieszenia wydań produktów, firmy zmagają się ze wzrostem średniego czasu przeglądu zmian o 441% oraz wydłużeniem oczekiwania na połączenie kodu. Zator w procesie wytwórczym przeniósł się z etapu pisania instrukcji na etap oceny architektury i bezpieczeństwa.

Analiza Harvard University (Fiona Chen i James Stratton) oparta na danych telemetrycznych Jellyfish oraz GitHub (obejmująca 700 firm, 700 000 pracowników i 300 mln zdarzeń) wskazuje jednoznacznie: agenci tacy jak Claude Code, Cursor czy Devin generują miesięcznie średnio 1 500 dodatkowych linii kodu na programistę (wzrost o 30%), zwiększają liczbę commitów o 20% oraz liczbę pull requestów o 23%. Mimo tego skoku produktowego, łączna liczba zamkniętych zgłoszeń i epików w systemie Jira nie wykazała żadnej statystycznie istotnej zmiany.

Węzeł gordyjski przeniósł się na fazę weryfikacji. Czas od zgłoszenia do scalenia pull requesta wydłużył się o 49%, liczba komentarzy przypadających na zmianę wzrosła o 35%, a udział pull requestów wymagających poprawek niemal się podwoił.

Równoległe badania LinearB przeprowadzone na próbie 8,1 mln pull requestów w 4 800 organizacjach potwadzają ten kryzys operacyjny. Programiści deklarują poczucie wzrostu szybkości pracy o 20%, jednak rzeczywisty zmierzony czas dostarczenia oprogramowania wydłużył się o 19%.

Główną przyczyną organizacyjną jest niedopasowanie tradycyjnych struktur Two-Pizza Teams (6–10 osób) do realiów pracy z agentami. Gdy czterech frontendowców w jednym zespole uruchamia własne agenty modyfikujące dziesiątki plików w ciągu godziny, liczba kolizji i konfliktów w Gicie rośnie wykładniczo. Odpowiedzią liderek rynkowych jest przejście na Two-Slice Teams — dwuosobowe zespoły posiadające wyłączną odpowiedzialność nad wyciętym modułem systemu (slice), co eliminuje wewnętrzne przekazania zadań (handoffs) i ogranicza przestrzeń konfliktów.

Czy code review wciąż ma sens, gdy większość kodu piszą agenti AI?

Zastępowanie inżynierów przez autonomiczne boty recenzenckie obniża jakość informacji zwrotnej i drastycznie zwiększa odsetek odrzuconych zmian w repozytoriach. Automatyczne narzędzia review generują w większości szum informacyjny, co zmusza zespoły do ręcznego weryfikowania każdego pull requesta. Bez bezpośredniego udziału człowieka weryfikacja kodu staje się fikcją, a wskaźnik udanych scaleń spada o ponad dwadzieścia punktów procentowych.

Badanie zaprezentowane na konferencji EASE 2026 (obejmujące 33 596 pull requestów wytworzonych przez agenty AI na GitHubie) wykazało, że 61,38% z nich nie posiadało żadnej zarejestrowanej aktywności recenzenckiej. Po uwzględnieniu automatycznych botów odsetek nieprzejrzystych scaleń sięga 84%. Co więcej, spośród komentarzy pozostawianych przez ludzi na pull requestach agentów aż 25,9% stanowiły komendy sterujące (np. polecenia naprawy błędu), a nie rzeczywista ocena architektury czy logiki biznesowej.

Empiryczne badanie MSR 2026 (autorstwa Kowshika Chowdhury’ego i zespołu na bazie zbioru AIDev obejmującego 3 109 pull requestów) ujawnia przepaść jakościową między przeglądem ludzkim a automatycznym:

• Wskaźnik scalenia (merge rate): pull requesty oceniane wyłącznie przez boty (CRA-only) osiągają 45,20%, podczas gdy zmiany recenzowane przez ludzi (human-only) osiągają 68,37% (różnica 23,17 p.p.).
• Wskaźnik porzucenia kodu: 34,88% zmian z recenzją botów kończy się zamknięciem bez scalenia, wobec 21,60% w przypadku weryfikacji ludzkiej.
• Jakość sygnału (signal-to-noise ratio): w 60,2% zamkniętych PR-ów ocenianych przez boty wskaźnik wartościowych uwag wynosił zaledwie 0–30%.
• Wydajność narzędzi CRA: 92,31% badanych botów (12 z 13) osiągnęło średni poziom sygnału poniżej 60%.

„ Wskaźnik sygnału do szumu (Signal-to-Noise Ratio) w narządziach AI Code Review: ├── semgrep-code-getsentry[bot] : 100,00% (wysoka precyzja wąskich reguł) ├── entelligence-ai-pr-reviews : 52,29% ├── cursor[bot] : 43,40% ├── github-advanced-security : 27,62% ├── Copilot[bot] : 19,79% └── codefactor-io[bot] : 0,00% (całkowity szum informacyjny) „

Zjawisko zamkniętej pętli (AI-to-AI code review), w którym jeden agent recenzuje kod wygenerowany przez drugiego, obejmuje już setki tysięcy zmian. Badanie ESEM 2026 na próbie 248 641 pull requestów wskazuje, że bot CodeRabbit generuje 35,0% uwag refaktoryzacyjnych dla kodu z Claude Code, ale tylko 10,5% dla kodu z Copilota. Rosnąca skala automatycznych interakcji nie zastępuje jednak odpowiedzialności inżynierskiej — formalne zatwierdzenie zmiany przesuwa się z bezmyślnego klikania przycisku approval na jawny brak sprzeciwu wobec architektury („You reviewed it. You understand it. You own it”).

Od bazy danych do bramki: jak Entire i SonarQube zmieniają kontrolę wersji

Tradycyjny system kontroli wersji Git nie rejestruje intencji ani kontekstu decyzji podejmowanych przez agenty programistyczne podczas sesji generowania kodu. Rosnąca prędkość tworzenia zmian doprowadza serwery do przeciążenia, zmuszając organizacje do porzucenia lokalnego przetwarzania na rzecz centralnych baz danych kontekstu. Nowe platformy zastępują zwykłe commity ciągłymi punktami kontrolnymi, zapobiegając bezpowrotnej utracie pamięci semantycznej o motywach architektonicznych.

Wysoka dynamika prac inżynieryjnych ujawnia ograniczenia architektoniczne Gita. W firmie Anthropic wskaźnik skompilowanych zmian w głównym monorepo wzrósł z 2 500 do 30 000 dziennie przy 25 mln checkoutów CI/CD dziennie, co wymusiło napisanie autorskiego systemu kontroli wersji SON. SON wykonuje operacje scalania i rebase po stronie serwera, redukując wagę infrastruktury 200-krotnie i skracając czas pobierania kodu z minut do sekund.

Nowym standardem rynkowym staje się Entire — platforma stworzona przez byłego CEO GitHub, wsparta finansowaniem w wysokości 60 mln USD. Entire działa jako warstwa danych kompatybilna z Gitem, dodając nowy element strukturalny: Checkpoint.

Równolegle w warstwie weryfikacji CI/CD firma Imprint (wdrażając zalecenia CTO Willa Larsona) wprowadziła proces Small Change. Przy skoku liczby połączonych PR-ów o 400% i wydłużeniu czasu oczekiwania na review z 33 do 77 minut, wdrożono automatyczny akcept dla zmian poniżej 1 000 linii kodu, pod warunkiem przejścia testów i braku uwag krytycznych ze strony botów SonarQube. Wynik: spadek łącznych incydentów o 42%, a incydentów krytycznych o 78%.

Stos weryfikacyjny SonarQube porządkuje walidację w trzech pętlach: 1. Sonar Vortex: Przekazuje kontekst architektury do Claude Code lub Cursor w czasie rzeczywistym przed utworzeniem zmian. 2. Gitar (AI Reviewer): Wykonuje wstępny przebieg i automatycznie naprawia błędy CI. 3. AI Code Assurance: Stosuje twarde bramki jakościowe uniemożliwiające scalenie kodu bez akceptacji wymogów bezpieczeństwa.

Ryzyka bezpieczeństwa i wymogi regulacyjne w procesie AI-native

Generowanie kodu na masową skalę bez ścisłych bramek walidacyjnych rodzi krytyczne podatności w obszarze bezpieczeństwa i zgodności z regulacjami prawnymi. Agenty autonomicznie dodają nieistniejące pakiety, ujawniają sekrety w repozytoriach oraz wprowadzają luki w kontroli dostępu do danych. Brak rygorystycznego rozdzielenia ról w procesie zatwierdzania zmian naraża instytucje na złamanie wymogów nadzorczych i awarie produkcyjne.

Kod tworzony przez agenty AI niesie ze sobą specyficzne wektory zagrożeń, które omijają klasyczne testy jednostkowe:

• Halucynacje pakietów (Package Hallucinations): Komercyjne modele LLM zmyślają nazwy bibliotek w 5,2% przypadków, a modele open-source aż w 21,7%. Atakujący rejestrują te nazwy w rejestrach publicznych (np. npm, PyPI), przejmując kontrolę nad procesem budowania aplikacji.
• Wycieki sekretów: Badanie GitGuardian wykazuje, że repozytoria wykorzystujące GitHub Copilot cechują się 6,4% wskaźnikiem wycieku kluczy i sekretów — to o 40% więcej niż średnia rynkowa.
• Luki w logice i kontroli dostępu: Według zestawienia OWASP 2025 nieprawidłowa kontrola dostępu (Broken Access Control) zajmuje 1. miejsce wśród podatności aplikacji. Kod generowany przez AI przechodzi testy składniowe, ale przyznaje nieuprawniony dostęp do zasobów.

W sektorze regulowanym Unii Europejskiej oraz rynków azjatyckich obowiązują rygorystyczne normy prawne. Wytyczne Bank Negara Malaysia (RMiT) oraz MAS TRM (Singapur) wymagają bezwzględnego rozdzielenia obowiązków (Segregation of Duties) w procesie SDLC.

„ Nadzorczy schemat rozdzielenia ról (Segregation of Duties): [Inżynier zleca zadanie] ──> [Agent AI generuje kod] ──> [Automatyczne bramki CI/CD] │ [ZAKAZ SAMOZATWIERDZENIA] <───────────────────────────────────────┘ │ ▼ [Niezależny inżynier / CODEOWNERS zatwierdza PR] ──> [Merge do main] „

Zgodnie z tymi zasadami osoba, która wydała polecenie agentowi programistycznemu, nie może samodzielnie zatwierdzić powstałego pull requesta. Platforma GitHub domyślnie blokuje możliwość zatwierdzania zmian od Copilota przez inicjatora sesji.

Zgodnie z zaleceniami Sergeya Marchuka (Oxagile / Forbes) organizacja musi ustanowić cztery formalne bramki przeglądu z imienną odpowiedzialnością: bramkę wymagań, architektury, dekompozycji oraz wdrożenia.

Wnioski praktyczne i rekomendacje

Ochrona wydajności inżynieryjnej w dobie powszechnego stosowania agentów AI wymaga natychmiastowej przebudowy mechanizmów weryfikacji oraz struktury zespołów programistycznych. Sama instalacja kolejnych asystentów bez wdrożenia twardych bramek walidacyjnych prowadzi wyłącznie do wzrostu długu technologicznego i opóźnień wdrożeniowych. Przedsiębiorstwa muszą przekierować uwagę z masowego generowania instrukcji na budowanie trwałych procedur nadzoru i rozliczalności.

• Skonfiguruj automatyczne narzędzia analizy statycznej (Semgrep, CodeQL, SonarQube, Gitleaks) z wymogiem zaliczenia wszystkich sprawdzianów przed przekazaniem pull requesta do przeglądu ludzkiego.
• Zmierz rzeczywisty czas przebywania zmian w kolejce przeglądu oraz udział komentarzy sterujących w stosunku do uwag merytorycznych, wykorzystując dane telemetryczne z platform LinearB lub Jellyfish.
• Zweryfikuj zasady prawne i wymogi CODEOWNERS w repozytoriach, wprowadzając bezwzględny zakaz samozatwierdzania pull requestów wygenerowanych przez agenty AI na wniosek tego samego inżyniera.
• Wdróż strukturę Two-Slice Teams (zespoły 1–2 osobowe z pełną odpowiedzialnością modułową) oraz zasady wstępnego zatwierdzania planu zmian przed przystąpieniem agenta do pisania kodu.

Źródła

• AI doesn’t need a new Git workflow. It needs better gates – DEV Community
• Beyond Git: How Entire is Reinventing Version Control for the AI Era – dFlow.sh
• Do We Still Need Code Reviews in the Age of Coding Agents? – DEV Community
• From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests – arXiv
• GIT i Code Review to przeszłość? Jak Agenci AI zmienią twoją pracę
• Harvard study: AI coding agents add 30% code, flat shipped output | AI Weekly
• How Version Control Will Evolve for the Agent Boom – Entire
• Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review – arXiv