Anthropic představil v Claude Code novou funkci Dynamic workflows společně s modelem Opus 4.8. Je to veliký příslib. Práci, kterou byste běžně plánovali na měsíce, prý zvládne za dny. Claude si sám napíše orchestrační skript, který v jedné session spustí desítky až stovky paralelních subagentů, a než vám výsledek odevzdá, sám si ho zkontroluje. To zní jako zásadní posun. Stojí ale za to oddělit, co je opravdu nové, co je marketing a co teprve ukáže praxe.
Co mají být Dynamic Workflows
Dynamic Workflows jsou dalším pokusem Anthropicu nabídnout neotřelý pohled na používání AI agentů a tedy intenzifikaci vývojářské práce. Už to samo o sobě znamená, že nejsou nástrojem pro každého. Pro hobíka či vývojáře, který zatím neví, kam jej vývoj dovede, se příliš nehodí. Noopak zkušený vývojář, která má přesnou představu, jak má jeho aplikace vypadat, mohou být zajímavé.
Dynamic workflows jsou ve fázi research preview. Vyžadují Claude Code verze 2.1.154 nebo novější a běží na všech placených plánech včetně API. Dokumentace potvrzuje i Pro plán, kde se funkce zapíná ručně v /config v řádku Dynamic workflows. Pro většinu českých sólo vývojářů, kteří jsou na Pro, je to ta podstatná informace.
Spustit běh jde dvěma způsoby. Buď v promptu použijete slovo „workflow”, načež Claude napíše skript pro vaši úlohu, nebo přepnete /effort na novou hodnotu ultracode - tehdy Claude sám rozhoduje, kdy pro úlohu workflow nasadí, a nastaví úroveň úsilí na xhigh. U ultracode je ale namístě opatrnost: je to nejdražší stupeň úsilí, mění na workflow prakticky každý prompt a obchází řadu potvrzení, takže náklady rostou rychle. Pro osahání funkce je to spíš špatná první volba.
Jak to funguje technicky
Dynamic workflow je v jádru JavaScriptový skript, který orchestruje subagenty ve velkém měřítku. Claude ho napíše pro úlohu, kterou popíšete, a runtime ho spustí na pozadí, zatímco vaše session zůstává responzivní.
Když se běh rozjede, Claude rozloží úlohu na podúlohy a rozhodí práci mezi paralelní agenty. Výsledky se ověřují, než se začlique dál. Část agentů řeší problém z nezávislých úhlů, jiní se snaží jejich nálezy vyvrátit, a běh iteruje, dokud se odpovědi nesblíží. Postup se průběžně ukládá, takže přerušený běh pokračuje tam, kde skončil. Koordinace probíhá mimo konverzaci, což má udržet plán na kolejích i u velkých úloh.
Čím se to liší od běžného týmu subagentů, který Claude Code uměl už dřív? Podle vývojářského týmu Anthropic dvěma věcmi: podporou o jeden až dva řády většího počtu agentů a fázovaným, polostrukturovaným postupem, kde práce probíhá po krocích. A může to být fičák. S nastavením ultracode může běh spustit až 1 000 paralelních subagentů. K dispozici jsou i schémata pro strukturované výstupy, předávání argumentů, rozpočty na tokeny a automatické opakování selhavších agentů. Z vašich tokenů se bude jen kouřit.
Důležitá info pro každého, kdo chce mít proces pod kontrolou: Claude Code před spuštěním ukáže plánovaný workflow s fázemi, počtem agentů, součtem tokenů a uplynulým časem, a nabídne volbu prohlédnout si vygenerovaný orchestrační skript přes „Show the raw script”. Nemusíte tedy kód pustit naslepo - máte možnost si přečíst, co se chystá běžet, a běh zrušit, pokud zadání bylo příliš široké. V auto módu se ovšem potvrzení objeví jen při prvním spuštění daného workflow, a přes claude -p nebo Agent SDK je potvrzení vypnuté úplně. Stojí za to to vědět, než si funkci pustíte v automatizaci, protože bude asi lepší si to celé osahat před tím, než to spustíte automatizovaně.
Kam workflows patří mezi ostatními nástroji
Než začnete řešit, jestli workflows použít, vyplatí se zařadit si je jako nejvyšší a nejdražší stupeň žebříčku, který Claude Code nabízí. Zdola nahoru: prostě se zeptat Clauda, vytvořit opakovatelný Skill, předat úlohu Subagentovi běžícímu paralelně s vaší session, sestavit Agent Team, kde spolu agenti komunikují, nasadit /goal pro úlohu opakovanou ve smyčce, a teprve nakonec Dynamic Workflow pro obří paralelní práci. Každý vyšší stupeň přidává složitost, výkon i náklad a riziko. A bylo by dobré si uvědomit, že pokud jste nezvládli předchozí stupeň, pouštět se do následujícího bude spíše overkill pro vaši práci.
Klíčové pro nás budiž rozlišení mezi /goal a workflow, protože se snadno spletou.
/goal je hloubka: jeden agent, který může spouštět další, běží ve smyčce a opakovaně kontroluje, jestli je úloha hotová, dokud nesplní zadané kritérium.
Workflow je šířka: desítky agentů běžících současně vedle sebe, každý na své části, výsledky se na konci sloučí. Neběží vstříc cílové čáře, vykonají plán nastavený na začátku a vrátí výsledek. Z toho plyne praktické vodítko: pokud se úloha rozpadá na mnoho kusů, které mohou běžet nezávisle a současně (revize každého souboru v projektu, migrace stovek souborů, riziková práce, kde chcete na každý kus maximum výpočtu) sedí workflow. Pro jednotlivé úpravy, rychlé dotazy a běžnou znalostní práci sáhněte po nižším stupni.
Jediný velký důkaz - a proč k němu být skeptický
Tohle přeskočte, pokud vás nezajímá rozšťourávání marketingových tvrzení.
Hlavním referenčním příkladem, který Anthropic uvádí, je nedávný přepis runtime Bun. Jarred Sumner s pomocí Dynamic Workflows portoval Bun ze Zigu do Rustu - zhruba 750 tisíc řádků Rustu, 99,8 % původní testovací sady prošlo, jedenáct dní od prvního commitu po merge. Jeden workflow namapoval správnou Rust lifetime pro každé pole struktury v původním kódu, další napsal každý soubor jako chováním identický port, stovky agentů pracovaly paralelně se dvěma recenzenty na každém souboru. To zní jako bombovní úspěch. Jenže když se dopátráme detailů, tak uvidíme, že to není tak jednoduché.
Za prvé, jde o mechanický refaktor. Kritici v komunitě upozorňují, že mechanické refaktory zvládají agenti relativně snadno i bez nové funkce, takže Bun nedokazuje, že workflows přidávají něco navíc. Za druhé, port běží v canary režimu a do produkce zatím nešel - sám Anthropic to v textu uvádí. Za třetí, a to je nejzávažnější: PR má 6 755 commitů a podle dostupných analýz ani jeden řádek nenapsal člověk. Recenzentský seznam mluví jasně - schválily ho boti, zatímco jediný lidský recenzent na pull request ani nestihl pohlédnout. Kód napsal Claude, zkontroloval Claude. Z toho plyne kritika, která se po vydání opakuje: celou codebase nikdo z lidí nepřečetl, což z ní pro správce dělá černou skříňku, jejíž cena se ukáže až při ladění nějakého budoucího vážného incidentu. Sumner sám připustil, že problémy s pamětí na přechodech přes hranice JavaScriptu Rust kompilátor neřeší a stále se spoléhají na lidský dohled.
Canary build je noční, experimentální sestavení z aktuálního stavu hlavní větve, které si nainstaluješ příkazem
bun upgrade --canary. Není to verze s číslem, kterou dostane běžný uživatel, je to bleeding edge pro ty, kdo chtějí testovat nejnovější změny a hlásit chyby. Název Canary se odvolává na testovací papušky…
Ke kompatibilitě testů patří ještě jedna výhrada. Objevila se obvinění, že některé testy byly upraveny tak, aby je verze v Rustu prošla, a že se vynořují chyby, které v původní Zig verzi nebyly. Číslo 99,8 % tedy neznamená tolik, kolik na první pohled slibuje - testovací sada ověřuje známé chování na známých cestách, ne robustnost v hraničních případech, chování pod zátěží nebo souběh.
Bun je tedy spíš ukázka odvahy a měřítka než důkaz spolehlivosti. Jako jediný velký referenční příběh pro novou funkci je to slabší základ, než jak ho marketing podává.
Hlavní spor: nástroj, nebo způsob, jak spálit víc tokenů?
Tohle je jádro debaty, která se rozjela pod oznámením. Dominantní reakce skeptiků zní, že jde o tokenmaxxing převlečený za produkt - tedy způsob, jak uživatele přimět spotřebovat mnohem víc tokenů, aniž by si toho všiml.
Na tom stojí druhá, věcnější námitka. Nejvýše hodnocený komentář pod oznámením říká, že úzkým hrdlem dnes není, jak rychle Claude prochází kódem, ale jestli úlohu udělá správně. Vývojáři potřebují spíš mechanismy pro řízení dlouhých běhů a vkládání korekcí za chodu než rychlejší způsob, jak spálit tokeny bez jistoty výsledku. Stačí jeden drobný špatný krok v plánu a padesát agentů sebevědomě staví na halucinovaném předpokladu. Plánovač proto musí být konzervativnější než pracovní agenti, ne chytřejší.
Jak velký ten cenový rozdíl reálně je? Anthropic sám u běžného používání Claude Code uvádí, že 90 % uživatelů zůstává pod 30 dolary za aktivní den a průměr se pohybuje kolem 13 dolarů na vývojáře a den. Dynamic workflows jsou ale jiná kategorie. Nejnázornější je zkušenost jednoho tvůrce obsahu, který funkci týden zkoušel: jeden jediný prompt mu spotřeboval polovinu měsíčního plánu za 200 dolarů během zhruba třiceti minut. Příčina je poučná - nechal workflow prohledat celý svůj desktop, takže agenti procházeli každý lokální soubor i repozitář. Neohraničené zadání rovná se hořící plán a spotřeba. Jiný jeho běh, audit jednačtyřiceti vlastních konfiguračních balíčků, spotřeboval zhruba pět milionů vstupních tokenů, protože spustil jednačtyřicet agentů naráz, každého s vlastním kontextovým oknem, které musí někdo načíst. To je podstata nákladu: každý agent je plné volání Clauda s vlastním oknem, a stačí jich spustit hodně, aby účet vylétl ke stropu. Jde o jednu zkušenost, ne o měření, ale směr potvrzuje varování samotného Anthropicu: jeden neopatrný běh dokáže spotřebovat násobek toho, co byste za běžnou práci utratili za celý den.
Pro vyváženost je nutné uvést druhou stranu. Boris Cherny z týmu Claude Code vyjmenoval, na co reálně funkci interně použil za posledních pár týdnů: autonomně dodal přes 20 optimalizací snižujících tokenovou náročnost Claude Code asi o 15 %, portoval tree-sitter, color-diff, yoga-layout a další moduly do TypeScriptu se zlepšením CPU a paměti dvoj- až desetinásobně, zrychlil CI a opakovaně hledal a opravoval flaky testy, snížil startup Claude Agent SDK o 61 % a dodal 69 PR zjednodušujících kód s odstraněním přes deset tisíc řádků. To jsou konkrétní, kontrolovatelné příklady, a je férové je postavit proti paušální skepsi. Rozdíl mezi tokenmaxxingem a užitečnou prací zjevně nebude ve funkci samotné, ale v tom, na jakou úlohu a jak ji nasadíte.
V použitelnosti Dynamic Workflows nakonec tedy rozhodne to, jak se Anthropicu podaří vyvážit přínos (tedy výsledek) a objem spotřebovaných tokenů (tedy náklady). Proto tento spor vlastně i zmiňuju, ve skutečnosti o nic jiného nejde, než náklady versus přínosy.
Reálná rizika, která marketing neřeší
Z dosavadních reakcí se dají vypíchnout čtyři problémy, o kterých oznámení mlčí.
Conflict resolution. Spustit agenty je snadná část. Těžké je vyřešit situaci, kdy dva z nich sáhnou na stejný soubor a neshodnou se na opravě. Tohle opakovaně zmiňují lidé, kteří podobné věci stavěli ručně měsíce, a u nové funkce zatím není jasné, jak to řeší.
Drift od záměru. U čehokoli většího než drobná komponenta agenti utíkají od toho, co bylo zamýšleno. Čas se pak přesouvá k podezíravé kontrole výstupu, jestli agent nepropašoval změnu nebo neporušil nějaký invariant. Konkrétní obrázek dává reportáž po launchi: jeden vývojář popsal session, kde se Claude pokusil spustit 47 souběžných agentů, úspěšně jich nastartoval 25 a během pětihodinového běhu nadělal chyby, které musel zachytit člověk. Pointou není, že je funkce rozbitá, ale že paralelní orchestrace ve fázi research preview pořád vyžaduje aktivní dohled. Víc paralelních agentů tenhle problém spíš násobí, než řeší.
Ztráta kontroly nad během. Tady je realita ještě tvrdší, než marketing naznačuje. Koordinace mimo konverzaci je prodávaná jako přednost, ale podle oficiálního popisu během vykonávání není povolen žádný vstup uživatele - jediné, co může workflow pozastavit, jsou žádosti agentů o oprávnění k příkazům mimo allowlist. Do běhu tedy nemůžete zasáhnout a nasměrovat ho, jen ho celý zastavit. Navíc subagenti uvnitř workflow vždy pracují v režimu acceptEdits a změny souborů si schvalují automaticky, bez ohledu na to, jak opatrný režim oprávnění jste nastavili pro samotnou session. Kdo je zvyklý každou změnu odklepávat, tuhle pojistku uvnitř workflow nemá.
Spouštění přes klíčové slovo. Funkce reaguje na slovo „workflow” v textu. Tady je nutné upřesnit, jak to přesně funguje, protože první vlna stížností to brala zkratkovitě. Samotné napsání slova „workflow” jen text zvýrazní a nic nespustí - skutečně spolehlivý trigger je explicitní věta typu „sestav mi dynamic workflow, který udělá tohle”. Past tedy není ani tak v jednom slově, jako spíš v módu ultracode, který mění prakticky každý prompt na workflow. Přesto platí, že kdo má v projektu MD soubory nebo konverzace plné slova „workflow”, potká zvýrazňování tam, kde ho nečeká, a opakovaně zaznělo volání po explicitním /workflow příkazu místo reakce na klíčové slovo.
Vyplatí se to pro běžný vibecoding projekt?
Krátká odpověď: většinou ne. A stojí za to říct to rovnou, místo abych čtenáři podsouval návod, jak utratit tokeny za funkci, kterou nepotřebuje.
Dynamic workflows řeší problém, který malý projekt nemá. Anthropic je staví pro úlohy příliš velké na jeden či několik průchodů jediného agenta - hledání chyby napříč celou službou, migraci dotýkající se stovek souborů, plán prověřený ze všech úhlů. Typický vibecoding projekt je landing page, menší aplikace na Astru, pár Workerů na Cloudflare. Tam je úzkým hrdlem vaše rozhodování o tom, co vlastně chcete a jak to vykreslit, ne počet agentů, které lze paralelizovat. K tomu připočtěte cenu: sám Anthropic varuje, že funkce spotřebuje podstatně víc tokenů než běžná session, a doporučuje začít na ohraničené úloze. Připomeňme číslo z předchozí sekce - jeden uživatel spálil polovinu plánu za 200 dolarů jediným špatně ohraničeným promptem za půl hodiny. Na Pro plánu, kde je limit nižší, vám podobná neopatrnost spolkne denní příděl ještě rychleji.
Existují ale tři situace, kdy i sólo vibecoder funkci využije.
První je bezpečnostní a kvalitativní audit hotového projektu. Když máte projekt postavený a chcete ho prověřit před nasazením, paralelní agenti s nezávislým ověřováním nálezů dávají smysl. Dokumentace přímo nabízí příklad: prověřit každý API endpoint pod src/routes/ na chybějící kontrolu autentizace. Jeden průchod by takové věci přehlédl, sada agentů ne.
Druhá je větší jednorázová migrace. Přechod na novou verzi frameworku, výměna knihovny napříč projektem, port mezi jazyky. Tedy přesně to mechanické, co i skeptici uznávají, že agenti zvládají.
Třetí je úklid kódu. Hledání mrtvého kódu a zjednodušování v projektu, který za pár měsíců nabobtnal. Že to funguje, doložil i tým Claude Code na vlastní codebase.
Tady jsem požádal o security audit projektu kurzy.vibecoding.cz - který je veřejně na githubu jako vzor pro naše video kurzy.
A takhle vypadá přehled Review a Verify jednotlivými agenty.
Praktický postup pro Pro plán
- Aktualizujte Claude Code na verzi 2.1.154 nebo novější.
- Zapněte funkci v
/configv řádku Dynamic workflows - na Pro je defaultně vypnutá. - Nejbezpečnější první test je vestavěný workflow
/deep-research. Rozhodí hledání do více úhlů, dohledá zdroje, ověří tvrzení proti sobě a vrátí jednu zprávu s citacemi. Vyberte ohraničenou otázku, ať vidíte spotřebu a chování dřív, než pustíte něco velkého. - Pro kalibraci rozpočtu na reálné úloze zadejte něco úzce vymezeného, co jen reportuje a nic nemění - třeba workflow, který prověří jen složku
auth/middleware/na race conditions a vypíše nálezy bez zásahů do kódu. Jakmile uvidíte, jak workflow úlohu rozloží a kolik agentů spustí, máte kalibrační bod pro větší práci. - Pokud úloha nevyžaduje plný výkon, řekněte Claudovi, ať pracovní agenty postaví na model Haiku. Každý agent je plné volání s vlastním kontextem, takže levnější model na desítkách agentů znamená výrazně nižší účet.
- Než běh potvrdíte, využijte náhled - Claude Code ukáže fáze, počet agentů a součet tokenů, a v potvrzovacím dialogu nabídne volbu „Show the raw script” (klávesou Ctrl+G se skript otevře v editoru). Tady to nepřeskakujte, je to vaše pojistka proti nečekanému účtu za tokeny i proti tomu, aby workflow sáhlo někam, kam nemá. Pokud je zadání příliš široké, zvolte „No” a zužte ho.
- Plný běh spustíte explicitní větou typu „sestav mi dynamic workflow, který…”. Pouhé slovo „workflow” v textu běh nespustí, jen ho zvýrazní.
- Běh sledujete v zobrazení
/workflows- ukáže každého agenta, model, na kterém běží, spotřebu tokenů i čas, a odtud ho jde i zastavit. Pozastavený běh obnovíte tak, že ho vyberete a stisknetep- agenti, kteří už doběhli, vrátí uložené výsledky, zbytek se dopočítá. Postup se ukládá průběžně, takže přerušený běh pokračuje tam, kde skončil. - Když se workflow osvědčí a budete ho opakovat, uložte si skript toho běhu jako vlastní příkaz. Pozor ale, kam se ukládá: defaultně může skončit v globálním pracovním adresáři Claude Code, ne ve vašem projektu. Pokud ho chcete mít u projektu, řekněte Claudovi výslovně, ať soubor uloží do
.claude/workflows/v projektu. V dalších sessions ho pak spustíte jako/<jméno>.
Závěr
Dynamic workflows jsou zajímavý koncept. Nejhlubší změna je v tom, že rozhodnutí o orchestraci se přesouvá z vývojáře na model - dřív jste logiku rozdělení práce psali do slash příkazů, šablon promptů nebo souborů subagentů, teď napíšete požadavek a orchestraci napíše Claude. Vaše práce se posouvá o úroveň výš: místo toho, jak úlohu rozsekat, formulujete kritéria úspěchu, omezení a hranice důvěry. Jako teze to stojí za sledování. Jako ověřená praxe to zatím neexistuje. Jediný velký referenční příběh je sporný, první uživatelé hlásí chyby i účty za tokeny a nejsilnější výhrada - že rychlost není úzké hrdlo, správnost ano - zůstává nezodpovězená. Týden po vydání navíc pořád neexistuje jediné nezávislé měření, jen marketing a první dojmy. Funkce je výslovně označená jako research preview a tak se k ní vyplatí přistupovat: opatrně, na malých ohraničených úlohách, s okem na spotřebě a bez očekávání zázraků.
Pro typicky vibecoderské úlohy, kdy nevíte úplně přesně, co realizujete a pohybujete se na hranici mezi výzkumem a kódováním, bych Dynamic Workflows nenasazoval, je to zbytečně náročné na promýšlení zadání a ztráta průběžné kontroly nad postupem prací.