Autonomní AI kódovací agenti v produkci

Většina debat o AI kódovacích agentech uvízne na špatné otázce. Který model, který framework, které IDE. O tom, jestli agent přežije kontakt s produkčním repozitářem, přitom rozhoduje otázka mnohem užší a o dost méně zábavná: co musí platit, než se jeho kód dostane do hlavní větve?

Naše odpověď jsou čtyři pojistky. Agent dělá jen na issue, které mu přidělil člověk. Jeho plán schválí člověk dřív, než vznikne řádek kódu. Review běží v oddělených kolech ještě před pull requestem. A žádný agent nemerguje vlastní práci.

Provozujeme malou flotilu agentů na vlastní práci a jeden z nich píše kód. Otevírá pull requesty v repozitářích, na kterých stojí náš byznys, aniž by ho někdo spouštěl ručně. Není to demo prostředí a tlačítko zpět tam nikdo nemá.

Tři z těch pojistek sedí na samotném kódovacím agentovi. Čtvrtá platí pro každého agenta, kterého provozujeme. Žádná z nich není chytrá a všechny čtyři vypadají jako byrokracie přesně do chvíle, než vás poprvé zachrání.

Náš kódovací agent si práci nikdy nebere sám. Neprohledává backlog, jestli se tam nenajde něco, co by mu sedlo. Nebere si nepřidělené issue a nepřebírá cizí. Reaguje na jedinou věc: na GitHub issue, které mu výslovně přidělil člověk.

Zní to jako omezení agenta. Ve skutečnosti je to omezení škody, kterou stihne napáchat. Agent, který si vybírá práci sám, má z definice neohraničený rozsah. A jakmile rozsah ohraničený není, už nedokážete říct, co vlastně měl úkol udělat. Každá otázka, kterou si položíte později, se vrací k přidělení. Proč sáhl do toho souboru? Kdo to chtěl? Patřilo to do zadání?

Přidělení je zároveň nejlevnější systém oprávnění, jaký kdy postavíte. Není co konfigurovat, žádný policy engine. Někdo rozhodl, že úkol dostane právě tento agent, a to rozhodnutí zůstává v historii issue i se jménem.

Agent si přečte issue, napíše plán a zastaví se. Člověk ho schválí výslovně: reakcí 👍, štítkem approved, nebo komentářem, který to řekne natvrdo. Bez jednoho z toho nevznikne ani řádek kódu.

Podstatné je, že souhlas je zaznamenané rozhodnutí, ne dohad. Agent, který si smí souhlas vyvodit z konverzace, ho jednou najde ve zprávě, která žádný souhlas nebyla, a pak nikdo neukáže na okamžik, kdy práci někdo povolil. Reakce, štítek i vyslovené ano tuhle zkoušku vydrží. Vlákno, které vyšumělo, ne.

Je to také nejlevnější místo celé linky, kde jde špatnou práci zastavit, a jediné, kde se levně ptá, jestli to má vůbec vznikat. Přečíst plán trvá pár minut. Přečíst diff, který ze špatného plánu vznikl, trvá mnohem déle. A to už je na stole hotová práce, která si říká o to, aby se nezahodila.

Co pojistka neudělá? Práci nezlevní na nulu. Přesouvá náklad z psaní do čtení a u čtení člověk zůstává. Celá dohoda stojí právě na této výměně. Kdo vám prodává autonomní agenty jako způsob, jak nad prací přestat přemýšlet, prodává něco jiného.

Než pull request vznikne, projde práce několika oddělenými koly review a každé si nese vlastní otázku. Dělá kód to, co sliboval plán? Jaká rizika přináší, bezpečnost na prvním místě? Udrží to po nás další člověk?

Několik kol proto, že jednomu se nedá věřit. Jediné kolo, které má najít všechno, obvykle najde to, čeho si všimlo nejdřív, a pak k tomu napíše sebejisté shrnutí. Když práci rozdělíte, dostane každé kolo jednu úzkou otázku. A jen na úzkou otázku odpoví reviewer dobře. Kolo, které nic vážného nenajde, review ukončí, pokud změna nesahá na něco citlivého. Čistá změna tak neplatí za obřad, který nepotřebuje.

Všimněte si, co review záměrně neotevírá: rozhodnutí, která už padla v plánu. Ta otázka patří k pojistce 2 a tam je mnohem levnější. Jakmile existuje diff, stojí „mělo to vůbec vzniknout“ přepsání místo komentáře. Dobře popsaný nesmysl vám agent naimplementuje svědomitě a kvalitně, a jediné levné místo, kde se to dá zachytit, je dřív, než začne.

