Dirigir workers em segundo plano

Este guia mostra como conduzir uma conversa como diretor, e não como worker: a sessão lê e verifica, e agentes em segundo plano fazem as edições.

O que muda quando você digita /vibe

Duas coisas, e só a primeira é imposta pelo mecanismo:

1. As ferramentas da própria sessão caem para somente leitura, mais cinco verbos de worker. A única forma de ela afetar o repo é por meio de um worker, e a única forma de saber o que aconteceu é lendo os arquivos que um worker tocou.
2. Ela recebe a instrução de verificar lendo, não de acreditar. O relatório de um worker é uma alegação sobre o que ele fez, não uma evidência de que funcionou.

A primeira é a que sustenta tudo. Um diretor que ainda consegue usar grep e editar vai fazer o trabalho sozinho sob pressão, que é justamente o modo de falha que isso existe para evitar.

/vibe migrate the auth module to the new session API

Os workers começam em branco

Um worker nunca viu a sua conversa e nunca vai ver. O briefing é todo o contexto dele.

É isso que mantém o padrão barato — vinte workers carregando cada um o histórico do diretor custariam vinte vezes o contexto do diretor — e é também a única coisa que torna os briefings difíceis de escrever. “Agora faça o outro também” soa como uma instrução completa para o diretor e como absolutamente nada para uma sessão nova.

Um bom briefing nomeia arquivos, comandos e a definição de pronto:

Em lib/features/auth/, substitua toda chamada a SessionStore.read(key) por SessionStore.get(key). O novo método retorna Future<String?> onde o antigo retornava String?, então quem chama precisa de await. Execute fvm flutter analyze lib/features/auth quando terminar e relate qualquer erro que você não conseguiu corrigir.

Os cinco verbos

Verbo	O que faz
vibe_spawn	Inicia um worker com um briefing. Retorna imediatamente.
vibe_list	Nível, status, tempo decorrido e último resultado de todos
vibe_send	Um turno de acompanhamento para um worker que já terminou
vibe_wait	Bloqueia até que um worker termine
vibe_kill	Para um worker

O spawn é assíncrono por decisão de projeto. Um diretor que bloqueia a cada spawn está executando workers um de cada vez, o que é uma forma mais lenta de fazer o que ele já fazia sozinho. Use vibe_wait apenas quando você realmente não puder prosseguir sem uma resposta específica.

Dois níveis

Nível	Para
fast	Trabalho mecânico com especificação clara — edições, renomeações, rascunhos, execução de comandos
good	Design, julgamento ou revisão do que um worker fast produziu

Um formato comum é fazer fan-out de workers fast por arquivos independentes e então gerar um worker good para revisar o que eles fizeram em conjunto.

Verificação

Esta é a parte que decide se o padrão vale alguma coisa.

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

Depois leia os arquivos que ele nomeou. O diretor tem read, search, lsp e ast_grep; é justamente por isso que eles continuam disponíveis. Um diretor que aceita o relatório ao pé da letra é um resumidor do otimismo de outros agentes.

lsp(action: "diagnostics", file: "*") depois de uma rodada de workers costuma ser a verificação única mais rápida.

Quando um worker perde o fio

Mate-o e escreva um novo briefing. Um briefing novo e corrigido é mais barato do que uma discussão, e vibe_send só funciona em um worker que já terminou o turno.

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

Limites

• Oito workers simultâneos. Um teto de gasto, não um limite técnico: cada um é uma sessão de modelo completa, e um diretor que faz fan-out de vinte parou de acompanhar o que todos eles estão fazendo.
• Nenhum worker sobrevive ao modo. Quando a execução termina, todos eles são interrompidos e a transcrição diz quantos. Um agente em segundo plano ainda editando arquivos depois que a conversa seguiu adiante é a única falha que isso não pode ter.
• Por baixo, os workers são subagentes comuns. O mesmo limite de profundidade, a mesma política de guardrails, o mesmo log de execução filho. O modo vibe muda quem os conduz, não o que eles têm permissão de fazer — então prompts de aprovação ainda aparecem para as chamadas de escrita e de execução de um worker.

Quando não usar

O modo vibe é para trabalho que se decompõe em briefings independentes. Se o próximo passo depende da saída do passo anterior, você está descrevendo um pipeline ou uma orquestração, e os dois expressam dependências de verdade em vez de fazer o diretor simulá-las com vibe_wait.

Relacionados

• Executar agentes em paralelo — as outras formas de fazer fan-out
• Orquestração — quando o trabalho tem uma forma
• Ferramentas de agente integradas — os verbos e seus argumentos