Triage des taches bloquees en developpement parallele

Vous pouvez faire tourner 10 agents IA de programmation en parallele maintenant. Donnez a chacun un ticket, pointez-les vers une base de donnees beads partagee et laissez-les travailler. Les agents creent des sous-taches, enregistrent les bugs qu'ils decouvrent, mettent a jour les statuts et ferment les tickets quand ils ont termine. C'est veritablement productif.

Jusqu'a ce que quelque chose se bloque.

Quand un humain est bloque, il le dit. Il poste sur Slack, le signale en standup, va au bureau de quelqu'un. Les agents ne font rien de tout ca. Un agent rencontre une dependance qu'il ne peut pas resoudre et soit se bloque silencieusement, soit commence a contourner le probleme de manieres qui creent plus de problemes. Trois agents peuvent etre coinces sur la meme tache amont non resolue et vous ne le saurez pas avant de vous demander pourquoi rien n'a ete livre depuis quatre heures.

C'est le probleme de triage pour le developpement avec agents. Pas "comment ameliorer nos standups" mais "comment voir ce qui est coince dans une flotte de travailleurs autonomes qui ne se plaignent pas." Voici ce que nous avons appris en construisant Beadbox, un tableau de bord en temps reel pour beads qui vous montre exactement ce que vos agents font, sur quoi ils sont bloques et ce qui vient de devenir disponible.

Allez directement a ce qui vous interesse :

• Comment les agents creent des chaines de blocage -- les motifs propres au travail avec agents
• Detection automatique des dependances -- captez les blocages des leur formation
• Un workflow de triage CLI-first -- scriptable, executable par des agents
• Visibilite en temps reel -- voyez les blocages au moment ou ils surviennent
• Evaluer les outils de triage -- ce qu'il faut chercher
• La boucle du superviseur -- comment nous gerons 10+ agents au quotidien

Comment les agents creent des chaines de blocage

Les agents generent des problemes de dependance differemment des equipes humaines. Comprendre les modes de defaillance compte car les reponses de triage sont differentes.

Les agents ne modelisent pas les dependances a l'avance. Un architecte humain decompose une fonctionnalite en taches et reflechit a l'ordre. Un agent de programmation recoit une tache, commence a travailler et decouvre en cours d'implementation qu'il a besoin de quelque chose qui n'existe pas encore. Il peut creer un nouveau ticket pour cette dependance. Il peut essayer de le construire en ligne et creer un desordre. Il peut simplement s'arreter. Aucun de ces resultats n'est visible sauf si vous surveillez la base de tickets.

Les agents travaillent plus vite que les graphes de dependance ne se mettent a jour. L'Agent-3 ferme une tache que l'Agent-7 attendait, mais l'Agent-7 ne le sait pas car il a verifie les blocages il y a 10 minutes. Pendant ce temps, l'Agent-7 est toujours inactif ou travaille sur quelque chose de moindre priorite. Le deblocage a eu lieu, mais l'information ne s'est pas propagee.

Les dependances circulaires emergent de la decomposition parallele. Quand plusieurs agents decomposent du travail simultanement, ils peuvent creer des cycles qu'aucun agent individuel ne voit. L'Agent-1 cree la Tache A qui depend de la Tache B. L'Agent-2 cree la Tache B qui depend de la Tache C. L'Agent-3 cree la Tache C qui depend de la Tache A. Chaque dependance avait du sens localement. Le cycle n'est visible que d'en haut.

La contention de ressources est invisible. Deux agents doivent modifier le meme fichier, ou les deux ont besoin de l'environnement de staging, ou les deux ont besoin que la meme bibliotheque partagee soit dans un etat stable. Aucune dependance n'est declaree car aucun agent ne sait que l'autre existe. Les deux ralentissent et aucun ne rapporte pourquoi.

Le fil conducteur : les agents produisent des situations de blocage plus vite qu'ils ne les signalent. Le superviseur (vous) a besoin d'outils qui font remonter les blocages automatiquement, pas d'outils qui attendent que quelqu'un leve un drapeau.

Detection automatique des dependances

La solution, ce sont des donnees de dependance explicites, interrogeables, creees au moment de la tache et verifiees en continu. Voici ce que ca donne avec beads, le gestionnaire de tickets Git-natif sur lequel nous faisons tourner notre flotte d'agents.

Les agents enregistrent les dependances quand ils creent des taches :

