Przegląd kodu z użyciem AI potrzebuje sprzeciwu, nie konsensusu

adamsreview opisuje sześciopoleceniowy przepływ przeglądu kodu z równoległymi perspektywami oceny, bramkami walidacji, przejściem z człowiekiem, partnerskim przeglądem Codex oraz pętlą poprawek, która ponownie przegląda zmiany przed commitem.¹

Ten projekt wskazuje prawdziwą granicę przeglądu kodu z użyciem AI. Lepszy przegląd nie wynika z kolejnego strumienia komentarzy bota. Lepszy przegląd wynika z niezależnych recenzentów, którzy się nie zgadzają, zachowują ten spór, weryfikują twierdzenie i przekazują ocenę człowiekowi-recenzentowi, zanim projekt potraktuje ustalenie jako blokujące.

TL;DR

Przegląd kodu z użyciem AI powinien optymalizować zdyscyplinowany sprzeciw, a nie konsensus. Użyteczny system przeglądu przydziela niezależne perspektywy, deduplikuje ustalenia, weryfikuje każde twierdzenie, oddziela potwierdzone błędy od spraw wymagających ludzkiej oceny i pozostawia człowieka recenzentem odpowiedzialnym za decyzję. Konsensus może ukrywać rzadkie, ale ważne ustalenia. Pakiet przeglądu powinien zachowywać twierdzenia mniejszościowe, dopóki dowody ich nie obalą, a potem śledzić poprawkę i wynik ponownego przeglądu.

Najważniejsze wnioski

Dla liderów inżynierii: - Traktujcie przegląd AI jako przepływ dowodów, a nie system głosowania. - Pozostawcie ludziom uprawnienia do scalania, nawet gdy agenci znajdują prawdziwe błędy.

Dla twórców agentów: - Przydzielajcie niezależne perspektywy przeglądu z różnymi mandatami: poprawność, bezpieczeństwo, testy, wpływ na użytkownika, utrzymywalność, zachowanie w środowisku wykonawczym i ryzyko wydania. - Zachowujcie ustalenia mniejszościowe jako ustrukturyzowane twierdzenia, dopóki walidacja ich nie obali.

Dla recenzentów kodu: - Wymagajcie dowodów, kroków odtworzenia, objętych plików, wyników walidatora, stanu decyzji człowieka i weryfikacji poprawki. - Odrzucajcie systemy przeglądu, które zamieniają zgodność opinii w pewność bez udowodnienia samego twierdzenia.

Dlaczego przegląd kodu z użyciem AI potrzebuje sprzeciwu?

Przegląd kodu zawodzi po cichu, gdy każdy recenzent szuka tej samej klasy defektów.

Przegląd jednoagentowy tworzy jeden kształt porażki. Model skanuje diff, generuje prawdopodobnie brzmiące komentarze i pomija wszystko, co wypada poza jego uwagę. Przegląd wieloagentowy może poprawić ten kształt tylko wtedy, gdy agenci pozostają niezależni. Jeśli pięciu agentów czyta to samo polecenie wejściowe, dziedziczy te same priorytety i zapada się w to samo podsumowanie, system kupił jedynie powtórzenie.

Sprzeciw zmienia powierzchnię przeglądu. Recenzent bezpieczeństwa może zakwestionować przepływ żądania, który recenzent poprawności akceptuje. Recenzent testów może wskazać brak pokrycia regresji po tym, jak recenzent produktu zaakceptuje zachowanie. Recenzent środowiska wykonawczego może odrzucić implementację, która wygląda czysto w kodzie, ale zawodzi pod ograniczeniami wdrożenia.

Ustalenie mniejszościowe ma znaczenie, bo poważne błędy często zaczynają się jako samotne zastrzeżenia. Wynik konsensusu może pogrzebać takie zastrzeżenie. Dobry przepływ przeglądu utrzymuje je przy życiu wystarczająco długo, by potwierdzić albo obalić twierdzenie.

Czego powinni szukać niezależni recenzenci?

Niezależni recenzenci potrzebują odrębnych mandatów, a nie odrębnych nazw.

Lista perspektyw powinna zmieniać się zależnie od repozytorium. System płatności potrzebuje perspektyw oszustw i uzgadniania. Kompilator potrzebuje perspektyw poprawności formalnej, diagnostyki i wydajności. System publikacji potrzebuje perspektyw cytowań, SEO, tłumaczeń i cache.

