Code review podle rizika: jak ho nastavit v týmu s AI

Claude píše zhruba 90 % kódu v samotném Claude Code. Od června do září se přitom počet mergnutých PR zhruba zdvojnásobil a podíl těch, které se musely revertovat, klesl o více než 40 %. To všechno tvrdí tým Claude Code v příspěvku z 15. 10. 2026. Čísla jsou od Anthropicu a nikdo je nezávisle neověřil, příspěvek navíc neuvádí absolutní počty, jen procentní změnu. I tak je z něj dobře vidět, jak vypadá code review podle rizika — a co z něj můžeš převzít do vlastního týmu, i když nemáš žádný Anthropic tarif.

Hlavní myšlenka je prostá: když kód přibývá několikanásobně rychleji, nemůže se na každý PR dívat dva lidé. Review se proto nepřidává na počet lidí, ale na riziko změny. Tenhle článek ti ukáže, jak vrstvy vypadají, jak si je postavit po svém a kde se to nejčastěji pokazí.

01Proč klasické review při AI kódu nestačí

Když agent napíše za den desítky PR, tradiční pravidlo „každý PR schvalují dva lidé“ se zlomí na dvou místech. Lidé se stanou úzkým hrdlem a začnou schvalovat bez čtení. Nebo review úplně obejdou. Obojí vede k revertům.

Tým Claude Code to řeší opačně: neptá se, kolik lidí musí PR schválit, ale co by se stalo, kdyby v něm byla chyba. Dokumentace, texty v UI nebo funkce za feature flagem jsou jiná liga než automatický updater, billing nebo CI workflow. Podobný problém řešíme i v textu o tom, jak přežít záplavu AI kódu, a v návodu jak reviewovat AI kód. Nový je tady důraz na to, že hloubku kontroly určuje klasifikace rizika, ne nálada reviewera.

Jako pojistku sleduje tým revert rate a incidenty. Pokud rostou, znamená to jediné: lidský čas se jen přesunul jinam, ale neušetřil se.

02Vrstvy review: co se děje, než se podívá člověk

Příspěvek popisuje sedm vrstev. Pro tvůj tým stojí za to pochopit hlavně první pět.

1. Ověření ještě před PR

Agent nemá jen tvrdit, že „to funguje“. Má spustit testy, build a porovnání screenshotů a ukázat výstup. Subagent navíc zkontroluje diff v čerstvém kontextu. Boris Cherny podle příspěvku odhaduje, že když Claude dostane způsob, jak si práci ověřit, je výsledek dvakrát až třikrát lepší.

Dva soubory dělají velký rozdíl:

• CLAUDE.md — stack, konvence, cíle a „ne-cíle“; krátký a odkazující na další dokumenty.
• REVIEW.md — píší ho vlastníci kódu a říká, na čem v dané části záleží. Dobrý REVIEW.md popisuje, jak vypadá selhání („dokumentace lže“, „konfigurace špatně směruje“), omezuje počet drobností, vypisuje cesty k přeskočení a vyžaduje soubor a řádek jako důkaz.

2. AI review na každém PR

Claude čte diff proti celému repozitáři i záměru PR. Několik agentů hledá chyby paralelně, další skupina o každém nálezu hlasuje a zveřejní se jen to, na čem se shodne dost agentů. Nálezy zaměřené jen na styl a úklid se zahazují. Komentáře mají značky Important, Nit nebo Pre-existing a každý nález se musí opravit, nebo uzavřít s důvodem.

Číslo, které stojí za zapamatování: po spuštění research preview vzrostl podíl interních PR s věcným komentářem z 16 % na 54 %. Většina PR nad 1 000 řádků dostane nález, malé PR obvykle projdou čisté.

3. Bezpečnostní review, které blokuje

Otevřený nález z bug review nebo security review zablokuje merge. Nález se zavře opravou v dalším commitu, nebo tím, že autor uzavře vlákno s důvodem — tak se vyřizují falešné poplachy. Podobnou funkci má open-source GitHub Action pro security review a příkaz /security-review.

4. Povinné CI

Lint, typy, testy na všech platformách a build. Šablona PR se ptá, jak byla změna otestována a jak se vrací zpět; to podepisuje ten, kdo změnu zadal.

5. Lidské schválení podle rizika

Tady je jádro. Klasifikátor určí úroveň z podoby samotné změny a druhý klasifikátor ještě zkontroluje, jestli člověk není potřeba tak či tak.

Pár pravidel, která tabulku drží pohromadě:

• Lehčí cesty dostanou jen důvěryhodní autoři (většinou vlastnící tým).
• Schválení od agenta se nikdy nepočítá jako schválení od člověka.
• Kdo zadal prompt agentovi, který PR napsal, je povinný reviewer.
• Schválení platí pro jeden konkrétní commit; nový commit, za který systém neručí (push od agenta, ručně vyřešený merge), vyžaduje nové schválení.
• Vždy projde člověkem cokoli, co vlastníci označí jako citlivé, a každý soubor CI workflow.

