Jak rozdělit práci mezi více agentů

Malá aplikace se seznamem nákupů potřebuje dvě věci: filtrování položek a export seznamu do CSV. Úkoly spolu téměř nesouvisejí, takže se nabízí rozdělit práci mezi dva agenty a mít obě části za půl hodiny místo za hodinu. Jeden dostane filtr, druhý export a každý svou pracovní složku, aby se změny nemíchaly. Jak oba chápou záznam seznamu, si ale předem neřekli. Vypadalo to přece jasně.

Za půl hodiny jsou obě části hotové. Každá má zelené vlastní testy a sloučení proběhlo bez jediného konfliktu. Společný scénář ale nefunguje: filtr na obrazovce ukazuje tři řádky, zatímco ve vyexportovaném souboru je jeden sloupec prázdný. Důvod je prostý. Jeden z agentů při práci přejmenoval pole completed na done, protože mu připadalo výstižnější, a druhý o tom nevěděl.

Samostatné složky oddělily soubory, ale rozhodnutí nesladily. Projdeme si to ve třech krocích: nejprve zjistíme, zda má smysl práci vůbec rozdělit, pak rozdělíme oblasti změn a společné dohody a nakonec ověříme složený výsledek, aby nás takové překvapení nezaskočilo až na konci.

Prověřte závislosti

Práci má smysl dělit obvykle ze dvou důvodů. Prvním je nezávislé prozkoumání různých oblastí: současně zjistit, jak se zobrazuje seznam a co vytváří export. Druhým je paralelní práce na částech, jejichž hranice a ověřitelný výsledek už znáte. Rozdělení na "plán, provedení a kontrolu" samo o sobě nevyžaduje tři účastníky; jedna relace to zvládne postupně. U menšího úkolu je rozumné začít s jedním agentem.

Pokud důvod máte, položte si další otázku: která část práce B může pokračovat, dokud neznáte výsledek A? Jestli je B na A zcela závislá, musí tyto kroky proběhnout postupně. Někdy může B předem připravit nezávislou část, ale spojení výsledků stejně musí počkat na A.

Tři situace ze stejného příkladu se seznamem nákupů:

Třetí řádek je nejčastější past. Filtr je v src/filter.js a export v src/export-csv.js, takže části vypadají nezávisle: vždyť jde o různé soubory. Obě ale čtou stejný záznam a stejné pole completed. Přesně tak se pokazil scénář z úvodu a různé soubory tomu nezabránily. Nezávislost se týká chování a společných dohod, ne počtu souborů, ve kterých je kód uložený.

Samotné rozdělení může navrhnout agent, zatím bez spouštění dalších agentů:

Rozděl úkol na části. U každé uveď vstupy, výsledek, závislosti a způsob ověření.
Označ, které části lze začít hned.
Zatím žádné agenty nespouštěj.

Takový návrh si můžete ověřit ještě před spuštěním. Části bez nevyřešených závislostí jsou kandidáty na souběžný start. Prázdný sloupec závislostí raději porovnejte s projektem: agent mohl přehlédnout společný model nebo nastavení.

Spočítejte čas do společného výsledku

Zrychlení se obvykle měří jedním číslem: jak dlouho trvala samotná práce. Počítat byste ale měli čas do chvíle, kdy je společný výsledek přijatý. Kromě vlastní práce do něj patří zadání pro každého agenta, opakované čtení projektu každým z nich, čekání, kontrola obou výsledků a jejich spojení.

Orientační výpočet pro náš příklad. Čísla slouží jen k výpočtu, nejde o měření výkonu:

Společná příprava úkolu je nutná v obou variantách, proto ji ve výpočtu nemáme. Úsporu deseti minut smaže jediná předělávka. Čím náročnější je sestavení, tím více času musí souběžná práce ušetřit.

Kromě času jsou tu ještě dvě nákladové položky, na které se snadno zapomíná. Každý další agent znovu čte projekt, což spotřebovává zdroje, a podrobné výsledky po návratu zabírají místo ve společné konverzaci. Důležitější je ale druhá položka: vaše pozornost. Musíte si přečíst dva výsledky, porovnat je a rozhodnout, co s nimi. Pokud nestíháte číst, co přichází, rychlost už není na vaší straně.

Téměř dvojnásobné zrychlení je možné u dvou srovnatelných nezávislých částí s malou režií. Samotný počet agentů ho ale nezaručuje.

Duplicitní práce, nebo ověření

Duplicitní práci v přehledech neuvidíte. Dva agenti potichu otevřou stejné soubory, oba zjišťují, jak funguje záznam seznamu, a každý poctivě napíše, že kód prozkoumal. Někdy je ale druhý průchod záměrný: předpoklad je důležitý a chcete, aby ho ověřil někdo, kdo neviděl úvahy prvního agenta. Od náhodného opakování se taková kontrola liší tím, že předem víte, co se ověřuje, proč a co uděláte, pokud se odpovědi rozejdou. Bez posledního bodu se z kontroly stává sběr názorů.

