Per decenni, le navi che attraversavano il Canale della Manica si schiantavano contro gli scogli di Eddystone.

Erano rocce basse, traditrici, spesso invisibili nella nebbia e nella tempesta. Non erano lontane dalla civiltà. Non erano in mezzo a un oceano sconosciuto. Erano lì, davanti a tutti. E proprio per questo erano così pericolose.

Alla fine del Seicento, qualcuno ebbe un’idea audace: costruire un faro direttamente sopra gli scogli.

Non accanto.

Non sulla costa.

Proprio sopra il pericolo.

Il primo tentativo fallì miseramente. Una tempesta spazzò via il faro e uccise il suo progettista, Henry Winstanley.

Ma da quel fallimento nacque una domanda nuova.

Non: “Come si costruisce un faro?”

Ma: “Come si costruisce un faro che continui a funzionare durante la tempesta?”

Quella domanda cambiò l’ingegneria marittima.

Perché un faro non muove le navi.
Non controlla il mare.
Non genera vento.
Non produce energia per i motori.

Eppure, per secoli, è stato una delle tecnologie più importanti della navigazione.

La sua funzione era semplice: mostrare continuamente dove si trovavano gli scogli.

Gli LLM sono navi potenti.

Gli harness sono fari.

L’intelligenza non basta

Negli ultimi anni abbiamo parlato moltissimo di modelli linguistici. GPT, Claude, Gemini, Llama e molti altri.

Li abbiamo trattati come se fossero il centro della storia. E in parte lo sono. Un modello linguistico è una macchina straordinaria: scrive codice, riassume documenti, interpreta richieste, genera piani, analizza errori, suggerisce soluzioni.

Ma c’è un equivoco.

Un LLM, da solo, non è un prodotto.

È un motore.

E un motore potentissimo, senza volante, freni, cruscotto, serbatoio, regole di sicurezza e una strada percorribile, non ci porta molto lontano. Anzi, può portarci molto velocemente nel posto sbagliato.

Qui entrano in gioco gli harness.

Un harness è lo strato che rende utilizzabile un LLM in un contesto reale.

Non produce l’intelligenza.

La incanala.

Non sostituisce il modello.

Lo collega al mondo.

Non è il cervello.

È il sistema nervoso, la cabina di pilotaggio, il faro e, qualche volta, anche il freno d’emergenza.

Perché tutti ne parlano

Forse avete sentito parlare di Claude Code, Codex, OpenCode, Pi Agent e molti altri strumenti simili.

Spesso vengono descritti come “agent”, “coding agent”, “AI developer”, “AI assistant” o “autonomous workflow”. Ma sotto la superficie, molta della differenza tra questi strumenti non sta solo nel modello che usano.

Sta nell’harness.

Un harness decide come connettere il modello agli strumenti esterni.
Decide quando eseguire un comando.
Decide quali file leggere.
Decide quanto contesto passare al modello.
Decide che cosa ricordare e che cosa dimenticare.
Decide come usare gli MCP.
Decide come orchestrare più agenti.
Decide quando chiedere il permesso all’utente.
Decide quando fermarsi.

Queste decisioni sembrano dettagli tecnici. In realtà sono il prodotto.

Due strumenti possono usare lo stesso modello e comportarsi in modo completamente diverso. Uno può sembrare rapido, disciplinato e intelligente. L’altro può sembrare confuso, lento e costoso.

Non perché il modello sia diverso.

Ma perché è diverso il faro.

Il problema del contesto

La parte più importante di un harness è probabilmente la gestione del contesto.

Noi esseri umani tendiamo a pensare che “più informazioni” significhi “più intelligenza”. Ma spesso è il contrario.

Un modello con troppo contesto può diventare meno efficace. Deve navigare tra file inutili, vecchie istruzioni, dettagli irrilevanti, frammenti duplicati, log rumorosi, richieste passate e informazioni che non servono più.

È come chiedere a un capitano di attraversare una tempesta mentre qualcuno gli rovescia sulla scrivania tutte le mappe nautiche mai prodotte nella storia dell’umanità.

Il problema non è avere molte mappe.

Il problema è sapere quale mappa serve adesso.

Un buon harness deve fare esattamente questo: scegliere.

