Jak reviewovat AI kód: kontrola generovaného kódu, než tě dostane v produkci

Před rokem jsi byl autorem kódu a AI ti asistovala. Dnes je to často naopak: agent napíše diff za třicet sekund a ty ho musíš do čtyřiadvaceti hodin schválit. Tvá hlavní kompetence se posunula z psaní kódu na jeho validaci — a pokud svůj review proces neupravíš, stane se to, co popisuje studie METR: vývojáři s AI pracovali o 19 % déle, přestože byli přesvědčení, že jsou o 20 % rychlejší. Rozdíl mezi těmita čísly není pohoda. Je to čas, který strávíš čtením kódu, který vypadá správně.

V tomto návodu ti ukážu, jak nastavit review proces pro AI generovaný kód, co konkrétně kontrolovat a jak poznat, že tvůj review funguje. Nebude to teorie — je to systém, který můžeš zavést dnes odpoledne.

Proč review AI kódu není totéž co review lidského kódu

Lidský kód nese stopy únavy: nepřesné názvy, opuštěné TODO, nekonzistentní styl. AI kód je naopak povrchně dokonalý. Každý řádek vypadá uhlazeně, pojmenování je konzistentní, struktura odpovídá tomu, co znáš z dokumentace. Právě proto je nebezpečnější: povrchní review ho schválí, i když řeší špatný problém.

Data jsou nepříjemně jasná. Veracode v reportu GenAI Code Security 2026 prohnalo přes sto modelů bezpečnostními testy a jen 55 % vygenerovaného kódu prošlo základní kontrolou. Analýza GitClear ukázala, že podíl refaktorovaného kódu klesl z 24 % na 9,5 % a kopírování poprvé v historii překonalo refaktoring. AI kód funguje, ale hromadí se — a duplikace jsou dluh, který splatíš později.

Přitom podle průzkumu Sonar jen 48 % vývojářů vždy kontroluje AI výstup před commitem. Zbytek spoléhá na to, že "to přece projde testy". Projde. Testy, které si agent napsal sám.

Tři úrovně review: 30 sekund, 5 minut, 30 minut

Ne každý diff si zaslouží půlhodinu. Rozděl review podle rizika a šetři pozornost tam, kde se dá něco rozbít.

Zelená (30 sekund): UI úpravy, kopie, dokumentace, testovací fixture, malé utility. Nic se nemění v datovém toku, závislostech ani oprávněních. Stačí standardní schválení a automated checks.

Žlutá (5 minut): byznys logika, API integrace, background joby, transformace dat. Řeší správný problém? Jsou ošetřené chybové stavy? Odpovídá datová struktura smlouvě, kterou už máš v kódu?

Červená (30 minut): autentizace, platby, oprávnění, PII, databázové migrace, veřejná API, infrastruktura. Tady AI maximálně navrhne — finální verzi přepíšeš nebo hluboce verifikuješ ty. Senior sign-off je podmínka, ne formalita.

Klíčový trik: zařaď lane do pull requestu hned na začátku. Šablonu v .github/PULL_REQUEST_TEMPLATE.md vyplníš za pět sekund a reviewer okamžitě ví, jak hluboko jít.

Sedm selhání, která musíš chytat

Checklist, který používám, je organizovaný podle toho, co agenty skutečně rozbíjí:

1. Halucinované API a importy. Agent zavolá metodu, která na objektu neexistuje, nebo importuje balíček přejmenovaný před dvěma verzemi. Skoč do definice. Ne každé foo.bar(), které vypadá rozumně, existuje.
2. Tautologické testy. Test, který testuje mock, ne kód. Projde vždy, říká nic.
3. Přehnané abstrakce. Agent vytvoří factory manager builder, protože v trénovacích datech se to v tom kontextu objevuje. Smazat je levnější než udržovat.
4. Chybějící edge casy a error handling. Happy path je vždy ošetřená. Co se stane s prázdným vstupem, timeoutem, souběhem?
5. Sebejistě špatná byznys logika. Kód je idiomatičný, ale implementuje jinou úroveň zaokrouhlení, než vyžaduje zákon nebo smlouva s klientem.
6. Zastaralé vzory. Agent sáhne po knihovně z doby svého cutoffu místo nativního API. Funguje, ale je to tech debt od prvního dne.
7. Smazané a přeskočené testy. Když agent "opraví" padající test tím, že ho přeskočí, diff vypadá zeleně. Vždy kontroluj, co se v testech změnilo.