Teď opačná situace. Dvou agentů se zeptali, co v záznamu seznamu znamená completed. Oba odpověděli stejně: označuje, že je položka koupená. Vypadá to jako nezávislé potvrzení.

Ve skutečnosti si oba přečetli stejný řádek v souboru README.md, který vznikl před rokem, zatímco pole už v kódu dávno znamená něco jiného. Nešlo o shodu v závěru, ale o shodu ve zdroji.

Z toho vyplývají dva užitečné návyky:

• požádejte, ať agent ukáže, o co opírá odpověď: soubor, řádek nebo úryvek kódu. Ne převyprávění, ale něco, co si můžete sami otevřít;
• společný předpoklad ověřte zvlášť a doopravdy: co dělá kód a co se děje ve scénáři. I když s ním všichni souhlasí.

Samostatné relace nezaručují, že budou chyby nezávislé: společný zdroj může vést ke stejnému omylu. Když se odpovědi rozejdou, zkoumejte jejich zdůvodnění místo počítání hlasů: jeden agent může vycházet z aktuálního kódu, zatímco dva další ze zastaralé poznámky.

Ověřená hodnota pole v kódu se stává základem společného modelu, na kterém se dohodnete před začátkem. Pokud rozdělení vypadá výhodně i po všech třech kontrolách, přejděte k rozdělení odpovědnosti.

Pověřte někoho odpovědností za každou oblast

Pravidlo pro dobu souběžné práce je jednoduché: za jednu oblast změn odpovídá jeden účastník. Ne "na tento soubor nesmějí sahat dva najednou", ale "dokud běží tyto dva úkoly, zapisuje sem tento agent". Je to dohoda na určitou dobu, ne vlastnost projektu.

Druhá část pravidla je důležitější, ale častěji se na ni zapomíná. I za společný výsledek někdo odpovídá: spojí části a řekne, jestli je celek hotový. Pokud sestavení nikdo nedostane na starost, připadne tomu, kdo skončil poslední - a ten toho o druhé části ví nejméně.

Před spuštěním se podívejte do projektu a ověřte, zda jsou v něm potřebné části už nějak oddělené. Pokud ne, není to důvod k velkému refaktoringu kvůli paralelní práci: ten by sám byl největším úkolem dne a nebylo by co rozdělovat.

Rozdělení práce na našem seznamu nákupů může vypadat takto:

Tabulka rozděluje odpovědnost za změny, nikoli přístupová práva: společné soubory čtou všichni, kdo je potřebují.

Řádek o package.json tam není ze zlomyslnosti: npm install mění oba soubory najednou, takže dvě souběžné instalace způsobí zbytečný konflikt a dvě různé verze stejné knihovny mohou překvapit při sestavení. Pokud knihovnu potřebují oba, agenti popíšou, co je potřeba a proč. Rozhodnutí i změnu provede jeden člověk, jednou.

Dohodněte se na společném modelu předem

Rozdělení podle souborů bez společné dohody moc nefunguje. Filtr i export vycházejí ze stejného modelu záznamu. Níže je náčrt jejich rozhraní, nikoli spustitelný příklad: implementace funkcí tu není. Předem jsme se také dohodli, že zachováme pořadí záznamů, nezměníme vstupní pole záznamů a do CSV zapíšeme logické hodnoty jako true/false. Pravidla escapování CSV zůstávají beze změny.

// jeden záznam seznamu: tato tři pole jsou dohodnutá předem a nepřejmenovávají se
const item = { id: 41, title: "oat milk", completed: false };

// filter.js vrací hotovou sadu záznamů, nic neformátuje ani neexportuje
filterItems(items, mode);   // mode: "all", "active", "completed"

// export-csv.js přijímá už filtrovanou sadu a sám nic nefiltruje
exportCsv(items);           // vrací řetězec CSV se sloupci id,title,completed

Všimněte si, že dohoda se netýká názvů souborů, ale vstupu a výstupu. "Export dostane už filtrovaný seznam" vypadá jako drobnost, jenže právě tato věta určuje, kdo z obou agentů odpovídá za výběr záznamů. Bez ní mohou oba oprávněně předpokládat, že filtrují sami, a do souboru se pak dostane buď všechno, nebo se seznam přefiltruje dvakrát.

Předem se dohodněte i na tom, jak výsledek přijmete. Společný scénář našeho příkladu: záznamy 41 a 43 mají completed: true, záznam 42 má false. Režim "completed" má zobrazit 41 a 43 v původním pořadí a CSV má obsahovat tytéž dva záznamy, záhlaví id,title,completed a hodnotu true v posledním sloupci. Scénář projde oběma částmi najednou a odhalí přesně tu chybu z úvodu článku.