03Merge queue, flagy a rollback

Zbylé dvě vrstvy mají jeden cíl: aby chyba, která projde, nebyla drahá. Merge queue znovu spouští kontroly nad nejnovějším main s aplikovanou změnou. Nové chování jde za feature flagy, nejdřív pro interní uživatele, a veřejné vydání jde nejprve do kanálu latest, zatímco stable zaostává. Flagy se vypínají bez deploye, služba na směně hlídá problémy a incident review se ptá, která vrstva to měla zachytit. Tým přiznává, že zatím nemá „jističe“, které by při zhoršení metrik samy zpřísnily schvalování.

04Jak z incidentů udělat testy pro AI reviewera

Nejpřenositelnější nápad je tenhle: incidenty se stávají evaly. Tým sesbíral minulé PR, které způsobily incident nebo revert, inženýři potvrdili chybu i její umístění, a reviewer proti této sadě běží denně. Každá změna promptů, nástrojů nebo modelu se skóruje proti všem případům; co skóre nezlepší, se zahazuje.

Hluk se měří také: každý komentář se zařadí podle reakce (opraveno, označeno jako chybné, záměrné, odmítnuto). Reviewer běží i na známých čistých PR a počítá se, kolik poplachů by vedlo ke škodlivé změně. Priorita je jasná: nejdřív chytit skutečné chyby, až potom snižovat počet kol review.

Pozor na nekonečné smyčky

Jeden PR v CLI prošel přes padesát kol „review → oprava“ přes noc, než ho autor zastavil. Rozbor přes git blame ukázal, že asi 59 % toho, co reviewer stále označoval, byl kód přítomný už při jeho prvním průchodu. Opatření podle příspěvku:

• strop kol: po třech kolech reviewer vyzve autora, ať přehodnotí přístup,
• po prvních průchodech jen review samotného diffu,
• označení celé třídy chyby, aby se opravily všechny výskyty,
• žádné opakování už zveřejněných nálezů,
• noční běhy nad existujícím kódem.

05Co dělat s review podle rizika ve svém týmu

Nepotřebuješ Anthropic, abys z toho něco vzal. Takhle bych postupoval:

1. Rozděl cesty v repozitáři na tři tiery. Do vysokého dej auth, billing, CI a release workflow, instalátory. Nízké riziko jsou dokumentace, texty a změny za flagem.
2. Zapiš to do CODEOWNERS a branch protection. Citlivé cesty musí vždy chtít člověka, ať je autor kdokoli.
3. Přidej do šablony PR tři otázky: Testování, Riziko, Jak to vrátit.
4. Zapni AI reviewera na jednom repozitáři, pár týdnů ho ladíš přes REVIEW.md a teprve pak rozšiř. Srovnání nástrojů najdeš v článku o AI code review nástrojích, kompletní postup v návodu na AI code review pipeline.
5. Omez počet kol a nepusť bota, aby nahradil povinného člověka. Schválení se po novém commitu odvolává.
6. Měř lidský čas a hlídej reverty. Medián a 95. percentil schválení na PR, čekání na člověka — a revert rate jako pojistku.

Pokud ti review zdržují velké PR, pomůže je rozdělit; viz stacked PR na GitHubu. A pro samotného agenta platí, že kvalitu práce zvedne hlavně možnost ověřit si výsledek — Claude Code proto před PR sám spouští testy a build.

Pozor čísla v příspěvku (zdvojnásobení PR, pokles revertů o 40 %) pocházejí od samotného týmu Claude Code a jde o jeho vlastní repozitáře. Tvůj tým, tvůj kód a tvoje metriky se mohou lišit. Berte to jako inspiraci, ne jako záruku.

06Code Review pro Claude Code: dostupnost a cena

Produktová verze, Code Review pro Claude Code, je od 15. 10. 2026 v obecné dostupnosti pro tarify Team a Enterprise. Podle oficiální dokumentace nákladů nemá fixní cenu za review: účtuje se podle spotřeby tokenů přes usage credits, odděleně od zahrnutého využití tarifu, a platí ji organizace.

• Přidaný repozitář má výchozí režim After every push, který spouští nejvíc review. Pro pilot doporučuje dokumentace Once after PR creation nebo Manual (@claude review).
• Měsíční limit výdajů nastavíš v administraci; po jeho vyčerpání se review přeskakují a PR dostane komentář.
• Průměrnou cenu na review uvidíš ve sloupci Average cost v administraci. Spoléhej na ni, ne na čísla třetích stran.
• Hloubku volí admin pro každý repozitář: Quick, Standard (výchozí) nebo Deep.

Produkt zveřejňuje nálezy, ale PR neschvaluje ani neblokuje; blokování po otevřených nálezech si tým Claude Code nastavuje ve vlastních repozitářích. Lokálně můžeš spustit /code-review v session Claude Code na jakémkoli tarifu.

07Časté otázky