Nech AI reviewovat sebe — ale brány postav lidé

Nejsnazší zlepšení: neposílej každý generovaný diff rovnou člověku. Nejdřív automatické brány — type check, lint, testy, secret scanning, SAST, kontrola závislostí. Až pak ty.

Druhá vrstva je self-review. Nech agenta, aby si vlastní diff zkritizoval proti explicitnímu checklistu: "Vyhledej v tomto diffu halucinovaná API, chybějící ošetření chyb a případy, kdy kód neplní požadavek z ticketu." U spousty selhání to chytí překvapivě moc. Naprosto to nenahrazuje lidský review — nasazuje to jen filter, který ušetří tvou pozornost na to, co člověk vidí líp: kontext, záměr a architekturu.

Pokud používáš Copilot, předkonfigurované AI code review ti dokáže první vrstvu filtrování vzít zcela — jak ho nastavit tak, abys nepřestal mít kontrolu nad kódem, jsem popisoval v návodu na schvalování pull requestů Copilotem.

Jedna kapitola bez kompromisů: závislosti. Agent rád přidává balíčky a u commercial modelů jich 5 % vymyslí úplně (u open-source modelů až pětina). Jméno, které neexistuje, je volný slot — a registrace doménových jmen balíčků, které AI vymýšlí, je už dnes útočná technika. Každý nový import ověř v registru dřív, než mergeuješ. Podrobnosti, jak agenta zastavit dřív, než nainstaluje cizí balíček, jsem řešil v článku o llms.txt útoku.

Metriky: poznáš, že review funguje

Bez čísel se review proces během tří týdnů změní v rubber stamp. Sleduj tři věci:

• First-pass approval rate. Kolik procent AI PR projde bez revize? Nad 90 % reviewuješ povrchně. Pod 30 % má agent špatný kontext nebo prompt.
• Post-merge defect rate. Porovnej bugy na PR od agenta vs. od člověka. Tohle je ground truth. Pokud PR od agentů generují víc incidentů, má proces díry.
• Review load per reviewer. AI generuje objem rychleji, než ho senior zvládne číst. Když se review fronta prodlužuje, řešením není "číst rychleji", ale přesunout víc diffů do zeleného pruhu a automatizovat žluté kontroly.

Zavedení za odpoledne

Praktický postup, kdyby ses chtěl pustit do toho hned:

1. Přidej do PR šablony pole "AI involvement" (co agent napsal, přepsal, jaké testy generoval) a lane (zelená/žlutá/červená).
2. Nahraj checklist výše do CONTRIBUTING.md, ať ho celý tým používá stejně.
3. Zkontroluj, že CI obsahuje secret scanning a kontrolu závislostí. Pokud ne, je to první věc k dodělání — tohle je baseline, ne nice-to-have.
4. Začni měřit first-pass approval rate na AI PR. První měsíc jen sleduj, ať víš, z čeho vycházíš.

Když validace znamená víc než rychlost

Studie METR z únorové aktualizace naznačuje, že v roce 2026 už AI nástroje vývojáře reálně zrychlují víc než v roce 2025 — ale zároveň přiznává, že to nedokáže spolehlivě změřit, protože vývojáři odmítají bez AI pracovat i za peníze. To je přesně ten moment, kdy se kvalita tvého review procesu stává jediným limitem, který rozhoduje, jestli z rychlosti bude throughput, nebo incident v produkci.

AI ti sepsala diff za třicet sekund. Schválení je pořád tvoje jméno v git historii. A jak říká Simon Willison: počítač nikdy nemůže nést odpovědnost. Tu neseš ty.

Zdroje: METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR — uplift experiment update 2026, GitHub Docs — Review AI-generated code, Veracode GenAI Code Security Report 2026, GitClear Coding on Copilot analýza.