Code review i wdrożenie

Bezpieczne wdrażanie kodu pisanego przez agentów opiera się na pięciu mechanizmach kontroli budowanych po kolei: pakiecie dowodów wymuszanym przez CI w każdym pull requeście, kierowaniu zmian według klasy ryzyka przez code ownerów, agencie review, który robi triaż przed decyzją człowieka, bramkach pipeline’u, których agent nie może osłabić, oraz progressive delivery z automatycznym rollbackiem. Nikt nie czyta każdej linii każdego diffa; kod czyta człowiek tylko przy zmianach klasy high.

Ta sekcja jest dla programistów, którzy merge’ują to, co napisali ich agenci, i dla tech leadów odpowiedzialnych za zasady code review. Gdy agenci otwierają więcej pull requestów, niż zespół zdąży przeczytać, albo blokujesz kolejkę, albo zatwierdzasz na wiarę. Strony poniżej zastępują obie drogi dowodami, na które możesz się powołać.

Który przewodnik po code review i wdrożeniu pasuje do twojego problemu?

Twoja sytuacja	Zacznij od
Opisy PR-ów agentów nie zawierają niczego sprawdzalnego	Pakiet dowodów
Kolejka code review jest wąskim gardłem	Code review PR-a agenta
Chcesz osobnych agentów review do różnych obszarów	Warstwowe review pull requestów
PR-y krążą między agentem a recenzentem	Ograniczona pętla review-fix
Agent edytuje CI albo pipeline działa wolno	Automatyzacja pipeline’ów
Merge’ujesz zmiany, których nikt nie przeczytał linia po linii	Progressive delivery
Od miesięcy nikt nie robił rollbacku produkcji	Przećwiczony rollback
Musisz ustalić, kto zatwierdza zmiany na produkcji	Akceptacja produkcji
Agent pisze Dockerfile’e, manifesty albo Terraform	Konteneryzacja i infrastruktura jako kod

Ta sekcja następuje po testowaniu i przekazuje zmianę eksploatacji, gdy ta trafi na produkcję.

W jakiej kolejności budować ścieżkę wdrożenia?

1. Wymagaj pakietu dowodów w każdym pull requeście. Pakiet przypisuje każde kryterium akceptacji do checku, który się wykonał, i deklaruje klasę ryzyka; CI odrzuca pull request z niekompletnym pakietem. Zobacz pakiet dowodów.
2. Kieruj zmiany według klasy ryzyka przez CODEOWNERS. Zmiany low i standard są zatwierdzane na podstawie pakietu; zmiany high (uwierzytelnianie, pieniądze, schemat, migracje, poluzowany test) czyta wskazana osoba. Zobacz politykę klas ryzyka.
3. Uruchom agenta review, zanim zmianę zobaczy człowiek. Agent raportuje według listy kontrolnej z repozytorium; potem człowiek przeprowadza sześciokrokowy triaż z code review PR-a agenta.
4. Trzymaj pipeline poza zasięgiem agenta. Wymagaj checków i przypisz code ownerów do .github/workflows/; zobacz automatyzację pipeline’ów i ochronę wyroczni.
5. Wdrażaj za flagą albo przez canary z automatycznym rollbackiem i przećwicz rollback. Zobacz progressive delivery.

Gdzie działa agent review w każdym z narzędzi?

Pakiet dowodów, triaż i klasy ryzyka są wszędzie takie same; różni się tylko miejsce działania agenta review.

Claude Code

W sesji uruchom /code-review. W CI uruchom swoją listę kontrolną przez claude -p z allowlistą narzędzi tylko do odczytu. Dla zmian high polecenie claude ultrareview 482 uruchamia w chmurze wieloagentowe review pull requesta 482: trzy jednorazowe darmowe uruchomienia w planach Pro i Max, potem zwykle od 5 do 25 USD za każde. Nie działa w Bedrock, Google Cloud, Foundry ani przy Zero Data Retention. Zarządzana usługa Code Review (plany Team i Enterprise; ogólnie dostępna według Anthropic, sprawdzone 2026-10-16) czyta plik REVIEW.md z katalogu głównego repozytorium. Zobacz code review i wdrożenie z Claude Code.

Codex

codex exec review --base main -o review.md robi review gałęzi względem main i zapisuje uwagi do pliku (Codex CLI 0.157.1). Własną listę kontrolną przekaż jako prompt zamiast --base; tych dwóch opcji nie da się łączyć. Na GitHubie skomentuj pull request @codex review, a zasady review zapisz w AGENTS.md. Zobacz code review i wdrożenie z Codex.

