AI code review se z experimentu posunulo do běžného PR workflow. GitHub, GitLab, Atlassian i specializované služby už umějí automaticky komentovat diff, shrnovat změny a navrhovat opravy. Skutečné měřítko ale není, jestli model občas najde bug. Rozhoduje, jestli zkrátí lidské review, nebo jen přidá další proud komentářů, které musí někdo ověřit.

AI review dává nejlepší poměr přínosu a rizika tam, kde dělá první průchod: shrne velký diff, upozorní na opakující se chyby, najde zjevné bezpečnostní vzory, připomene chybějící test nebo srovná změnu s acceptance criteria v ticketu. Jako náhrada lidského review neobstojí. I oficiální dokumentace GitHub Copilot code review říká, že výstupy Copilotu je nutné ověřovat a doplnit lidským review.

Pro praxi je to důležitější než seznam nástrojů. AI reviewer má stát před člověkem: shrnout diff, najít rutinu a nechat rozhodnutí na reviewerovi. Nemá rozhodovat o sloučení do chráněné větve. Jakmile ho tak nastavíte, svádí to ke dvěma špatným návykům: autor si řekne, že základní věci už zkontroloval bot, a reviewer začne číst komentáře bota místo diffu. Obě zkratky vypadají úsporně přesně do chvíle, než projde změna, kterou model bez doménového kontextu snadno mine.

Review už dnes nedělají jen lidé

Z pohledu dostupných nástrojů je posun hotový. GitHub má Copilot code review přímo v PR, IDE i CLI a umožňuje automatické review pro vybrané větve. GitLab nabízí Duo Code Review včetně custom review instructions. Atlassian nabízí Rovo Dev code review pro vývojářské workflow kolem Bitbucketu a GitHubu, typicky s napojením na kontext Jiry. Vedle nich jsou specializované služby jako CodeRabbit, Qodo, Bito nebo open-source PR-Agent, které slibují hlubší práci s repozitářem, pravidla nad projekty, lokální review, compliance checky a integrace do CI.

GitHub v březnu 2026 na svém blogu uvedl, že Copilot provedl přes 60 milionů code reviews. Jako měření kvality ten údaj neobstojí; rozsah adopce ale ukazuje dobře. AI review už není funkce pro pár týmů, které si hrají s novým botem. Začíná měnit očekávání kolem pull requestu: dřív se čekalo na prvního člověka, dnes se často čeká na prvního člověka po botovi.

To zní jako drobnost, ale mění to ekonomiku review. Klasické review je drahé hlavně proto, že vyžaduje pozornost zkušeného člověka. AI komentář je levný na vygenerování a drahý na validaci, pokud není přesný. Jeden špatný komentář není problém. Dvacet polovičatých poznámek v každém PR už problém je, protože se z nich stane šum, který autor i reviewer musí protřídit.

Data jsou střízlivější než produktové stránky

Dostupná data zatím neříkají, že AI review je k ničemu. Říkají něco praktičtějšího: hodnota je nerovnoměrná, šum se snadno podceňuje a běžné metriky review se po nástupu agentů hůř interpretují. Část výsledků navíc pochází z čerstvých preprintů a konkrétních datasetů, takže nejde o definitivní verdikt pro každý tým a každý typ repozitáře.

Jedna z větších studií nad code review agenty, tedy CRA, pracovala s 3109 pull requesty z AIDev datasetu. Samotné srovnání merge rate autoři počítali v podmnožině 2456 PR se stavem „Commented“. V ní měla PR reviewovaná pouze code review agenty merge rate 45,20 %, u human-only review šlo o 68,37 %. Abandonment byl u CRA-only PR 34,88 % proti 21,60 % u lidského review. V navazující analýze 98 uzavřených CRA-only PR autoři uvádějí, že 12 ze 13 sledovaných agentů mělo průměrný poměr signálu a šumu pod 60 %. Jinak řečeno: v tomto vzorku byla značná část komentářů málo využitelná nebo příliš hlučná.

