Podatek Review: Dlaczego Recenzja Kodu AI To Teraz Najważniejsza Umiejętność

Podatek Review: Dlaczego Recenzja Kodu AI To Teraz Najważniejsza Umiejętność

11 min czytania

Podatek Review

Kiedyś recenzowałeś kod pisany przez ludzi, których znasz. Kasia zawsze zapomina o null checkach. Marcin over-engineeruje obsługę błędów. Darek pisze funkcje za długie, ale działają. Nauczyłeś się ich patternów przez miesiące. Mogłeś przeskanować PR od każdego z nich w piętnaście minut, bo wiedziałeś gdzie będą bugi.

Teraz recenzujesz kod pisany przez nikogo. Żadnych patternów. Żadnych nawyków. Żadnych “tells.” Każdy PR wygląda syntaktycznie idealnie i architektonicznie rozsądnie. Nazwy zmiennych dobre. Komentarze pomocne. Testy przechodzą.

A gdzieś w środku jest podatność bezpieczeństwa, zhallucynowane wywołanie API albo błąd logiczny, którego szukanie zajmie czterdzieści pięć minut - jeśli go w ogóle znajdziesz.

Witaj w podatku review. Ukrytym koszcie, na który nikt nie zabudżetował.

Liczby, których nikt się nie spodziewał

Kiedy ankieta JetBrains 2025 Developer Ecosystem zapytała developerów, która umiejętność będzie najważniejsza w erze AI, odpowiedź zaskoczyła. To nie było prompt engineering. Nie “nauka pracy z AI.” 47% wskazało recenzowanie i walidację kodu generowanego przez AI jako umiejętność numer jeden. Pokonało “efektywne promptowanie narzędzi AI” z 42%.

Developerzy wiedzą coś, czego nie wiedzą ich managerowie. Wąskie gardło się przesunęło.

CodeRabbit przeanalizował 470 open-source’owych pull requestów z GitHuba, porównując kod generowany przez AI i pisany przez ludzi. PR-y AI zawierały 1.7x więcej problemów ogólnie. Nie marginalnie. Nie “mniej więcej tyle samo.” Prawie dwa razy więcej problemów na review.

Obraz bezpieczeństwa jest gorszy. Kod generowany przez AI był 2.74x bardziej podatny na wprowadzenie luk cross-site scripting (XSS). 1.91x częściej wprowadzał insecure direct object references. 1.88x częściej miał nieprawidłową obsługę haseł. 1.82x częściej implementował niebezpieczną deserializację.

Veracode przetestował ponad 100 dużych modeli językowych w Java, Pythonie, C# i JavaScript. 45% wygenerowanych próbek kodu oblało podstawowe testy bezpieczeństwa. Cross-site scripting miał 86% wskaźnik porażek. Java wypadła najgorzej - 72% wskaźnik porażek bezpieczeństwa.

Te liczby nie opisują problemu jakości, który lepsze modele naprawią w następnym kwartale. Opisują strukturalną zmianę w tym, gdzie żyje praca. Generowanie kodu stało się tanie. Ewaluacja kodu stała się droga. I ten koszt spada całkowicie na recenzenta.

Dlaczego kod AI jest trudniejszy do recenzji

W polskich zespołach programistycznych - zwłaszcza tych ze średnimi i mniejszymi firmami - code review często opiera się na zaufaniu osobistym. Znasz Wojtka od trzech lat. Wiesz że pisze solidny kod, ale ma słaby punkt w obsłudze wyjątków. Znasz Asię, która zawsze pokrywa edge case’y ale pisze za długie metody. To nieformalna wiedza, która przyspiesza każde review.

AI code nie ma odcisków palców. Każdy PR wygląda jakby napisał go kompetentny obcy. Powierzchnia jest czysta. Zmienne dobrze nazwane. Struktura wygląda rozsądnie. To jest pułapka.

Kod AI pada na krawędziach, nie w centrum. Główna ścieżka logiczna zazwyczaj działa. Testy, które developer napisał, zazwyczaj przechodzą. Ale warunki brzegowe - null input, równoległy dostęp, zdeformowany payload od klienta, przeciwko któremu nikt nie testował - to tam kod AI się sypie. Te awarie są niewidoczne w normalnym review, bo nie wyglądają źle. Wyglądają jak kod, który po prostu… nie obsługuje jakiegoś przypadku.

