Articoli
Basta Fan-out alla cieca: architettura di orchestrazione a quattro livelli con Claude Haiku 5.5
Claude Haiku 5.5 è veloce ed economico, ma demandargli tutti i task in parallelo amplifica solo errori di valutazione, review bias e rischi di Supply Chain. Questa guida analizza l'architettura a livelli basata su giudizio con Fable, orchestrazione con Opus, implementazione con Sonnet e Haiku, validazione in CI e collaudo con Opus, spiegando quali task meritano davvero il Fan-out.
· 7 min di lettura
Claude Haiku 5.5 è stato rilasciato il 7 ottobre 2026. Con prompt fino a 100,000 tokens, costa un ventesimo rispetto a Sonnet 5.5 e vanta la latenza più bassa tra i modelli dell'attuale generazione Claude.
Trattandosi di un modello così rapido ed economico, la tentazione è forte: scomporre ogni singolo task di coding e spararlo in parallelo a un nugolo di istanze Haiku per chiuderlo in fretta.
In fase di prototipazione può anche funzionare. Portato in un contesto di produzione, però, questo approccio va subito a sbattere contro tre problemi:
- I modelli compatti non gestiscono bene l'ambiguità. Il posizionamento ufficiale di Haiku 5.5 riguarda compiti ad alto volume e bassa latenza, come classificazione, estrazione, routing e subagent. Se i requisiti presentano ambiguità di business o necessitano del contesto dell'intero sistema, il modello rischia di restituire un output apparentemente completo, ma che punta nella direzione sbagliata.
- Lasciar scegliere la risposta a un modello introduce un review bias. Quando si passano decine di output a un modello di grandi dimensioni, questo tende a premiare la versione con l'«architettura più elegante» anziché quella con la logica e l'esecuzione realmente corrette.
- I permessi crescono all'aumentare dei Worker. Se si permette a subagent paralleli di installare pacchetti o ritoccare configurazioni in automatico, avviare N Worker significa aprire N potenziali punti d'ingresso per dipendenze malevole.
Per questa ragione sono passato a un'orchestrazione gerarchica (Hierarchical Orchestration): ogni livello gestisce esclusivamente ciò che sa fare meglio, mentre la parallelizzazione con Haiku viene impiegata solo dove serve davvero.
In sintesi: Fable ragiona e pianifica, Opus smista e collauda, Sonnet cura l'implementazione principale, mentre Haiku si occupa solo di compiti meccanici e task esplorativi verificabili in automatico. Le soluzioni candidate passano prima dalla CI, poi al vaglio del modello.
L'architettura a quattro livelli: giudizio, orchestrazione, validazione, collaudo#
Input requisiti
│
▼
[Livello di giudizio] Fable: decisioni architetturali, scomposizione dei task, criteri di accettazione
│
▼
[Livello di orchestrazione] Opus Main Session: solo smistamento, nessuna riscomposizione
├─► Percorso A: complesso ma con confini chiari ──► Implementazione Sonnet
├─► Percorso B: task meccanici ──► Singolo Haiku
├─► Percorso C: esplorativo, soluzioni multiple ──► Più Haiku, ciascuno in un Git Worktree dedicato
│
▼
[Livello di validazione] Build, Type Check, Test, Benchmark (il Percorso C mantiene solo i primi 2–3)
│
▼
[Livello di collaudo] Opus converge in base ai criteri di accettazione
In caso di fallimento si scala: Haiku corregge 2 volte senza successo ➔ Sonnet ➔ Ritorno a Opus
L'assegnazione di ciascun modello al rispettivo livello segue il posizionamento ufficiale e i costi di listino. Di seguito riporto i dati della documentazione ufficiale Anthropic all'8 ottobre 2026, con tariffe espresse in dollari USA per milione di token:
| Modello |
Posizionamento ufficiale |
Latenza |
Prezzo Input / Output |
| Claude Fable 5.1 |
Ragionamento complesso e task agentic prolungati |
Più lenta |
$10 / $50 |
| Claude Opus 5.5 |
Coding agentic prolungato e knowledge work |
Media |
$4 / $20 |
| Claude Sonnet 5.5 |
Il miglior compromesso tra velocità e capacità |
Veloce |
$2 / $10 |
| Claude Haiku 5.5 |
Task ad alto volume e bassa latenza: classificazione, estrazione, routing e subagent |
Più veloce |
Da $0.10 / $0.50 |
Il pricing di Haiku 5.5 è scaglionato: superati i 100,000 tokens di prompt, passa a $0.50 / $2.50.
Livello di giudizio: Fable per decisioni architetturali e Acceptance Criteria#
Non tutti i requisiti necessitano di Fable. Essendo il livello più oneroso e lento, lo riservo ai casi con requisiti ambigui, integrazioni cross-system o decisioni architetturali critiche.
L'output richiesto a Fable comprende tre elementi:
- Design della soluzione
- Scomposizione dei task
- Criteri di accettazione (Acceptance Criteria) verificabili tramite test per ciascun sotto-task
Ragionamento e scomposizione devono restare nello stesso livello. Chi ha una visione chiara dei punti ciechi del sistema è in grado di definire sotto-task con interfacce pulite; delegare l'architettura ad A e la scomposizione a B porta quasi sempre a confini sfumati.
Fanno eccezione i task di sicurezza. I modelli Claude di questa generazione integrano classificatori di safety: se una richiesta viene bloccata, restituiscono stop_reason: "refusal", rischiando di fermare anche attività di sicurezza lecite. Il classificatore di Fable 5.1 copre gran parte dei contenuti security, e la documentazione ufficiale chiarisce che il modello non è progettato per questo dominio; Opus 5.5, al contrario, consente l'analisi delle vulnerabilità nel codice sorgente. Di conseguenza, per la remediation delle vulnerabilità affido l'analisi iniziale direttamente a Opus.
Livello di orchestrazione: Opus smista senza riscomporre#
Opus agisce da Main Session, gestendo routing e assegnazione dei compiti. Questo livello non rimette in discussione l'architettura né effettua una seconda scomposizione.
- Percorso A, complesso ma con confini chiari: compiti con logica complessa ma interfacce ben definite vengono assegnati a Sonnet, che rappresenta il motore principale dell'implementazione.
- Percorso B, compiti prettamente meccanici: codice Boilerplate, ridenominazione di variabili, aggiunta di unit test lineari o stesura di documentazione vengono gestiti da una singola istanza di Haiku.
- Percorso C, task esplorativi e ottimizzazioni: tuning delle prestazioni, scritture alternative di query SQL complesse o Regex, troubleshooting di Flaky Test. Solo in questi casi si attiva il Fan-out: più istanze Haiku lavorano in parallelo, ciascuna all'interno di un Git Worktree indipendente per testare approcci differenti.
A prescindere dal percorso seguito, ogni output deve transitare per il livello di validazione.
Livello di validazione: prima le macchine, poi il modello#
Una pratica diffusa consiste nel raccogliere tutto il codice generato in parallelo e passarlo a Opus o Sonnet chiedendo una review via prompt.
Il problema è che il modello, leggendo il codice, si lascia facilmente ingannare da un'impaginazione ordinata o da annotazioni di tipo complete, che non garantiscono affatto il superamento dei test sui casi limite. I candidati devono quindi superare prima i controlli automatici:
- Build e Type Check: compilazione riuscita e coerenza dei tipi
- Unit / Integration Tests: superamento dei test unitari e di integrazione
- Benchmark / Profiling: misurazione di performance e footprint di memoria
Le soluzioni che non superano i test automatici vengono scartate subito. Per il Percorso C, Opus esamina soltanto i primi 2–3 candidati che hanno superato i controlli con le metriche migliori, riducendo drasticamente il consumo di token e context window.
Livello di collaudo: Opus fa convergere, scalando in caso di errore#
Infine, Opus consolida i risultati verificandoli rispetto agli Acceptance Criteria definiti a monte. Se un Worker si blocca, si attiva una scala di escalation (Escalation Path):
- Se Haiku fallisce e non supera 2 tentativi automatici di correzione, i retry si interrompono.
- Il task passa a Sonnet per la correzione.
- Se anche Sonnet non supera il collaudo, significa che la scomposizione del task o le assunzioni iniziali contengono contraddizioni. Il task torna a Opus, che valuta se rimandarlo a Fable per una nuova scomposizione.
Tre regole prima di passare alla produzione#
Evitare il Fan-out indiscriminato#
I compiti semplici non richiedono una moltitudine di Worker, mentre quelli fortemente ambigui superano le capacità di un modello compatto. Il Fan-out parallelo su più Haiku ha senso solo per compiti esplorativi con un ampio spazio delle soluzioni e verificabili rapidamente tramite test automatici.
Isolare gli ambienti, bloccare il Lockfile#
Un Git Worktree isola le modifiche al codice sorgente, evitando che Worker paralleli sovrascrivano i file a vicenda; non impone però vincoli alla rete né al raggio d'azione del runtime. Per proteggersi da un Supply Chain Attack servono una sandbox adeguata e il divieto assoluto per i Worker di installare pacchetti non verificati o modificare il Lockfile. Concedere permessi di installazione indiscriminati equivale a permettere all'Agent di introdurre dipendenze e script non verificati nella codebase.
Validare con metriche misurabili, non con giudizi del modello#
Esiti dei test, coverage, consumo di memoria e latenza sono parametri riproducibili e confrontabili. I feedback testuali del modello possono fornire spunti utili, ma non possono costituire il criterio di collaudo della qualità del codice.
Usare i modelli economici dove servono davvero#
Haiku 5.5 rende la parallelizzazione accessibile, ma il parallelismo in sé non garantisce la correttezza del risultato. Separando con rigore giudizio, smistamento, validazione e collaudo, il risparmio economico e la rapidità si traducono in un reale vantaggio ingegneristico.
Questa architettura a livelli rispecchia esattamente il concetto di Graph descritto in Gli agenti AI sono a tutti gli effetti un team agile: chi inizia, a chi passa il testimone una volta completato il lavoro e a chi scalare quando emerge un problema.