Když Meta tento týden spustila Muse Code, hlavní zprávou bylo konkurenční pozicování: další terminálový kódovací agent, který se přidává ke Claude Code, Codexu a Cursoru v boji o vývojářské workflow. Ale v samotném Zuckerbergově popisu nástroje se skrývá zajímavější signál pro každého, kdo píše nebo recenzuje kód pro živobytí.

„Když je úkol dostatečně velký, rozdělí se mezi samostatné podagenty, kteří pracují paralelně v izolovaných worktreech,“ napsal Zuckerberg a popsal tak přístup Muse Code k velkým úkolům. „Vaší pracovní kopie se nikdo nikdy nedotkne. Při testování jsme nechali nástroj postavit šest funkcí pro hru současně, a to bez jediné kolize.“

To není popis funkce. To je popis pracovní náplně – té vaší.

Co vlastně znamenají „izolované worktrees“

Git worktree umožňuje mít najednou rozbalené (checked out) více větví téhož repozitáře do oddělených adresářů, takže může současně postupovat několik linií práce, aniž by si jeden checkout šlapal na paty druhému. Muse Code podle popisu Mety využívá tento mechanismus k tomu, aby mohlo několik podagentů psát kód současně, aniž by se dotkli vaší živé pracovní kopie nebo navzájem svých souborů. Je to rozumné inženýrské rozhodnutí: kolize na úrovni souborů jsou tím typem konfliktu mezi více agenty, kterému se nejsnáze zabrání mechanicky – a tak se mu mechanicky zabrání a model se může soustředit na samotné psaní kódu.

Slovo, kterého si je třeba všimnout, je „rozdělí se“ (fans out). Lidský vývojář nevnímá šest paralelních worktreů jako šest proudů kódu, které postupně ručně kontroluje jeden po druhém – je to šest proudů, které mu dopadnou na stůl zhruba naráz, přičemž každý vyžaduje rozhodnutí: má se to zapojit, potřebuje to přepracovat, koliduje to s něčím, co právě udělal sourozenecký agent v jiném worktreu?

Dovednost, která se skutečně mění

Posledních pár let byl dominantním modelem programování s pomocí AI konverzační a jednotný přístup: jeden vývojář, jeden asistent, jedno vlákno tam a zpět, kontrolované zhruba v reálném čase, jak vzniká. Tato dovednost – dobře formulovat prompty, zachytit špatný návrh v okamžiku, kdy vznikne, iterovat – je stále potřebná. Není to ale dovednost, na kterou je optimalizovaný design Muse Code. Rozdělení práce mezi podagenty předpokládá, že jste už přešli k jinému způsobu práce: úkol si předem rozložíte na části, které mohou běžet nezávisle na sobě, a pak najednou kontrolujete hotový (nebo částečně hotový) výstup od několika agentů, místo abyste jednoho agenta řídili tah po tahu.

To se blíží spíš roli tech leada, který rozdělí sprint mezi malý tým, než párovému programátorovi, který sdílí obrazovku s chatbotem. Na jednotlivých rozhodnutích o kódu už tolik nezáleží – důležitější je rozklad úkolu (rozdělili jste práci podle linií, které jsou skutečně nezávislé?) a kontrolní průchod (dokážete rychle poznat, jestli je šest paralelních diffů jednotlivě správných a zároveň dohromady soudržných?).

Izolace řeší kolize, ne provázanost

Stojí za to se u toho zastavit, protože je to snadné přehlédnout: izolované worktrees zabrání tomu, aby dva agenti přepsali stejný soubor. Vůbec ale nezabrání tomu, aby dva agenti nezávisle na sobě vymysleli dva různé způsoby, jak udělat totéž – druhého pomocníka pro formátování data, druhý wrapper pro opakované pokusy, duplicitní API route – protože ani jeden z agentů neviděl, co staví ten druhý. Izolace v gitu je záruka na úrovni souborového systému, ne záruka návrhu. Recenzent, který šest worktreů spojuje zpátky dohromady, je jediné místo, kde lze zachytit duplicitní abstrakci, nekonzistentní konvenci pojmenování nebo dvě funkce, které tiše předpokládají odlišné tvary dat. Pokud tento recenzent diffy jen prolétne pohledem, protože objem paralelního výstupu předbíhá pečlivé čtení, přesně tenhle typ odchylky se pak dostane do produkce.

To přerámovává, co má „code review“ znamenat ve chvíli, kdy jsou nástroje s rozdělováním práce mezi agenty běžné: méně kontroly jednotlivého diffu řádek po řádku (syntaxe agenta bývá obvykle v pořádku), více slaďování napříč diffy – ověřování, že paralelní proudy práce vygenerované AI jsou vzájemně v souladu, pokud jde o sdílené konvence, sdílené datové modely a sdílené zpracování chyb.

K čemu se skutečně vyplatí směřovat

Nic z toho nevyžaduje konkrétně Muse Code – stejný vzor rozdělování práce se objevuje napříč hlavními kódovacími agenty, což naznačuje, že se z něj stává výchozí architektura, ne sázka jednoho dodavatele. Pár konkrétních věcí, které se vyplatí trénovat už teď, bez ohledu na to, jaký nástroj používáte:

  • Pište zadání úkolů, která se dají čistě rozložit. Než požádáte o paralelní práci, zeptejte se sami sebe, jestli jsou jednotlivé části skutečně nezávislé – dotýkají se stejných souborů, stejných sdílených konstant, stejného API kontraktu? Pokud ano, není to úkol pro šest paralelních agentů; je to úkol pro jednoho agenta pracujícího postupně, nebo pro vás, abyste nejdřív ručně oddělili sdílené části.
  • Trénujte kontrolu v bodě sloučení, ne v bodě diffu. Zvykněte si stahovat vedle sebe několik hotových větví a ptát se „shodují se tyhle navzájem“, ne jen „je každá z nich sama o sobě správně“.
  • Ovládejte základy git worktree. Pokud budou nástroje, které používáte, popisovat své vnitřní fungování tímto způsobem, je pochopení toho, co worktree garantuje a co ne, naprostým základem pro to, abyste výstupu mohli důvěřovat – nebo mu správně nedůvěřovat.
  • Jasně si stanovte vlastnictví sdílených věcí. Konstant, schémat, sdílených utilit, konvencí pojmenování. Čím víc z toho ukotvíte předtím, než rozdělení práce začne, tím méně slaďovací práce vás čeká potom.

Lidé, kteří z nástrojů jako Muse Code vytěží nejvíc, nebudou ti, kdo umí nejlépe formulovat prompty. Budou to ti, kdo si nenápadně osvojili schopnost vést malý, rychlý a občas neukázněný tým – i když je každý jeho člen model.