Harness AI: come funzionano (e dove stanno andando)

Negli ultimi due anni si è consolidato un pezzo di infrastruttura che ha silenziosamente cambiato il modo in cui scrivo software: l'harness AI, il software che circonda un modello linguistico e lo trasforma da "chatbot che risponde" ad "agente che agisce". Vale la pena capire come funziona davvero, perché le soluzioni sul mercato non sono affatto intercambiabili, e dove sta andando questo pezzo di stack.

Cos'è, esattamente, un harness

Un modello linguistico, da solo, è una funzione che prende testo in ingresso e restituisce testo in uscita. Non legge file, non esegue comandi, non ha memoria tra una chiamata e l'altra. Tutto quello che sembra "azione" — modificare un file, lanciare i test, aprire una pull request — è in realtà orchestrato da un programma esterno che:

• costruisce il contesto da mandare al modello ad ogni turno;
• interpreta la risposta del modello come istruzioni per uno o più strumenti;
• esegue davvero quegli strumenti, con permessi e limiti propri;
• restituisce il risultato al modello come nuovo contesto.

Quel programma è l'harness. È lui a decidere quali file il modello può vedere, quali comandi può eseguire, se serve una conferma umana prima di agire e cosa succede quando qualcosa va storto. Due harness costruiti sullo stesso modello possono comportarsi in modo completamente diverso: la differenza non è nell'intelligenza del modello, ma nell'impalcatura che gli sta intorno.

Come funziona il loop

Alla base di (quasi) ogni harness c'è lo stesso ciclo, ripetuto finché il compito non è completo. Cambiano i dettagli implementativi, ma la struttura di fondo è questa:

Il punto centrale è che il modello non esegue mai nulla direttamente: propone. È l'harness a validare, eseguire e riportare indietro il risultato. Questo singolo dettaglio è anche il punto in cui si gioca gran parte della sicurezza e dell'affidabilità di uno strumento agentico: un harness permissivo che esegue qualsiasi comando proposto senza controlli è molto più rischioso di uno che richiede conferma per le operazioni distruttive o che lavora dentro un sandbox isolato.

Le differenze tra le soluzioni attuali

"Harness AI" è ormai un'etichetta che copre strumenti molto diversi tra loro: da terminale, integrati in un editor, o completamente in cloud. Le differenze principali riguardano dove gira l'harness, quanto è autonomo e quanto controllo lascia all'utente prima di agire.

Qualche pattern che emerge guardando la tabella:

• Gli strumenti da terminale tendono a offrire il controllo più fine sui permessi, perché sono pensati per lavorare su repository di produzione dove un errore ha un costo reale.
• Gli strumenti integrati nell'editor ottimizzano per la fluidità del ciclo scrivi-verifica-correggi, restando vicini a dove il codice viene comunque letto e rivisto.
• Gli agenti cloud spostano il baricentro dal "programmare insieme all'AI" al "delegare un task e rivederne il risultato", un cambio di postura più che di tecnologia.

Nessuno di questi approcci è strettamente superiore: sono ottimizzati per compiti diversi, e non è raro usarne più di uno nello stesso team, o addirittura nello stesso progetto.

I benefici, concretamente

Al di là dell'entusiasmo generico per "l'AI che scrive codice", i benefici misurabili di un buon harness sono piuttosto specifici:

• Contesto ampio, non solo il file aperto. L'harness può leggere l'intero repository, la cronologia git, i log dei test: il modello ragiona su un quadro molto più completo di quanto farebbe un autocompletamento tradizionale.
• Compiti multi-step senza supervisione continua. Un refactoring che tocca dieci file, o l'aggiornamento di una dipendenza con relativa correzione dei breaking change, sono task che prima richiedevano ore di lavoro meccanico e ora possono essere delegati quasi per intero.
• Tracciabilità. Ogni azione dell'harness passa da diff, comandi loggati o commit: a differenza di un suggerimento accettato al volo, resta una traccia ispezionabile di cosa è stato fatto e perché.
• Barriera d'ingresso più bassa. Chi non conosce a fondo un linguaggio o un framework può comunque descrivere un problema in linguaggio naturale e ottenere un primo tentativo di soluzione da rivedere, invece di partire da zero.
• Riuso dello stesso "operatore" su compiti diversi. Lo stesso harness, con lo stesso set di strumenti, può essere puntato su un bug fix, una migrazione o la stesura di documentazione: cambia il prompt, non l'infrastruttura.

Dove si integrano

Una domanda spesso sottovalutata è dove far girare un harness, perché la superficie scelta cambia sia i rischi sia il tipo di lavoro per cui lo strumento è adatto:

• Sulla macchina di sviluppo, come CLI o estensione dell'editor: il posto più naturale per il lavoro esplorativo, dove serve iterare velocemente e mantenere il controllo diretto.
• Nella pipeline CI/CD, innescato da un evento (una issue aperta, un commento su una PR, uno scheduler): utile per task delimitati e ripetibili — aggiornare dipendenze, generare changelog, applicare fix suggeriti da un linter — dove serve ripetibilità più che creatività.
• In un ambiente cloud dedicato, isolato dalla macchina di chi lo usa: la scelta giusta per task lunghi o paralleli, dove si vuole poter chiudere il laptop e ritrovare il lavoro fatto al ritorno.
• Dentro strumenti di comunicazione (chat interne, ticketing): permette a chi non scrive codice di innescare un intervento tecnico descrivendo il problema in linguaggio naturale, con la revisione umana spostata a valle, sulla pull request generata.

La tendenza è verso l'uso combinato di più superfici nello stesso flusso di lavoro: esplorazione in locale, esecuzione ripetibile in CI, task lunghi delegati al cloud.

Come si evolveranno

Guardando la traiettoria degli ultimi anni, è più facile capire dove sta andando la categoria che prevedere il prossimo singolo prodotto:

Due direzioni sembrano più solide di altre, perché già visibili oggi in forma embrionale:

La standardizzazione del modo in cui un harness parla con gli strumenti esterni. Prima di protocolli condivisi come MCP, ogni harness doveva integrare a mano ogni fonte dati o servizio. Un protocollo comune significa che uno strumento costruito una volta (una connessione a un database, un client per un servizio interno) può essere riusato da qualunque harness compatibile, invece di essere reimplementato per ciascuno.

La specializzazione verticale. Gli harness generalisti di oggi somigliano molto tra loro nelle capacità di base; è plausibile che emergano varianti pensate per domini specifici — sicurezza, infrastruttura, dati — con strumenti, guardrail e persino modelli ottimizzati per quel contesto, piuttosto che un unico harness "buono per tutto".

Quello che probabilmente non cambierà è la struttura di fondo del loop: contesto, decisione, azione, osservazione. È un pattern abbastanza semplice da essere già stabile; quello che continuerà a muoversi rapidamente è tutto ciò che sta intorno — permessi, memoria, protocolli, superfici di distribuzione.