Jak dělat review kódu přes agenta

Představte si stránku se seznamem nákupů: otevře se, přidávají se položky, tlačítka vypadají správně. Jenže hotová obrazovka ještě neznamená, že je kód dobře promyšlený. Vývojáři si proto kód navzájem samostatně prohlížejí, aby našli přehlédnuté chyby a probrali řešení. Tuto práci můžete svěřit agentovi a on si s ní poradí výborně. Jen mu musíte vysvětlit zadání.

1. Jak se dělá review kódu v týmu

V malém týmu dostal vývojář úkol: vytvořit seznam nákupů, do kterého je možné přidávat položky a odstraňovat je po jedné. Napsal kód, zkusil přidat chleba a mléko, odstranil chleba. Všechno fungovalo. Než předal práci dál, vývojář si své změny ještě jednou přečetl: odstranil zapomenutý kus kódu, opravil nejasný název. Tomu se říká sebekontrola.

Pak poprosil kolegu, aby se na kód podíval. Kolega zná programovací jazyk a čte, jak funguje přidávání, jak program vybírá položku k odstranění, co se děje se zbytkem seznamu. Takové prohlížení se nazývá review kódu, neboli code review, a ten, kdo kontroluje, reviewer.

Kolega si všimne: program vybírá nákup k odstranění podle názvu. Pokud se v seznamu objeví dva záznamy "Mléko", kliknutí na jeden může odstranit oba. Autor zkoušel chleba a mléko. Na takový případ prostě nenarazil.

Reviewer zanechá komentář vedle příslušné části kódu: "Teď se odstraňují všechny nákupy s tímto názvem. Povolujeme stejné záznamy? Pokud ano, měli bychom odstranit pouze vybranou položku". Autor upřesní požadavek: stejné záznamy jsou povoleny, protože je mohly přidat různí lidé. Po diskusi změní způsob výběru položky. Kolega se podívá na opravu ještě jednou a ověří si, že je připomínka zapracovaná.

Diagram ukazuje průběh review s poznámkami: kód přechází od autora ke kolegovi, pak se vrací k opravě. Pokud po opětovném prohlédnutí zůstanou otázky, diskuse a úpravy se opakují. Když podstatné připomínky nejsou, kolega změnu schválí.

Takto vypadá běžný pracovní cyklus: napsal, ukázal, dostal připomínku, prodiskutoval, opravil. Někdy je připomínek víc, někdy žádné. Stane se také, že autor vysvětlí své rozhodnutí a kolega svou otázku stáhne. Review nevyžaduje souhlas s každým komentářem.

Při takovém prohlížení se probírá i srozumitelnost kódu: vyzná se v něm další vývojář, nemusí se jedno pravidlo měnit na několika místech? Kolega se zároveň dozví, jak je nová část programu postavená. Znalost projektu se tak postupně rozkládá mezi lidi, místo aby zůstala jen u autora.

Tady je snadné zaměnit review s testováním. Když člověk přidá dva nákupy a klikne na tlačítko, ověřuje chování běžícího programu. Když čte kód odstranění a zjišťuje, které záznamy vybere, provádí review. Během review můžete program spustit, abyste si ověřili domněnku. Tyto metody se navzájem doplňují.

2. Jak svěřit review agentovi

Teď si představte, že seznam nákupů napsal Claude Code podle vašeho popisu. Umíte vysvětlit, co se má na stránce dít, ale její programovou logiku si přečíst nedokážete. Technickou část review můžete svěřit také agentovi: přečte soubory a vysvětlí poznámky běžnými slovy.

Role z příběhu týmu zůstávají stejné. Je tu autor kódu a reviewer, který dostal samostatný úkol. V Claude Code pro to můžete využít subagenta: pomocníka, kterému hlavní agent svěří konkrétní práci. V našem případě čte kód a vrací poznámky.

Je také užitečné požádat autora, aby si svoji vlastní práci ještě jednou zkontroloval. Samostatný reviewer přináší jiný pohled: dostane úkol vyhodnotit výsledek. Dejte mu požadavky, aby pochopil, která řešení jsou přípustná. Například zákaz stejných nákupů by formálně odstranil problém s mazáním, ale změnil by zamýšlené chování stránky.

Doporučení Claude Code k review navrhují samostatného reviewera a jasná kritéria. Tam také doporučují soustředit se na poznámky, které ovlivňují správnost fungování a požadavky. Aplikujme to na malý kousek projektu.

