Comment Uncle Bob organise des réseaux de neurones avec tmux et git worktrees

Uncle Bob (Robert Martin), créateur du Manifeste Agile et auteur des livres Clean Code, a publié un nouveau projet appelé SwarmForge sur GitHub. Tout en haut du README, un avis rouge en majuscules demande aux lecteurs de ne pas acheter le token de cryptomonnaie SWARM, avec lequel l'auteur n'a aucun lien. Derrière cette bannière insolite se cache une idée intéressante : un système multi-agents construit à partir d'outils Unix, de scripts zsh et de git worktrees.

Alors que la plupart des auteurs de frameworks IA bourrent leurs solutions de lourdes bibliothèques Python, SwarmForge résout le problème localement et de manière pragmatique.

Pourquoi exécuter plusieurs agents à la fois

Lorsque vous donnez à un codeur basé sur Claude ou Copilot une tâche complexe, il atteint rapidement les limites de contexte. Ou alors, il casse discrètement le code voisin. Dans la vraie vie, les programmeurs résolvent ce problème par la division du travail. L'un rédige les spécifications, un autre code en utilisant TDD, un troisième vérifie l'architecture et refactorise.

SwarmForge apporte cette pratique aux réseaux de neurones. L'outil lance des sessions tmux, attribue à chaque agent un rôle et un git worktree séparé, puis organise l'échange de tâches entre eux. Ainsi, les agents travaillent sur le même dépôt simultanément mais physiquement, ils n'interfèrent pas entre eux et n'écrasent pas les fichiers des autres.

Ensembles de rôles prêts à l'emploi

Au lieu d'une configuration fastidieuse, l'auteur propose de télécharger des scénarios prêts à l'emploi depuis différentes branches du dépôt :

Branche two-pack. Développement express pour les petites tâches : le codeur implémente le comportement via TDD, et le nettoyeur supprime les doublons et corrige les défauts architecturaux.
Branche four-pack. Cycle standard avec un rédacteur de spécifications Gherkin, un codeur, un refactoriseur et un architecte.
Branche six-pack. Chaîne complète avec une étape séparée de durcissement par mutation et un agent QA.
Build personnalisé. Votre propre variante à partir d'un ensemble arbitraire de rôles, décrite dans un fichier de configuration texte.

Vous pouvez attribuer un client CLI séparé à chaque rôle. Rien ne vous empêche de mettre Claude dans le rôle d'architecte et de confier les tâches routinières à Codex ou Copilot.

Passage de tâches entre agents

Le principal problème des systèmes multi-agents est que les agents adorent s'inonder mutuellement de messages et perdre le contexte. SwarmForge n'a pas de chat direct entre les réseaux de neurones.

Au lieu d'une invocation directe de commandes, SwarmForge exécute un daemon en arrière-plan sur Babashka (un interpréteur Clojure pour les scripts). Le daemon surveille les répertoires outbox et inbox dans le système de fichiers .swarmforge/handoffs/.

Lorsqu'un agent termine une étape, il appelle un script local swarm_handoff.sh. Le script vérifie le transfert et crée un fichier de tâche. Si du code est transféré, l'agent doit spécifier le hash de commit exact de 10 caractères. Le daemon récupère le fichier, vérifie le commit et le déplace dans le dossier inbox de l'agent suivant.

Cette approche protège contre les hallucinations. Un réseau de neurones ne peut pas transmettre le travail plus loin s'il n'a pas commité les modifications dans son git worktree.

Configuration et lancement

Tous les paramètres sont stockés dans un simple fichier texte swarmforge/swarmforge.conf. Chaque ligne décrit une fenêtre et définit son rôle, son fournisseur, le nom du worktree et les paramètres CLI supplémentaires :

window coordinator codex master
window coder copilot wt-coder --yolo
window refactorer claude wt-refactorer
window architect claude wt-arch task --dangerously-skip-permissions

Lancer le système dans un projet existant prend quelques commandes terminal. Choisissez une branche, téléchargez l'archive et exécutez le script d'entrée :

BRANCH=four-pack
curl -L "https://github.com/unclebob/swarm-forge/archive/refs/heads/${BRANCH}.tar.gz" | tar -xz --strip-components=1
./swarm

Le script ./swarm vérifie les utilitaires, télécharge les scripts partagés depuis la branche main, initialise les git worktrees pour chaque rôle et ouvre les sessions tmux. Sur macOS, il tire automatiquement Terminal.app ou Ghostty, sur Windows — Windows Terminal depuis WSL.

Lors du lancement, SwarmForge essaie de bloquer le mode veille de l'OS via caffeinate sur macOS ou systemd-inhibit sur Linux, afin que les agents ne s'endorment pas en plein travail.

Qui bénéficiera de SwarmForge

Le projet laisse une impression intéressante. D'un côté, on retrouve le style caractéristique d'Uncle Bob : accent sur TDD, métriques de qualité du code, spécifications Gherkin et règles strictes de l'architecture propre. D'un autre côté, la dépendance à Babashka, tmux et des outils CLI spécifiques rend la barrière d'entrée perceptible.

Si les idées de Clean Code résonnent avec vous et que vous souhaitez expérimenter le développement autonome sans les frameworks volumineux comme AutoGen ou CrewAI, SwarmForge mérite d'être essayé. C'est un bon exemple de comment les utilitaires Unix de base et un workflow Git approprié aident à coordonner des systèmes IA complexes.