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

Questo e il mio terminale in questo momento.

13 agenti Claude Code, ognuno nel proprio pannello tmux, che lavorano sullo stesso codebase. Non come esperimento. Non per vantarmi. Cosi rilascio software ogni singolo giorno.

Il progetto e Beadbox, una dashboard in tempo reale per monitorare agenti AI di coding. E 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 piu di due o tre agenti e ti chiedi come tenere traccia di quello che fanno tutti, questo e il punto a cui sono arrivato dopo mesi di iterazione.

Il team

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

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

Ogni CLAUDE.md inizia con un paragrafo d'identita e una sezione sui confini. Ecco una versione abbreviata di quello 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, potevano condividere un unico prompt generico. Con 13, ruoli espliciti e protocolli sono la differenza tra coordinamento e caos.

Il livello di coordinamento

Tre strumenti tengono insieme la flotta.

beads e un issue tracker open-source, Git-native, pensato esattamente per questo workflow. Ogni task e un "bead" con stato, priorita, 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                           # vedi la specifica completa + commenti
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 pubblica il suo piano

gn / gp / ga sono strumenti di messaggistica tmux. gn invia un messaggio al pannello di un altro agente. gp sbircia l'output recente di un altro agente (senza interromperlo). ga accoda un messaggio non urgente.

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

I protocolli CLAUDE.md definiscono percorsi di escalation, formato di comunicazione e criteri di completamento. Ogni agente sa: prendi in carico il bead, commenta il tuo piano prima di scrivere codice, esegui i test prima di pushare, commenta DONE con passi di verifica, marca come ready for QA, riferisci a super.

Super esegue un ciclo di pattugliamento ogni 5-10 minuti: sbircia l'output di ogni agente attivo, controlla lo stato dei bead, verifica che la pipeline non si sia bloccata. E come una rotazione di reperibilita in produzione, tranne che i servizi sono agenti AI e gli incidenti sono "eng2 e sospettosamente silenzioso da 20 minuti."

Una giornata reale

Ecco cosa e successo realmente un mercoledi 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 vede e lo segnala a super.

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

Nel frattempo, in parallelo:

PM segnala due bug scoperti durante il test di rilascio. Uno e cosmetico: il badge nell'header mostra "v0.10.0-rc.7" invece di "v0.10.0" sulle build finali. L'altro e specifico alla piattaforma: lo strumento di automazione degli screenshot restituisce una striscia vuota sui Mac ARM64 perche Apple Silicon renderizza la WebView di Tauri tramite il compositing Metal, e il backing store e vuoto.

Ops trova la causa dello screenshot bug. La soluzione e elegante: dopo la cattura, verifica se l'altezza dell'immagine e sospettosamente piccola (sotto 50px per una finestra che dovrebbe essere alta 800px), e usa come fallback la cattura schermo basata sulle coordinate.

Growth estrae dati da PostHog ed esegue un'analisi di correlazione IP. La scoperta: le ads su Reddit hanno generato 96 click e zero utenti attribuibili e fidelizzati. Il traffico dal README su GitHub converte al 15.8%. Questo articolo esiste grazie a quell'analisi.

Eng1, sbloccato dal design della Activity Dashboard di arch, inizia a costruire la gestione dello stato dei filtri incrociati e le funzioni utility. 687 test superati.

QA1 valida la correzione del badge nell'header: avvia un server di test, usa l'automazione del browser per verificare che il badge si renderizzi correttamente, verifica che 665 unit test passino, marca PASS.