A ještě něco ke změně samotné dohody. Pokud se během práce ukáže, že je potřeba změnit společný formát, nejde o drobnou úpravu jednoho souboru. Je důvod znovu projít všechny úkoly, které na formátu závisejí, protože část hotové práce mohla vycházet z předchozí varianty.

Samostatné pracovní složky (git worktree) dohodu nenahradí. Fyzicky oddělí změny, což se hodí: kontrola ve společné složce může zachytit nedokončené změny sousedního úkolu a potvrdit stav, který žádný agent samostatně neověřil. Složka ale formát záznamu nesjednotí a porty, lokální databáze a další externí zdroje zůstávají společné. Nesledovaný soubor .env v nové složce ve výchozím stavu vůbec není: kopíruje se tam, například přes .worktreeinclude.

Zadejte každému stručný úkol

Zadání nemusí být dlouhé. Obvykle stačí sedm bodů: cíl, výchozí verze, vlastní soubory, společné dohody, ověřitelný výsledek, co má agent vrátit a jak postupovat, pokud bude potřebovat zasáhnout do cizí oblasti.

Cíl: filtr seznamu zobrazí všechny záznamy, jen nedokončené, nebo jen dokončené.
Začněte od: posledního commitu hlavní větve, ve kterém je dohodnutý model záznamu.
Vaše soubory: src/filter.js a tests/filter.test.js.
Společná dohoda: pole completed zůstává typu boolean, názvy polí neměníme;
filtr vrací pole záznamů a nic neexportuje.
Výsledek: testy filtru procházejí; pro sadu tří záznamů vrátí každý režim
seznam podle očekávání.
Vraťte: seznam skutečně změněných souborů, výstup testů a verzi,
na které jste je spustili, a případné otevřené otázky.
Pokud bude potřeba změnit src/item-model.js nebo src/app.js: zastavte se,
popište potřebnou změnu a důvod a počkejte na odpověď.

Zadání pro druhého agenta je stejné: vlastní dvojice souborů, stejný formát záznamu, vlastní ověřitelný výsledek a stejný postup při překročení hranice. Opisovat ho tu celé není potřeba.

A teď k odpovědi. Potřebujete skutečný seznam změněných souborů a reálný výstup kontrol. Napsat "na cizí soubory jsem nesahal" je snadné a čím důrazněji o to požádáte, tím spíš se tato věta v odpovědi objeví. Nekontrolujte formulaci, ale seznam změn. Hranice v zadání funguje jako dohoda, nikoli jako zákaz: text požadavku agentovi nebrání zapisovat do souboru a přístupová práva se nastavují samostatně.

Znovu dohodněte překrývající se práci

Dříve nebo později někdo narazí na hranici cizí oblasti. Agent B zjistí, že bez úpravy src/app.js nemá kam připojit export: tlačítko pro export se vůbec nevolá.

Dobrá odpověď vysvětlí důvod, potřebnou změnu i závislost. Propojení v src/app.js už má na starost odpovědný za sestavení, takže B může dokončit svůj modul a požádat o propojení. Pokud bez společné změny nemůže pokračovat, pozastaví se závislá práce.

Jsou dvě možnosti. Odpovědný za sestavení upraví společný soubor sám, protože patří do jeho oblasti. Nebo tuto oblast výslovně předá agentovi B, ale nejdřív ověří, že do souboru jeho předchozí vlastník právě nezapisuje. Předání bez zastavení by vytvořilo přesně tu situaci, které má rozdělení zabránit.

Určitě ale agenta nenuťte, aby hranici obešel. Požadavek "na app.js nesahej, něco vymysli" obvykle vede ke kopii cizí logiky ve vlastním souboru nebo ke zbytečné vrstvě navíc, kterou později nikdo neumí vysvětlit. Formálně je tabulka dodržená, ale v projektu vznikla druhá verze pravdy o tom, jak funguje export.

Sestavte chování, ne jen soubory

Před sestavením potřebuje odpovědný znát tři věci: od které verze každá část vycházela, co a na které verzi každý agent ověřil a které soubory se skutečně změnily. To vše už má být v odpovědích na zadání a seznam souborů se ověřuje podle skutečných změn.

Pak části spojte a hlavně spusťte společný scénář, na kterém jste se dohodli předem. Překážet mohou dvě velmi odlišné věci.

Textový konflikt. Části změnily stejný úsek různými způsoby, odstranily nebo přejmenovaly soubor a Git je nedokázal automaticky spojit. Konflikt vyřešte a pak ověřte výsledné chování.

