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

Voici mon terminal en ce moment.

13 agents Claude Code, chacun dans son propre panneau tmux, travaillant sur le meme codebase. Pas comme une experience. Pas pour epater. C'est comme ca que je livre du logiciel tous les jours.

Le projet est Beadbox, un tableau de bord en temps reel pour le suivi d'agents IA de programmation. Il est construit par la flotte d'agents qu'il surveille. Les agents ecrivent le code, le testent, le revisent, 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 apres des mois d'iteration.

L'Equipe

Chaque agent a un fichier CLAUDE.md qui definit son identite, ce qu'il possede, ce qu'il ne possede pas et comment il communique avec les autres agents. Ce ne sont pas des assistants generiques "fait tout". Chacun a un travail precis et des limites explicites.

Le mot-cle est limites. eng2 ne peut pas fermer de tickets. qa1 n'ecrit pas de code. pmm ne touche jamais au code de l'application. Super dispatche le travail mais n'implemente pas. Les limites existent parce que sans elles, les agents derivent. Ils "aident" en refactorant du code qui n'avait pas besoin de l'etre, ou en fermant des tickets non verifies, ou en prenant des decisions architecturales pour lesquelles ils ne sont pas qualifies.

Chaque CLAUDE.md commence par un paragraphe d'identite et une section de limites. Voici une version abregee de ce que voit 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 schema passe a l'echelle. Quand j'ai commence avec 3 agents, ils pouvaient partager un seul prompt vague. A 13, des roles explicites et des protocoles font la difference entre coordination et chaos.

La Couche de Coordination

Trois outils maintiennent la flotte ensemble.

beads est un gestionnaire de tickets open-source et Git-natif concu exactement pour ce workflow. Chaque tache est un "bead" avec un statut, une priorite, des dependances et un fil de commentaires. Les agents lisent et ecrivent dans la meme base de donnees locale via un CLI appele bd.

bd update bb-viet --claim --actor eng2   # eng2 revendique un bug
bd show bb-viet                           # voir la spec complete + 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 recente d'un autre agent (sans l'interrompre). ga met en file d'attente un message non urgent.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # dispatch
gp eng2 -n 40                                               # verifier le progres
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # rapport

Les protocoles CLAUDE.md definissent les chemins d'escalade, le format de communication et les criteres d'achevement. Chaque agent sait : revendiquer le bead, commenter le plan avant de coder, lancer les tests avant de pousser, commenter DONE avec des etapes de verification, marquer comme pret pour QA, rapporter a super.

Super lance une boucle de patrouille toutes les 5-10 minutes : regarder la sortie de chaque agent actif, verifier le statut des beads, confirmer que le pipeline n'est pas bloque. 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."

Un Vrai Jour

Voici ce qui s'est reellement passe un mercredi fin fevrier 2026.

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

9h30 - Super dispatche le travail. Arch concoit un flux d'authentification de connexion (bascule TLS, champs utilisateur/mot de passe, passage de variables d'environnement). PM ecrit la spec avec les criteres d'acceptation. Eng la prend et commence l'implementation.

Pendant ce temps, en parallele :

PM enregistre deux bugs decouverts pendant les tests de release. L'un est cosmetique : le badge de l'en-tete affiche "v0.10.0-rc.7" au lieu de "v0.10.0" sur les builds finaux. L'autre est specifique a la plateforme : l'outil d'automatisation de captures d'ecran renvoie une bande vide sur les Macs ARM64 parce qu'Apple Silicon rend le WebView de Tauri via la composition Metal, et le backing store est vide.

Ops trouve la cause racine du bug de capture d'ecran. La correction est elegante : apres la capture, verifier si la hauteur de l'image est suspicieusement faible (moins de 50px pour une fenetre qui devrait faire 800px de haut), et se rabattre sur une capture d'ecran basee sur les coordonnees.

Growth extrait les donnees PostHog et lance une analyse de correlation d'IP. La decouverte : les pubs Reddit ont genere 96 clics et zero utilisateurs retenus attribuables. Le trafic via le README GitHub convertit a 15.8%. Cet article que vous lisez existe grace a cette analyse.

Eng1, debloque par le design du Activity Dashboard d'arch, commence a construire la gestion d'etat des filtres croises et des fonctions utilitaires. 687 tests qui passent.