Kod AI wygląda wiarygodnie. To najgłębszy problem. Zhallucynowane wywołanie API wygląda dokładnie jak prawdziwe. Podatność na SQL injection wygląda jak każde inne zapytanie do bazy. Race condition, który ujawnia się tylko pod obciążeniem, wygląda jak czysty kod współbieżny. Wizualna pozorność poprawności jest niemal idealna. Znalezienie prawdziwych bugów wymaga uruchomienia kodu w głowie, nie tylko przeczytania go.

Kod AI nie ma sygnałów intencji. Kiedy człowiek pisze obejście, zazwyczaj zostawia ślad - komentarz, TODO, nazwę zmiennej, która sygnalizuje świadomość hacka. AI nie zostawia takich śladów. Generuje coś, co wygląda jak zamierzone rozwiązanie, nawet gdy to obejście czegoś, czego nie zrozumiał. Nie odróżniasz “to jest właściwe podejście” od “to jedyne podejście, jakie model potrafił wygenerować” po samym kodzie.

Addy Osmani, engineering lead w Google, podsumował tę zmianę precyzyjnie: “AI może napisać pierwszą wersję, ale nigdy nie outsource’uj czytania. Brak ludzkiego review oznacza brak wiarygodnego tropu od zachowania do intencji.”

Rachunek podatkowy

Oto ile kosztuje podatek review.

Czas. Benchmark Opsera 2026 wykazał, że PR-y generowane przez AI czekają 4.6x dłużej na review w porównaniu z pisanymi przez ludzi. Nie dlatego, że recenzenci są leniwi. Dlatego, że review trwa dłużej i jest ich więcej. Faros AI zmierzył 91% wzrost czasu review PR-ów wśród 10 000+ developerów. PR-y są 154% większe. Każda linijka wymaga więcej uwagi, bo nie możesz polegać na rozpoznawaniu patternów.

Obciążenie poznawcze. Każdy PR wygenerowany przez AI to cold review. Nie wnosisz żadnego modelu tego, kto to napisał i jakich błędów się spodziewać. To wymusza myślenie System 2 - powolne, świadome, wysiłkowe przetwarzanie - dla każdej linijki. Ludzkie PR-y pozwalają używać Systemu 1 - szybkiego, opartego na patternach skanowania - dla znanych części i rezerwować System 2 dla nowych. Z kodem AI nie ma znanych części. Wszystko jest nowe. Cały dzień.

To ten sam mechanizm, który stoi za AI brain fry. Badanie BCG wykazało, że nadzór nad outputem AI - ewaluacja, weryfikacja, integracja - powodował 14% więcej wysiłku mentalnego, 12% więcej zmęczenia psychicznego i 19% więcej przeciążenia informacyjnego. Recenzowanie kodu AI to nadzór AI w najczystszej formie.

Jakość. Pod obciążeniem poznawczym jakość review spada. Zaczynasz prześlizgiwać się. Zaczynasz ufać testom zamiast czytać logikę. Zaczynasz zatwierdzać PR-y z “lgtm” bo już recenzowałeś siedem innych dzisiaj i twoja pojemność na dokładną ewaluację się skończyła. Ślepa strefa managera wchodzi w grę: zmergowane PR-y idą w górę. Bug rate też. Nikt ich nie łączy.

Bezpieczeństwo. 2.74x wzrost XSS to nie teoria. Georgia Tech’s Vibe Security Radar śledził 35 nowych CVE w samym marcu 2026, które były bezpośrednim wynikiem kodu generowanego przez AI. Wzrost z 6 w styczniu i 15 w lutym. Linia trendu przyspiesza. Każde CVE zaczęło się jako PR, który ktoś zatwierdził.

5-warstwowy framework review

Standardowe checklisty code review zostały zbudowane dla kodu pisanego przez ludzi. Sprawdzają styl, logikę, wydajność i oczywiste bugi. Dla kodu generowanego przez AI potrzebujesz dodatkowych warstw, bo tryby awarii są inne.

Warstwa 1: Weryfikacja intencji

Zanim przeczytasz choćby jedną linijkę kodu, odpowiedz na pytanie: Co ten kod ma robić?

Przeczytaj ticket. Przeczytaj opis PR-a. Zbuduj mentalny model oczekiwanego zachowania. Potem przeczytaj kod i sprawdź, czy pasuje.

Brzmi oczywiste. Nie jest. Z ludzkimi PR-ami często znasz intencje, bo uczestniczyłeś w dyskusji projektowej albo znasz obszar feature’a. Z PR-ami AI developer mógł promptować o rozwiązanie bez pełnego określenia ograniczeń. Kod może rozwiązywać odrobinę inny problem niż ten, który opisuje ticket.

Weryfikacja intencji łapie klasę bugów, w których kod działa idealnie, ale robi błędną rzecz.