Mechanizm pozostaje stabilny: każda perspektywa wytwarza twierdzenie, nie werdykt.

Dlaczego konsensus zawodzi jako sygnał przeglądu?

Konsensus odpowiada na niewłaściwe pytanie.

Głosowanie większościowe pyta, czy wielu recenzentów się zgadza. Przegląd kodu musi wiedzieć, czy twierdzenie przetrwa kontakt z kodem, testami, środowiskiem wykonawczym i polityką projektu.

Zgodność może oznaczać, że ustalenie jest oczywiste. Zgodność może też oznaczać, że każdy recenzent miał ten sam martwy punkt. Niezgoda może oznaczać szum. Niezgoda może też oznaczać, że jeden recenzent znalazł prawdziwy błąd.

Lepszą metryką jest stan twierdzenia:

Ta maszyna stanów wygrywa z konsensusem, bo traktuje niezgodę jako inwentarz dowodów. Przepływ może zamykać szumne ustalenia bez ich wymazywania i może promować samotne ustalenia, gdy walidacja potwierdzi defekt.

Co robi silny przepływ przeglądu AI?

Silny przepływ przeglądu kodu z użyciem AI działa etapami.

1. Wykrywaj niezależnie. Perspektywy przeglądu sprawdzają diff bez oglądania wniosków innych.
2. Deduplikuj twierdzenia. System grupuje równoważne ustalenia bez spłaszczania odrębnych dowodów.
3. Waliduj tanio. Szybkie kontrole wyłapują nietrafione twierdzenia: istnienie pliku, osiągalność zmienionych linii, obecność testów, błędy typów i oczywiście nieaktualny kontekst.
4. Waliduj głęboko. Twierdzenia o dużym wpływie dostają wolniejszy przegląd: odtworzenie, czytanie śladu, ukierunkowane testy, rozumowanie o bezpieczeństwie albo krytykę drugiego modelu.
5. Klasyfikuj stan. Przepływ oznacza każde ustalenie jako potwierdzone, obalone, manualne, tylko raport albo poniżej bramki.
6. Przeprowadź człowieka przez niepewność. Recenzent rozstrzyga oceny, promuje ważne twierdzenia i odrzuca pracę o niskiej wartości.
7. Naprawiaj grupami. Powiązane ustalenia poruszają się razem, żeby system nie nakładał sprzecznych łatek.
8. Ponownie przeglądaj poprawki. Przepływ jeszcze raz sprawdza zmieniony kod i wycofuje regresje przed commitem.
9. Napisz pakiet. Końcowy artefakt zapisuje ustalenia, dowody, decyzje, testy, commity i nierozwiązane luki.

adamsreview daje konkretny przykład takiego kształtu. README opisuje do siedmiu równoległych perspektyw subagentów, deduplikację, walidację od taniej do głębokiej, opcjonalny całościowy przegląd, partnerski przegląd Codex, wstrzykiwanie zewnętrznych ustaleń, przejście przez niepewne ustalenia i pętlę poprawek, która ponownie przegląda oraz wycofuje regresje przed commitowaniem zachowanych poprawek.¹ README oznacza też twierdzenie o wydajności jako anegdotyczne, co ma znaczenie. Traktuj projekt jako użyteczny dowód projektowy, nie jako benchmark.

Jak powinno wyglądać ustalenie z przeglądu AI?

Użyteczne ustalenie potrzebuje wystarczającej struktury, żeby inny recenzent, agent albo zadanie CI mogło je później sprawdzić.

id: SEC-003
lens: security
claim: "Nowy endpoint webhooka przyjmuje niepodpisane ponowione żądania."
severity: high
affected_files:
  - app/routes/webhooks.py
evidence:
  - "Handler czyta JSON przed walidacją podpisu."
  - "Zestaw testów obejmuje poprawne podpisy, ale nie brakujące podpisy."
validator:
  cheap_check: pass
  deep_check: manual
  reason: "Osiągalna ścieżka potwierdzona; wpływ exploita wymaga oceny właściciela."
human_decision:
  status: promoted
  reviewer: "recenzent odpowiedzialny za decyzję"
fix_group: webhook-auth
post_fix_review:
  status: pending
remaining_gap: "Potrzebny test replay dla zniekształconego payloadu ponowienia."

