VM0 dev workflow: Řízení AI agentů jako týmu

V týmu VM0 dev každý vývojář pracuje současně s několika instancemi Claude Code. Obvykle s více než osmi.

K agentovi Claude Code přistupujeme stejně jako ke skutečnému vývojáři. (Ano, naše firma se napůl v žertu jmenuje AI Colleagues Co!)

Proto filozofie návrhu VM0 dev workflow odráží klasické postupy týmového řízení v softwarovém inženýrství.

Používáme GitHub Issues ke sledování práce, Pull Requests pro kontrolu a slučování kódu a GitHub Actions pro automatizaci. Za více než dva měsíce nám toto nastavení pomohlo vydat 404 verzí a napsat více než 230,000 řádků kódu.

Tento příspěvek vysvětluje, jak jsme workflow učinili funkčním a proč hlavním problémem nikdy nebyly schopnosti AI, ale lidská koordinace.

AI-poháněný dev workflow v praxi

Když koordinujete více AI agentů paralelně, úzkým hrdlem není to, zda model umí psát kód. Skutečným limitem je kognitivní zátěž člověka.

Tento workflow se skládá z 14 slash příkazů, rozdělených do tří vrstev: Deep Dive, Správa Issues a Správa PR.

Podívejme se nejprve, jak vypadá můj workflow a jak se obvykle staví nová funkce.

Sjednocení požadavků

Člověk otevře relaci s Claudem a začne /deep-research. Claude shromáždí fakta z kódu, dokumentace a relevantního kontextu. Diskutujeme zjištění a sjednotíme se na tom, jaký problém vlastně řešíme.
Hledání řešení

Pomocí /deep-innovate Claude navrhne několik možných směrů s jejich výhodami a nevýhodami. Diskutujeme, zúžíme výběr a zvolíme směr.
Vytvoření issue

Vytvoříme GitHub issue pomocí /issue-create. Člověk issue zkontroluje, aby byly požadavky jasně zachyceny.
Plánování a schválení

Pomocí /issue-plan necháme Clauda pokračovat v práci. Claude automaticky spustí celý deep-dive workflow a výsledky zveřejní do issue, včetně:
1. zjištění z /deep-research
2. srovnání z /deep-innovate
3. konkrétního implementačního plánu z /deep-plan
Implementace

Po schválení /issue-action umožní Claudovi realizovat plán, napsat testy, otevřít PR a zajistit úspěšné CI.
Kontrola a sloučení

Používáme /pr-review pro strukturovanou kontrolu, poté provádíme finální lidskou revizi před sloučením.

Člověk zasahuje ve třech bodech: požadavky, směr a akceptace. Vše ostatní běží autonomně.

Změna myšlení: vedete tým AI vývojářů

Okamžik, kdy jsem si uvědomil, že potřebujeme strukturovaný workflow, nastal, když přidání dalších relací Claude situaci zhoršilo. Čím více instancí jsem spustil paralelně, tím těžší bylo sledovat, co která dělá, v jakém je stavu a co už bylo rozhodnuto.

Bez externích nástrojů jsem prostě nedokázal spravovat tolik instancí Claude najednou. Tehdy mi došlo: tohle není problém AI, ale řízení.

GitHub je přirozený nástroj pro spolupráci v softwarovém vývoji, takže místo vymýšlení něčeho nového jsem začal Clauda brát jako lidského kolegu. Jakmile jsem to udělal, moje kapacita řízení se najednou rozšířila.

Deset let zkušeností s řízením projektů a týmů najednou dávalo v tomto novém kontextu smysl. Když jsem Clauda bral jako člena týmu a GitHub jako společný komunikační a řídicí prostor, celý systém byl opět zvládnutelný.

Dobrý vedoucí týmu ví, kdy zasáhnout a kdy ustoupit:

Kontrolní bod	Co dělám já	Co dělá AI
Požadavky	Sjednotit problém, upřesnit rozsah	Prozkoumat kód, shromáždit kontext
Směr	Zkontrolovat zjištění, schválit přístup	Navrhnout 2-3 přístupů, zhodnotit kompromisy
Akceptace	Zkontrolovat PR, ověřit kvalitu	Implementovat, testovat, opravit CI

To odráží fungování efektivních softwarových týmů. Vývojáře nemikromanažuji, ale stanovím jasné požadavky, zkontroluji klíčová rozhodnutí a ověřím výsledek. Stejný princip platí při řízení AI agentů.

Deep dive flow vynucuje strukturované, pomalé myšlení

Deep dive workflow vynucuje promyšlené uvažování před implementací. Někdy Claude narazí na slepou uličku. Když se to stane, donutíme Clauda zastavit a společně to prodiskutujeme. Má tři fáze:

Fáze	Příkaz	Účel	Výstup
Výzkum	/deep-research	Shromáždit fakta, pochopit kontext	research.md
Inovace	/deep-innovation	Prozkoumat více přístupů	innovate.md
Plán	/deep-plan	Definovat konkrétní kroky	plan.md

Každá fáze má přísné hranice.

Výzkum: žádné návrhy
Inovace: žádné detaily
Plán: žádná implementace

Tato omezení nutí Clauda k pomalému, promyšlenému uvažování místo okamžitého psaní kódu. Bez nich se často přehlédnou okrajové případy a architektonické otázky!

Příklad použití

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

U jednoduchých úkolů můžete deep dive přeskočit a jít rovnou na /issue-create.

U složitých úkolů s technickou nejistotou deep dive fáze pomáhají zajistit, že jste s Claudem sladěni ještě před zahájením implementace.