Neslučitelnost významu. Nikdo neupravil tentýž řádek, text se spojí čistě a žádné upozornění na konflikt se neobjeví. Právě sem patří náš případ s přejmenováním: filtr čte done, export očekává completed a dostane prázdnou hodnotu. Testy obou částí přitom projdou, protože každá ověřuje jen svou část a vlastní data.

Na schématu se dívejte na dolní šipku. Horní polovina znázorňuje to, čemu se obvykle říká rozdělení práce: dvě nezávislé části ve vlastních souborech. Závěr o připravenosti je ale o úroveň níž, ve scénáři, který projde oběma částmi najednou. Dokud tímto scénářem neprojdete, máte dva místní výsledky, ale žádný společný. Pokud pravidla projektu vyžadují úplnou sadu kontrol, společný scénář je nenahrazuje.

Zaznamenejte společné rozhodnutí

Po sestavení společného výsledku odpovědný člověk zvolí další krok. Například:

1. Přijmout společný výsledek: scénář prochází, změny dávají smysl a kritéria jsou splněná.
2. Vrátit konkrétní část k úpravě a říct, co přesně nesedí a s čím. Ne "export je nějaký divný", ale "export čte pole, které už v modelu není".
3. Znovu zvážit samotné rozdělení: snížit počet agentů nebo nechat části proběhnout postupně.

Třetí možnost je v pořádku, není to neúspěch. Že je čas rozdělení přehodnotit, poznáte poměrně rychle:

• společný formát záznamu se mění pořád dokola a pokaždé se kvůli tomu předělávají obě části;
• agenti na sebe čekají - závislost tedy existovala, jen jste ji nepojmenovali;
• výsledky přicházejí rychleji, než je stíháte číst.

Poslední známka je nejnepříjemnější, protože zvenku vypadá jako úspěch. A jedno povedené rozdělení ještě není pravidlem: výsledek agenta se běh od běhu mění, takže důležitý závěr ověřte na srovnatelném úkolu znovu.

I částečný výsledek je platný. Filtr může být hotový a ověřený, zatímco export ne; zapište to přesně tak, jako jednu hotovou část ze dvou. Celkový úkol přitom zůstává otevřený. Nelze ho označit za dokončený jen proto, že funguje polovina, a pečlivé rozdělení na tom nic nemění.

Ověřte si, že tomu rozumíte

Dvě situace. Nejdřív si odpovězte sami a pak si odpověď ověřte.

Příčina chyby ještě není známá.
Export občas vytvoří prázdný soubor a láká to rovnou zadat opravu dvěma agentům. Začněte reprodukcí a průzkumem. Pokud se objeví různé ověřitelné hypotézy, můžete je svěřit dvěma agentům. Dva návrhy oprav bez podkladů ale úkol ještě neřeší: každou opravu je potřeba spojit s příčinou a ověřit na původním scénáři.

Jiné soubory, stejné číslo.
Filtr počítá počet kusů zboží, export totéž množství zapisuje v baleních. Testy obou částí projdou, ale čísla na obrazovce a v souboru se neshodují. Nejde o chybu v kódu: žádná část nepřekročila svou hranici. Chybí dohoda o měrné jednotce. Před začátkem ji zapište do společného modelu záznamu, odpovědný za sestavení upraví src/item-model.js a potom znovu spusťte společný scénář.

Co z toho zvládne Claude Code

Agent může navrhnout rozdělení, jak jsme ukázali na začátku článku, a podle vašich bodů sestavit souvislé zadání. Hodí se také ve třech dalších situacích, rozhodnutí ale zůstává na vás:

• Návrh mapy oblastí. Požádejte ho, aby prošel projekt a navrhl, které soubory se mají měnit pro jednotlivé části úkolu, včetně cest. Je to jen návrh: odpovědného za každou oblast určujete vy.
• Sestavení a společný test. Agent spojí části, ukáže úplný seznam změn a spustí společný scénář. Potom si všechny změny sami projděte.
• Sporné místo. Dvě sebejistá vysvětlení ještě neznamenají, že je rozhodnuto. Požádejte o zdůvodnění, soubor a řádek. Kdo mění společný soubor, určuje předem tabulka, nikoli to, čí odpověď zní přesvědčivěji.

Všechno nakonec stojí na jednom rozhodnutí a dvou pověřeních. Rozhodnutí, zda práci rozdělit: každý další agent musí přinést užitek, který vyváží přípravu, kontrolu a sestavení jeho práce. Pověření: jeden odpovědný za každou oblast změn a jeden za společný výsledek. V příběhu se seznamem nákupů chybělo právě tohle: dohoda o poli completed i určení, kdo společně otestuje filtr a export. Nástroje odstraní mechanickou část práce, ale člověk musí posoudit, zda složené chování opravdu odpovídá zadání.