Agenti v CI jako kontrolní brána, ne jako generátor kódu

Dvě různé role pro stejný nástroj

Když se dnes mluví o agentech ve vývoji, myslí se tím skoro vždy psaní kódu. Agent dostane zadání, napíše funkci, spustí testy a otevře pull request. Je to působivé a v malých, dobře ohraničených úkolech to funguje.

Problém je v tom, co se stane, když se splete. Vygenerovaný kód vypadá hotově. Je správně naformátovaný, má komentáře, prošel linterem. Jestli dělá to, co má, se pozná až tím, že ho někdo přečte řádek po řádku, nebo až za běhu.

Druhá role je nudnější a tím pádem bezpečnější. Agent nic nepíše. Dostane diff, který se chystá do hlavní větve, a napíše, co na něm považuje za rizikové. Tím se role obrací: člověk už nekontroluje stroj, stroj upozorňuje člověka.

Proč se to dá zkontrolovat

Tohle je podle nás ten hlavní důvod, a přitom se o něm mluví nejmíň.

Když agent napíše „tenhle commit mění návratový typ funkce, kterou volá pět dalších míst, a žádné z nich se nezměnilo“, je to tvrzení o konkrétních řádcích. Ověření trvá pár vteřin: buď to tak je, nebo není. Když se agent splete, poznáte to okamžitě a nic to nestálo.

Když agent napíše funkci, žádné takové ověření neexistuje. Musíte přečíst celý kód a rozmyslet si, co dělá, což je přesně ta práce, kterou měl ušetřit.

Kontrola, u které poznáte falešný poplach za deset vteřin, se dá nasadit i tehdy, když se mýlí každou třetí. Generátor, u kterého to nepoznáte, ne.

Co taková brána hlídá dobře

Nejlíp fungují věci, které se špatně hlídají okem a dobře se popisují slovy. Z toho, co jsme si postupně nechali hlídat, se osvědčilo tohle:

• Drift závislostí. Nová verze knihovny, která se do větve dostala jako vedlejší efekt jiné práce. Člověk ji v diffu přeskočí, protože je to jeden řádek v lock souboru.
• Změna veřejného chování bez testu. Upravená funkce, kterou volá víc míst, a žádný nový test. Není to vždycky chyba, ale vždycky to stojí za otázku.
• Migrace schématu bez cesty zpět. Odebraný sloupec, přejmenovaná tabulka, změněný typ. Tady je cena za přehlédnutí nejvyšší a náklad na kontrolu nejnižší.
• Tajemství v diffu. Token, klíč nebo heslo, které se omylem dostalo do commitu. Na tohle existují i obyčejné nástroje a je rozumné mít obojí.
• Rozbitá hranice vrstev. Import z míst, odkud se importovat nemá. Statická pravidla to pokryjí jen do chvíle, než se objeví výjimka, kterou nikdo nezapsal.

Společné mají to, že odpověď je krátká a dá se na ni ukázat prstem.

Co o tom víme a co ne

Tady je potřeba být upřímný, protože kolem agentů ve vývoji se v roce 2026 píše hodně a měří málo.

Doporučení začít kontrolní branou místo generování je napříč zdroji konzistentní. Argument je pokaždé stejný: menší odpor při zavádění, menší riziko, snazší vyhodnocení. Zní to rozumně a odpovídá to naší zkušenosti.

Měřené výsledky k tomu ale nejsou. Nenašli jsme studii, která by porovnala tým s kontrolní bránou a tým bez ní na srovnatelných projektech a změřila, o kolik se zkrátil čas revize nebo kolik chyb se zachytilo dřív. Čísla, která kolují, pocházejí většinou od firem, které příslušný nástroj prodávají, a metodiku k nim nezveřejňují.

Takže: je to rozumný odhad podložený praxí, ne doložený fakt. Kdyby vám to někdo prodával s procenty, chtějte po něm metodiku.

Jak to máme u sebe

Nestavěli jsme na to nic nového. Spíš se ukázalo, že stejný princip už v našich systémech roky používáme na jiných místech.

V ClientDecku, našem systému pro řízení reklamních kampaní, prochází každý zásah do klientského účtu schvalovací frontou. Automatika navrhuje, člověk rozhoduje, a u každé změny zůstane jméno, důvod a termín kontroly. Je to přesně ta role, o které je tenhle text, jen v jiné doméně než kód.

V Indepanelu, vlastním hostingovém panelu, má nasazení kontroly, které musí projít, než se verze pustí k lidem, a automatický návrat zpět, když neprojdou. Agent tam nic nerozhoduje; rozhoduje pravidlo. Agent je užitečný o krok dřív, nad diffem, kde se pravidlo napsat nedá.

A v obsahovém hubu, kterým spravujeme texty pro weby skupiny, má kontrola podobu obyčejného skriptu: ověří odkazy, délky titulků, jestli má každý článek všechny jazykové verze. Není na tom nic chytrého, a právě proto se tomu dá věřit. Agent dává smysl až tam, kde se pravidlo nedá napsat dopředu.

Z toho plyne pořadí, které doporučujeme: nejdřív napsat pravidla, která jdou napsat, a teprve na zbytek pustit agenta. Opačné pořadí vede k tomu, že agent hlásí věci, které měl odchytit linter.

Kde to nefunguje

Nemá smysl zamlčovat, kde jsme narazili.

• Na velkých diffech. Čím větší změna, tím hůř agent pozná, co je podstatné. Brána tlačí k menším commitům, což je samo o sobě dobře, ale je to změna zvyku, ne nastavení.
• Když je nálezů moc. Kontrola, která u každého commitu napíše deset poznámek, se po týdnu přestane číst. Lepší je začít s jedinou věcí, kterou hlídá, a přidávat pomalu.
• Jako blokující krok. Agent, který neumí sestavu shodit, se dá zavést za odpoledne. Agent, který ji shodit umí, potřebuje důvěru, kterou si musí nejdřív vybudovat.
• U cizího kódu bez kontextu. Bez znalosti domény hlásí agent spoustu věcí, které jsou v daném projektu záměr.

Co si z toho odnést

Jestli s agenty ve vývoji začínáte, začněte tím, co se dá zkontrolovat. Jedna kontrola nad diffem, neblokující, s jedním jasným tématem. Za měsíc uvidíte, jestli vám hlásí věci, které byste jinak přehlédli, nebo jen šum. To je vyhodnocení, které zvládnete sami a nepotřebujete k němu cizí procenta.

Generování kódu tím neodepisujeme. Jen má smysl později, až víte, kde vám agent pomáhá a kde si vymýšlí, protože tohle poznání vám nikdo nedodá s nástrojem.

Stavíme a provozujeme vlastní systémy, takže tyhle věci neřešíme teoreticky. Jak vypadá zbytek skupiny, je na independency.cz.