Code review s AI – jak ho dělat, aby opravdu pomáhal

AI dokáže projít diff rychleji než člověk a nikdy ji neomrzí upozorňovat na chybějící ošetření chyb. Zároveň ale nezná váš byznys, nevidí celý systém a umí s jistotou tvrdit nesmysly. Nejlepší výsledky přináší kombinace: AI udělá první průchod, člověk rozhoduje.

Co AI v review zvládá dobře

• Mechanické chyby: neošetřené null/None, off-by-one, chybějící await, zapomenuté uzavření souboru nebo spojení.
• Bezpečnostní vzory: skládání SQL z řetězců, innerHTML s uživatelským vstupem, tajemství v kódu, chybějící kontrola oprávnění.
• Čitelnost: nejasné názvy, příliš dlouhé funkce, duplicitní kód.
• Okrajové případy: prázdný seznam, nula, záporná čísla, Unicode, časová pásma.
• Chybějící testy a návrhy, co testovat.

Kde AI selhává

• Nezná záměr. Neví, že „sleva se nesčítá“ je obchodní pravidlo, pokud jí to neřeknete.
• Nevidí zbytek systému. Když dostane jen diff, neví, že funkce volaná o dva soubory vedle už validaci dělá.
• Halucinuje API. Může navrhnout metodu, která v dané verzi knihovny neexistuje.
• Je přehnaně ochotná. Na otázku „najdi chyby“ najde vždy nějaké, i když jsou to jen stylistické drobnosti.

Z toho plyne: výstup AI berte jako seznam podezření k ověření, ne jako verdikt.

Jak připravit kontext

Kvalita review stojí na tom, co AI dostane:

1. Diff – ideálně s kontextem kolem změn:

git diff main...HEAD -U10 > zmeny.diff

-U10 přidá 10 řádků kontextu místo výchozích 3.

2. Celé dotčené soubory, pokud nejsou obrovské. Diff bez kontextu vede k povrchním připomínkám.
3. Popis záměru – co má změna dělat a proč. Klidně text z pull requestu.
4. Omezení – verze jazyka a frameworku, konvence týmu, co se změnit nesmí.

Šablona promptu

Jsi zkušený recenzent kódu. Projdi následující změnu.

Kontext: Django 5.1, Python 3.12, PostgreSQL. Změna přidává export
faktur do CSV pro účetní. Export smí stáhnout jen uživatel s rolí "accountant".

Zaměř se v tomto pořadí na:
1. Chyby v logice a okrajové případy
2. Bezpečnost (oprávnění, injection, únik dat)
3. Výkon (N+1 dotazy, načítání všeho do paměti)
4. Čitelnost – jen podstatné věci, ne styl, ten řeší linter

Ke každému nálezu uveď: soubor a řádek, závažnost (kritické/střední/drobné),
proč je to problém a konkrétní návrh opravy. Pokud si nejsi jistý,
napiš to. Pokud v některé kategorii nic nenajdeš, napiš "bez nálezů".

[diff a soubory]

Poslední dvě věty jsou důležité: dovolují AI říct „nevím“ a „nic tu není“, což snižuje množství vymyšlených připomínek.

Cílené otázky fungují lépe než obecné

Místo „zkontroluj kód“ se ptejte konkrétně:

• „Co se stane, když items bude prázdný seznam?“
• „Může tenhle endpoint zavolat uživatel bez role accountant?“
• „Kolik SQL dotazů provede tahle smyčka pro 1000 faktur?“
• „Je tahle funkce bezpečná při souběžném volání?“

Automatizace v CI

AI review lze zapojit do pull requestů. Existují hotové GitHub Actions i nástroje, které komentují PR. Pár zásad:

• AI komentáře označte jako návrhy, ne jako blokující kontrolu.
• Nespouštějte AI review na PR z forků s přístupem k tajemstvím (riziko úniku přes upravený workflow).
• Nejdřív nechte doběhnout linter a testy – AI nemusí řešit formátování.

Checklist pro lidského recenzenta

Po AI průchodu zůstává na člověku:

• [ ] Řeší změna skutečně zadaný problém?
• [ ] Odpovídá architektuře a konvencím projektu?
• [ ] Ověřil jsem tvrzení AI (existuje navržená metoda, je chyba reálná)?
• [ ] Je změna srozumitelná pro někoho, kdo ji bude za rok upravovat?
• [ ] Jsou testy smysluplné, nebo jen zvyšují pokrytí?

Review vlastního kódu před odesláním

Nejlevnější review je to, které uděláte sami před otevřením PR. Pošlete AI svůj diff s otázkou „co by na tom recenzent kritizoval?“ a opravte to dřív, než to uvidí kolegové. V ColdHost AI můžete importovat repozitář z GitHubu do Projektu, nechat si změny zkontrolovat (u rozsáhlejších změn s modelem Polaris) a opravy rovnou poslat zpět jako pull request.