Questo è il mio terminale in questo momento.

Sessione tmux con 13 agenti

13 agenti Claude Code, ognuno nel proprio pane tmux, che lavorano sulla stessa codebase. Non è un esperimento. Non è per vantarmi. Così rilascio software ogni singolo giorno.

Il progetto è Beadbox, una dashboard in tempo reale per monitorare agenti AI di coding. È costruito dalla stessa flotta di agenti che monitora. Gli agenti scrivono il codice, lo testano, lo revisionano, lo impacchettano e lo rilasciano. Io coordino.

Se stai gestendo più di due o tre agenti e ti chiedi come tenere traccia di quello che fanno, questo è il punto a cui sono arrivato dopo mesi di iterazione. Un bug segnalato alle 9 del mattino è stato fixato entro le 15, mentre quattro altri workstream procedevano in parallelo. Non sempre fila tutto liscio, ma la produttività è reale.

Il team

Ogni agente ha un file CLAUDE.md che definisce la sua identità: di cosa si occupa, di cosa no, e come comunica con gli altri agenti. Non sono assistenti generici "fai qualsiasi cosa". Ognuno ha un compito preciso e confini espliciti.

Gruppo	Agenti	Di cosa si occupano
Coordinamento	super, pm, owner	Dispatch del lavoro, specifiche di prodotto, priorità di business
Engineering	eng1, eng2, arch	Implementazione, system design, test suite
Qualità	qa1, qa2	Validazione indipendente, release gate
Operations	ops, shipper	Test di piattaforma, build, esecuzione dei rilasci
Growth	growth, pmm, pmm2	Analytics, posizionamento, contenuti pubblici

La parola chiave è confini. eng2 non può chiudere issue. qa1 non scrive codice. pmm non tocca mai il sorgente dell'app. Super assegna il lavoro ma non implementa. I confini esistono perché senza, gli agenti vanno alla deriva. "Aiutano" facendo refactor di codice che non ne aveva bisogno, chiudendo issue non verificate, o prendendo decisioni architetturali per cui non sono qualificati.

Ogni CLAUDE.md inizia con un paragrafo di identità e una sezione sui confini. Ecco una versione abbreviata di quella di 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.

Questo pattern scala. Quando ho iniziato con 3 agenti, bastava un unico prompt generico. Con 13, ruoli espliciti e protocolli fanno la differenza tra coordinamento e caos.

Il livello di coordinamento

Tre strumenti tengono insieme la flotta.

beads è un issue tracker open-source e Git-native, pensato esattamente per questo workflow. Ogni task è un "bead" con stato, priorità, dipendenze e un thread di commenti. Gli agenti leggono e scrivono sullo stesso database locale tramite una CLI chiamata bd.

bd update bb-viet --claim --actor eng2   # eng2 prende in carico un bug
bd show bb-viet                           # visualizza spec completa + commenti
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 pubblica il suo piano

gn / gp / ga sono tool di messaggistica tmux. gn invia un messaggio al pane di un altro agente. gp sbircia l'output recente di un altro agente (senza interromperlo). ga mette in coda un messaggio non urgente.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # dispatch
gp eng2 -n 40                                               # controlla il progresso
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # report

I protocolli CLAUDE.md definiscono i percorsi di escalation, il formato di comunicazione e i criteri di completamento. Ogni agente sa: claimare il bead, commentare il piano prima di scrivere codice, far girare i test prima del push, commentare DONE con i passi di verifica, segnare come ready for QA, riferire a super.

Ecco come funziona in pratica. Questo è un bead reale di oggi: super assegna il task, eng2 commenta un piano numerato, eng2 commenta DONE con i passi di verifica QA e i criteri di accettazione spuntati, super lo passa a QA.

Un thread di commenti reale che mostra il workflow PLAN/DONE completo

Super fa un giro di controllo ogni 5-10 minuti: sbirciare l'output di ogni agente attivo, controllare lo stato dei bead, verificare che la pipeline non si sia bloccata. È come un turno di reperibilità in produzione, solo che i servizi sono agenti AI e gli incident sono "eng2 è sospettosamente silenzioso da 20 minuti."

