SwarmForge : ce que l'essaim d'agents d'Uncle Bob réussit
SwarmForge fait tourner plusieurs agents de codage IA dans des fenêtres tmux, chacun dans son propre worktree git, chacun tenant exactement un rôle d'ingénierie. L'outillage est volontairement banal. L'intéressant, c'est l'organigramme qu'il encode.
Ce qu'est réellement SwarmForge
SwarmForge est un harnais en shell et Babashka autour de trois primitives que la plupart des équipes possèdent déjà : les fenêtres tmux, les worktrees git et les fichiers de prompt. Chaque fenêtre exécute un agent dans un rôle, sur son propre worktree sous .worktrees/, de sorte que deux agents ne se disputent jamais le même répertoire de travail. Le comportement vient d'un texte brut dans swarmforge/roles/<role>.prompt, posé sur une constitution.prompt partagée et ses articles. Les agents ne tapent pas dans le terminal des autres : ils mettent en file des passations validées via .swarmforge/handoffs/, et la charge utile est soit une abréviation de commit de dix caractères, soit une note de quatre-vingts caractères au maximum. Les backends se choisissent par rôle, donc une même session peut mélanger Claude, Codex, Copilot et Grok.
La branche main est documentaire. Les essaims exécutables vivent sur les branches two-pack, four-pack et six-pack : on récupère la branche dont on veut la forme, puis on lance ./swarm. Les prérequis sont zsh, git, tmux, Babashka et une CLI d'agent configurée.
Trois formes d'essaim
Chaque branche est une réponse différente à la question de savoir combien de processus une tâche mérite. Le flux est un anneau, pas une file : le travail revient.
two-pack
coder → cleaner → coder
Un coder qui travaille en test-first et un cleaner qui fait le nettoyage, la revue CRAP et DRY, et les corrections d'architecture. La plus petite boucle utile : écrire, puis confier à quelqu'un qui n'y est pas attaché.
four-pack
specifier → coder → refactorer → architect → specifier
Les spécifications d'acceptation Gherkin entrent en tête. Un refactorer nettoie sans changer le comportement et complète la couverture, un architect revoit la structure et le sens des dépendances avant que l'anneau ne revienne à la spécification.
six-pack
specifier → coder → cleaner → architect → hardener → QA
Ajoute une passe de durcissement qui mute le code pour trouver les angles morts, et un rôle QA qui exécute une vérification réelle. C'est la forme qui traite la qualité comme des préoccupations distinctes plutôt que comme les bonnes intentions d'un seul agent.
Un agent, une discipline
Les rôles sont l'argument. Chacun d'eux est un travail qu'on entasse d'ordinaire sur la même personne, dans la même heure, sous la même échéance.
specifier
Écrit les spécifications d'acceptation Gherkin et les procédures QA. Rien n'entre dans l'essaim sous forme de phrase vague, ce qui est le mode de défaillance dont la plupart des workflows d'agents ne se relèvent jamais.
coder
Implémente en test-first. C'est le prompt de rôle, et non une page de politique que personne ne lit, qui fait du TDD le comportement par défaut de cette fenêtre.
cleaner
Nettoyage local, couverture, revue CRAP et DRY. Le nommage et la duplication obtiennent une passe dédiée au lieu d'un commentaire de revue que personne n'applique jamais.
architect
Structure des modules, frontières, sens des dépendances. Le seul rôle autorisé à se soucier de la forme de l'ensemble plutôt que du ticket devant lui.
rôle de durcissement
Durcissement par mutation : perturber le code et découvrir où la suite est aveugle. Une vérification négative, placée délibérément après que le code est déjà propre.
QA
Scripts de vérification exécutables et notifications. La vérification est quelque chose qui tourne et qui rapporte, pas l'impression que le changement avait l'air correct.
Comment fonctionne la coordination
Trois fichiers et trois scripts portent tout le protocole. C'est bien le point : la topologie est une donnée, et la discipline est du texte.
La topologie tient dans un fichier de configuration
confChaque ligne déclare une fenêtre tmux : quel rôle, quel backend d'agent, quel worktree, et si le travail est reçu à la tâche ou par lots.
# swarmforge/swarmforge.conf
# window <role> <agent> <worktree> [task|batch] [extra-cli-args...]
window coordinator codex master
window coder codex coder
window architect codex architectLes passations sont validées, pas discutées
shUn agent met une passation sortante en file, le rôle suivant accepte le travail quand il est libre, et clore l'élément courant est un acte explicite. La charge utile est un commit ou une note très courte, donc c'est au code de porter le sens.
# queue work for the next role: a commit, or a note of <= 80 chars
./swarm_handoff.sh coder 4f2a9c1b0d "boundary rule now specified"
# on the receiving side
./ready_for_next.sh # accept the next item or batch
./done_with_current.sh # close it out and free the windowLe standard vit dans l'arbre de prompts
textLes articles partagés portent les règles d'ingénierie, les règles de passation et le workflow ; les articles locaux sont là où un projet les surcharge. Les prompts de rôle se posent par-dessus. Votre standard de code devient une entrée du travail au lieu d'un document à son sujet.
swarmforge/
swarmforge.conf
constitution.prompt
constitution/articles/
engineering.prompt
handoffs.prompt
workflow.prompt
project.prompt
local-engineering.prompt
local-workflow.prompt
roles/
<role>.promptCe qu'il faut emprunter même sans jamais le lancer
Donner à chaque passe un nom et une seule tâche
- - Séparer spécification, implémentation, nettoyage, structure et vérification en passes distinctes avec des instructions distinctes
- - Cesser de demander à un agent, ou à un ingénieur, de tenir les cinq préoccupations à la fois
- - Nommer la passe dans la pull request pour que les relecteurs sachent quelles questions sont déjà réglées
Isoler l'espace de travail, pas seulement la branche
- - Un worktree git par rôle supprime toute la classe de pannes où deux agents modifient le même fichier en même temps
- - L'isolation rend le travail parallèle lisible : chaque rôle a un arbre inspectable indépendamment
- - La même astuce marche pour une personne qui fait tourner plusieurs agents en local, sans aucun essaim
Rendre les passations étroites et validées
- - Une référence de commit plus une ligne courte force l'intention dans le code et le message
- - La validation à la frontière de passation attrape la requête malformée avant que le rôle suivant y gaspille un run
- - Les passations étroites sont auditables : on peut reconstituer qui a transmis quoi, et quand
Garder le standard là où le travail se fait
- - Des règles d'ingénierie écrites comme articles de prompt sont lues à chaque tâche, contrairement à une page de wiki
- - Séparer les règles partagées des surcharges locales pour que l'exception d'une équipe ne devienne pas la règle de tous
- - Versionner les règles avec le code et relire leurs modifications comme du code
Les réserves honnêtes
L'anneau coûte ce que coûte l'anneau
Six rôles qui se relisent, cela fait plusieurs runs d'agent par changement. Sur de petites tâches, la boucle two-pack est généralement le choix rationnel ; le six-pack est pour un travail dont les défauts coûteraient cher.
Quatre-vingts caractères, c'est un tuyau étroit
La minuscule charge utile de passation est une discipline : le commit doit s'expliquer lui-même. Cela veut dire aussi que la compréhension partagée de l'essaim vit entièrement dans les specs et le code. Si votre base de code ne s'explique pas déjà, l'essaim ne le fera pas pour vous.
Les rôles sont des prompts, pas des garanties
Un prompt qui dit d'utiliser le TDD est une forte incitation, pas un mécanisme d'application. Ce qui tient vraiment est exécutable : le run de tests, le run de mutation, le script QA. Gardez cela dans la CI, pas seulement dans l'essaim.
Quelqu'un signe toujours
La sortie de l'essaim est une proposition de changement, pas une décision de release. La responsabilité ne se répartit pas entre des fenêtres tmux, et le travail du relecteur devient plus dur, pas plus simple, quand le volume de code plausible augmente.
Le workflow est la contribution
Retirez tmux, Babashka et l'installation par tarball, et SwarmForge est une affirmation sur le génie logiciel : les disciplines qui rendent le code habitable sont séparables, et chacune mérite son tour avec ses propres instructions. Cette affirmation était vraie avant les agents, et c'est exactement pour cela qu'elle se transpose.
Lisez-le comme une implémentation de référence plutôt que comme une plateforme. Adoptez la décomposition en rôles, l'isolation par worktree et la passation validée, et vous obtenez l'essentiel de la valeur, que le travail soit fait par six agents, deux ingénieurs, ou un de chaque.
Articles d'ingénierie liés
Le rôle de durcissement et le rôle cleaner pointent tous deux vers des pratiques qui méritent d'être comprises pour elles-mêmes.
Les tests de mutation sont négatifs. Les tests TDD sont positifs.
Un run de mutation ne peut que signaler ce qu'une suite ne remarque pas, alors qu'un test TDD énonce ce que le système doit faire. Comment utiliser chacun en conséquence.
La métrique CRAP : complexité et couverture en un chiffre
Comment la formule CRAP combine complexité et couverture, ce que chaque score exige, et comment en faire une barrière sans lancer un chantier de nettoyage.
FAQ
Que faut-il pour faire tourner SwarmForge ?
zsh, git, tmux et Babashka, plus une CLI d'agent configurée comme Claude, Codex, Copilot ou Grok. Il n'y a aucun service cloud ni couche d'orchestration à monter : l'essaim, ce sont des fenêtres tmux que vous pouvez regarder, avec un worktree par rôle sur le disque.
Par quelle branche une équipe doit-elle commencer ?
two-pack. Deux rôles suffisent à sentir si la discipline de passation convient à votre travail, et le coût d'un anneau complet de six rôles est difficile à justifier avant de le savoir.
Un essaim d'agents supprime-t-il le besoin de QA ?
Non. Il déplace la QA dans un rôle nommé avec des scripts exécutables, ce qui vaut mieux que de la laisser implicite, mais la vérification doit toujours être écrite par quelqu'un qui comprend ce que le produit doit à ses utilisateurs.
Est-ce une orchestration prête pour la production ?
Traitez-le comme une référence de workflow plutôt que comme une plateforme gérée. La valeur durable, c'est la décomposition des préoccupations d'ingénierie et le protocole de passation étroit, et les deux s'adoptent indépendamment des scripts shell.