Voici mon terminal en ce moment.

Session tmux avec 13 agents

13 agents Claude Code, chacun dans son propre panneau tmux, travaillant sur le même codebase. Pas comme une expérience. Pas pour épater. C'est comme ca que je livre du logiciel tous les jours.

Le projet est Beadbox, un tableau de bord en temps réel pour le suivi d'agents IA de programmation. Il est construit par la flotte d'agents qu'il surveille. Les agents écrivent le code, le testent, le révisent, l'empaquettent et le livrent. Moi, je coordonne.

Si vous faites tourner plus de deux ou trois agents et que vous vous demandez comment suivre ce qu'ils font tous, voici ou j'en suis après des mois d'itération. Un bug a été signalé a 9h et corrigé a 15h, pendant que quatre autres flux de travail tournaient en parallèle. Ca ne se passe pas toujours bien, mais le débit est réel.

L'équipe

Chaque agent a un fichier CLAUDE.md qui définit son identité, ce qu'il possède, ce qu'il ne possède pas et comment il communique avec les autres agents. Ce ne sont pas des assistants génériques "fait tout". Chacun a un travail précis et des limites explicites.

Groupe	Agents	Ce qu'ils possèdent
Coordination	super, pm, owner	Dispatch de travail, specs produit, priorités business
Ingénierie	eng1, eng2, arch	Implémentation, conception système, suites de tests
Qualité	qa1, qa2	Validation indépendante, gates de release
Opérations	ops, shipper	Tests de plateforme, builds, exécution de releases
Croissance	growth, pmm, pmm2	Analytics, positionnement, contenu public

Le mot clé est limites. eng2 ne peut pas fermer de tickets. qa1 n'écrit pas de code. pmm ne touche jamais au code source de l'app. Super dispatche le travail mais n'implémente pas. Les limites existent parce que sans elles, les agents dérivent. Ils "aident" en refactorant du code qui n'avait pas besoin d'être refactoré, en fermant des tickets qui n'étaient pas vérifiés, ou en prenant des décisions architecturales pour lesquelles ils ne sont pas qualifiés.

Chaque CLAUDE.md commence par un paragraphe d'identité et une section de limites. Voici une version abrégée de celui de eng2 :

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests. You own implementation quality: the code you write is correct, tested, and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable verification steps. If your DONE comment doesn't let QA verify without reading source code, it's incomplete.

Ce schéma tient a l'échelle. Quand j'ai commencé avec 3 agents, ils pouvaient partager un seul prompt générique. A 13, les rôles explicites et les protocoles sont la différence entre coordination et chaos.

La couche de coordination

Trois outils tiennent la flotte ensemble.

beads est un gestionnaire de tickets open-source et natif Git concu exactement pour ce workflow. Chaque tâche est un "bead" avec un statut, une priorité, des dépendances et un fil de commentaires. Les agents lisent et écrivent dans la même base de données locale via un CLI appelé bd.

bd update bb-viet --claim --actor eng2   # eng2 revendique un bug
bd show bb-viet                           # voir le spec complet + commentaires
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 poste son plan

gn / gp / ga sont des outils de messagerie tmux. gn envoie un message au panneau d'un autre agent. gp regarde la sortie récente d'un autre agent (sans l'interrompre). ga met en file un message non urgent.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # dispatch
gp eng2 -n 40                                               # vérifier la progression
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # rapporter

Les protocoles CLAUDE.md définissent les chemins d'escalade, le format de communication et les critères de complétion. Chaque agent sait : revendiquer le bead, commenter son plan avant de coder, lancer les tests avant de pousser, commenter DONE avec des étapes de vérification, marquer ready for QA, rapporter a super.

Voici a quoi ca ressemble en pratique. C'est un vrai bead d'aujourd'hui : super assigne la tâche, eng2 commente un plan numéroté, eng2 commente DONE avec des étapes de vérification QA et des critères d'acceptation cochés, super dispatche a QA.

Un vrai fil de commentaires de bead montrant le workflow complet PLAN/DONE

Super exécute une boucle de patrouille toutes les 5-10 minutes : regarder la sortie de chaque agent actif, vérifier le statut du bead, confirmer que le pipeline n'est pas bloqué. C'est comme une rotation d'astreinte en production, sauf que les services sont des agents IA et les incidents sont "eng2 est suspicieusement silencieux depuis 20 minutes."

Une vraie journée

Voici ce qui s'est réellement passé un mercredi de fin février 2026.

9h14 - Un utilisateur GitHub nommé ericinfins ouvre l'Issue #2 : il ne peut pas connecter Beadbox a son serveur Dolt distant. L'app ne supporte que les connexions locales. Owner le voit et le signale a super.

9h30 - Super dispatche le travail. Arch concoit un flux d'auth de connexion (toggle TLS, champs utilisateur/mot de passe, passage de variables d'environnement). PM écrit le spec avec des critères d'acceptation. Eng le prend en charge et commence a implémenter.

