Dirijează workerii din fundal

Acest ghid îți arată cum să duci o conversație ca director, nu ca worker: sesiunea citește și verifică, iar agenții din fundal fac editările.

Ce se schimbă când tastezi /vibe

Două lucruri, iar doar primul este impus de mecanism:

1. Instrumentele proprii ale sesiunii trec în mod doar în citire, plus cinci verbe pentru workeri. Singura cale prin care poate afecta repo-ul este printr-un worker, iar singurul mod în care poate afla ce s-a întâmplat este să citească fișierele atinse de un worker.
2. I se spune să verifice citind, nu crezând. Raportul unui worker este o afirmație despre ce a făcut, nu o dovadă că a funcționat.

Primul este cel care susține totul. Un director care poate încă să caute cu grep și să editeze va face munca singur sub presiune, iar acesta este modul de eșec pe care acest mecanism există ca să îl prevină.

/vibe migrate the auth module to the new session API

Workerii pornesc de la zero

Un worker nu ți-a văzut niciodată conversația și nici nu o va vedea. Brieful este întregul lui context.

Asta este ce menține tiparul ieftin — douăzeci de workeri care ar ține fiecare istoricul directorului ar costa de douăzeci de ori contextul directorului — și este totodată singurul lucru care face briefurile greu de scris. „Acum fă-l și pe celălalt” sună ca o instrucțiune completă pentru director și ca nimic pentru o sesiune nouă.

Un brief bun numește fișiere, comenzi și definiția lui „terminat”:

În lib/features/auth/, înlocuiește fiecare apel la SessionStore.read(key) cu SessionStore.get(key). Metoda nouă întoarce Future<String?>, pe când cea veche întorcea String?, așa că apelanții au nevoie de await. Rulează fvm flutter analyze lib/features/auth când termini și raportează orice erori pe care nu le-ai putut rezolva.

Cele cinci verbe

Verb	Ce face
vibe_spawn	Pornește un worker pe baza unui brief. Se întoarce imediat.
vibe_list	Nivelul, starea, timpul scurs și ultimul rezultat pentru fiecare
vibe_send	O tură suplimentară pentru un worker care a terminat
vibe_wait	Blochează până când un worker își încheie execuția
vibe_kill	Oprește unul

Pornirea este asincronă prin construcție. Un director care se blochează la fiecare pornire rulează workerii unul câte unul, ceea ce este o variantă mai lentă a ceea ce făcea oricum singur. Folosește vibe_wait doar când chiar nu poți continua fără un răspuns anume.

Două niveluri

Nivel	Pentru
fast	Muncă mecanică cu o specificație clară — editări, redenumiri, schițe, rularea de comenzi
good	Proiectare, judecată sau revizuirea a ceea ce a produs un worker fast

O formă obișnuită este să distribui în paralel workeri fast pe fișiere independente, apoi să pornești un worker good care să revizuiască ce au făcut ei împreună.

Verificarea

Aceasta este partea care decide dacă tiparul valorează ceva.

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

Apoi citește fișierele pe care le-a numit. Directorul are read, search, lsp și ast_grep; exact acesta este rostul păstrării lor. Un director care ia raportul de bun este un sumarizator al optimismului altor agenți.

lsp(action: "diagnostics", file: "*") după o rundă de workeri este de obicei cea mai rapidă verificare unică.

Când un worker pierde firul

Oprește-l și dă-i un brief nou. Un brief nou, corectat, este mai ieftin decât o ceartă, iar vibe_send funcționează doar pe un worker care și-a terminat deja tura.

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

Limite

• Opt workeri concurenți. Un plafon de cheltuială, nu o limită tehnică: fiecare este o sesiune completă de model, iar un director care distribuie douăzeci a încetat să mai urmărească ce fac toți.
• Niciun worker nu supraviețuiește modului. Când rularea se încheie, toți sunt opriți, iar transcriptul spune câți. Un agent din fundal care încă editează fișiere după ce conversația a mers mai departe este singurul eșec pe care acest mecanism nu-l poate avea.
• Workerii sunt, în esență, subagenți obișnuiți. Același plafon de adâncime, aceeași politică de guardrail-uri, același copil de jurnal de rulare. Vibe schimbă cine îi conduce, nu ce le este permis să facă — așa că solicitările de aprobare apar în continuare pentru apelurile de scriere și de execuție ale unui worker.

Când să nu îl folosești

Modul vibe este pentru munca ce se descompune în briefuri independente. Dacă pasul următor depinde de rezultatul pasului anterior, descrii un pipeline sau o orchestrare, iar ambele exprimă dependențele corect, în loc să îl facă pe director să le simuleze cu vibe_wait.

Vezi și

• Rulează agenți în paralel — celelalte moduri de a distribui în paralel
• Orchestrare — când munca are o formă
• Instrumente agent integrate — verbele și argumentele lor