Další práce nad AI-generated pull requesty upozorňuje na související problém. Nejde přímo o měření AI reviewerů, ale o varování, že po vstupu agentů do PR procesu přestává být běžná review metrika jednoznačná. V analyzovaném AIDev datasetu autoři uvádějí, že většina AI-generated PR neměla zaznamenanou review aktivitu; zároveň upozorňují, že to nemusí znamenat absenci lidského dohledu mimo stopu v PR. U reviewovaných PR navíc hráli velkou roli další AI agenti. Počet komentářů už proto nemusí znamenat lidskou pozornost. Označení „reviewed“ nemusí znamenat, že diff opravdu pochopil někdo, kdo za něj ponese odpovědnost.

Nasazení AI review nestojí na tom, jestli model někdy najde správný problém. Tým musí vědět, kolik užitečných nálezů dostane za lidskou pozornost, kterou validace bota spotřebuje.

Kde AI reviewer opravdu pomáhá

Nejlepší případ použití je orientace v cizím nebo velkém PR. Lidský reviewer často nezačíná hledáním bugu. Nejdřív se snaží pochopit, co se vlastně změnilo, proč to vzniklo, které části systému to zasahuje a co má smysl číst detailně. AI shrnutí diffu, seznam dotčených oblastí nebo upozornění na chybějící testy tady může ušetřit čas. Ušetří hlavně první mechanickou část práce: orientaci v diffu, dotčených místech a zjevně chybějících testech.

Druhý dobrý scénář jsou opakující se vzory. Neřešené null, zjevně špatná validace vstupu, zapomenutý test pro novou větev, chybějící rollback u migrace, práce s tokenem v logu, změna API bez úpravy dokumentace. Tady AI review funguje podobně jako chytřejší lint. Jen nesmí suplovat lint, formatter nebo SAST. Jestli bot komentuje věci, které má řešit Prettier, ESLint, Semgrep nebo CI, je nastavený špatně.

Třetí užitečný scénář je před-review na straně autora. GitHub umožňuje používat Copilot code review nad vybraným kódem i nad necommitnutými změnami ve VS Code, tedy ještě před tím, než feedback skončí v hlavním PR vlákně. Autor dostane levný první feedback, opraví zjevnosti a lidský reviewer pak nečte komentáře typu „tady by mohl být lepší název proměnné“.

Čtvrtý scénář je kontrola proti explicitním pravidlům. GitLab podporuje custom review instructions, podobnou cestou jdou Qodo, Bito i CodeRabbit. Bez pravidel model sklouzne k obecným radám. S pravidly může hlídat, že endpointy v billing části mají audit log, změny v auth vyžadují test na expiraci tokenu a migrace musí mít rollback poznámku. Pořád to není doménové porozumění, ale už to není ani generická kontrola stylu.

Kdy z toho vznikne druhý CI spam

AI review selhává hlavně tam, kde mu dáte široký mandát a žádný postih za šum. V takovém zadání model snadno vyrobí komentář za každou cenu. Výsledkem jsou poznámky, které technicky nezní úplně špatně, ale reviewer po třiceti sekundách pozná, že neberou v úvahu architekturu, historické rozhodnutí nebo konkrétní trade-off.

Studie rozhovorů s inženýry o AI-assisted code review popisuje zajímavý paradox. AI může snížit sociální tření, protože kritika od bota nebolí stejně jako kritika od kolegy. Zároveň ale zvyšuje kognitivní zátěž, pokud generuje příliš mnoho detailních komentářů s nízkou důvěryhodností. Vývojář pak nedělá méně review. Dělá review review.

Tohle je dobrý test každého nástroje. Po měsíci se nemá počítat objem komentářů, ale přijaté nálezy, ručně odmítnuté nálezy, opravy před lidským review a čas reviewerů. Konkrétní metriky jsou důležitější než dodavatelský dashboard. Pokud se většina AI komentářů po čase ignoruje, nevznikla automatizace. Tým jen dostal další účet, který píše do PR.

