# Perché l’“harness” batte il modello: lezioni pratiche dai sistemi multi‑agente > Source: > Published: 2026-07-22 08:40:31+00:00 Architettura, ruoli e disciplina del contesto: come spendere meno token e ottenere risultati più affidabili Negli ultimi mesi è diventato evidente un punto che molti team frontend (e non solo) stanno imparando sulla propria pelle: **il modello “più forte” non ti salva da un’architettura debole**. Puoi avere un LLM di fascia altissima, ma se lo inserisci in un flusso di lavoro confuso—contesto che cresce senza controllo, ruoli mischiati, merge continui e test gestiti male—bruci token, tempo e qualità. Il contrario è ancora più interessante: **un harness ben progettato riesce a spremere risultati sorprendenti anche da modelli più economici**, soprattutto quando li fai lavorare con ruoli chiari. Con “harness” non si intende un prompt più lungo o due regole in più. Un harness è l’insieme di: In pratica: è la differenza tra “un modello che scrive codice” e **un sistema ingegnerizzato che produce software**. Un agente singolo che deve portare avanti un progetto grande tende a fallire per motivi molto concreti: Questa è la radice della “deriva”: non è (solo) un limite del modello, è un limite del *processo*. Un approccio multi‑agente efficace usa una metafora molto semplice: **albero e foglie**. La regola che cambia tutto è disciplinare: Questa divisione riduce drasticamente la necessità che un singolo agente “cammini tutto l’albero” portandosi dietro ogni antenato, ogni decisione e ogni vincolo. Una delle conseguenze più pratiche di questo schema è che puoi usare: Il risultato è controintuitivo per chi è abituato a “scalare” comprando solo il modello migliore: **il costo totale può crollare** senza perdere qualità, perché l’esecuzione è la parte più token‑intensiva. In un confronto tra combinazioni diverse, l’assetto “frontier come planner + economico come worker” è riuscito a ottenere **gli stessi esiti funzionali** con una spesa in token **ordine di grandezza più bassa** rispetto all’uso del frontier sia come planner sia come worker. Un harness maturo non si vede solo dal punteggio finale, ma da metriche operative che chiunque faccia engineering riconosce: Se il tuo swarm genera una valanga di conflitti, non è “un problema Git”: è un segnale che stai facendo lavorare gli agenti in modo troppo sovrapposto, senza confini chiari. Un harness migliore tende a: Un altro pattern: **meno codice prodotto** può significare un processo più pulito. Se il sistema risolve lo stesso compito con molte meno linee, spesso vuol dire: Non è una regola assoluta—talvolta più codice è “più correttezza”—ma in scenari agentici un’enorme produzione di codice è spesso un campanello d’allarme. C’è un’idea che vale oro per chi lavora in team (e per chi costruisce prodotti): **l’unità di lavoro si sta spostando**. Con gli swarm, ciò che fai a monte diventa decisivo: **una spec ben scritta è un moltiplicatore di qualità**. Non serve che sia infinita; serve che sia verificabile: Ricostruire un database sembra lontano dal frontend, ma le lezioni sono identiche per: Se oggi stai sperimentando agenti per generare codice, la priorità non è inseguire sempre il modello più nuovo: è **costruire un harness che impedisca il caos**. Se vuoi rendere l’approccio ripetibile, questi punti sono una base solida: Il messaggio finale è semplice e molto “ingegneristico”: **l’architettura del processo batte la potenza bruta**. Un modello frontier può essere la scelta giusta—soprattutto per pianificare e prendere decisioni—ma la differenza tra un esperimento costoso e un sistema produttivo sta nella disciplina del tuo harness: ruoli separati, contesto controllato, integrazione ordinata e test che guidano ogni passo. In un mondo dove la capacità di generare codice è ormai una commodity, il vantaggio competitivo si sposta su ciò che molti sottovalutano: **come organizzi il lavoro degli agenti** e come trasformi una spec in software verificabile, senza bruciare budget e senza perdere il controllo del progetto. Articolo originale: [https://frontendfacile.it/blog/perche-l-harness-batte-il-modello-lezioni-pratiche-dai-sistemi-multi-agente](https://frontendfacile.it/blog/perche-l-harness-batte-il-modello-lezioni-pratiche-dai-sistemi-multi-agente)