Warstwa 2: Polowanie na edge case’y

Modele AI są trenowane na happy paths. Najczęstsze patterny w danych treningowych to te, w których inputy są poprawne, połączenia stabilne i nic nie idzie źle. Kod generowany przez AI odzwierciedla ten bias.

Dla każdej funkcji lub endpointu zapytaj:

  • Co się dzieje z null lub pustym inputem?
  • Co się dzieje przy równoczesnym dostępie?
  • Co się dzieje kiedy serwis zewnętrzny nie odpowiada?
  • Co się dzieje z inputem, który jest technicznie poprawny ale złośliwy (SQL injection, payloady XSS, zbyt duże requesty)?
  • Co się dzieje kiedy ta funkcja jest wywołana w kolejności, której autor nie przewidział?

To warstwa, w której żyje 2.74x luka XSS. Kod obsługuje normalne requesty poprawnie. Nie obsługuje requesta, który zawiera <script>alert('xss')</script> w polu nazwa użytkownika.

Warstwa 3: Detekcja halucynacji

Modele AI pewnie generują wywołania API, które nie istnieją, używają zdeprecjonowanych metod, referują paczki, które nigdy nie zostały zaimportowane, i stosują patterny z jednego frameworka do innego. Te halucynacje wyglądają syntaktycznie poprawnie.

Sprawdź:

  • Czy wszystkie zaimportowane paczki istnieją i są we właściwych wersjach?
  • Czy wszystkie wywołania API pasują do faktycznej sygnatury? (Nie do tego jak powinna wyglądać - do tego jak faktycznie wygląda.)
  • Czy są metody wywoływane na obiekcie, które nie istnieją?
  • Czy pattern obsługi błędów jest poprawny dla tej konkretnej biblioteki, czy to generyczny pattern, który model pożyczył z innej biblioteki?

Ta warstwa wymaga wiedzy domenowej. Musisz znać swój codebase i swoje zależności. Nie da się jej zautomatyzować.

Warstwa 4: Świadomość integracji

AI generuje kod w izolacji. Nie wie, że twój serwis ma rate limiter, że pula połączeń do bazy jest wymiarowana na 50 równoczesnych zapytań, że twój framework logowania oczekuje specyficznego formatu, albo że serwis innego zespołu zwraca błędy w niestandardowy sposób.

Sprawdź:

  • Czy ten kod respektuje istniejące patterny w codebase? Nie “czy pattern jest rozsądny” ale “czy to ten sam pattern, którego używamy wszędzie indziej?”
  • Czy to się skaluje? AI często generuje rozwiązania, które działają przy 10 requestach na sekundę ale padają przy 10 000.
  • Czy obsługa błędów integruje się z twoim monitoringiem i alertingiem? Czy będziesz wiedział, kiedy ten kod pada na produkcji?
  • Czy są efekty uboczne, które wpływają na inne serwisy albo zespoły?

Warstwa 5: Weryfikacja behawioralna

To warstwa, którą większość checklist pomija całkowicie.

Uruchom kod. Nie tylko testy. Uruchom faktyczny flow, który użytkownik wywoła. Otwórz przeglądarkę. Wyślij formularz. Sprawdź odpowiedź. Zweryfikuj stan bazy danych. To jedyny wiarygodny sposób potwierdzenia, że kod robi to, co mówi ticket.

Potem uruchom adversarialny flow. Wyślij formularz ze złymi danymi. Zrób request dwa razy szybko po sobie. Odłącz sieć w trakcie operacji. To tutaj edge case’y z Warstwy 2 stają się realne.

Weryfikacja behawioralna jest powolna. Jest też warstwą, w której łapie się bugi o największym wpływie. Bugi, które przechodzą statyczne review, przechodzą testy, przechodzą CI, i padają na produkcji.

Jak uczynić podatek znośnym

Podatek review jest realny i nie zniknie. Ale możesz obniżyć stawkę.

Mniejsze PR-y z zakresu AI. Jeśli developer generuje 500 linii kodu AI, recenzja jest wyczerpująca. Jeśli generuje 50 linii na PR z jasnym zakresem, każde review jest ogarnialne. Ograniczenie to nie “używaj mniej AI.” To “submituj mniejsze jednostki.”

AI jako recenzent pierwszego przejścia. Używaj narzędzi AI review (CodeRabbit, Codacy itp.) do screeningu Warstwy 1 - styl, oczywiste problemy, znane patterny podatności. To uwalnia ludzkich recenzentów na Warstwy 3-5 gdzie ludzki osąd jest niezastąpiony. Osmani opisuje to jako “cykl pozytywny, w którym AI pisze kod, zautomatyzowane narzędzia łapią problemy, AI je naprawia” - ale człowiek nadal podpisuje się pod całością.