K zorganizování review od vás stačí málo: popsat požadované chování a zvolit, které potvrzené problémy chcete opravit. Čtení programové logiky, hledání příčiny a analýzu technických námitek můžete svěřit agentům.

V diagramu jsou tři role: vy zadáváte požadavky a vybíráte úpravy, hlavní agent organizuje práci a opravuje kód, revieweři studují kód a poznámky. Hlavní agent jim předává potřebné materiály a vám vrací výsledky. Pokud potvrzené problémy nejsou, kroky opravy se přeskočí. Níže tuto posloupnost projdeme třemi dotazy.

Na výstupu máte srozumitelné vysvětlení problému, výsledek jeho ověření a zprávu o opravě. A pokud se poznámka ukáže jako chybná, užitečný výsledek máte i tak: vyhnuli jste se zbytečné úpravě.

Pokud chcete nastavit trvalého asistenta pro takové kontroly, bude se vám hodit článek o vytváření a spouštění subagenta. Jak pro něj připravit podrobnější zadání, rozebírá článek o briefu a formátu výsledku.

Dotaz 1. Zkontrolovat napsaný kód

Spusťte Claude Code ve složce projektu. Následující tři dotazy posílejte do hlavní relace: hlavní agent sám předává práci pomocníkům. Tady i dál používáme výukový seznam nákupů; pro svůj projekt nahraďte popis chování.

Svěř samostatnému subagentu review kódu seznamu nákupů
v aktuálním projektu. Zkontroluj přidávání a odstraňování položek.
Požadavky: stejné názvy jsou povoleny; odstraňuje se pouze
vybraná položka; prázdný nákup nejde přidat.

Přečti aktuální kód a související části projektu.
Hledej chyby, které porušují tyto požadavky.
Kód neměň. Nepřidávej nové možnosti.
Ke každé poznámce vysvětli jednoduchými slovy:
co se může pokazit, při jaké akci a proč si to myslíš.
Uveď místo v kódu pro další kontrolu jiným agentem.
Pokud problémy nenajdeš, tak to napiš. Vyjmenuj, co bylo zkontrolováno
a co zůstalo neznámé. Ulož zprávu do REVIEW_REPORT.md.
Neznám programovací jazyk: vysvětli výsledek bez nutnosti číst kód.

Soubor REVIEW_REPORT.md bude běžnou textovou zprávou. Název jsme zvolili sami, poslouží i jakýkoli jiný: je potřeba, aby v dalším dotazu bylo jasné, které poznámky ověřovat. Pokyn "kód neměň" odděluje prohlížení od opravy; zapsat zprávu je přitom dovoleno.

Užitečná odpověď v našem příkladu by mohla znít takto: "Pokud přidáte dva nákupy se stejným názvem, odstranění jednoho odebere oba. Kód vybírá položky podle názvu, takže zasáhne obě shody". Je to výukový příklad odpovědi, ne výsledek kontroly vašeho projektu.

Chápete důsledek: člověk ztratí záznam, který chtěl ponechat. Název souboru a místo v kódu potřebuje další agent, aby našel příčinu. Sami tuto část rozebírat nemusíte.

3. Jak znovu zkontrolovat poznámky

I agent-reviewer se mýlí. Například napíše: "Do seznamu je možné přidat prázdný nákup". Zní to přesvědčivě. Ale kontrola prázdného vstupu už existuje v jiné části programu, kterou nečetl. Poznámka popisuje neexistující problém.

Takové sebevědomé, ale vymyšlené tvrzení se často nazývá halucinace AI. V review je to obzvlášť nepříjemné: agent může navrhnout opravu a vy strávíte čas změnou kódu, který už fungoval správně. Proto se vyplatí ověřovat jak samotný kód po napsání, tak i poznámky k němu.

První krok už máme za sebou: nechali jsme autorovu práci někoho prohlédnout. Teď předáme zprávu spolu s aktuálním projektem jinému reviewerovi. Jeho úkol: zjistit, zda se každá poznámka potvrdí. S prvním reviewerem smí nesouhlasit.

Dotaz 2. Zkontrolovat zprávu reviewera

Svěř jinému subagentu opětovné ověření REVIEW_REPORT.md
podle aktuálního kódu projektu a požadavků z předchozího dotazu.
Předej mu tyto požadavky výslovně.