Pendant ce temps, en parallèle :

PM signale deux bugs découverts pendant les tests de release. L'un est cosmétique : le badge du header affiche "v0.10.0-rc.7" au lieu de "v0.10.0" sur les builds finaux. L'autre est spécifique a la plateforme : l'outil de capture d'écran retourne une bande vide sur les Mac ARM64 parce qu'Apple Silicon rend le WebView de Tauri via la composition Metal, et le backing store est vide.

Ops trouve la cause du bug de capture. La solution est élégante : après la capture, vérifier si la hauteur de l'image est suspicieusement petite (moins de 50px pour une fenêtre qui devrait faire 800px de haut), et se rabattre sur une capture basée sur les coordonnées de l'écran.

Growth extrait les données PostHog et lance une analyse de corrélation d'IP. Le constat : les publicités Reddit ont généré 96 clics et zéro utilisateur retenu attribuable. Le trafic du README GitHub convertit a 15.8%. Cet article même existe grâce a cette analyse.

Eng1, débloqué par le design d'Activity Dashboard d'arch, commence a construire la gestion d'état de filtres croisés et les fonctions utilitaires. 687 tests passent.

QA1 valide le fix du badge du header : lance un serveur de test, utilise l'automatisation navigateur pour vérifier que le badge s'affiche correctement, confirme que 665 tests unitaires passent, marque PASS.

