Diriger des workers en arrière-plan

Ce guide vous montre comment mener une conversation en directeur plutôt qu’en worker : la session lit et vérifie, et des agents en arrière-plan se chargent des modifications.

Ce qui change quand vous tapez /vibe

Deux choses, et seule la première est appliquée par la machinerie :

1. Les propres outils de la session passent en lecture seule, plus cinq verbes de worker. La seule façon d’agir sur le dépôt est de passer par un worker, et la seule façon de savoir ce qui s’est passé est de lire les fichiers qu’un worker a touchés.
2. Il lui est demandé de vérifier en lisant, pas en croyant. Le rapport d’un worker est une déclaration sur ce qu’il a fait, pas une preuve que cela a fonctionné.

C’est la première qui porte la charge. Un directeur qui peut encore utiliser grep et modifier fera le travail lui-même sous pression, ce qui est exactement le mode de défaillance que ce dispositif existe pour empêcher.

/vibe migrate the auth module to the new session API

Les workers démarrent à vide

Un worker n’a jamais vu votre conversation et ne la verra jamais. Le brief constitue tout son contexte.

C’est ce qui rend le dispositif économique — vingt workers détenant chacun l’historique du directeur coûteraient vingt fois le contexte de celui-ci — et c’est aussi ce qui rend les briefs difficiles à rédiger. « Maintenant, fais aussi l’autre » se lit comme une instruction complète pour le directeur et comme rien du tout pour une session vierge.

Un bon brief nomme les fichiers, les commandes et la définition de « terminé » :

Dans lib/features/auth/, remplacez chaque appel à SessionStore.read(key) par SessionStore.get(key). La nouvelle méthode renvoie Future<String?> là où l’ancienne renvoyait String?, donc les appelants doivent utiliser await. Lancez fvm flutter analyze lib/features/auth une fois terminé et signalez les erreurs que vous n’avez pas pu corriger.

Les cinq verbes

Verbe	Ce qu’il fait
vibe_spawn	Démarre un worker sur un brief. Renvoie immédiatement.
vibe_list	Palier, statut, temps écoulé et dernier résultat pour chacun
vibe_send	Un tour de suivi pour un worker qui a terminé
vibe_wait	Bloque jusqu’à ce qu’un worker ait fini
vibe_kill	En arrête un

Le lancement est asynchrone par conception. Un directeur qui bloque à chaque lancement exécute les workers un par un, ce qui revient à faire plus lentement ce qu’il faisait déjà lui-même. N’utilisez vibe_wait que lorsque vous ne pouvez vraiment pas avancer sans une réponse précise.

Deux paliers

Palier	Pour
fast	Travail mécanique avec une spécification claire — modifications, renommages, brouillons, exécution de commandes
good	Conception, jugement ou relecture de ce qu’a produit un worker fast

Le schéma courant consiste à répartir des workers fast sur des fichiers indépendants, puis à lancer un worker good pour relire ce qu’ils ont fait collectivement.

Vérification

C’est la partie qui détermine si le dispositif vaut quoi que ce soit.

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

Ensuite, lisez les fichiers qu’il a nommés. Le directeur dispose de read, search, lsp et ast_grep ; c’est tout l’intérêt de les lui conserver. Un directeur qui prend le rapport au pied de la lettre n’est qu’un résumeur de l’optimisme des autres agents.

lsp(action: "diagnostics", file: "*") après une série de workers est généralement la vérification la plus rapide.

Quand un worker perd le fil

Arrêtez-le et rédigez un nouveau brief. Un brief frais et corrigé coûte moins cher qu’une discussion, et vibe_send ne fonctionne que sur un worker qui a déjà terminé son tour.

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

Limites

• Huit workers simultanés. Un plafond de dépense, pas une limite technique : chacun est une session de modèle complète, et un directeur qui en répartit vingt ne suit plus ce que tous font.
• Aucun worker ne survit au mode. À la fin de l’exécution, ils sont tous arrêtés et la transcription indique combien. Un agent en arrière-plan qui continue de modifier des fichiers alors que la conversation est passée à autre chose est la seule défaillance que ce dispositif ne peut pas se permettre.
• Sous le capot, les workers sont des sous-agents ordinaires. Même plafond de profondeur, même politique de garde-fous, même enfant dans le journal d’exécution. Vibe change qui les pilote, pas ce qu’ils ont le droit de faire — les demandes d’approbation apparaissent donc toujours pour les appels d’écriture et d’exécution d’un worker.

Quand ne pas l’utiliser

Le mode vibe s’adresse au travail qui se décompose en briefs indépendants. Si l’étape suivante dépend de la sortie de l’étape précédente, vous décrivez un pipeline ou une orchestration, et les deux expriment correctement les dépendances au lieu de faire simuler celles-ci au directeur avec vibe_wait.

Voir aussi

• Exécuter des agents en parallèle — les autres façons de répartir le travail
• Orchestration — quand le travail a une forme
• Outils d’agent intégrés — les verbes et leurs arguments