Achtergrondworkers sturen

Deze handleiding laat zien hoe je een gesprek als regisseur voert in plaats van als worker: de sessie leest en verifieert, en achtergrondagents doen het bewerken.

Wat er verandert wanneer je `/vibe` typt

Twee dingen, en alleen het eerste wordt door het mechanisme afgedwongen:

De eigen tools van de sessie gaan naar alleen-lezen, plus vijf worker-werkwoorden. De enige manier waarop de sessie de repo kan beïnvloeden is via een worker, en de enige manier om te weten wat er is gebeurd, is door de bestanden te lezen die een worker heeft aangeraakt.
De sessie krijgt de opdracht te verifiëren door te lezen, niet door te geloven. Het rapport van een worker is een bewering over wat hij heeft gedaan, geen bewijs dat het heeft gewerkt.

Het eerste is het dragende deel. Een regisseur die nog steeds kan zoeken en bewerken, doet het werk onder druk zelf, en dat is precies de faalmodus die dit moet voorkomen.

/vibe migrate the auth module to the new session API

Workers beginnen blanco

Een worker heeft je gesprek nooit gezien en zal dat ook nooit doen. De briefing is zijn volledige context.

Dat is wat het patroon goedkoop houdt — twintig workers die elk de geschiedenis van de regisseur vasthouden, zouden twintig keer de context van de regisseur kosten — en het is ook het enige dat briefings moeilijk te schrijven maakt. “Doe nu ook de andere” leest voor de regisseur als een volledige instructie en voor een verse sessie als helemaal niets.

Een goede briefing noemt bestanden, commando’s en de definitie van klaar:

Vervang in lib/features/auth/ elke aanroep van SessionStore.read(key) door SessionStore.get(key). De nieuwe methode retourneert Future<String?> waar de oude String? retourneerde, dus aanroepers hebben await nodig. Voer fvm flutter analyze lib/features/auth uit als je klaar bent en meld eventuele fouten die je niet kon oplossen.

De vijf werkwoorden

Werkwoord	Wat het doet
`vibe_spawn`	Start een worker met een briefing. Keert onmiddellijk terug.
`vibe_list`	Niveau, status, verstreken tijd en laatste resultaat voor iedereen
`vibe_send`	Een vervolgbeurt voor een worker die klaar is
`vibe_wait`	Blokkeert tot één worker is afgerond
`vibe_kill`	Stopt er één

Het starten is bewust asynchroon. Een regisseur die bij elke start blokkeert, draait workers één voor één, wat een langzamere manier is om te doen wat hij al zelf deed. Gebruik vibe_wait alleen wanneer je echt niet verder kunt zonder een specifiek antwoord.

Twee niveaus

Niveau	Voor
`fast`	Mechanisch werk met een duidelijke specificatie — bewerkingen, hernoemingen, concepten, commando’s uitvoeren
`good`	Ontwerp, beoordeling, of het reviewen van wat een `fast`-worker heeft geproduceerd

Een veelvoorkomende vorm is om fast-workers over onafhankelijke bestanden uit te waaieren en daarna één good-worker te starten die beoordeelt wat ze samen hebben gedaan.

Verifiëren

Dit is het deel dat bepaalt of het patroon iets waard is.

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

Lees daarna de bestanden die hij noemde. De regisseur heeft read, search, lsp en ast_grep; dat is precies het punt van ze behouden. Een regisseur die het rapport voor waar aanneemt, is een samenvatter van het optimisme van andere agents.

lsp(action: "diagnostics", file: "*") na een ronde workers is meestal de snelste enkele controle.

Wanneer een worker de draad kwijtraakt

Beëindig hem en geef een nieuwe briefing. Een verse, gecorrigeerde briefing is goedkoper dan een discussie, en vibe_send werkt alleen voor een worker die zijn beurt al heeft afgerond.

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

Grenzen

Acht gelijktijdige workers. Een plafond op de kosten, geen technische limiet: elk is een volledige modelsessie, en een regisseur die er twintig uitwaaiert, volgt niet meer wat ze allemaal doen.
Geen enkele worker overleeft de modus. Wanneer de run eindigt, worden ze allemaal gestopt en vermeldt het transcript hoeveel het er waren. Een achtergrondagent die nog bestanden bewerkt nadat het gesprek verder is gegaan, is de enige fout die dit zich niet kan permitteren.
Workers zijn onderhuids gewone subagenten. Hetzelfde dieptelimiet, hetzelfde beveiligingsbeleid, hetzelfde kind in het runlog. Vibe verandert wie hen aanstuurt, niet wat ze mogen doen — daarom verschijnen er nog steeds goedkeuringsprompts bij schrijf- en uitvoeringsaanroepen van een worker.

Wanneer je het niet moet gebruiken

De vibe-modus is bedoeld voor werk dat uiteenvalt in onafhankelijke briefings. Als de volgende stap afhangt van de uitvoer van de vorige stap, beschrijf je een pipeline of een orkestratie, en beide drukken afhankelijkheden goed uit in plaats van de regisseur ze met vibe_wait te laten simuleren.

Gerelateerd

Agenten parallel uitvoeren — de andere manieren om uit te waaieren
Orkestratie — wanneer het werk een vorm heeft
Ingebouwde agenttools — de werkwoorden en hun argumenten