Řízený agentní workflow. Jak používáme AI agenty

AI agent umí přečíst repozitář, navrhnout plán, změnit kód a spustit testy. Tím ještě nevzniká spolehlivý vývojový proces. Produkční tým musí vědět, kdo schválil záměr, jaká oprávnění agent dostal, co přesně ověřil a kdo změnu přijal.

V Rise proto používáme review-gated Shadow model. Agent připravuje změnu v izolovaném worktree, ale V1 se spouští ručně. Lidé schvalují plán, výjimky, merge i nasazení. Systém automatizuje opakovatelnou práci a uchovává důkazy.

Tento model doporučujeme týmům, které chtějí zrychlit implementaci, ale nechtějí se vzdát kontroly nad rozsahem, bezpečností a vydáním. Není automaticky nejrychlejší pro každý experiment. U malého vratného úkolu může být ad hoc zadání levnější.

1. Ad hoc prompting

   Rychlý start pro malý vratný úkol. Kontext, oprávnění a důkazy pokaždé závisí na člověku.

2. Review-gated Shadow

   Hodí se pro produkční tým, který potřebuje měřitelné brány, omezené opravy a lidský merge.

3. Autonomní továrna

   Vyžaduje silnou izolaci, observabilitu, nouzové zastavení a důvěru v automatické změny s větším dopadem.

Co znamená review-gated Shadow

Shadow neznamená, že agent jen sleduje člověka. Pracuje ve skutečném vývojovém toku, ale oprávnění měnit společný základ a produkci zůstává mimo jeho dosah.

Práce začíná WorkOrderem. Ten určuje cíl, povolený rozsah souborů, riziko, požadované kontroly a zakázané akce. Agent z něj připraví plán. Implementace začne až po schválení člověkem.

Jeden writer pak dostane vlastní worktree. Izolace omezuje situace, kdy si dvě relace přepíšou soubory nebo znehodnotí výsledky testů. Stejný princip popisují návody pro Codex a Claude Code worktrees.

1. Schválený WorkOrder

   Rozsah, riziko, oprávnění a požadované důkazy jsou známé předem.

2. Plán a lidské schválení

   Agent nejdřív vysvětlí postup, dotčené hranice a způsob ověření.

3. Izolovaná implementace

   Jeden writer pracuje v samostatném worktree s omezeným počtem oprav.

4. Přesné kontroly

   Deterministické příkazy ověří dohodnutý rozsah a vytvoří opakovatelné výsledky.

5. Nezávislé review a předání

   Čerstvý kontext prověří změnu. Evidence manifest dostane člověk, který rozhodne o mergi a deployi.

Neúspěšné kontroly vracejí změnu k implementaci. Nálezy z review ji vracejí do plánování.

Kontroly tvoří přesné příkazy projektu, ne obecný pokyn k otestování. Když kontrola selže, writer smí provést jen předem omezený počet oprav. Potom se změna zastaví a čeká na nové rozhodnutí.

Hotovou změnu čte reviewer s čerstvým kontextem. Neupravuje potichu práci writera. Nálezy vrací do plánování nebo vydá stanovisko. Evidence manifest zaznamená rozsah, příkazy, výsledky, známá rizika a otevřené otázky.

Poslední brána patří člověku. Agent neprovádí merge ani deploy. GitHub rulesets mohou technicky vyžadovat pull request, review a úspěšné status checks. Za přijetí rizika přesto odpovídá tým.

Co automatizujeme a co rozhodují lidé

Automatizace je vhodná tam, kde má stejný vstup vést ke stejnému kontrolovatelnému rozhodnutí. Lidská brána patří tam, kde je nutné posoudit obchodní souvislost, výjimku nebo dopad na provoz.

1. Automatizované kroky

   Validace kontraktu, dry-run, stavová pravidla, hooks, CI kontroly a sestavení důkazů.

2. Lidská rozhodnutí

   Schválení plánu, výjimky z rozsahu, přijetí rizika, merge, release a deploy.