# Agent creates a task and discovers it needs an API that doesn't exist
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# Agent creates its own task and declares the dependency
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

Ce bd dep add est un seul appel CLI. N'importe quel agent IA (Claude Code, Cursor, Copilot Workspace) peut l'executer. Pas de bibliotheque client API, pas de danse d'authentification. La dependance est maintenant une donnee structuree, interrogeable par tout autre agent ou script.

La detection de cycles tourne automatiquement :

# beads checks the full dependency graph for cycles
bd dep cycles

# Output when cycles exist:
# CYCLE DETECTED: beads-a1b -> beads-c3d -> beads-e5f -> beads-a1b

Sur un graphe de 5 000 dependances, ca prend ~70ms. Lancez-le comme hook post-commit ou sur un cron de 5 minutes. Quand trois agents creent independamment un cycle de dependance, vous le detectez en minutes au lieu de le decouvrir des heures plus tard quand les trois sont a l'arret.

Trouvez toutes les taches bloquees en une commande :

bd blocked --json | jq -r '.[] |
  "BLOCKED: \(.id) \(.title)\n  waiting on: \(.blocked_by | join(", "))\n  assignee: \(.owner // "unassigned")\n"'

Sortie :

BLOCKED: beads-x7q Build order history page
  waiting on: beads-m2k Implement /api/v2/orders endpoint
  assignee: agent-3

BLOCKED: beads-r4p Deploy staging environment
  waiting on: beads-j9w Fix Docker build, beads-n1c Update TLS certificates
  assignee: agent-7

Maintenant vous savez que l'Agent-3 et l'Agent-7 sont bloques, sur quoi ils sont bloques et ce qui doit se passer pour les debloquer. L'ensemble de cette requete a pris 30ms sur une base de 10K tickets.

Detectez les PRs bloquees par conventions de nommage de branches :

#!/bin/bash
# blocked-prs.sh: find PRs whose dependencies haven't merged

for pr in $(gh pr list --json number,headRefName --jq '.[].headRefName'); do
  ISSUE_ID=$(echo "$pr" | grep -oE 'beads-[a-z0-9]+')
  [ -z "$ISSUE_ID" ] && continue

  BLOCKERS=$(bd show "$ISSUE_ID" --json | jq -r '.blocked_by[]' 2>/dev/null)
  for blocker in $BLOCKERS; do
    BLOCKER_STATUS=$(bd show "$blocker" --json | jq -r '.status')
    if [ "$BLOCKER_STATUS" != "closed" ]; then
      echo "PR ($pr) blocked: $ISSUE_ID waiting on $blocker ($BLOCKER_STATUS)"
    fi
  done
done

Vingt lignes de shell. Tourne localement, lit des donnees locales, vous dit quelles PRs de vos agents ne peuvent pas encore etre fusionnees et pourquoi.

Un workflow de triage CLI-first

Le triage dans un workflow avec agents n'est pas une reunion. C'est un script qui tourne en boucle. Le superviseur (humain ou agent) regarde ce qui est bloque et prend une decision pour chaque element.

Voici le script de triage que nous utilisons reellement :

#!/bin/bash
# triage.sh: agentic fleet blocker triage

echo "========================================="
echo "TRIAGE REPORT: $(date +%Y-%m-%d %H:%M)"
echo "========================================="