Dokładne pola mogą się zmienić. Dyscyplina nie powinna. Ustalenie nazywa twierdzenie, dowody, wynik walidatora, decyzję człowieka, grupę poprawek, stan po poprawce i pozostałą lukę. Komentarz mówiący „sprawdź auth webhooka” nie może wspierać odpowiedzialnej decyzji o scaleniu. Ustrukturyzowane ustalenie może.

Dlaczego człowiek musi pozostać recenzentem odpowiedzialnym za decyzję?

Model przeglądu GitHub daje recenzentom trzy wysokopoziomowe wyniki przed scaleniem: komentarz, zatwierdzenie albo żądanie zmian.² Przegląd AI może te wyniki zasilać. Nie powinien ich po cichu zastępować.

Projekt polityki LLM dla Rust jasno wyznacza tę granicę. Według stanu na 18 maja 2026 r. polityka pozostaje otwartym pull requestem, a nie przyjętą polityką Rust.³ Projekt dopuszcza prywatny przegląd LLM, ale zakazuje traktowania przeglądu LLM jako wystarczającego do scalenia albo odrzucenia zmiany. Mówi też, że boty przeglądowe muszą pozostać doradcze, komentarze botów nie mogą same blokować, a ludzcy recenzenci muszą wyraźnie zatwierdzić komentarze, które chcą mieć zaadresowane.⁴

Ta granica chroni odpowiedzialność. Bot może odkryć prawdziwy błąd. Bot może też tworzyć nieaktualne komentarze, płytkie zastrzeżenia stylistyczne albo pewne siebie fałszywe alarmy. Recenzent odpowiedzialny za decyzję odpowiada za zablokowanie, scalenie, zażądanie zmian albo zignorowanie twierdzenia.

Rola człowieka powinna być widoczna w artefakcie:

Przegląd AI zdobywa zaufanie, gdy wyostrza ludzki przegląd. Traci je, gdy ukrywa autorytet w werdykcie bota.

Co powinien zawierać pakiet przeglądu?

Pakiet przeglądu zmienia uruchomienie przeglądu w trwały obiekt decyzyjny.

Minimalne pola:

Pakiet nie powinien czytać się jak transkrypt. Transkrypt pokazuje wszystko, co się stało. Pakiet przeglądu pokazuje to, czego odpowiedzialny recenzent potrzebuje do decyzji.

Pakiet zachowuje też pamięć instytucjonalną. Gdy ten sam fałszywy alarm wróci w następnym tygodniu, zespół może zobaczyć, dlaczego przepadł. Gdy ustalenie mniejszościowe zamieni się w błąd produkcyjny, zespół może prześledzić, jak twierdzenie przeszło przez system.

Co badania mówią o porażkach agentowych PR-ów?

Ten wzorzec porażki wykracza poza boty przeglądowe.

Artykuł MSR 2026 przeanalizował 33 000 pull requestów napisanych przez agentów na GitHubie i wykazał, że zadania dokumentacyjne, CI oraz aktualizacji buildów osiągały najwyższy sukces scalenia, podczas gdy zadania wydajnościowe i naprawy błędów wypadały najgorzej.⁵ Autorzy ustalili też, że niescalone PR-y częściej dotykały większej liczby plików, wprowadzały większe zmiany i oblewały CI. Ich analiza jakościowa wskazała wzorce odrzucenia, takie jak słabe zaangażowanie recenzentów, zduplikowane PR-y, niechciane implementacje i niedopasowanie agenta.⁵

Te ustalenia wspierają praktyczną zasadę: przegląd kodu z użyciem AI nie powinien pytać wyłącznie, czy diff ma błędy. Powinien pytać, czy przepływ pracy agenta daje maintainerom obiekt nadający się do przeglądu. Duże, niedopasowane, słabo przejrzane PR-y potrzebują lepszych pakietów przeglądu, węższych granic commitów i silniejszych punktów ludzkiej decyzji.

Jak zespoły powinny zacząć?

Zacznijcie od małego systemu przeglądu, który daje lepsze decyzje, a nie więcej komentarzy.

1. Wybierzcie dwie albo trzy perspektywy dla najbardziej ryzykownych ścieżek kodu.
2. Wymagajcie, by każde ustalenie zawierało twierdzenie, dowody, objęty plik i wynik walidacji.
3. Zachowujcie ustalenia mniejszościowe, dopóki walidator ich nie obali.
4. Kierujcie twierdzenia manualne do ludzkiego recenzenta, zamiast ukrywać je pod wynikiem punktowym.
5. Śledźcie fałszywe alarmy, żeby system uczył się, co zespół odrzuca.
6. Ponownie przeglądajcie poprawki przed commitem.
7. Dołączajcie pakiet do PR-a.

