Diriger des workers en arrière-plan

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

Ce qui change quand vous tapez /vibe

Deux choses, et seule la première est imposée par le mécanisme :

1. Les outils propres à la session passent en lecture seule, auxquels s’ajoutent cinq verbes de worker. La seule façon pour elle 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 modifiés.
2. On lui demande de vérifier en lisant, et non en croyant. Le rapport d’un worker est une affirmation sur ce qu’il a fait, et non une preuve que cela a fonctionné.

C’est la première qui est déterminante. Un directeur qui peut encore faire un grep et modifier des fichiers finira par faire le travail lui-même sous pression, ce qui est précisément le mode de défaillance que ce mode existe pour prévenir.

/vibe migrate the auth module to the new session API

Un worker démarre sans rien

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

C’est ce qui rend ce modèle économique — vingt workers portant chacun l’historique du directeur coûteraient vingt fois le contexte du directeur — et c’est aussi ce qui rend les consignes difficiles à rédiger. “Fais aussi l’autre” est une instruction complète pour le directeur, mais ne dit absolument rien à une session vierge.

Une bonne consigne nomme les fichiers, les commandes et la définition du travail 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 ont besoin d’un await. Lancez fvm flutter analyze lib/features/auth quand vous avez terminé et signalez les erreurs que vous n’avez pas pu corriger.

Les cinq verbes

Verbe	Ce qu’il fait
vibe_spawn	Lance un worker à partir d’une consigne. Renvoie immédiatement.
vibe_list	Niveau, 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 se termine
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 est une façon plus lente de faire ce qu’il faisait déjà lui-même. N’utilisez vibe_wait que lorsque vous ne pouvez vraiment pas continuer sans une réponse précise.

Deux niveaux

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

Une approche courante consiste à répartir des workers fast sur des fichiers indépendants, puis à lancer un worker good pour réviser ce qu’ils ont fait collectivement.

Vérifier

C’est la partie qui détermine si ce modèle vaut quelque chose.

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 toute la raison de les 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 ronde de workers est habituellement la vérification unique la plus rapide.

Quand un worker perd le fil

Arrêtez-le et rédigez une nouvelle consigne. Une consigne nouvelle et corrigée coûte moins cher qu’une argumentation, 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épenses, 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 modifie encore des fichiers après que la conversation est passée à autre chose est la seule défaillance que ce mode 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 de journal d’exécution. Le mode vibe change qui les pilote, pas ce qu’ils ont le droit de faire — les demandes d’approbation continuent donc d’apparaître 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 consignes indépendantes. Si l’étape suivante dépend du résultat de l’étape précédente, vous décrivez un pipeline ou une orchestration, et les deux expriment correctement les dépendances au lieu d’obliger le directeur à les simuler 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