Una giornata reale

Ecco cos'è successo davvero un mercoledì di fine febbraio 2026.

9:14 – Un utente GitHub di nome ericinfins apre la Issue #2: non riesce a connettere Beadbox al suo server Dolt remoto. L'app supporta solo connessioni locali. Owner lo nota e lo segnala a super.

9:30 – Super smista il lavoro. Arch progetta un flusso di autenticazione per la connessione (toggle TLS, campi username/password, passaggio di variabili d'ambiente). PM scrive la spec con i criteri di accettazione. Eng prende in carico e inizia a implementare.

Nel frattempo, in parallelo:

PM segnala due bug scoperti durante il release testing. Uno è cosmetico: il badge nell'header mostra "v0.10.0-rc.7" invece di "v0.10.0" sulle build finali. L'altro è specifico della piattaforma: il tool di screenshot automation restituisce una striscia vuota sui Mac ARM64 perché Apple Silicon renderizza la WebView di Tauri attraverso il compositing Metal, e il backing store è vuoto.

Ops trova la root cause del bug degli screenshot. Il fix è elegante: dopo la cattura, verificare se l'altezza dell'immagine è sospettosamente piccola (sotto 50px per una finestra che dovrebbe essere alta 800px) e fare fallback alla cattura schermo basata su coordinate.

Growth estrae i dati da PostHog e fa un'analisi di correlazione IP. La scoperta: le Reddit Ads hanno generato 96 click e zero utenti retained attribuibili. Il traffico dal README su GitHub converte al 15,8%. Questo articolo esiste grazie a quell'analisi.

Eng1, sbloccato dal design dell'Activity Dashboard di arch, inizia a costruire il cross-filter state management e le funzioni utility. 687 test verdi.

QA1 valida il fix del badge nell'header: avvia un server di test, usa la browser automation per verificare che il badge venga renderizzato correttamente, controlla che 665 unit test passino, segna PASS.

14:45 – Shipper fa il merge della PR del release candidate, pusha il tag v0.10.0 e triggera il workflow di promozione. La CI genera artefatti per tutte e 5 le piattaforme (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica ogni artefatto, aggiorna le release note su entrambi i repo, fa il redeploy del sito e aggiorna il Homebrew cask.

15:12 – Owner risponde sulla GitHub Issue #2:

Buone notizie: la v0.10.0 è appena uscita con supporto completo all'autenticazione del server Dolt. Aggiorna e dovresti essere sbloccato.

Bug segnalato la mattina. Fix rilasciato nel pomeriggio. E nel frattempo, la feature successiva era già in fase di design, un altro bug veniva investigato, le analytics venivano analizzate, e QA stava verificando in autonomia un fix separato.

Non è perché 13 agenti sono veloci. È perché 13 agenti sono paralleli.

Cosa va storto

Questa è la parte che la maggior parte dei post "guardate il mio setup AI" omette.

I rate limit colpiscono ad alta concorrenza. Quando 13 agenti girano tutti sullo stesso account API, bruci token velocemente. In questa giornata, super, eng1 ed eng2 hanno raggiunto il tetto del rate limit contemporaneamente. Tutti fermi. Aspetti. È l'equivalente AI di quando tutti in ufficio cercano di usare la stampante nello stesso momento, solo che la stampante costa a pagina e c'è un limite di pagine al minuto.

QA rimanda indietro il lavoro. È intenzionale, ma aggiunge cicli. QA ha respinto una build perché il commento DONE dell'engineer non includeva i passi di verifica. Il fix funzionava, ma QA non poteva confermarlo senza leggere il sorgente. Di ritorno a eng, riscrittura del commento di completamento, di nuovo a QA, ri-verifica. Venti minuti per qualcosa che avrebbe dovuto prenderne cinque. Il protocollo genera attrito, ma quell'attrito è strutturale. Ogni volta che ho saltato la QA, qualcosa si è rotto in produzione.

I context window si riempiono. Gli agenti accumulano contesto durante una sessione. Super ha un protocollo che invia una direttiva "salva il tuo lavoro" al 65% di utilizzo del contesto. Se perdi quella finestra, l'agente perde il filo.

Gli agenti si inchiodano. A volte un agente finisce in un loop di errori e continua a riprovare lo stesso comando che fallisce. Il giro di controllo di super lo intercetta, ma solo se controlli abbastanza spesso. Ho perso 30 minuti per un agente che stava fallendo educatamente in silenzio.

L'overhead di coordinamento è reale. File CLAUDE.md, protocolli di dispatch, giri di controllo, commenti sui bead, report di completamento. Per un setup a due agenti è overkill. Per 13 agenti è la struttura minima che funziona. C'è un punto di svolta intorno ai 5 agenti dove il coordinamento informale smette di funzionare e servono protocolli espliciti, altrimenti perdi il controllo.

Cosa ho imparato

La specializzazione batte la generalizzazione. 13 agenti focalizzati superano 3 agenti "full-stack". Quando qa1 fa solo validazione e non scrive mai codice, trova cose che eng ha mancato, ogni volta. Quando arch fa solo design e non implementa mai, i design escono più puliti perché non c'è la tentazione di tagliare la spec per semplificare l'implementazione.

QA indipendente non è negoziabile. QA ha il suo clone del repo. Testa il codice pushato, non il working tree. Non si fida del self-report dell'engineer. Sembra lento. Trova bug a ogni rilascio.

Senza visibilità, la flotta va alla deriva. Con più di 5 agenti, non puoi tracciare lo stato saltando tra i pane tmux e facendo bd list a mente. Ti serve una dashboard che mostri l'albero delle dipendenze, quali agenti stanno lavorando su cosa e quali bead sono bloccati. È il problema per cui ho costruito Beadbox.

Il loop ricorsivo conta. Gli agenti costruiscono Beadbox. Beadbox monitora gli agenti. Quando gli agenti producono un bug in Beadbox, la flotta lo intercetta con lo stesso processo QA che ha intercettato ogni altro bug. Il tool migliora perché il team che lo usa di più è lo stesso che lo costruisce. Sono consapevole che questo è o geniale o la macchina di Rube Goldberg più elaborata mai costruita. Le feature rilasciate suggeriscono la prima ipotesi. La mia fattura di token suggerisce la seconda.

Lo stack

Se vuoi provare, ecco cosa ti serve:

beads: Issue tracker open-source e Git-native. È la spina dorsale del coordinamento. Ogni agente legge e scrive su di esso.
Claude Code: Il runtime degli agenti. Ogni agente è una sessione Claude Code in un pane tmux con il proprio file di identità CLAUDE.md.
tmux + gn/gp/ga: Terminal multiplexer per far girare gli agenti fianco a fianco. I tool di messaggistica permettono agli agenti di comunicare senza shared memory.
Beadbox: Dashboard visuale in tempo reale che ti mostra cosa sta facendo la flotta. È quello di cui stai leggendo.

Non servono tutti i 13 agenti per iniziare. Due engineer e un agente QA, coordinati tramite beads, cambieranno il modo in cui pensi a quello che un singolo sviluppatore può shippare.

Cosa arriva dopo

La lacuna più grande nel setup attuale è rispondere a tre domande con un colpo d'occhio: quali agenti sono attivi, idle o inchiodati? Dove si accumula il lavoro nella pipeline? E cos'è appena successo, filtrato per agente o per fase della pipeline che mi interessa?

Al momento serve un giro di controllo e tanti comandi gp. Per questo stiamo costruendo una dashboard di coordinamento direttamente dentro Beadbox: una barra di stato agenti in alto, un flusso pipeline che mostra dove si accumulano i bead, e un feed di eventi con filtri incrociati dove cliccare su un agente o una fase filtra tutto il resto di conseguenza. Tutti e tre i livelli condividono la stessa sorgente dati in tempo reale. Tutti e tre si aggiornano live.

Anteprima Activity Dashboard

I 13 agenti lo stanno costruendo adesso. Scriverò quando sarà live.

Sviluppo software con 13 agenti AI. Ecco com'è davvero