# 1. What's blocked?
echo -e "\n--- BLOCKED TASKS ---"
bd blocked --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title)
    blocked by: \(.blocked_by | join(", "))
    assignee: \(.owner // "unassigned")\n"'

# 2. What's available for agents to pick up?
echo -e "\n--- READY (unblocked, open) ---"
bd ready --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title) (\(.owner // "unassigned"))"'

# 3. Which agents have gone quiet?
echo -e "\n--- STALE IN-PROGRESS (no update in 2h) ---"
CUTOFF=$(date -v-2H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -d '2 hours ago' --iso-8601=seconds)
bd list --status=in_progress --json | jq -r --arg cutoff "$CUTOFF" '.[] |
  select(.updated_at < $cutoff) |
  "STALE: \(.id) \(.title) (last update: \(.updated_at), assignee: \(.owner // "unknown"))"'

# 4. Dependency health
echo -e "\n--- DEPENDENCY CYCLES ---"
bd dep cycles 2>&1 || echo "No cycles detected."

echo -e "\n--- FLEET STATS ---"
bd stats

Pour les equipes humaines, "stagnant" signifie 48 heures sans mise a jour. Pour les agents, 2 heures de silence sur une tache en cours est un signal d'alerte. Soit l'agent est bloque et ne le signale pas, soit il a plante. Dans les deux cas, vous devez regarder.

L'arbre de decision pour chaque element bloque :

1. Un autre agent peut-il le debloquer ? Repriorisez la tache bloquante, assignez un agent disponible.
2. La dependance est-elle fausse ? Les agents declarent parfois des dependances trop conservatrices pendant la planification. Si le blocage n'est pas reel, supprimez-le : bd dep remove beads-x7q beads-m2k (supprime la dependance de x7q envers m2k, debloquant x7q instantanement).
3. Le travail peut-il etre decoupe ? Faites faire a l'agent bloque les parties qui n'ont pas besoin de la dependance. Creez une tache de suivi pour le reste.
4. Est-ce un blocage externe ? Quelque chose que seul un humain peut resoudre (cle API, decision de conception, attribution d'acces). Etiquetez-le, notez la resolution attendue et reassignez l'agent a un autre travail pret.

L'option 2 arrive constamment avec les agents. Ils modelisent les dependances en se basant sur leur comprehension du codebase au moment de la planification. Une fois l'implementation demarree, la forme reelle du travail revele que la moitie de ces dependances etaient inutiles.

Visibilite en temps reel du travail des agents

Lancer un script de triage toutes les 30 minutes laisse des trous. Quand les agents travaillent vite, beaucoup de choses se passent entre les verifications. La question devient : pouvez-vous voir les blocages se former en temps reel ?

Comment Beadbox le fait :

La base de donnees beads vit dans un repertoire .beads/ sur votre systeme de fichiers. Chaque bd update, bd create ou bd close qu'un agent execute ecrit dans ce repertoire. Beadbox le surveille avec fs.watch() et pousse les changements vers l'interface via WebSocket en quelques millisecondes.

L'effet pratique : l'Agent-5 lance bd update beads-x7q --status=closed dans un terminal. Le tableau de bord Beadbox montre immediatement cette tache comme fermee, et toute tache qui etait bloquee par elle apparait comme nouvellement disponible. Vous voyez la cascade sans lancer aucune commande.

Cela compte parce que le travail des agents cree des rafales. Un agent peut fermer trois taches en 90 secondes, chacune debloquant du travail different en aval. Un tableau de bord base sur le polling avec un intervalle de rafraichissement de 30 secondes montrerait un etat intermediaire confus. La propagation sub-seconde vous montre le tableau complet en direct.

Si vous n'utilisez pas Beadbox, la surveillance du systeme de fichiers fonctionne aussi :

# Watch the beads database for changes, alert on new blocks
# Note: fswatch fires on every write. In production you'd debounce this
# (e.g., sleep 2 after each trigger) to avoid noise during burst writes.
fswatch -o .beads/ | while read; do
  BLOCKED_COUNT=$(bd blocked --json | jq length)
  if [ "$BLOCKED_COUNT" -gt 0 ]; then
    echo "$(date): $BLOCKED_COUNT tasks currently blocked"
    # Pipe to ntfy, Slack webhook, or any notification system
  fi
done

Fermez la boucle avec la CI :

# In your CI post-build step: auto-close the issue when the build passes
if [ "$BUILD_STATUS" = "success" ]; then
  ISSUE_ID=$(echo "$BRANCH_NAME" | grep -oE 'beads-[a-z0-9]+')
  if [ -n "$ISSUE_ID" ]; then
    bd update "$ISSUE_ID" --status=closed
    bd comments add "$ISSUE_ID" --author ci \
      "Build passed. Commit: $COMMIT_SHA. Closing automatically."
  fi
fi

Quand la CI ferme ce ticket, tout ce qui etait bloque par lui se debloque. Si un agent surveille bd ready pour du nouveau travail, il prend la tache debloquee automatiquement. Pas d'humain dans la boucle pour les deblocages routiniers.

C'est la difference entre les outils qui suivent le statut et les outils qui le propagent. La plupart des logiciels de gestion de projet font le premier : vous mettez a jour une carte, la carte change de couleur. La propagation signifie que les effets en aval (deblocage des dependants, mise en surface du travail disponible, mise a jour des rouleaux de progression) se produisent sans que personne ne clique.

Evaluer les outils de triage pour les workflows avec agents

Si vous cherchez de l'outillage pour gerer une flotte d'agents, les exigences different de ce dont une equipe humaine a besoin.

Indispensable : un CLI que les agents peuvent appeler. Si votre gestionnaire de tickets n'a qu'une interface web, les agents ne peuvent pas l'utiliser. Ils doivent executer des commandes shell. bd create, bd update, bd blocked sont des one-liners que tout agent de programmation sait deja executer. Les API REST fonctionnent aussi, mais elles necessitent des tokens d'authentification, des clients HTTP et de la gestion d'erreurs. Les Unix pipes sont plus simples.

Indispensable : graphe de dependances interrogeable. "Bloque" comme etiquette de statut est inutile pour l'automatisation. Vous avez besoin de "A depend de B" comme donnee structuree pour que les scripts puissent parcourir le graphe, detecter les cycles et calculer ce qui est pret.

Indispensable : lectures locales sub-seconde. Quand les agents interrogent le travail disponible, le temps de reponse compte. Un aller-retour API de 2 secondes par requete, multiplie par 10 agents interrogeant chaque minute, cree une surcharge mesurable. beads renvoie les resultats de bd ready en 30ms sur une base de 10K tickets parce que tout est local.

Souhaitable : propagation des changements en temps reel. Si les agents creent et resolvent 50 tickets par heure, vous devez voir l'etat au fur et a mesure qu'il change, pas sur un intervalle de rafraichissement.

Signal d'alarme : "detection de blocages par IA." Les outils qui pretendent detecter les blocages en analysant les descriptions de tickets produisent des faux positifs et ratent les vrais blocages qui n'ont jamais ete documentes. Les declarations explicites avec bd dep add battent l'inference.

Signal d'alarme : outils qui necessitent un navigateur pour trier. Debloquer une tache via une interface web prend 5-15 secondes de clics. Via le CLI, bd dep remove prend 18ms. Sur 50 taches bloquees, c'est 1 minute contre 12 minutes. Quand vous supervisez des agents qui bougent vite, la vitesse de triage est votre goulot d'etranglement.

Comment les outils courants gerent le blocage

La boucle du superviseur

Voici le workflow que nous executons quotidiennement, gerant plus de 10 agents IA sur un seul projet :

1. Les agents declarent les dependances au moment de la creation de la tache. Chaque bd create qui a un prerequis recoit un bd dep add immediatement. C'est un seul appel CLI supplementaire par tache.

2. Un agent superviseur lance bd blocked toutes les 30 minutes. Si quelque chose est nouvellement bloque, il resout le blocage lui-meme (reprioriser, reassigner) ou le signale a l'humain.

3. Beadbox tourne sur l'ecran de l'humain. Le tableau de bord montre le graphe complet de dependances avec les taches bloquees mises en evidence en temps reel. La plupart du temps, l'automatisation gere les deblocages routiniers. Quand elle ne peut pas (dependance externe, decision architecturale, attribution d'acces), l'humain voit le probleme immediatement et intervient.

4. Les taches stagnantes sont signalees agressivement. Un agent qui n'a pas mis a jour sa tache en cours depuis 2 heures est soit bloque, soit plante. Le superviseur verifie et soit relance l'agent, reassigne le travail ou investigue.

5. Les fausses dependances sont elaguees en continu. Les agents sur-declarent les dependances pendant la planification. Au fur et a mesure que l'implementation revele la forme reelle du travail, le superviseur (ou les agents eux-memes) suppriment les dependances qui se sont averees inutiles. Un graphe propre est un graphe utile.

Le principe sous-jacent : les agents sont rapides mais pas auto-conscients. Ils ne savent pas ce que les autres agents font, ne remarquent pas quand les blocages se resolvent et ne se plaignent pas quand ils sont coinces. Le travail du superviseur est d'etre le systeme nerveux qui connecte tout cela. Des donnees de dependance structurees, interrogees automatiquement et rendues visuellement, c'est ce qui rend cela possible.

Beadbox est gratuit pendant la beta. Il vous montre ce que vos agents font, ce qui est bloque et ce qui vient de devenir disponible, en temps reel.

brew tap beadbox/cask && brew install --cask beadbox

Si vous utilisez deja beads, Beadbox lit votre repertoire .beads/ existant sans etape d'import. Essayez-le.