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