Cursor

Bugbot sprawdza pull requesty pod kątem błędów, bezpieczeństwa i jakości kodu. PR Routing & Approval przydziela recenzentów według własności kodu i może zatwierdzać pull requesty niskiego ryzyka, które spełniają twoje reguły; niech jedną z nich będzie „żadna zmiana nie dotyka klasy high”. Zobacz code review i wdrożenie z Cursorem.

W CI gałąź poddawana review jest niezaufana

Job review, który wczytuje ustawienia agenta z gałęzi, uruchamia jej hooki i serwery MCP z sekretami joba. Nie wczytuj ustawień projektu z tego commita (--bare --setting-sources "" --strict-mcp-config dla claude -p) i trzymaj sekrety poza jobem. Pełny wzorzec opisuje strona agenci headless w CI.

Prompty do skopiowania: code review i wdrożenie

Zacznij od audytu: pokaże, które z pięciu mechanizmów twoje repozytorium już ma.

Prompt do skopiowania: audyt ścieżki wdrożenia w repozytorium

Audit how a change in this repository gets from a pull request to production.
Read only: do not edit files, open pull requests or run deploys.

Check for each control and cite the file and line that proves it exists:
1. Evidence: a pull request template that asks for acceptance criteria mapped
   to checks, a risk class and a rollback path; a CI job that fails when the
   description is incomplete.
2. Routing: .github/CODEOWNERS entries for auth, payments, database migrations,
   tests and .github/workflows/.
3. Review: a committed review checklist or REVIEW.md that a review agent runs.
4. Pipeline: checks required on main; any workflow that deploys without them.
5. Delivery: flag or canary config; a rollback that needs no new build.

Output a table: control, status (present, partial, missing), evidence, and the
smallest change that would close the gap. List the gaps in the order above.

Drugi prompt uruchom na gotowej gałęzi, zanim otworzysz pull request.

Prompt do skopiowania: czy ta gałąź może iść na produkcję?

Decide whether the changes on this branch against main are ready to ship.
Do not edit, commit, push or deploy.

1. Run the test, type-check and lint commands from package.json. Paste each
   command, its exit status and the commit SHA from git rev-parse HEAD.
2. List every behavior change as one sentence, and mark any the linked issue
   did not ask for.
3. List every changed test, snapshot, fixture, CI or lint file, and say whether
   it makes a check stricter, looser or neutral.
4. Propose a risk class: high if the diff touches auth, payments, schema,
   migrations or loosens a check; standard for other behavior changes; low
   for docs and copy.
5. Name the rollback: the flag to switch off, or the exact revert, and the
   metric and threshold that would trigger it.

End with SHIP, FIX FIRST (with the items), or NEEDS A CODE OWNER (with the
paths), and one sentence of reasoning.

Jak udowodnić, że zmianę można bezpiecznie wdrożyć?

Każdy mechanizm zostawia dowód wytworzony przez maszyny i ma wskazanego właściciela: check pakietu na ostatnim commicie, raport agenta review z notatkami z triażu, lekturę kodu przez code ownera przy zmianach high oraz metryki canary albo flagi w ustalonych wcześniej granicach. Kto zatwierdza który dowód, opisuje strona pakiet dowodów. Mierz odsetek błędów, które przeszły na produkcję, w podziale na klasy ryzyka, oraz odsetek pakietów, które przechodzą check za pierwszym razem; zobacz ramy metryk.

Co się psuje, gdy agenci wdrażają kod?

• Zielone checki pochodzą ze starszego commita. Naprawa: wymagaj SHA commita przy każdym wyniku; ufaj CI, nie agentowi.
• Agent luzuje test, żeby build przeszedł. Naprawa: przypisz code ownera do ścieżek testów i CI, a każdy poluzowany check klasyfikuj jako high.
• Każdy pull request jest eskalowany. Naprawa: zawęź wrażliwe ścieżki do kodu, w którym błąd jest kosztowny i wolno wykrywany.
• Rollback wymaga nowego buildu. Naprawa: wdrażaj za flagą albo przez canary, które da się przerwać w kilka sekund, i przećwicz to.
• Agent review zakopuje prawdziwy problem w uwagach o stylu. Naprawa: ogranicz go do uwag istotnych dla produkcji, według wagi.

Co dalej z code review i wdrożeniem?

Zacznij od pakietu dowodów, potem wprowadź triaż code review PR-a agenta. Jeśli twój zespół wciąż czyta każdy diff, zobacz jak pomóc zespołowi przestać czytać każdy diff i kolejkę code review, gdy pull requesty otwierają agenci.