Un sistema multi-agent per lo sviluppo software con governance umana, controllo dei costi e decision-making strategico
→ Codice e repository completo su GitHub: https://github.com/rheorix/agentic-company
Introduzione
Questo weekend mi sono chiesto come sfruttare davvero l’AI per rendere più efficiente l’intero processo di sviluppo software (SDLC – Software Development Life Cycle).
Non mi interessava usare Claude Code per scrivere codice più velocemente o migliorare la qualità delle singole righe.
Volevo qualcosa di più radicale:
Cosa succederebbe se un team di sviluppo fosse composto solo da agenti AI specializzati?
- Un Product Manager che non esiste fisicamente
- Un Developer che non esiste
- Un QA Engineer che non esiste
- Un Cost Controller che non esiste
E tu, al centro del sistema, non più come esecutore, ma come decision maker strategico.
Non micro-gestisci il lavoro.
Non scrivi ogni riga di codice.
Definisci la direzione, imposti i vincoli, valuti la qualità delle decisioni e governi il budget dell’intero sistema.
L’obiettivo non è automatizzare lo sviluppo.
È costruire un’organizzazione di agenti AI con ruoli specializzati, in cui il lavoro viene distribuito ma la responsabilità decisionale rimane umana.
–> Codice e repository completo su GitHub: https://github.com/rheorix/agentic-company
Cos’è un’architettura multi-agent
Nel contesto dello sviluppo software, un’architettura multi-agent distribuisce il lavoro tra modelli specializzati invece che affidarlo a un unico LLM generalista.
Nel pattern Orchestrator → Subagents:
- ogni agente ha una responsabilità chiara e limitata
- ogni agente opera con una context window isolata
- un sistema centrale (Orchestrator) coordina il flusso di lavoro
Il risultato è un sistema più:
- stabile
- prevedibile
- controllabile
In sintesi
- Architettura: Orchestrator → Subagents
- Ruoli: PM, Developer, QA, Cost Controller
- Stack: Java 21, Spring Boot 3.x, Maven, JUnit 5 + Mockito
- Output: applicazione REST completa
- Costo medio per feature: < $1
Perché un singolo agente non basta
Il vero limite non è la capacità del modello, ma la gestione del contesto.
Un LLM può eccellere nella logica applicativa, nella progettazione delle API o nella scrittura dei test.
Ma quando deve tenere tutto insieme, emerge il fenomeno della attention dilution.
Attention dilution
È una condizione in cui, aumentando la quantità di informazioni nel contesto, il modello fatica a dare il giusto peso ai dettagli davvero rilevanti.
È lo stesso motivo per cui nei team umani il lavoro viene suddiviso:
non per incapacità individuale, ma per aumentare la qualità complessiva.
La soluzione: separare i contesti
Il principio è semplice: ogni agente vede solo ciò che gli serve.
- PM → requisiti e obiettivi
- Developer → specifiche tecniche
- QA → codice prodotto
Nessun contesto superfluo.
Nessuna sovrapposizione inutile.
Questo approccio aumenta la precisione e riduce l’ambiguità.
Il pattern Orchestrator → Subagents
Il flusso è lineare e controllato:
Orchestrator
↓
PM → specifica
↓ (approval umano)
Developer → codice
↓ (approval umano)
QA → test + report
↓ (approval umano)
Cost Controller → report costiNon è una rete caotica di agenti che dialogano liberamente.
È una pipeline strutturata con punti di controllo espliciti.
Setup: come iniziare
Prerequisiti
- Java 21
- Maven
- npm install -g @anthropic-ai/claude-code
- claude login
Struttura del progetto
agentic-company/
├── CLAUDE.md
├── .claude/agents/
├── shared/
└── output/- .claude/agents/ → comportamento degli agenti
- shared/ → stato condiviso
- output/ → codice generato
CLAUDE.md: il sistema operativo del team
Questo file rappresenta le regole costituzionali del sistema:
- stack tecnologico
- regole di comunicazione
- gate di approvazione obbligatori
Regole fondamentali
- Nessun codice senza specifiche approvate
- Nessun commit senza validazione umana
- Ogni fase si interrompe per approvazione
I ruoli degli agenti
- Product Manager → trasforma richieste informali in specifiche (shared/spec.md)
- Developer → implementa solo quanto definito (output/src/)
- QA Engineer → scrive test e report (shared/qa_report.md)
- Cost Controller → monitora token e costi (shared/cost_report.md)
Lo stato condiviso vive nel filesystem:
- shared/project_state.json
- shared/decisions_log.md
–> Il filesystem diventa lo strato di coordinamento
Primo run
claudePrompt iniziale:
Build a Spring Boot REST API for a TODO list using the full agent workflow with approval gates.
Il flusso rimane sempre lo stesso:
specifica → approvazione → implementazione → approvazione → test → validazione
Parallelismo (quando ha senso)
Il parallelismo funziona solo su task indipendenti.
Esempio:
- Developer implementa endpoint
- QA scrive test corrispondenti
Regola pratica: massimo 2–3 agenti in parallelo
Ottimizzazione dei costi
| Ruolo | Modello |
| Product Manager | Sonnet |
| Developer | Sonnet |
| QA Engineer | Haiku |
| Cost Controller | Haiku |
Questa distribuzione permette una forte riduzione dei costi senza sacrificare la qualità.
Errori comuni da evitare
- Eccessiva autonomia (senza gate di approvazione)
- Specifiche troppo vaghe
- Eccesso di parallelismo
- Ignorare il decision log
Cosa cambia davvero
Questo esperimento non riguarda solo l’automazione dello sviluppo.
Riguarda la governance del lavoro tecnico attraverso agenti AI.
Il ruolo umano si sposta su tre assi:
- Visione strategica
- Governance del sistema
- Controllo dei costi e dell’impatto
Non sei più un esecutore.
Sei il punto di controllo decisionale del sistema.
Conclusione
Questo esperimento è nato come una curiosità tecnica.
Ma il risultato più importante è organizzativo:
stiamo imparando a costruire sistemi di lavoro in cui l’esecuzione può essere delegata, ma la responsabilità no.
Stiamo passando da strumenti di produttività a veri e propri sistemi di produzione governati da decision maker umani.
Separare ruoli, limitare i contesti e introdurre punti di controllo non è più solo ingegneria del software:
sta diventando una forma matura di governance operativa AI-driven.
E, almeno per ora, il vero valore non risiede nell’autonomia del sistema, ma nella qualità delle decisioni umane.
→ Codice e repository completo su GitHub: https://github.com/rheorix/agentic-company
Se stai sperimentando con sistemi multi-agent o workflow simili, mi interessa capire come li stai costruendo: lascia qui sotto un commento con il tuo approccio o i tuoi risultati.