V našem modelu se automatizují tyto části.

• Validace kontraktu kontroluje povinná pole a povolené příkazy ve WorkOrderu a workflow.
• Dry-run inicializace ukáže plánované soubory a změny bez zápisu do cílového projektu.
• Stavová a oprávnění pravidla v YouTracku hlídají povolené přechody a role. YouTrack workflows jsou určené pro podobná pravidla. YouTrack MCP poskytuje agentům řízené nástroje.
• Hooks zastaví zakázaný příkaz nebo spustí kontrolu v přesném okamžiku. Claude Code hooks jsou příkladem deterministické vrstvy kolem modelu.
• CI zopakuje důvěryhodné kontroly v čistém prostředí.
• Evidence manifest spojí vstupy, výsledky a review do jednoho předání.

Člověk dál schvaluje záměr, změnu rozsahu, bezpečnostní výjimku, přijetí rizika, merge, release a deploy. Tato hranice odpovídá také doporučením OWASP. Patří mezi ně minimální oprávnění, lidské schválení citlivých akcí, validace, auditní stopa a limity zdrojů.

Sedm workflow vyžaduje různá pravidla

Jedna univerzální šablona vypadá jednoduše, ale hotfix a výzkumný spike mají jiný cíl. K 24. červenci 2026 máme na úrovni kontraktu validováno sedm typů workflow. Živé integrace a oprávnění ověřujeme zvlášť pro každý projekt.

Limit neomezuje přemýšlení vývojáře. Brání agentovi opakovat stejnou strategii bez nového rozhodnutí.

Proč nestačí prompting nebo samotné CI

Ad hoc prompting se hodí pro malý a snadno vratný úkol. Jeho slabinou je paměť procesu. Rozsah, oprávnění a způsob ověření skládá operátor při každé relaci znovu.

CI řeší jinou vrstvu. Umí odmítnout změnu, která neprojde testem. Obvykle ale neví, zda agent směl upravit daný modul, zda plán schválil vlastník nebo zda další pokus ještě dává ekonomický smysl.

Review-gated Shadow přidává kontrakt před implementací a důkazy po ní. Je vhodnější pro produkční tým, který musí rozhodnutí později vysvětlit. Cenou je příprava WorkOrderu a čas u lidských bran.

Plně autonomní továrna může bez čekání zpracovat více nezávislých úloh. Potřebuje silnější izolaci, observabilitu, nouzové zastavení, správu identity a důvěru v automatický merge nebo deploy. Pro menší tým je to samostatný systém, ne volba v promptu.

Jak měřit přínos bez vymyšlených procent

Neuvádíme obecné procento úspory. Výsledek závisí na kvalitě repozitáře, testů, zadání i zkušenosti reviewera. Smysl má porovnat přijaté změny před a po zavedení workflow.

Sledujte čas od schváleného zadání po přijatou změnu, čistý review čas, počet oprav, regrese po vydání, zamítnuté nepovolené akce a cenu přijaté změny. Do výsledku patří i náklady na zamítnuté nebo nepoužitelné návrhy.

První týdny mají vytvořit výchozí stav. Teprve potom má smysl měnit limity, přidat další workflow nebo automatizovat další bránu.

Kde začít

Začněte jedním typem opakované změny, jedním repozitářem a ručním spuštěním. Definujte WorkOrder, povolené příkazy, vlastníka schválení a důkazy vyžadované při předání. Nejdřív spusťte dry-run.

Starší článek o člověku ve smyčce při AI vývoji vysvětluje, proč zůstává odborný úsudek potřebný. Governance checklist pro AI agenta doplňuje data, nástroje a nouzové zastavení.

Pokud teprve vybíráte vhodný proces, podívejte se na službu AI automatizace. Řízený agentní workflow dává smysl až tehdy, když tým umí určit odpovědnost, zakázané akce a způsob přijetí hotové změny.