Meta v experimentu popsaném ve studii AI-Assisted Fixes to Code Review Comments at Scale ukázala, jak citlivé je samotné UX. Když AI navrhovala patche přímo reviewerům, review se podle autorů prodloužilo o více než 5 %. Po změně rozhraní, kdy byly AI opravy viditelné hlavně autorům, se regresi podařilo odstranit. Ten výsledek není univerzální zákon. Pro nasazení z něj ale plyne jednoduchá věc: špatně umístěná AI pomoc může zpomalit přesně ten krok, který měla zrychlit.

Bezpečnostní proces z modelu nebude

Security review je lákavý scénář použití, protože ručních bezpečnostních reviewerů je málo a PR přibývá. Anthropic například popisuje automatizované security reviews v Claude Code a samostatně píše o Claude Code Security. Je dobré to sledovat. Nemělo by to ale nahrazovat klasický bezpečnostní proces.

AI review může upozornit na podezřelý vstup bez validace, únik secretu do logu, slabé ověření oprávnění nebo nebezpečné použití knihovny. V bezpečnosti ale nestačí najít některé chyby. Potřebujete vědět, které chyby nesmíte minout.

Tady je zvlášť nepříjemná citlivost modelů na zadání. V kontrolovaném experimentu na čtyřech modelech studie o confirmation bias v LLM-assisted security review zjistila, že zarámování zranitelného kódu jako „bug-free“ snížilo míru detekce zranitelností o 16,2 až 93,5 procentního bodu. Model tedy nereaguje jen na kód. Reaguje i na metadata, tón zadání a kontext, který může být chybný nebo záměrně manipulační.

AI reviewer může security nález eskalovat, ne uzavírat. U auth, billing, osobních údajů, kryptografie, migrací oprávnění a infrastruktury má být výstup AI jen podklad pro člověka, SAST, dependency scanning a testy. Pokud bot napíše „no security issues found“, nemá to mít větší váhu než ticho v logu.

Pravidla patří před roll-out

Nasazení AI review není hlavně otázka výběru dodavatele. Je to změna review procesu. Pokud pravidla nevzniknou před roll-outem, vzniknou živelně v komentářích pod PR.

Základní pravidlo: AI nesmí být jediný schvalovatel sloučení do chráněných větví. Může přidat komentář, shrnutí, checklist nebo suggested fix. Finální odpovědnost musí zůstat u člověka. Druhé pravidlo: komentáře bota mají být jasně označené a snadno skrytelné. Třetí pravidlo: AI review má běžet selektivně. Velké PR, změny v citlivých adresářích, neznámý autor, chybějící testy, security label, migrace databáze. Plošné komentování každého drobného PR je nejrychlejší cesta k ignorování.

Čtvrté pravidlo se týká oprávnění. Review bot není jen „účet s komentářem“. Často čte diff, metadata PR, interní ticket, někdy i CI výstupy. U GitHub Actions dává smysl držet se principu minimálních oprávnění, u GitHub Apps začínat bez oprávnění a přidat jen nezbytné scope podle dokumentace k permissions. GitLab u merge request pipelines z forků výslovně varuje před rizikem krádeže secrets při běhu v parent projektu. AI review job nesmí být postranní cesta k citlivým proměnným.

Páté pravidlo je datové. U každého nástroje si před pilotem zjistěte, co posílá mimo vaši infrastrukturu, jakou má retenci, zda používá data k tréninku a jestli podporuje data residency nebo on-prem režim. Qodo v dokumentaci uvádí centralizovanou governance a on-premise nasazení, Atlassian u Rovo Dev roll-outu otevřeně popisuje limity kolem auditů, HIPAA a data residency. U regulovaného kódu jsou to provozní a právní parametry, ne jen položky v nákupním checklistu.

Jak to zavést, aby z toho nebyla hračka na týden

Nejrozumnější pilot je malý a měřitelný. Nejdřív vyberte jeden až tři týmy a jeden typ repozitáře. Ideálně takový, kde nejsou extrémní compliance požadavky, ale probíhá dost PR na to, aby se něco dalo měřit. Před zapnutím AI review si určete výchozí hodnoty: medián čekání na první lidské review, medián času do sloučení, počet lidských komentářů na PR, revert rate, počet chyb nalezených po mergi a přibližný čas seniorních reviewerů.

