Automatyzacja review PR — dowody przed akceptacją

Automatyzacja review PR ma ułatwiać ocenę zmiany, a nie produkować akceptacje. Dobry workflow najpierw uruchamia checki deterministyczne, potem prosi agenta o review względem zaakceptowanego zamiaru i ryzyk, zachowuje odtwarzalne dowody i kieruje wynik do nazwanej ludzkiej bramki. Właściwa liczba reviewerów AI to najmniejszy zestaw znajdujący użyteczne, niepowielone problemy.

Q9 · Bramki jakości Dowód na maksymalny wynik: checki deterministyczne, skupione review specyfikacji i ryzyka, odtwarzalne ustalenia, routing według ryzyka oraz nazwana ludzka bramka merge.

Użyj czterech warstw review

1. Udowodnij fakty mechaniczne. Uruchom formatowanie, typy, testy jednostkowe i integracyjne, kontrolę zależności, skan sekretów i checki polityki repo. To dowody pass/fail, nie opinie modelu.
2. Porównaj z zaakceptowanym zamiarem. Daj reviewerowi intent.md, spec.md, plan.md, diff i wyniki testów. Zapytaj, czy zmiana realizuje kontrakt i czy dowody pokrywają zachowanie najwyższego ryzyka.
3. Kieruj według ryzyka. Auth, uprawnienia, płatności, migracje, publiczne API, infrastruktura i dane wrażliwe dostają review specjalistyczne oraz ostrzejszą ludzką bramkę. Dokumentacja lub zmiany tylko w testach mogą mieć lżejszą ścieżkę.
4. Jawnie przypisz władzę. Znalezisko AI może blokować check tylko przez zrecenzowaną politykę. Nazwany człowiek zachowuje władzę merge tam, gdzie reguły repo wymagają osądu.

Claude Code może działać przez GitHub Actions, Cursor oferuje Bugbot, a Codex zapewnia code review. To warianty implementacji, a nie dowód, że trzy narzędzia są lepsze od jednego. Mierz precision, duplikaty, escaped defects, czas kolejki i wysiłek review we własnych repozytoriach.

Prompty do wklejenia

Zrecenzuj diff względem intent.md, spec.md i plan.md. Wypisz tylko materialne rozbieżności. Dla każdej podaj plik i linię, wpływ oraz reprodukcję albo brakujący test. Zwróć „brak materialnych ustaleń”, gdy dowody są wystarczające.

Sprawdź wyłącznie zmienione ścieżki auth, uprawnień, danych, migracji i rollbacku. Oddziel potwierdzone defekty od hipotez. Nie akceptuj ani nie merguj; przygotuj dowody dla nazwanego reviewera.

Uzgodnij wyniki checków deterministycznych i review. Usuń duplikaty, oznacz każde ustalenie jako odtworzone, prawdopodobne lub bez dowodu i wskaż regułę repo decydującą, czy blokuje merge.

Dowody akceptacyjne

• Każde blokujące ustalenie ma reprodukcję, nieudany check albo bezpośrednio wskazaną regułę.
• PR zapisuje zaakceptowany zamiar, dotknięte systemy i dane, odwracalność, wykonane polecenia i otwarte ryzyka.
• Ryzykowne zmiany trafiają do bramek specjalistycznych i ludzkich zdefiniowanych w polityce.
• Metryki odróżniają użyteczne znaleziska od szumu i mierzą czas do zaakceptowanej zmiany, nie liczbę komentarzy.
• Awaria lub brak reviewera AI daje jawny stan niepełnych dowodów; nigdy nie staje się milczącą akceptacją.

Wzorzec awarii: teatr reviewerów

Workflow zawodzi, gdy zespół wymaga kilku botów na każdym PR-ze, liczy komentarze jako pokrycie albo traktuje „looks good” od AI jako władzę. Ogranicz nakładających się reviewerów, użyj checków deterministycznych jako źródła faktów mechanicznych, wymagaj dowodów dla ustaleń modelu i kieruj osąd do osoby odpowiedzialnej za dany system.

Dalej: kontrola zmiany

Użyj Gates vs guardrails, by rozmieścić kontrole w całym cyklu, a potem AI w CI/CD, by uruchomić ograniczoną pętlę serwerową.

Q10 · Gates vs guardrails Rozmieść kontrole przed, podczas i po generowaniu.

Q13 · AI w CI/CD Uruchamiaj audytowalne agenty bez oddawania władzy merge i produkcji.