Používejte GitHub jako sdílenou paměť

Většina AI nástrojů považuje kontext za dočasný. Po ukončení relace paměť mizí.

VM0 používá GitHub jako trvalou paměť:

GitHub funkce	Co ukládá
Issue body	Požadavky a rozhodnutí
Komentáře k issue	Výzkum, možnosti, plány
Komentáře k PR	Recenze a shrnutí
Štítky	Stav workflow

To řeší i lidský problém: obnovení kontextu.

Když spravuji 8+ instancí Claude, dostávám oznámení o dokončení práce. Ale nedokážu z Claudeovy konverzace zjistit, co dělal, jaká rozhodnutí padla nebo jaký je aktuální stav.

GitHub issues to řeší. Každé issue zobrazuje:

Původní požadavky
Výsledky výzkumu (co bylo zjištěno)
Fázi inovace (jaké možnosti byly zvažovány)
Schválený plán (co bude implementováno)

Tento strukturovaný formát zefektivňuje kontrolu. Mohu rychle projít fáze, pochopit přístup a schválit nebo požádat o změny, aniž bych si musel pamatovat původní konverzaci.

Po dokončení práce si nemusím pamatovat, co se odehrálo v chatu. Stačí otevřít issue a vidím celý příběh, strukturovaně zaznamenaný.

Předávání mezi agenty

Protože veškerý kontext je na GitHubu, práce může plynule přecházet mezi agenty:

Jeden agent vytvoří issue nebo PR
Jiný pokračuje později pomocí /deep-research issue 123 nebo /issue-plan 123 nebo /deep-research PR 124

U dlouhých diskusí /issue-compact vše konsoliduje do přehledného těla issue. To usnadňuje předání jak lidem, tak AI.

Shrnutí workflow vzorů

Po tom všem shrnu několik praktických tipů.

Jednoduché úkoly

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Použijte, když jsou požadavky jasné a práce přímočará.

Složité úkoly

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

To zabrání plýtvání úsilím na špatném postupu.

Paralelní práce

Více agentů může pracovat současně, zatímco člověk kontroluje dokončené kontrolní body. Zde workflow škáluje nejlépe.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Přehled příkazů

Deep dive příkazy

Příkaz	Účel
`/deep-research`	Shromáždit informace, pochopit kód. Žádné návrhy povoleny.
`/deep-innovate`	Prozkoumat 2-3 přístupů, zhodnotit kompromisy. Žádný kód povolen.
`/deep-plan`	Vytvořit konkrétní kroky implementace. Žádná implementace povolena.

Issue příkazy

Příkaz	Účel
`/issue-create`	Vytvořit issue z kontextu konverzace
`/issue-bug`	Vytvořit hlášení chyby s kroky k reprodukci
`/issue-feature`	Vytvořit požadavek na funkci zaměřený na požadavky
`/issue-plan`	Spustit celý deep-dive workflow, zveřejnit výsledky do issue
`/issue-action`	Pokračovat v implementaci po lidském schválení
`/issue-compact`	Konsolidovat tělo issue + komentáře pro předání

PR příkazy

Příkaz	Účel
`/pr-check`	Sledovat CI pipeline, automaticky opravovat, opakovat až 3x
`/pr-review`	Kontrolovat PR po commitech podle projektových standardů
`/pr-comment`	Shrnout diskusi z konverzace do komentáře PR

Začínáme

Začněte jednoduše: Použijte /issue-create → /issue-plan → /issue-action pro svůj první úkol
Přidejte deep dive pro složité úkoly: Když jsou požadavky nejasné nebo technicky složité, začněte /deep-research
Škálujte postupně: Přidávejte další instance Claude, jakmile si zvyknete na rytmus kontrol
Důvěřujte procesu: Nechte Clauda pracovat autonomně mezi kontrolními body

Workflow je navržen pro postupné zavádění. Nemusíte používat všech 14 příkazů hned od začátku. Začněte základním issue flow, poté přidejte deep dive fáze a paralelní práci, jakmile získáte jistotu.

Úvahy o škálování: Co dělat, když máte více agentů

Workflow byl testován s 10+ paralelními instancemi Claude. Naše doporučení:

Až 10 agentů: Pohodlné pro hlubokou spolupráci s každým
Nad 10: Nedoporučujeme

Omezujícím faktorem není workflow, ale lidská pozornost a kvalita rozhodnutí. Při řízení více než 10 agentů riskujete, že se stanete úzkým hrdlem v kontrolních bodech a kvalita rozhodnutí začne klesat.

Platí zde klasický princip „tým na dvě pizzy“. Stejná omezení, která limitují velikost lidského týmu, omezují i počet AI agentů, které může jeden člověk efektivně řídit.

Aktuálně zkoumám dvouvrstvou týmovou strukturu 8×8 pro škálování nad 10 agentů, ale zatím jsem nevyvinul účinné postupy. Podělím se, až budou konkrétní výsledky…

VM0 dev workflow mění pohled na vývoj softwaru, když se AI stává součástí týmu.

Když AI agenty vnímáte jako členy týmu, ne jen jako nástroje, vše do sebe zapadne. GitHub se stává sdílenou pamětí týmu. Issues jsou pracovní úkoly. PR jsou výstupy. A vy jste vedoucí týmu, zaměřený na architekturu, směr a kvalitu, zatímco váš AI tým řeší implementaci.

Tak jsme vydali 404 verzí za 2 měsíce. A tak můžete škálovat i svůj vývoj s AI.