Pak spusťte stínový režim. Bot analyzuje PR, ale nepíše do hlavního vlákna. Tým po týdnu nebo dvou vyhodnotí, které nálezy by byly užitečné a které by jen přidaly hluk. Teprve potom zapněte komentáře. Ne pro všechno. Začněte u větších PR, u PR do chráněných větví, u vybraných adresářů nebo u změn s konkrétním labelem.

PR šablona by měla AI držet na uzdě. Autor má uvést, proč změna vznikla, jaké nese riziko, jak se testovala, zda při psaní použil AI, zda spustil AI review a které návrhy odmítl. Lidský reviewer má mít explicitně vypsáno, co má zkontrolovat člověk: architekturu, bezpečnost, doménovou správnost, migrace, kompatibilitu a rollback. To nejsou věci, které vyřeší komentář „consider adding a test“.

Instrukce pro repozitář by měly být krátké a tvrdé. Nekomentuj styl, který řeší formatter. Nepiš komentář bez konkrétního návrhu. Neopakuj komentář, pokud už ho pokrývá CI. U auth, billing, migrací a práce s osobními údaji zvyš prioritu. U testů navrhuj konkrétní případ, ne obecnou větu „add tests“. Špatné AI review často nevzniká kvůli stylu odpovědi, ale kvůli příliš volnému zadání typu „něco zkontroluj“.

Co měřit po měsíci

Úspěch AI review se nemá měřit počtem komentářů. To je metrika pro dodavatelský dashboard, ne pro tým. Po měsíci se ptejte hlavně na to, zda se zkrátil čas do prvního lidského review, zda se zkrátil čas do sloučení, zda klesl počet zjevných chyb, které dřív musel psát člověk, zda se nezvýšil počet revertů, zda se nezhoršil abandonment a zda autoři AI návrhy přijímají, nebo je po čase ignorují. Podstatné je, jestli se ušetřil čas seniorům, nebo se jen přesunul na ověřování poznámek od bota.

GitLab má GitLab Duo and SDLC trends, Bito nabízí vlastní code review analytics, CodeRabbit má dashboard a reports. Tyhle produktové statistiky jsou užitečné, ale nestačí. Produktové statistiky berte jen jako doplněk. Důležité je, zda klesá čekání, šum a počet chyb po mergi.

Když po měsíci roste počet komentářů a neklesá čas seniorních reviewerů, pilot selhal nebo má špatné nastavení. Když klesá čas prvního review, ale roste revert rate, také to není dobrý výsledek. Nejlepší scénář je nudný: méně zjevných připomínek od lidí, rychlejší orientace ve velkých PR a stejná nebo lepší kvalita po mergi.

Kdy ho raději nezapínat

AI review nedává smysl všude. Pokud tým nemá stabilní testy, jasná code ownership pravidla, chráněné větve a rozumnou PR šablonu, bot jen přidá další chaos. Pokud se review dnes zasekává na tom, že PR mají pět tisíc řádků a žádný popis, AI to nevyřeší. Jen vytvoří shrnutí nepořádku.

Stejně tak bych byl opatrný u týmů, které už teď trpí notifikační únavou. Další komentující účet může proces zhoršit i tehdy, když má občas pravdu. Review kultura se neléčí tím, že k lidem přidáte bota. Léčí se menšími PR, jasným ownership, rychlejší CI, lepšími testy a pravidly, která platí pro člověka i pro nástroj.

Dejte botovi úzký rozsah, minimální oprávnění, pravidla na úrovni repozitáře a měřte poměr užitečných nálezů a šumu. Po pilotu by mělo být vidět, že bot bere seniorům rutinu, ne že tým jen rychleji ignoruje další komentáře. Pokud po měsíci šetří čas seniorům, nezahlcuje autory a pomáhá najít rutinní chyby před lidským review, nechte ho růst. Pokud jen zvyšuje počet komentářů, vypněte ho dřív, než si tým zvykne ignorovat další červenou bublinu.