V celé organizaci platí jedno pravidlo a nemá výjimky. Agenti nemergují autonomně a nikdy nemergují změny vlastní konfigurace. Merge proběhne mimo agenta, až když člověk schválí přesně ten commit.

Nebezpečná je právě ta konfigurace. Agent, který smí mergovat změny vlastní konfigurace, si dokáže rozšířit oprávnění, a nemusí k tomu mít žádný úmysl. Stačí jeden věrohodně vypadající pull request, který pravidlo uvolní, a merge od toho, koho to pravidlo omezuje. Hranice je pryč, aniž by ji kdokoli vědomě zrušil. Merge mimo agenta drží všechny ostatní pojistky, protože je to jediná z nich, kterou agent nemůže obejít.

Nejde přitom o kvalitu kódu. Pravidlo bychom drželi, i kdyby agent psal kód líp než my. Governance řeší, kdo má jaké oprávnění, ne kdo píše hezčí funkce.

Obvyklá námitka zní, že při silné pipeline je lidský merge zbytečný. Ať rozhodnou testy, linter a bezpečnostní sken, a merguje se na zelenou.

U selhání, kvůli kterým CI vzniklo, to platí. U tohoto ne. CI kontroluje změnu podle pravidel, která už existují, a nám jde právě o změnu těch pravidel. Pull request, který uvolní oprávnění, vyhodí kontrolu nebo rozšíří allow-list, projde každým testem v sadě. Nic v té sadě totiž nebylo napsané tak, aby se ozvalo. Zelená znamená „souhlasí se stávající konfigurací“, a upravuje se právě ta konfigurace.

V menším měřítku se stejná mezera ukáže i u běžného kódu. Testy potvrdí chování, které někoho napadlo popsat. Na otázku, jestli ta funkce má vůbec existovat, žádný test není. A je to přesně ta otázka, kterou si agent o vlastní práci umí položit nejhůř.

Pojistky fungují jen do té míry, do jaké reviewer vidí, co schvaluje. Na jednom z našich projektů už každý pull request dostane vlastní preview prostředí, které se automaticky nasadí v Coolify.

Z diffu poznáte, jestli kód vypadá správně. Z preview poznáte, jestli ta věc funguje. To jsou dvě různé otázky. U změn od agenta váží ta druhá víc než dřív, protože se autora nedá smysluplně zeptat, jestli si to zkusil. Když je běžící verze na jedno kliknutí, je review skutečná kontrola, a ne formalita, která se jen proroluje.

Celá flotila nás stojí zhruba 400 $ měsíčně, asi 8 500 Kč. Dva lidé, kteří by dělali srovnatelnou rutinu, by nás vyšli někde kolem 400 000 Kč měsíčně. To je zhruba sedmačtyřicetinásobek.

Čtěte to číslo opatrně, protože se snadno přečte jako něco, co není. Není to měření produktivity a není to plán headcountu. Malý tým si za to reálně kupuje možnost nasadit lidi na vlastní produkty místo na rutinní vnitřní provoz. V našich repozitářích ležely pull requesty tři měsíce, protože nikdy nebyly ničí priorita. A ničí priorita nebyly proto, že ta práce byla skutečná, ale malá. Přesně takovou práci teď agenti berou.

Něco to číslo také zamlčuje, a je to totéž, co zamlčí každé srovnání od dodavatele. Všechny čtyři pojistky spotřebovávají lidskou pozornost: plán ke schválení, nálezy z review k přečtení, merge k provedení. Ten čas je reálný, roste s počtem agentů a ve 400 $ není. Kdo vám nabídne cenu agenta bez ceny review, dává vám půlku rovnice.

Pokud pouštíte kódovací agenty kamkoli do blízkosti produkčního repozitáře, zaveďte tyto čtyři věci v tomto pořadí:

Nic z toho nezávisí na tom, jaký model používáte, a právě o to jde. Modely se budou dál zlepšovat, náklad na review bude dál klesat, a obejít kterékoli z těch čtyř pravidel nebude levnější než dnes.

Jestli chcete tuto debatu vést nad svými repozitáři místo nad našimi, jsou tu naše práce na AI platformě a zavádění agentů ve velkých firmách. Jestli jste teprve na začátku a řešíte, co pro váš tým agentní vývoj znamená, začněte u agentic codingu a u toho, jak přemýšlíme o řízení toho, co agent smí volat.