Dirigi i worker in background

Questa guida mostra come condurre una conversazione come direttore anziché come worker: la sessione legge e verifica, mentre gli agenti in background eseguono le modifiche.

Cosa cambia quando digiti /vibe

Due cose, e solo la prima è imposta dalla macchina:

1. Gli strumenti propri della sessione passano in sola lettura, più cinque verbi per i worker. L’unico modo in cui può incidere sul repo è tramite un worker, e l’unico modo in cui può sapere cosa è successo è leggere i file che un worker ha toccato.
2. Le viene detto di verificare leggendo, non di credere. Il resoconto di un worker è un’affermazione su ciò che ha fatto, non una prova che abbia funzionato.

La prima è quella che regge il resto. Un direttore che può ancora usare grep e modificare i file farà il lavoro da solo sotto pressione, ed è esattamente la modalità di fallimento che questa soluzione esiste per prevenire.

/vibe migrate the auth module to the new session API

I worker partono da zero

Un worker non ha mai visto la tua conversazione e non la vedrà mai. Il brief è tutto il suo contesto.

È ciò che rende economico questo schema — venti worker che conservassero ciascuno la cronologia del direttore costerebbero venti volte il contesto del direttore — ed è anche l’unica cosa che rende difficili da scrivere i brief. «Adesso fai anche l’altro» per il direttore è un’istruzione completa, per una sessione nuova non dice assolutamente nulla.

Un buon brief indica i file, i comandi e la definizione di «fatto»:

In lib/features/auth/, sostituisci ogni chiamata a SessionStore.read(key) con SessionStore.get(key). Il nuovo metodo restituisce Future<String?> dove il vecchio restituiva String?, quindi i chiamanti hanno bisogno di await. Al termine esegui fvm flutter analyze lib/features/auth e segnala gli errori che non sei riuscito a correggere.

I cinque verbi

Verbo	Cosa fa
vibe_spawn	Avvia un worker su un brief. Restituisce subito.
vibe_list	Livello, stato, tempo trascorso e ultimo risultato di ognuno
vibe_send	Un turno successivo per un worker che ha finito
vibe_wait	Si blocca finché un worker non termina
vibe_kill	Ne ferma uno

L’avvio è asincrono per progettazione. Un direttore che si blocca a ogni avvio esegue i worker uno alla volta, che è un modo più lento di fare ciò che stava già facendo da solo. Usa vibe_wait solo quando davvero non puoi procedere senza una risposta specifica.

Due livelli

Livello	A cosa serve
fast	Lavoro meccanico con una specifica chiara — modifiche, rinomine, bozze, esecuzione di comandi
good	Progettazione, giudizio o revisione di ciò che ha prodotto un worker fast

Una forma comune è distribuire worker fast su file indipendenti, poi avviare un worker good che riveda ciò che hanno fatto nel complesso.

La verifica

È la parte che decide se questo schema vale qualcosa.

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

Poi leggi i file che ha indicato. Il direttore ha read, search, lsp e ast_grep; è proprio questo il motivo per cui li mantiene. Un direttore che prende per buono il resoconto è un riassuntore dell’ottimismo degli altri agenti.

lsp(action: "diagnostics", file: "*") dopo un giro di worker è di solito il singolo controllo più rapido.

Quando un worker perde il filo

Uccidilo e riscrivi il brief. Un brief nuovo e corretto costa meno di una discussione, e vibe_send funziona solo su un worker che ha già concluso il suo turno.

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

Limiti

• Otto worker in contemporanea. Un tetto di spesa, non un limite tecnico: ognuno è una sessione di modello completa, e un direttore che ne distribuisce venti ha smesso di tenere traccia di ciò che fanno tutti.
• Nessun worker sopravvive alla modalità. Quando l’esecuzione termina, vengono fermati tutti e la trascrizione dice quanti erano. Un agente in background che continua a modificare file dopo che la conversazione è andata avanti è l’unico guasto che questa modalità non può permettersi.
• Sotto il cofano i worker sono sottoagenti normali. Stesso tetto di profondità, stessa policy dei guardrail, lo stesso registro delle esecuzioni figlio. Vibe cambia chi li guida, non ciò che possono fare — quindi le richieste di approvazione compaiono comunque per le chiamate di scrittura ed esecuzione di un worker.

Quando non usarla

La modalità vibe serve per il lavoro che si scompone in brief indipendenti. Se il passo successivo dipende dall’output di quello precedente, stai descrivendo una pipeline o un’orchestrazione, ed entrambe esprimono le dipendenze in modo proprio invece di farle simulare al direttore con vibe_wait.

Correlati

• Esegui agenti in parallelo — gli altri modi per distribuire il lavoro
• Orchestrazione — quando il lavoro ha una forma
• Strumenti agent integrati — i verbi e i loro argomenti