Deve mantenere il contesto piccolo, pulito e rilevante. Un contesto più piccolo significa spesso un modello più concentrato, più economico e più veloce.

Ma c’è un rischio.

Se il contesto è troppo piccolo, il modello perde informazioni essenziali. Dimentica vincoli, obiettivi, decisioni precedenti, errori già risolti. Inizia a ripetere lavoro. Oppure, peggio, prende decisioni apparentemente corrette basandosi su una memoria incompleta.

La vera arte non è dare tutto al modello.

La vera arte è dargli solo ciò che conta.

L’efficienza è una forma di intelligenza

Oggi molti confronti tra harness si concentrano sulle funzionalità.

Questo strumento supporta più comandi.
Quell’altro supporta più agenti.
Questo ha più integrazioni.
Quello gestisce meglio gli MCP.
Questo può modificare file.
Quello può eseguire test.

Tutto vero.

Ma c’è un’altra dimensione, meno appariscente e forse più importante: l’efficienza.

Per sviluppare la stessa funzionalità, alcuni harness impiegano meno tempo e meno token. Altri sono più capaci in certe situazioni complesse, ma consumano molto di più.

Non esiste una risposta unica.

Un harness molto potente può essere perfetto per un refactoring complesso, ma ridicolo per un compito semplice. Un harness leggerissimo può essere eccellente per operazioni rapide, ma fragile quando bisogna coordinare più strumenti, mantenere memoria o ragionare su una codebase grande.

A volte vediamo sistemi che, solo per rispondere “ciao”, impiegano decine di secondi e migliaia di token.

Naturalmente, salutare un LLM non serve. E non serve neanche ringraziarlo.

Ma siamo umani.

Abbiamo passato migliaia di anni a trattare gli oggetti come se avessero un’anima. Abbiamo dato nomi alle navi, parlato alle automobili, insultato le stampanti e ringraziato gli ascensori quando arrivavano in fretta.

Non sorprende che diciamo “grazie” anche a una macchina statistica.

Il problema non è il nostro “grazie”.

Il problema è un harness che lo prende troppo sul serio.

Gli agent swarm e il ritorno della burocrazia

Alcuni harness possono orchestrare team di agenti, spesso chiamati agent swarm.

L’idea è affascinante: invece di avere un solo agente che fa tutto, possiamo avere più agenti specializzati. Uno analizza i requisiti. Uno scrive codice. Uno esegue i test. Uno controlla la sicurezza. Uno rivede l’architettura. Uno produce documentazione.

Sembra una piccola organizzazione artificiale.

E proprio per questo introduce un vecchio problema umano: la burocrazia.

Quando un solo agente sbaglia, il problema è semplice. Quando dieci agenti collaborano male, il problema diventa politico.

Chi decide?
Chi verifica?
Chi ha l’ultima parola?
Chi impedisce a un agente di correggere il lavoro di un altro all’infinito?
Chi controlla che il team non consumi un milione di token per produrre tre righe di codice?

Gli agent swarm saranno utilissimi in alcune situazioni. Ma non sono magia.

Sono organizzazioni.

E come tutte le organizzazioni, funzionano solo se hanno ruoli chiari, vincoli chiari, obiettivi chiari e un buon sistema di controllo.

Anche qui, il valore non sta solo nel modello.

Sta nell’harness.

La sicurezza è il vero scoglio

In un’intervista al creatore di Claude Code, gli chiesero quale fosse stata la parte più difficile da sviluppare.

La risposta fu: la sicurezza.

È una risposta molto meno glamour di “ragionamento”, “agentic workflow” o “multi-step planning”.

Ma è probabilmente la risposta giusta.

Un harness può eseguire comandi sulla macchina dell’utente. Può leggere file. Può modificarli. Può cancellarli. Può installare pacchetti. Può chiamare API. Può accedere a repository, ticket, documenti, database, segreti, log e infrastrutture.

A quel punto, il problema non è più solo: “Il modello capisce?”

Il problema diventa: “Che cosa gli permettiamo di fare?”

La soluzione ingenua è chiedere sempre il permesso all’utente.

Ma questa soluzione non funziona.

Perché l’utente, dopo la terza richiesta, clicca sempre sì.