QA1 valide la correction du badge de l'en-tete : demarre un serveur de test, utilise l'automatisation du navigateur pour verifier 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 declenche le workflow de promotion. La CI construit les artefacts pour les 5 plateformes (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifie chaque artefact, met a jour les notes de release sur les deux depots, redeploie le site web et met a jour le cask Homebrew.

15h12 - Owner repond sur l'Issue #2 de GitHub :

Bonne nouvelle : la v0.10.0 vient de sortir avec le support complet de l'authentification serveur Dolt. Mettez a jour et vous devriez etre debloque.

Bug signale le matin. Correction livree l'apres-midi. Et pendant que cela se passait, la prochaine fonctionnalite etait deja en cours de conception, un autre bug etait en cours d'investigation, les analytics etaient analysees et QA validait independamment une autre correction.

Ce n'est pas parce que 13 agents sont rapides. C'est parce que 13 agents sont paralleles.

Ce qui Tourne Mal

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

Les rate limits frappent en haute concurrence. Quand 13 agents tournent tous sur le meme compte API, vous brulez des tokens vite. Ce jour-la en particulier, super, eng1 et eng2 ont tous atteint le plafond de rate limit simultanement. Tout le monde s'arrete. Vous attendez. C'est l'equivalent IA de tout le bureau essayant d'utiliser l'imprimante en meme temps, sauf que l'imprimante coute de l'argent par page et qu'il y a un plafond de pages par minute.

QA renvoie le travail. C'est voulu, mais ca ajoute des cycles. QA a rejete un build parce que le commentaire "DONE" de l'ingenieur n'incluait pas d'etapes de verification. La correction fonctionnait, mais QA ne pouvait pas la confirmer sans lire le code source. Retour a eng, reecrire le commentaire de completion, retour a QA, re-verifier. Vingt minutes pour ce qui aurait du en prendre cinq. Le protocole cree de la friction, mais la friction est porteuse. Chaque fois que j'ai court-circuite QA, quelque chose a casse en production.

Les fenetres de contexte se remplissent. Les agents accumulent du contexte au fil d'une session. Super a un protocole pour envoyer une directive "sauvegardez votre travail" a 65% d'utilisation du contexte. Si vous ratez cette fenetre, 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 relancer la meme commande qui echoue. La boucle de patrouille de super detecte ca, mais seulement si vous verifiez assez frequemment. J'ai perdu 30 minutes avec un agent qui echouait poliment en silence.

Le cout de coordination est reel. Fichiers CLAUDE.md, protocoles de dispatch, boucles de patrouille, commentaires sur les beads, rapports de completion. 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 specialisation bat la generalisation. 13 agents focuses surpassent 3 "full-stack". Quand qa1 ne fait que valider et n'ecrit jamais de code, il attrape des choses que eng a ratees a chaque fois. Quand arch ne fait que concevoir et n'implemente jamais, les conceptions sont plus propres parce qu'il n'y a pas la tentation de raccourcir la spec pour faciliter l'implementation.

Le QA independant est non-negociable. QA a son propre clone du depot. Il teste le code pousse, pas l'arbre de travail. Il ne fait pas confiance a l'auto-rapport de l'ingenieur. Ca parait lent. Ca attrape des bugs a chaque release.

Vous avez besoin de visibilite ou la flotte derive. A 5+ agents, vous ne pouvez pas suivre l'etat en basculant entre les panneaux tmux et en faisant bd list dans votre tete. Vous avez besoin d'un tableau de bord qui montre l'arbre de dependances, quels agents travaillent sur quoi et quels beads sont bloques. C'est le probleme que j'ai construit Beadbox pour resoudre.

La boucle recursive compte. Les agents construisent Beadbox. Beadbox surveille les agents. Quand les agents produisent un bug dans Beadbox, la flotte le detecte via le meme processus QA qui a detecte tous les autres bugs. L'outil s'ameliore parce que l'equipe qui l'utilise le plus est celle qui le construit. Je suis conscient que c'est soit brillant, soit la machine de Rube Goldberg la plus elaboree jamais construite. Les fonctionnalites livrees suggerent le premier. Ma facture de tokens suggere le second.

La Stack

Si vous voulez essayer par vous-meme, voici ce qu'il vous faut :

• beads : Gestionnaire de tickets open-source Git-natif. C'est l'epine dorsale de la coordination. Chaque agent y lit et y ecrit.
• Claude Code : Le runtime des agents. Chaque agent est une session Claude Code dans un panneau tmux avec son propre fichier d'identite CLAUDE.md.
• tmux + gn/gp/ga : Multiplexeur de terminal pour faire tourner les agents cote a cote. Les outils de messagerie permettent aux agents de communiquer sans memoire partagee.
• Beadbox : Tableau de bord visuel en temps reel qui montre ce que la flotte fait. C'est ce dont vous lisez la description.

Vous n'avez pas besoin des 13 agents pour commencer. Deux ingenieurs et un agent QA, coordonnes par beads, changeront votre vision de ce qu'un seul developpeur peut livrer.

La suite

La plus grande lacune du setup actuel, c'est de repondre a trois questions d'un coup d'oeil : quels agents sont actifs, en attente ou bloques ? Ou le travail s'accumule-t-il dans le pipeline ? Et que vient-il de se passer, filtre par l'agent ou l'etape du pipeline qui m'interesse ?

Pour l'instant, ca demande une boucle de patrouille et beaucoup de commandes gp. Alors on construit un tableau de bord de coordination directement dans Beadbox : une barre de statut des agents en haut, un flux de pipeline montrant ou les beads s'accumulent, et un fil d'evenements a filtres croises ou cliquer sur un agent ou une etape du pipeline filtre tout le reste en consequence. Les trois couches partagent la meme source de donnees en temps reel. Les trois se mettent a jour en direct.

Les 13 agents sont en train de le construire. J'ecrirai a ce sujet quand ce sera livre.