Nie zaczynajcie od automatycznego nakładania łatek. Zacznijcie od godnych zaufania artefaktów przeglądu. Gdy przepływ ustaleń zdobędzie zaufanie, mogą pojawić się wąskie ścieżki automatycznych poprawek: mechaniczne testy, oczywiste kontrole null, korekty na poziomie literówek albo poprawki wypromowane przez człowieka podczas przejścia.

Celem nie jest sprawienie, by przegląd kodu wydawał się autonomiczny. Celem jest sprawienie, by trudniej było oszukać ludzki przegląd.

Krótkie podsumowanie

Przegląd kodu z użyciem AI potrzebuje niezależnego sprzeciwu, bo sama zgodność nie może udowodnić ustalenia. Silny system rozdziela recenzentów według mandatów, zachowuje twierdzenia mniejszościowe, waliduje dowody, kieruje niepewność do ludzi i ponownie przegląda poprawki przed commitem. Kontrakt przeglądu GitHub nadal kończy się ludzkimi stanami przeglądu.² Projekt polityki Rust utrzymuje przegląd LLM jako doradczy, dopóki człowiek nie zatwierdzi twierdzenia.⁴ adamsreview pokazuje jeden obecny kształt przepływu z perspektywami, bramkami, przejściem i ponownym przeglądem poprawek.¹

Zwycięskim artefaktem nie jest komentarz bota. Zwycięskim artefaktem jest pakiet przeglądu, który pozwala człowiekowi zdecydować odpowiedzialnie.

Częste pytania

Czym jest przegląd kodu z użyciem AI?

Przegląd kodu z użyciem AI wykorzystuje modele językowe albo agentów do sprawdzania zmian w kodzie, identyfikowania możliwych defektów, wyjaśniania ryzyk, sugerowania poprawek albo przygotowywania artefaktów przeglądu dla ludzi. Poważny system powinien dostarczać dowody i stan dla każdego ustalenia, zamiast wyłącznie publikować komentarze.

Czy przegląd kodu z użyciem AI powinien korzystać z wielu agentów?

Wielu agentów pomaga wtedy, gdy każdy agent ma niezależny mandat, a przepływ zachowuje niezgodę. Wielu agentów wnosi niewiele, gdy każdy widzi to samo polecenie wejściowe, tworzy to samo podsumowanie i zapada się w wynik konsensusu.

Dlaczego sprzeciw jest lepszy niż konsensus w przeglądzie kodu z użyciem AI?

Sprzeciw utrzymuje rzadkie ustalenia widoczne, dopóki dowody ich nie potwierdzą albo nie obalą. Konsensus może ukryć poważne ustalenie mniejszościowe, gdy większość recenzentów przegapi ten sam przypadek brzegowy. Przegląd kodu potrzebuje zwalidowanych twierdzeń, a nie tylko zgodności.

Czy recenzent AI może zablokować pull request?

Zespoły powinny pozostawić władzę blokowania ludziom. Projekt polityki LLM dla Rust mówi, że przegląd LLM musi pozostać doradczy, a recenzenci muszą wyraźnie zatwierdzić komentarze LLM, zanim zablokują PR.⁴ Ta zasada pasuje do szerszej zasady odpowiedzialności: człowiek-recenzent odpowiada za decyzję o scaleniu.

Co powinien zawierać pakiet przeglądu AI?

Pakiet przeglądu AI powinien zawierać zakres, perspektywy, ustalenia, dowody, wyniki walidacji, decyzje człowieka, grupy poprawek, wyniki ponownego przeglądu, dowód wydania, gdy jest istotny, oraz nierozwiązane luki. Pakiet powinien czynić decyzje przeglądowe audytowalnymi bez zmuszania czytelnika do czytania pełnego transkryptu.

Kiedy zespoły powinny pozwalać na automatyczne poprawki?

Zespoły powinny pozwalać na automatyczne poprawki dopiero wtedy, gdy przepływ ustaleń zdobędzie zaufanie. Zacznijcie od mechanicznych, niskoryzykownych poprawek albo ustaleń, które człowiek promuje podczas przeglądu. Każda automatyczna poprawka potrzebuje przeglądu po poprawce i ścieżki wycofania.

Źródła