È lo stesso motivo per cui per anni abbiamo accettato cookie, permessi, licenze software e policy sulla privacy senza leggerle. Non perché fossimo stupidi. Ma perché nessun essere umano può vivere leggendo ogni contratto, ogni avviso e ogni autorizzazione.

Se un harness chiede il permesso per tutto, non sta aumentando la sicurezza.

Sta addestrando l’utente a ignorare la sicurezza.

D’altra parte, se non chiede mai il permesso, diventa pericoloso.

La sfida è trovare il punto giusto tra due fallimenti opposti: bloccare tutto o lasciare fare tutto.

È qui che un harness maturo si distingue da un giocattolo.

Costruire sopra gli harness

Per molto tempo, molte aziende hanno pensato di dover costruire il proprio harness.

Il proprio workflow.
Il proprio agent framework.
La propria interfaccia.
La propria orchestrazione.
La propria memoria.
La propria integrazione con strumenti interni.

In alcuni casi ha senso.

Ma sempre più spesso la strategia migliore sarà diversa: costruire sopra gli harness esistenti.

Invece di sviluppare tutto da zero, le aziende potranno creare comandi, hook, SDK, strumenti MCP, policy, template, test, guardrail e integrazioni interne. Potranno lasciare che gli harness evolvano, migliorino, competano e si ottimizzino.

In altre parole, potranno approfittare dell’innovazione gratuita prodotta dalla competizione tra strumenti.

Questo è un passaggio importante.

Quando una tecnologia è immatura, tutti costruiscono tutto.
Quando una tecnologia matura, emergono piattaforme, standard, estensioni e convenzioni.

All’inizio del web, ogni sito sembrava un esperimento isolato. Poi sono arrivati browser, framework, CMS, API, librerie, CDN e standard.

Con gli harness siamo ancora nella fase in cui molti stanno costruendo il proprio faro di legno sugli scogli.

Alcuni saranno spazzati via dalla prima tempesta.

Altri diventeranno parte dell’infrastruttura invisibile del futuro.

La punta dell’iceberg

Oggi parliamo di harness soprattutto nel contesto dello sviluppo software.

Ma sarebbe un errore pensare che finirà lì.

Ogni volta che un LLM dovrà operare in un ambiente reale, servirà un harness.

Nella finanza.
Nella sanità.
Nella manifattura.
Nel supporto clienti.
Nella cybersecurity.
Nella logistica.
Nella progettazione di prodotti.
Nella formazione.
Nella ricerca scientifica.

Ovunque ci siano strumenti da usare, dati da selezionare, permessi da controllare, memoria da gestire, azioni da verificare e rischi da contenere, ci sarà bisogno di un harness.

Il modello sarà la parte più visibile.

L’harness sarà la parte che decide se quel modello può davvero lavorare.

È possibile che tra qualche anno smetteremo quasi di parlare dei modelli in sé. Non perché non saranno importanti, ma perché diventeranno sempre più intercambiabili. Come i motori elettrici. Come i database. Come i container.

La domanda non sarà solo: “Quale modello usi?”

La domanda sarà: “Dentro quale sistema lo fai operare?”

Il faro nella tempesta

Gli scogli di Eddystone non erano pericolosi perché nessuno sapeva che esistessero.

Erano pericolosi perché, nel momento decisivo, durante la nebbia, il buio e la tempesta, sapere in teoria non bastava.

Serviva un segnale continuo.

Serviva un’infrastruttura.

Serviva un faro.

Con gli LLM siamo nella stessa situazione.

Sappiamo che sono potenti.
Sappiamo che possono sbagliare.
Sappiamo che possono consumare risorse inutilmente.
Sappiamo che possono eseguire azioni rischiose.
Sappiamo che possono perdersi nel contesto.
Sappiamo che possono sembrare intelligenti anche quando stanno navigando verso gli scogli.

Il punto non è più dimostrare che la nave può muoversi.

Il punto è farla arrivare a destinazione durante la tempesta.

Gli harness sono nati per questo.

Non sono la parte più spettacolare dell’intelligenza artificiale.

Ma potrebbero diventare una delle più importanti.

Abbiamo visto solo la punta dell’iceberg.

Il bello deve ancora venire.

Procuratevi un pacchetto di popcorn.

E sedetevi con me a guardare.