U každé poznámky zjisti, zda popsaný problém existuje.
Zkontroluj související části kódu: je možné, že potřebné zpracování už existuje.
Nepovažuj první zprávu za důkaz. Pokud je pro závěr potřeba
kontrola spuštěním, proveď ji dostupnými prostředky.
Kód projektu neměň.

U každého bodu uveď: potvrzeno, vyvráceno
nebo zatím nelze určit. Zdůvodnění vysvětli srozumitelně.
Odděl závěry z čtení kódu od výsledků provedených kontrol.
Nevydávej neprovedenou kontrolu za provedenou.
Ulož výsledek do REVIEW_CHECK.md a stručně mi to vysvětli.

Poté budete mít REVIEW_CHECK.md s výsledkem ověření. V našem výukovém případě může druhý agent potvrdit problém se stejnými názvy a poznámku o prázdném vstupu vyvrátit: "Prázdný řetězec je odmítnut ještě před přidáním záznamu. První reviewer tuto kontrolu přehlédl".

To už pomáhá zvolit další krok. Problém s odstraňováním lze předat k opravě. Prázdný vstup kvůli této poznámce měnit nemusíte. Pokud agent napíše "zatím nelze určit", požádejte jej, aby vysvětlil, jaké údaje mu chyběly. Někdy je to otázka na vás: například zda se stejné záznamy mají počítat jako jeden nákup nebo dva.

Opětovná kontrola pomáhá odfiltrovat vymyšlené poznámky, ale nezaručuje jejich úplné zmizení. Dva agenti mohou udělat stejnou chybu. Proto odpověď potřebuje zdůvodnění: co přesně reviewer v projektu našel nebo jaký výsledek dostal při spuštění. Pouhé "souhlasím s předchozím agentem" nestačí.

4. Oprava a opětovné review

Teď zvolte, co opravit. K tomu stačí pochopit dopad problému na zamýšlené fungování stránky. V našem příkladu odstranění nákupu navíc zjevně vadí, takže bereme tento bod. Návrh přidat řazení můžete nechat na později. s opravou odstraňování stejně nesouvisí.

Předejte agentovi vybranou poznámku celou, aby nemusel hádat, co myslíte tím "oprav první chybu". Požádejte ho, aby po změně výsledek znovu zkontroloval. Je to pokračování příběhu týmu: kolega se dívá na už opravenou verzi.

Dotaz 3. Opravit a zkontrolovat výsledek

Oprav potvrzený problém z REVIEW_CHECK.md:
při odstranění jednoho nákupu zmizí všechny záznamy se stejným názvem.
Je třeba odstranit pouze vybranou položku. Stejné názvy jsou povoleny.
Ostatní návrhy z review zatím neimplementuj.

Po opravě zkontroluj dostupnými prostředky přidávání
a odstraňování nákupů, včetně dvou se stejným názvem.
Poté svěř samostatnému subagentu opětovné review opraveného kódu:
zda je příčina odstraněna a zda není narušeno přidávání a odstraňování.
Předej mu původní požadavky a popis opravovaného problému.

Vysvětli mi jednoduchými slovy, co se změnilo, jaké kontroly
byly provedeny a co ukázalo opětovné review.
Pokud se něco nepodařilo zkontrolovat, pojmenuj to zvlášť.
Nerozšiřuj úkol novými vylepšeními.

Ve vašem projektu nahraďte odstavec o nákupech potvrzenou poznámkou z vaší zprávy. Zbytek postupu můžete ponechat: oprava, kontrola, samostatný přezkum výsledku.

Dobrý výsledek říká něco konkrétního: "Teď se každá položka odstraňuje zvlášť. Kontrola se dvěma stejnými názvy nechala druhou položku na místě. Opětovné review původní příčinu chyby nenašlo". Tohle lze napsat jen po příslušných kontrolách. Pokud agent pouze četl kód, měl by to označit.

Můžete také otevřít stránku a vyzkoušet obvyklé akce. K tomu není potřeba znalost jazyka. Je to doplňková kontrola viditelného výsledku; technické review opravy dál provádí agent. Pokud mu na spuštění nestačily možnosti, zůstane ve zprávě srozumitelné omezení, a ne slib "všechno určitě funguje".

Z každého kola nemusíte dělat nekonečné dolaďování. Pokud je vybraný problém odstraněný, ověřený a opětovné prohlížení neodhalilo související chyby, můžete tento úkol uzavřít. A je to. Nové požadavky si zaslouží samostatnou diskusi.