Řiďte workery na pozadí

Tenhle návod ukáže, jak vést konverzaci jako ředitel, ne jako worker: relace čte a ověřuje, editaci dělají agenti na pozadí.

Co se změní, když napíšeš /vibe

Dvě věci, a jen tu první vynucuje mechanismus:

1. Vlastní nástroje relace klesnou na jen pro čtení, plus pět sloves pro workery. Na repozitář sáhne jedině přes workera a co se stalo, zjistí jedině čtením souborů, kterých se worker dotkl.
2. Dostane za úkol ověřovat čtením, ne vírou. Hlášení workera je tvrzení o tom, co udělal, ne důkaz, že to zabralo.

Nosná je ta první. Ředitel, který pořád umí grepnout a editovat, si práci pod tlakem udělá sám, a právě tomu má tenhle režim zabránit.

/vibe migrate the auth module to the new session API

Workeři začínají s prázdnou

Worker tvou konverzaci nikdy neviděl a ani neuvidí. Zadání je celý jeho kontext.

Právě proto ten způsob zůstává levný — dvacet workerů, z nichž každý drží historii ředitele, by stálo dvacetinásobek jeho kontextu — a zároveň se kvůli tomu zadání píše těžko. „Teď udělej i to druhé“ je pro ředitele hotový pokyn a pro čerstvou relaci vůbec nic.

Dobré zadání pojmenuje soubory, příkazy a definici hotového:

V lib/features/auth/ nahraď každé volání SessionStore.read(key) voláním SessionStore.get(key). Nová metoda vrací Future<String?> tam, kde stará vracela String?, takže volající potřebují await. Až budeš hotový, spusť fvm flutter analyze lib/features/auth a nahlás chyby, které se nepodařilo opravit.

Pět sloves

Sloveso	Co dělá
vibe_spawn	Spustí workera na zadání. Vrátí se hned.
vibe_list	Úroveň, stav, uplynulý čas a poslední výsledek u všech
vibe_send	Navazující tah pro workera, který už skončil
vibe_wait	Blokuje, dokud jeden worker nedoběhne
vibe_kill	Zastaví jednoho

Spouštění je asynchronní schválně. Ředitel, který na každé spuštění čeká, pouští workery po jednom, a to je jen pomalejší způsob, jak dělat práci, kterou by si stejně udělal sám. vibe_wait použij jen tehdy, když bez konkrétní odpovědi opravdu nejde dál.

Dvě úrovně

Úroveň	K čemu
fast	Mechanická práce s jasnou specifikací — úpravy, přejmenování, návrhy, spouštění příkazů
good	Návrh, úsudek, nebo revize toho, co udělal worker fast

Běžná podoba je rozeslat workery fast po nezávislých souborech a pak spustit jednoho workera good, který zreviduje, co dohromady udělali.

Ověřování

Tady se rozhoduje, jestli ten způsob vůbec stojí za to.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Pak přečti soubory, které uvedl. Ředitel má read, search, lsp a ast_grep; právě proto mu zůstávají. Ředitel, který hlášení přijme bez ověření, jen shrnuje optimismus ostatních agentů.

lsp(action: "diagnostics", file: "*") po kole workerů bývá ta nejrychlejší jednotlivá kontrola.

Když worker ztratí nit

Zabij ho a zadej práci znovu. Čerstvé, opravené zadání je levnější než hádka a vibe_send funguje jen u workera, který už svůj tah dokončil.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Limity

• Osm souběžných workerů. Strop výdajů, technická mez to není: každý je plná relace modelu a ředitel, který jich rozešle dvacet, už přestal hlídat, co vlastně dělají.
• Žádný worker režim nepřežije. Jakmile běh skončí, každý z nich se zastaví a přepis řekne, kolik jich bylo. Agent na pozadí, který pořád upravuje soubory, i když konverzace už šla dál, je to jediné selhání, které si tenhle režim nesmí dovolit.
• Workeři jsou vespod obyčejní subagenti. Stejný strop hloubky, stejná politika guardrailů, stejný potomek v záznamu běhu. Režim vibe mění, kdo je řídí, ne to, co smějí — výzvy ke schválení u workerových volání write a exec pořád přijdou.

Kdy ho nepoužívat

Režim vibe je pro práci, která se rozloží do nezávislých zadání. Když další krok závisí na výstupu předchozího, popisuješ pipeline nebo orchestraci. Obě závislosti vyjádří pořádně, takže je ředitel nemusí simulovat přes vibe_wait.

Související

• Spouštějte agenty paralelně — další způsoby, jak práci rozeslat
• Orchestrace — když má práce tvar
• Vestavěné nástroje agentů — slovesa a jejich argumenty