14h45 - Shipper fusionne la PR du release candidate, pousse le tag v0.10.0 et déclenche le workflow de promotion. La CI construit les artefacts pour les 5 plateformes (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper vérifie chaque artefact, met a jour les notes de release sur les deux repos, redéploie le site web et met a jour le cask Homebrew.

15h12 - Owner répond sur le GitHub Issue #2 :

Bonne nouvelle : v0.10.0 vient de sortir avec le support complet de l'auth pour serveur Dolt. Mettez a jour et vous devriez être débloqué.

Bug signalé le matin. Fix livré l'après-midi. Et pendant que tout ca se passait, la prochaine feature était déja en cours de conception, un autre bug était en cours d'investigation, les analytics étaient analysées, et QA vérifiait indépendamment un autre fix.

Ce n'est pas parce que 13 agents sont rapides. C'est parce que 13 agents sont parallèles.

Ce qui tourne mal

C'est la partie que la plupart des posts "regardez mon setup IA" omettent.

Les limites de taux frappent a haute concurrence. Quand 13 agents tournent sur le même compte API, vous brûlez des tokens vite. Ce jour-la, super, eng1 et eng2 ont tous atteint le plafond de limite de taux simultanément. Tout s'arrête. Vous attendez. C'est l'équivalent IA de tout le bureau essayant d'utiliser l'imprimante en même temps, sauf que l'imprimante coûte de l'argent par page et qu'il y a un plafond de pages par minute.

QA renvoie le travail. C'est par conception, mais ca ajoute des cycles. QA a rejeté un build parce que le commentaire "DONE" de l'ingénieur n'incluait pas d'étapes de vérification. Le fix fonctionnait, mais QA ne pouvait pas le confirmer sans lire le code source. Retour a eng, réécriture du commentaire de complétion, retour a QA, re-vérification. Vingt minutes pour ce qui aurait dû en prendre cinq. Le protocole crée de la friction, mais cette friction est structurelle. Chaque fois que j'ai court-circuité QA, quelque chose a cassé en production.

Les fenêtres de contexte se remplissent. Les agents accumulent du contexte au cours d'une session. Super a un protocole pour envoyer une directive "sauvegarde ton travail" a 65% d'utilisation du contexte. Si vous ratez la fenêtre, l'agent perd le fil de ce qu'il faisait.

Les agents se bloquent. Parfois un agent entre dans une boucle d'erreur et continue de réessayer la même commande qui échoue. La boucle de patrouille de super le détecte, mais seulement si vous vérifiez assez souvent. J'ai perdu 30 minutes a cause d'un agent qui échouait poliment en silence.

L'overhead de coordination est réel. Fichiers CLAUDE.md, protocoles de dispatch, boucles de patrouille, commentaires de beads, rapports de complétion. Pour un setup a deux agents, c'est excessif. Pour 13 agents, c'est la structure minimum viable. Il y a un point de bascule autour de 5 agents ou la coordination informelle cesse de fonctionner et ou vous avez besoin de protocoles explicites sous peine de perdre le fil de ce qui se passe.

Ce que j'ai appris

La spécialisation bat la généralisation. 13 agents focalisés surpassent 3 "full-stack". Quand qa1 ne fait que valider et n'écrit jamais de code, il attrape des choses qu'eng a ratées a chaque fois. Quand arch ne fait que concevoir et n'implémente jamais, les designs sont plus propres parce qu'il n'y a pas la tentation de raccourcir le spec pour faciliter l'implémentation.

Le QA indépendant n'est pas négociable. QA a son propre clone du repo. Il teste le code poussé, pas le working tree. Il ne fait pas confiance a l'auto-rapport de l'ingénieur. Ca semble lent. Ca attrape des bugs a chaque release.

Vous avez besoin de visibilité sinon la flotte dérive. A 5+ agents, vous ne pouvez pas suivre l'état en alternant entre les panneaux tmux et en exécutant bd list dans votre tête. Vous avez besoin d'un tableau de bord qui vous montre l'arbre de dépendances, quels agents travaillent sur quoi et quels beads sont bloqués. C'est le problème que j'ai construit Beadbox pour résoudre.

La boucle récursive compte. Les agents construisent Beadbox. Beadbox surveille les agents. Quand les agents produisent un bug dans Beadbox, la flotte le détecte via le même processus QA qui a détecté tous les autres bugs. L'outil s'améliore parce que l'équipe qui l'utilise le plus est l'équipe qui le construit. Je suis conscient que c'est soit brillant soit la machine de Rube Goldberg la plus élaborée jamais construite. Les features livrées suggèrent le premier. Ma facture de tokens suggère le second.

Le stack

Si vous voulez essayer vous-même, voici ce qu'il vous faut :

beads : Gestionnaire de tickets open-source natif Git. C'est la colonne vertébrale de la coordination. Chaque agent y lit et y écrit.
Claude Code : Le runtime d'agents. Chaque agent est une session Claude Code dans un panneau tmux avec son propre fichier d'identité CLAUDE.md.
tmux + gn/gp/ga : Multiplexeur de terminal pour faire tourner les agents côte a côte. Les outils de messagerie permettent aux agents de communiquer sans mémoire partagée.
Beadbox : Tableau de bord visuel en temps réel qui vous montre ce que la flotte fait. C'est ce que vous êtes en train de lire.

Vous n'avez pas besoin des 13 agents pour commencer. Deux ingénieurs et un agent QA, coordonnés via beads, changeront votre vision de ce qu'un seul développeur peut livrer.

La suite

Le plus grand manque dans le setup actuel est de répondre a trois questions d'un coup d'oeil : quels agents sont actifs, inactifs ou bloqués ? Ou le travail s'accumule-t-il dans le pipeline ? Et que vient-il de se passer, filtré par l'agent ou l'étape du pipeline qui m'intéresse ?

Pour l'instant ca nécessite une boucle de patrouille et beaucoup de commandes gp. Alors nous construisons un tableau de bord de coordination directement dans Beadbox : une bande de statut d'agents en haut, un flux de pipeline montrant ou les beads s'accumulent, et un feed d'événements a filtres croisés ou cliquer sur un agent ou une étape du pipeline filtre tout le reste. Les trois couches partagent la même source de données en temps réel. Les trois se mettent a jour en direct.

Apercu du Activity Dashboard

Les 13 agents le construisent en ce moment. J'écrirai a ce sujet quand ce sera livré.

Je livre du logiciel avec 13 agents IA. Voici a quoi ca ressemble vraiment