Představme si programátora, který si nechá od AI opravit výpočet ceny objednávky. Agent upraví funkci, přidá test a oznámí, že je hotovo. Člověk se podívá na zelený výsledek a změnu přijme. Jenže test vychází ze stejného nepochopení slevy jako samotná oprava. Všechno souhlasí, až na cenu, kterou má zákazník zaplatit.
Poslat takovou změnu druhému agentovi je rozumný nápad. Nástroj cc-pair právě tuhle práci organizuje: Claude Code a Codex si předávají revize, připomínky a opravy. Podle nás je na něm nejzajímavější obyčejná věc, kterou automatizuje — autor nemá být jediným člověkem, nebo v tomto případě jediným systémem, který posuzuje vlastní výsledek. Souhlas dvou modelů ovšem pořád není důkaz, že zadání pochopily správně.
Druhý pár očí, nikoli další tlačítko „vylepši“
V rychlé zprávě o cc-pair jsme popsali jednoduché uspořádání: oba agenti běží v samostatných terminálových relacích a komunikují přes sdílený adresář na disku. Podle dokumentace projektu může být autorem kterýkoli z nich. Jeden dokončí úkol a pošle žádost o kontrolu, druhý vrátí očíslované připomínky se závažností a verdiktem.
Autor má každý nález ověřit, opravit skutečný problém a znovu požádat o kontrolu. Připomínku může také odmítnout, ale musí uvést důvod. Výchozí postup po třech kolech, v nichž stále zůstává požadavek na změny, předá spor člověku. Není to nekonečná debata dvou chatbotů, kteří mají za každou cenu vyrobit dohodu.
Takto pojatá AI kontrola kódu má proti prostému „podívej se na svou práci ještě jednou“ konkrétní výhodu: vytváří oddělenou roli oponenta a záznam sporu. Ve zprávách zůstává, co bylo vytknuto a jak na to autor reagoval. Nástroj přitom sám neposuzuje, jestli je oprava správná. Organizuje výměnu názorů; jejich technický obsah dodávají agenti.
To je důležitý rozdíl i pro člověka, který programování teprve zkouší. Dlouhý seznam připomínek může působit jako důkladný audit, ačkoli obsahuje jen stylistické preference. Naopak jedna stručná poznámka o chybějící kontrole oprávnění může být zásadní. Kvalitu revize neurčuje délka odpovědi, ale to, zda pojmenuje problém a umožní ho ověřit.
Dva různí výrobci neznamenají dvě nezávislé pravdy
Spojení Claude Code a Codexu svádí k příjemné zkratce: když se shodnou systémy od různých firem, výsledek musí být spolehlivější. Jako pracovní hypotéza je to rozumné. Jako záruka už ne. Oba mohou dostat stejné neúplné zadání, číst stejnou zastaralou dokumentaci a přehlédnout stejný obchodní požadavek.
V příkladu s objednávkou může druhý agent správně zkontrolovat syntaxi, okrajové vstupy i nově napsaný test. Jestli ale nikdo neuvede, zda sleva platí před dopravou, nebo po ní, kontroluje program proti pravidlu, které si musí sám doplnit. Tohle není doložené selhání cc-pair, ale běžný logický problém takového uspořádání: dvě kontroly neúplného zadání z něj úplné zadání neudělají.
Oponent proto potřebuje původní požadavek, skutečné změny v souborech a možnost ověřit jejich chování. Neměl by dostat jen autorovu uklidňující zprávu, že vše funguje. Projekt v návrhu protokolu počítá se shrnutím a seznamem souborů, které si recenzent přečte ve společném repozitáři. Je na týmu, aby k této výměně přidal i přesné podmínky přijetí změny.
Dokumentace cc-pair neobsahuje srovnávací měření, ze kterého by šlo určit, kolik chyb tato dvojice zachytí navíc nebo kolik času ušetří. Ukazuje konkrétní revizi se záměrně vloženou chybou; to je ukázka postupu, ne benchmark spolehlivosti. Vlastní provozní test jsme neprováděli. Není proto důvod prodávat projekt jako už prokázaný lék na chyby agentů.
Rozhodovat mají výsledky testů, ne většina hlasů
Nejužitečnější připomínka druhého agenta je taková, kterou lze převést na pozorovatelnou kontrolu. U výpočtu ceny jde o konkrétní objednávku a očekávanou částku podle obchodních pravidel. U stránkování o poslední neúplnou stránku. U přístupu k dokumentům o pokus běžného uživatele přečíst cizí soubor. Agent může navrhnout, kde hledat; výsledek má potvrdit chování programu.
Přesně vymezené testy mají zároveň omezený dosah. Test cen nepotvrdí správnost přístupových práv a kontrola názvů databázových sloupců nepotvrdí správný účetní závěr. Na Radyz jsme tento rozdíl rozebírali u schema-guard a jeho kontroly SQL. Zelená kontrolka má význam jen tehdy, když víme, co přesně zkontrolovala.
Jinou cestu popisuje pilot Truth Firewall pro ověřování dokončených úloh: porovnává výsledek agenta s předem zadanými akceptačními kontrolami. Ani ten podle vlastního popisu nedokazuje úplnou správnost. Rozdíl proti vzájemné revizi je však podstatný — nespoléhá jen na názor dalšího modelu, ale také na konkrétní podmínky, které výsledek musí splnit.
Podle nás je správné tyto přístupy spojovat, ne je stavět proti sobě. Modelový oponent má hledat přehlédnuté souvislosti, test má ověřovat dohodnuté chování a člověk má rozhodovat o požadavcích a následcích. U rutinní opravy si lze dovolit lehčí kontrolu. U plateb, přístupových práv nebo zásahu do databáze je pohodlí autora špatný důvod ke zkrácení ověřování.
Nejcennější funkce může být chvíle, kdy se práce zastaví
Tři kola a potom člověk znějí méně atraktivně než plně autonomní vývoj. Právě tahle brzda je ale dobrý redakční důvod projekt sledovat. Spor se nemusí vyřešit tím, že jeden model konečně ustoupí. Může ukazovat na nejasné zadání, chybějící podklad nebo skutečné rozhodnutí, které nelze přenést na automatickou výměnu připomínek.
Také samotná komunikace má provozní hranice. Návrh protokolu a seznam známých omezení uvádí, že oba agenti musí pracovat ve stejném pracovním stromu Gitu, aby recenzent četl autorovy soubory. Oddělené pracovní stromy mají vlastní kanály. To pomáhá rozlišovat souběžné dvojice, ale dva terminály nad stejnými soubory nejsou dvě izolované kopie práce.
Nastavení navíc vyžaduje, aby oba agenti mohli zapisovat do společného komunikačního adresáře. Technika označovaná jako sandboxing omezuje, kam proces smí zasahovat; povolení sdíleného adresáře je konkrétní výjimka, ne důvod otevřít celý disk. Zprávy se ukládají lokálně, z toho ovšem nelze vyvozovat, že i zpracování kódu oběma AI probíhá bez odesílání dat jejich poskytovatelům. Místo předávání zpráv a místo inference jsou různé věci.
Před nasazením si má tým určit, jaká data smějí oba agenti číst, které testy jsou povinné a kdo smí změnu začlenit. Vyplatí se rovnou stanovit i časový a nákladový limit revize. Druhý agent může přinést užitečný nález, ale další kola nejsou zdarma a počet připomínek není měřítko přínosu. Smysluplné srovnání sleduje dokončené úlohy, nalezené skutečné chyby a práci, která zůstala člověku.
cc-pair nám nepřináší důvod pustit dva agenty bez dozoru do produkce. Přináší čitelnější způsob, jak mezi ně rozdělit práci a kontrolu. To je střízlivý, praktický přínos, který nepotřebuje slib bezchybného softwaru. Druhý agent má být oponent, ne alibi pro prvního — a už vůbec ne alibi pro člověka, který změnu schválí.