Rotuj obciążenie review. Jeśli jedna osoba recenzuje wszystkie PR-y generowane przez AI, będzie brain-fry’owana do czwartku. Rozłóż odpowiedzialność za review. Śledź godziny review na osobę, nie tylko liczbę zrecenzowanych PR-ów.

Ogranicz czas review AI. Ustaw twardy limit: 45 minut na review PR-a AI. Jeśli nie możesz skończyć review w tym czasie, PR jest za duży. Odeślij do podziału.

Paruj na pierwszym review. Kiedy członek zespołu zaczyna generować znaczące ilości kodu AI, sparuj się z nim na pierwszych kilku review. Pokaż mu czego szukasz. Buduj jego mięsień review. To inwestycja, która się kumuluje - tworzy więcej recenzentów zamiast koncentrować obciążenie.

Umiejętność, która ma znaczenie

Generowanie kodu staje się towarem. Modele są lepsze co kwartał. Luka między tym, co junior i senior mogą wyprodukować z pomocą AI, się zwęża.

Ale luka między tym, co junior i senior mogą ocenić, się poszerza. Ewaluacja wymaga rozumienia dlaczego kod działa, nie tylko że działa. Wymaga znajomości codebase’u, zależności, środowiska deploymentowego, edge case’ów, które produkcja obnaży. Nic z tego nie staje się łatwiejsze z AI. Wszystko staje się ważniejsze.

Developerzy, którzy inwestują w umiejętność review - którzy budują modele mentalne, uczą się patternów awarii, rozwijają instynkt na to gdzie AI się myli - będą tymi, którzy dostarczają oprogramowanie które faktycznie działa. Ci, którzy tego nie robią, będą dostarczać szybciej i łamać więcej.

Podatek review nie jest opcjonalny. Już go płacisz. Pytanie brzmi, czy płacisz go świadomie, z frameworkiem, czy nieświadomie, z incydentami na produkcji.

Framework OnTilt mierzy wzorce, które bezpośrednio mapują się na zmęczenie review: utrzymujące się wysokie obciążenie poznawcze, erozja nawyków weryfikacji i tendencja do ufania outputowi, bo sprawdzanie go czuje się jak za dużo pracy. Te wzorce pojawiają się w wymiarach “Negatywne konsekwencje” i “Utrata kontroli.”

Zrób autorefleksję - 14 pytań, 3 minuty, anonimowo. Nie zmniejszy podatku review. Pokaże ci, czy już płacisz więcej niż myślisz.

Źródła:

  • JetBrains. (2025). “The State of Developer Ecosystem 2025.” 24 534 developerów, 194 krajów. 47% stawia review kodu AI jako umiejętność #1. devecosystem-2025.jetbrains.com
  • CodeRabbit. (2026). “State of AI vs Human Code Generation Report.” 470 PR-ów z GitHuba. 1.7x więcej problemów, 2.74x więcej XSS, 1.91x więcej insecure object refs. coderabbit.ai
  • Veracode. (2025). “GenAI Code Security Report.” 100+ LLM-ów przetestowanych. 45% oblało testy bezpieczeństwa; XSS: 86% wskaźnik porażek; Java: 72% wskaźnik porażek. veracode.com
  • Opsera. (2026). “AI Coding Impact 2026 Benchmark Report.” 4.6x dłuższe oczekiwanie na review PR-ów AI; 32.7% vs. 84.4% wskaźnik akceptacji. opsera.ai
  • Faros AI. (2026). “The AI Productivity Paradox Research Report.” 10 000+ devów, 91% dłuższy czas review, 154% większe PR-y. faros.ai
  • Osmani, A. (2025-2026). “Code Review in the Age of AI” i “Treat AI-Generated Code as a Draft.” Elevate Substack. addyo.substack.com
  • Kellerman, G.R. i Kropp, M. (2026). Badanie “AI Brain Fry.” BCG/HBR. 14% więcej wysiłku mentalnego z nadzoru AI. Fortune
  • Georgia Tech School of Cybersecurity and Privacy. (2025-2026). “Vibe Security Radar.” 35 CVE z kodu AI w marcu 2026. gatech.edu

OnTilt to projekt badawczy analizujący wzorce behawioralne w pracy z AI. Quiz to narzędzie autorefleksji, nie instrument diagnostyczny. Więcej na stronie O projekcie.