14:45 - Shipper mergia la PR del release candidate, pusha il tag v0.10.0 e avvia il workflow di promozione. La CI genera gli artefatti per tutte e 5 le piattaforme (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica ogni artefatto, aggiorna le note di rilascio su entrambi i repo, rideploya il sito web e aggiorna il cask Homebrew.

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

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

Bug segnalato la mattina. Fix rilasciato nel pomeriggio. E mentre succedeva, la funzionalita successiva era gia in fase di progettazione, un bug diverso veniva investigato, le analytics venivano analizzate e QA stava verificando indipendentemente una correzione separata.

Non e perche 13 agenti sono veloci. E perche 13 agenti sono paralleli.

Cosa va storto

Questa e 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 particolare, super, eng1 ed eng2 hanno toccato il tetto del rate limit contemporaneamente. Tutti si fermano. Aspetti. E l'equivalente AI di quando tutti in ufficio cercano di usare la stampante nello stesso momento, tranne che la stampante costa a pagina e c'e un tetto di pagine al minuto.

QA respinge il lavoro. Questo e voluto, ma aggiunge cicli. QA ha respinto una build perche il commento "DONE" dell'ingegnere non includeva passi di verifica. La correzione funzionava, ma QA non poteva confermarla senza leggere il codice sorgente. Ritorno a eng, riscrittura del commento di completamento, ritorno a QA, ri-verifica. Venti minuti per quello che sarebbe dovuto essere cinque. Il protocollo crea attrito, ma quell'attrito e strutturale. Ogni volta che ho fatto scorciatoie sulla QA, qualcosa si e rotto in produzione.

Le finestre di contesto si riempiono. Gli agenti accumulano contesto durante una sessione. Super ha un protocollo per inviare una direttiva "salva il tuo lavoro" al 65% di utilizzo del contesto. Se perdi quella finestra, l'agente perde il filo di quello che stava facendo.

Gli agenti si bloccano. A volte un agente finisce in un loop di errori e continua a riprovare lo stesso comando fallimentare. Il ciclo di pattugliamento di super lo intercetta, ma solo se controlli abbastanza frequentemente. Ho perso 30 minuti per un agente che stava educatamente fallendo in silenzio.

L'overhead di coordinamento e reale. File CLAUDE.md, protocolli di dispatch, cicli di pattugliamento, commenti sui bead, report di completamento. Per un setup a due agenti, e eccessivo. Per 13 agenti, e la struttura minima necessaria. C'e un punto di incrocio attorno ai 5 agenti dove il coordinamento informale smette di funzionare e servono protocolli espliciti, oppure inizi a perdere il controllo di cosa sta succedendo.

Cosa ho imparato

La specializzazione batte la generalizzazione. 13 agenti focalizzati superano 3 agenti "full-stack". Quando qa1 si limita a validare e non scrive mai codice, trova cose che eng ha mancato ogni singola volta. Quando arch si limita a progettare e non implementa mai, i design sono piu puliti perche non c'e la tentazione di tagliare angoli nella specifica per semplificare l'implementazione.

QA indipendente non e negoziabile. QA ha il suo clone del repo. Testa il codice pushato, non il working tree. Non si fida del report dell'ingegnere. Sembra lento. Trova bug ad ogni rilascio.

Hai bisogno di visibilita o la flotta va alla deriva. Con piu di 5 agenti, non puoi tracciare lo stato saltando tra pannelli tmux ed eseguendo bd list nella tua testa. Hai bisogno di una dashboard che ti mostri l'albero delle dipendenze, quali agenti stanno lavorando su cosa e quali bead sono bloccati. E 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 tramite lo stesso processo QA che ha intercettato ogni altro bug. Lo strumento migliora perche il team che lo usa di piu e il team che lo costruisce. Sono consapevole che questo e o geniale o la macchina di Rube Goldberg piu elaborata mai costruita. Le funzionalita rilasciate suggeriscono la prima ipotesi. La mia fattura di token suggerisce la seconda.

Lo stack

Se vuoi provare tu stesso, ecco cosa ti serve:

• beads: Issue tracker open-source Git-native. E la spina dorsale del coordinamento. Ogni agente legge e scrive su di esso.
• Claude Code: Il runtime degli agenti. Ogni agente e una sessione Claude Code in un pannello tmux con il proprio file di identita CLAUDE.md.
• tmux + gn/gp/ga: Multiplexer di terminale per far girare gli agenti fianco a fianco. Gli strumenti di messaggistica permettono agli agenti di comunicare senza memoria condivisa.
• Beadbox: Dashboard visuale in tempo reale che ti mostra cosa sta facendo la flotta. E quello di cui stai leggendo.

Non hai bisogno di tutti i 13 agenti per iniziare. Due ingegneri e un agente QA, coordinati tramite beads, cambieranno il modo in cui pensi a quello che un singolo sviluppatore puo rilasciare.

Cosa arriva dopo

Il gap piu grande nel setup attuale e rispondere a tre domande con un colpo d'occhio: quali agenti sono attivi, in attesa o bloccati? Dove si accumula il lavoro nella pipeline? E cosa e appena successo, filtrato per l'agente o la fase della pipeline che mi interessa?

Al momento serve un loop di pattugliamento e molti comandi gp. Quindi stiamo costruendo una dashboard di coordinamento direttamente in Beadbox: una striscia di stato agenti in cima, un flusso pipeline che mostra dove si accumulano i beads, e un feed di eventi con filtri incrociati dove cliccare su un agente o una fase della pipeline filtra tutto il resto di conseguenza. Tutti e tre i livelli condividono la stessa sorgente dati in tempo reale. Tutti e tre si aggiornano in diretta.

I 13 agenti lo stanno costruendo adesso. Scrivero quando sara rilasciato.