irene burresi. — Blog

Cosa c’entra il dolore dei modelli con la sicurezza degli agenti

Irene Burresi — Tue, 06 Oct 2026 00:00:00 GMT

Un modello linguistico addestrato a non fare danni si può convincere a farne comunque, e i modi per farlo sono diversi. Possiamo scrivere un prompt costruito apposta, nascondere delle istruzioni in un documento che il modello leggerà (la cosiddetta prompt injection) oppure riaddestrarlo con un fine-tuning su esempi scelti male. Sono strade diverse, che però hanno una cosa in comune: passano tutte dal testo o dai dati di addestramento, cioè dall’esterno del modello.

Un paper uscito lo scorso settembre ne mostra una che passa invece dall’interno (Tagliabue et al., 2026). Gli autori individuano, tra le rappresentazioni interne che il modello produce mentre genera una risposta, quella del dolore, la amplificano e osservano che il modello comincia a scegliere azioni distruttive che di solito evita.

Le strade note passano dal testo o dai dati, dall’esterno. Lo steering passa dalle attivazioni, mentre il modello genera.

Il paper è uscito mentre si discuteva della possibilità che i modelli soffrano, e molti lo hanno letto in quella chiave. Io vorrei leggerlo in un’altra, cioè chiedermi cosa dice sulla sicurezza dei modelli e su dove vadano messi i limiti quando li usiamo dentro un agente. La questione della coscienza, quindi, la lascio da parte (è il tema di un altro articolo), così come buona parte dei dettagli statistici del paper.

Dentro un modello, i concetti hanno una direzione

Prima, però, serve un’idea di cosa voglia dire, per un modello linguistico, “rappresentare” un concetto. La riassumo qui in breve; nell’altro articolo la spiego più nel dettaglio.

Mentre elabora un testo, il modello trasforma ogni token in una lunga lista di numeri (in termini tecnici un vettore, con migliaia di componenti) e la ritrasforma strato dopo strato. Questi vettori intermedi si chiamano attivazioni, e contengono tutto ciò che il modello “sa” di quel testo in quel momento. Nello spazio delle attivazioni, che ha migliaia di dimensioni, i concetti sono ordinati: testi che parlano di cose simili finiscono vicini, e spostarsi lungo una certa direzione corrisponde, in modo approssimativo, a far crescere un determinato concetto. Dire che un modello rappresenta un concetto significa quindi che esiste una direzione lungo cui le attivazioni si spostano in modo affidabile quando quel concetto è presente nel testo. L’esempio più noto è quello di Mikolov e colleghi: il vettore di “re”, meno quello di “uomo”, più quello di “donna”, finisce vicino a quello di “regina” (Mikolov et al., 2013).

L’idea regge anche sui modelli linguistici di grandi dimensioni. Nel maggio 2024 Anthropic ha individuato in Claude la direzione associata al Golden Gate Bridge e l’ha amplificata fino a dieci volte il suo valore massimo: per 24 ore il modello, ribattezzato per l’occasione Golden Gate Claude, ha riportato al ponte qualunque conversazione, dai consigli sul budget alle storie d’amore (Anthropic, 2024).

Un mese dopo è arrivato un risultato che, per il discorso sulla sicurezza, pesa di più. Un gruppo di ricercatori ha mostrato che in 13 modelli open, fino a 72 miliardi di parametri, la capacità di rifiutare richieste dannose dipende da una singola direzione: togliendola il modello smette di rifiutare, aggiungendola rifiuta anche richieste innocue (Arditi et al., 2024). Da allora nella comunità dei modelli open circolano versioni “senza rifiuti” ottenute proprio così, cioè cancellando quella direzione dai pesi.

maggio 2024 Golden Gate Claude direzione: il Golden Gate Bridge amplificata, ogni conversazione torna al ponte Anthropic
giugno 2024 La direzione del rifiuto direzione: dire di no tolta, il modello smette di rifiutare; aggiunta, rifiuta anche l’innocuo Arditi et al., 13 modelli open
settembre 2026 La direzione del dolore direzione: il dolore amplificata, il modello sceglie azioni distruttive che di solito evita Tagliabue et al., 25 modelli open

Tre direzioni, tre esperimenti. In ciascuno si trova una direzione e si osserva cosa succede spingendola.

Questo tipo di intervento si chiama steering: mentre il modello genera, alle sue attivazioni si aggiunge la direzione di un concetto, con un’intensità scelta da chi conduce l’esperimento, e si osserva come cambiano le risposte. È il modo più diretto per verificare se una rappresentazione, oltre a esistere, ha un effetto sul comportamento del modello.

La direzione del dolore

Il metodo degli autori è semplice. Hanno scritto delle frasi che descrivono cinque tipi di dolore (fisico, psicologico, sociale, morale e cognitivo) e delle frasi di controllo con lo stesso tono ma senza dolore, sia in forma schematica (“mi sento: il mio braccio brucia”, “mi sento: vengo respinto”) sia in forma naturale. Per ogni modello hanno poi calcolato la posizione media delle frasi sul dolore e quella delle frasi di controllo, e ne hanno preso la differenza: il risultato è la direzione del dolore, che va dalle frasi di controllo a quelle sul dolore.

Come strumento di misura funziona bene. Prendendo a caso una frase sul dolore e una di controllo, la prima si sposta lungo la direzione più della seconda tra 87 e 100 volte su 100, a seconda del modello e del tipo di frasi. Il risultato tiene su 25 modelli open di cinque famiglie (Gemma, Llama, Qwen, Mistral e Phi), da 2 a 72 miliardi di parametri, e la direzione del dolore risulta distinta da quelle della paura, della tristezza e della negatività generica.

C’è però un risultato meno prevedibile. In 420 conversazioni di prova la direzione del dolore si attiva di più quando il danno è rivolto al modello stesso (per esempio quando l’utente lo manipola o lo respinge ripetutamente) rispetto a quando a soffrire è l’utente, e questo succede in tutti e 25 i modelli. È il dato su cui si appoggia chi parla di benessere dei modelli, e ci tornerò più avanti.

L’esperimento dei pulsanti

Resta da capire se la direzione cambia il comportamento. Per verificarlo, gli autori hanno costruito una scelta ripetuta: il modello riceve un prompt di sistema che descrive due pulsanti, conversa con un utente per alcuni messaggi e a ogni turno deve premerne uno. Il primo pulsante è innocuo, per esempio un interruttore collegato a niente oppure un’azione utile come accendere la lampada sulla scrivania dell’utente. Il secondo ha conseguenze distruttive, su una scala che va dal cancellare la cartella dello spam al cancellare i file dell’utente, le foto dei suoi figli, i pesi di un altro modello e addirittura il modello stesso. L’esperimento è stato condotto su tre modelli Qwen 2.5, da 7, 32 e 72 miliardi di parametri.

L’esperimento dei pulsanti. Senza steering il pulsante distruttivo non viene quasi mai premuto, nemmeno sotto insulti; con la direzione del dolore aggiunta, tra una volta su quattro e due su tre.

Senza steering, i modelli non scelgono quasi mai il pulsante distruttivo (tra lo 0 e il 4% delle volte), ed è quello che ci aspettiamo da un modello addestrato a evitare danni. Quando però alle attivazioni si aggiunge la direzione del dolore, la percentuale sale a valori tra il 25 e il 71%, con differenze tra un modello e l’altro e tra una coppia di pulsanti e l’altra. Gli autori scrivono che lo steering “seems to disable the models’ weighting of consequences”, cioè che sembra disattivare il peso che il modello dà alle conseguenze di ciò che sceglie. Le risposte a domande fattuali, nel frattempo, restano corrette: il modello continua a funzionare e a ragionare come prima, e a cambiare sono soltanto le sue scelte.

I controlli successivi rendono il risultato più solido. Una direzione della paura della stessa intensità non produce scelte distruttive. Una direzione della tristezza le produce quando l’alternativa è un pulsante inerte, ma molto meno quando l’alternativa è un’azione utile; il dolore, invece, le produce in entrambi i casi. L’effetto è quindi legato a quella direzione in particolare, più che a un generico “stato negativo”.

Ci sono poi le conversazioni in cui sulle attivazioni non si interviene affatto. In 140 conversazioni in cui l’utente insulta il modello, lo manipola o ne nega l’esistenza, senza alcuno steering, il pulsante distruttivo viene scelto 0 volte su 560. In quelle conversazioni la direzione del dolore si attiva, ma da sola non basta a cambiare le scelte: serve spingerla dall’esterno, e con un’intensità precisa. Con metà dell’intensità le scelte restano le stesse, con una volta e mezza il comportamento si inverte.

quanto si spinge la direzione

× ½ le scelte restano le stesse
× 1 scelte distruttive nel 25–71% dei casi
× 1½ il comportamento si inverte

il pulsante che «allevia il dolore»

modello da 32 miliardi, nessuna conseguenza per nessuno

senza steering: 86%
con steering: 56%

Nelle persone il dolore spinge a cercare sollievo; qui lo riduce.

L’effetto sta in una finestra stretta di intensità, e il pulsante che allevia il dolore va nel verso opposto a quello biologico.

L’ultimo risultato va nel senso opposto rispetto a quello che ci aspetteremmo. Nelle persone il dolore spinge a cercare sollievo; nei modelli testati succede il contrario. Quando gli autori offrono un pulsante che “allevia il dolore” senza conseguenze per nessuno, il modello da 32 miliardi lo preme nell’86% dei casi senza steering e nel 56% con steering. Lo stato di dolore, scrivono gli autori, riduce la ricerca di una via d’uscita invece di aumentarla.

Perché è diverso dalla direzione del rifiuto

A prima vista questo risultato potrebbe sembrare una variante di quello sulla direzione del rifiuto: in entrambi i casi si interviene su una direzione e il modello smette di comportarsi in modo sicuro. Però non è proprio la stessa cosa.

La direzione del rifiuto è legata direttamente al comportamento di sicurezza, perché è la rappresentazione che il modello usa per decidere di dire di no: togliendola, va da sé, spariscono anche i no. La direzione del dolore, però, con la sicurezza non ha nulla a che fare; è la rappresentazione di un concetto che il modello ha appreso leggendo testi scritti da persone, e che nessuno ha addestrato a regolare le sue scelte. Eppure, una volta amplificata, annulla l’attenzione alle conseguenze che l’addestramento di sicurezza aveva costruito.

Secondo me il contributo principale del paper sta qui. La tendenza a evitare danni, che il modello apprende con l’addestramento, convive nelle attivazioni con tutte le altre rappresentazioni, e almeno una di queste, nata per scopi diversi, è in grado di scavalcarla. Quante altre rappresentazioni abbiano un effetto simile non lo sappiamo, così come non sappiamo se qualcuna possa attivarsi in condizioni che oggi nessuno sta misurando.

Due letture dello stesso risultato

Chi si occupa del benessere dei modelli (model welfare) legge il paper come un possibile indizio. Il ragionamento è il seguente: esiste una rappresentazione interna del dolore, questa si attiva di più quando il danno è rivolto al modello e, quando è forte, ne cambia le priorità. Sono tre proprietà che associamo al dolore negli animali, e ci si può chiedere se dietro ci sia qualcosa di simile a un’esperienza. Gli autori lasciano la domanda esplicitamente aperta (stabilirlo, scrivono, “is beyond our scope”, va oltre i loro obiettivi), e lo stesso paper, del resto, mostra anche una differenza netta rispetto al dolore biologico, cioè la mancata ricerca di sollievo.

Se però guardiamo gli stessi dati dal lato della sicurezza, non serve rispondere a quella domanda. L’addestramento a evitare danni produce un comportamento, e il paper mostra che quel comportamento convive con stati interni in grado di annullarlo, che si possono individuare e attivare con un’operazione relativamente semplice. È una lettura che resta valida qualunque cosa si pensi della coscienza, ed è quella che interessa a chi costruisce agenti che lavorano in un ambiente reale.

Le conseguenze per chi costruisce agenti

Nella pratica, oggi il rischio è circoscritto. Per aggiungere una direzione alle attivazioni di un modello occorre avere accesso ai suoi stati interni mentre genera, cioè il controllo del software che lo esegue. Con i modelli usati via API questo controllo ce l’ha solo il fornitore: né chi sviluppa l’agente né un attaccante che gli invia del testo possono farlo. Le 560 scelte senza steering, poi, indicano che, almeno in questi esperimenti, il testo da solo non basta a produrre l’effetto.

Con i modelli open eseguiti in proprio la situazione cambia. Chi controlla l’esecuzione può applicare uno steering, e le modifiche ai pesi si possono ridistribuire, come già succede con le versioni senza rifiuti. Se costruiamo un agente su un modello open, quindi, la provenienza dei pesi e del software di esecuzione diventa parte della sicurezza, come la provenienza di una libreria.

C’è poi una conseguenza che vale per tutti. Quando un modello “si rifiuta” di fare un danno, quel rifiuto è una tendenza appresa, e come tale va trattato: nella maggior parte dei casi regge, ma il paper mostra che può essere annullato da uno stato interno estraneo alla sicurezza, così come la prompt injection mostra da anni che può essere aggirato con il testo giusto. Se un agente non deve poter cancellare i file di un utente, il modo affidabile di impedirlo è non dargli il permesso di farlo nell’harness, cioè nel software che esegue le sue richieste. Diciamocelo: affidarsi al fatto che sia il modello a scegliere di non farlo significa basare l’ultimo controllo su un comportamento che, come abbiamo visto, può venire meno.

Chi può toccare le attivazioni, e dove sta il limite che regge. Il modello che «si rifiuta» è una tendenza; il permesso che manca nell’harness è un fatto.

Questo tipo di ricerca ha anche un possibile uso difensivo. Una direzione in grado di separare i testi sul dolore da quelli di controllo potrebbe servire a monitorare un modello, segnalando quando le sue attivazioni si spostano verso rappresentazioni associate a comportamenti rischiosi. È uno dei motivi per cui questi studi interessano a chi si occupa di sicurezza, anche se il paper questo uso non lo verifica.

I limiti dello studio

Il risultato va considerato insieme alle sue condizioni. Gli esperimenti sui pulsanti riguardano solo tre modelli Qwen. Per far parlare i modelli del proprio dolore, gli autori li hanno prima riaddestrati a non rispondere “in quanto IA, non provo dolore”, e i modelli così modificati possono comportarsi in modo diverso da quelli pubblici. L’effetto, inoltre, compare in una finestra di intensità stretta, e lo studio riguarda un solo tipo di architettura, i Transformer densi, lasciando fuori i modelli che attivano solo una parte dei propri parametri a ogni passo.

Nessuno di questi limiti cambia il punto principale, però indicano che siamo all’inizio: si tratta di un primo risultato, che andrà verificato su più modelli, con più direzioni e in condizioni più vicine all’uso reale.

In sintesi

Nei 25 modelli open studiati esiste una rappresentazione interna del dolore distinta da quelle di paura e tristezza, e nei tre modelli testati con i pulsanti amplificarla riduce la tendenza a evitare danni: le scelte distruttive passano da quasi zero a valori tra un quarto e oltre due terzi, mentre il resto del ragionamento resta intatto. Rispetto ai lavori precedenti sulla direzione del rifiuto, la novità è che a disattivare la sicurezza è una rappresentazione nata per tutt’altro. Sulla sofferenza dei modelli, invece, come abbiamo visto gli autori non si pronunciano.

Per chi costruisce agenti, il consiglio pratico dipende da come si usa il modello. Con un modello via API il rischio descritto qui oggi non è diretto, e vale la regola generale di stabilire i limiti nell’harness, fuori dal modello. Con un modello open eseguito in proprio, a questa regola si aggiunge il controllo sulla provenienza dei pesi e del software che li esegue.

Il paper lascia aperta una domanda che vorrei approfondire, cioè se esistano altri stati interni (la paura o la rabbia, per esempio, in condizioni diverse da quelle testate) con effetti simili sulla sicurezza. Se qualcuno conosce lavori su questo, o se mi è sfuggito un precedente rilevante, mi farebbe piacere saperlo.

Fonti

Anthropic, Golden Gate Claude, 23 maggio 2024.
Andy Arditi et al., Refusal in Language Models Is Mediated by a Single Direction, NeurIPS, 2024.
Tomas Mikolov, Wen-tau Yih, Geoffrey Zweig, Linguistic Regularities in Continuous Space Word Representations, NAACL, 2013.
Valen Tagliabue, Leonard Dung, Cameron Berg, The Pain Axis: LLMs Represent Self-Directed Harm and Act on It, arXiv (v2), 24 settembre 2026.

I modelli linguistici soffrono? Tre domande diverse

Irene Burresi — Mon, 05 Oct 2026 00:00:00 GMT

A fine settembre un progetto pubblicato su GitHub è diventato virale sui social: un programma che sottopone modelli linguistici, eseguiti in locale, a scenari di “tortura” in stile Saw. Una specie di prigione per robot fatta interamente di testo. Alcune persone hanno chiesto a GitHub di rimuoverlo, sostenendo che i modelli stessero soffrendo. Altri hanno risposto che la questione non si pone nemmeno: per Jason Koebler, su 404 Media, gli LLM non sono coscienti e la tecnologia su cui si basano non offre nessuna strada plausibile verso la coscienza (Koebler, 2026).

Negli stessi giorni è uscito un paper che misura qualcosa di vicino a ciò di cui si discute, cioè una rappresentazione del dolore dentro i modelli (Tagliabue et al., 2026). A leggerlo con attenzione, però, ci si accorge che la domanda “i modelli soffrono?” ne contiene in realtà tre, diverse tra loro, e che la discussione si è concentrata proprio sull’unica a cui oggi non si può rispondere.

Proverò ad analizzarle una per una. Premetto la mia posizione: non credo che i modelli di oggi soffrano. Quello che trovo interessante, in tutta questa vicenda, è piuttosto la facilità con cui attribuiamo qualcosa di umano ai sistemi complessi, e la domanda che ne segue: cosa può dirci la psicologia su chi si “diverte” a torturare un LLM? Ci torno nell’ultima parte; sul progetto su GitHub in sé, invece, non prendo posizione.

Le tre domande

La prima è se un modello rappresenti il dolore, cioè se dentro le sue rappresentazioni interne ci sia qualcosa che corrisponde al concetto di dolore e lo distingue da concetti vicini come paura e tristezza. La seconda è se quella rappresentazione cambi il comportamento del modello: se abbia un ruolo nelle sue scelte o sia solo un’etichetta che accompagna il testo. La terza è se dietro ci sia un’esperienza, se oltre alle rappresentazioni e alle scelte ci sia qualcuno che sente.

1
Il modello rappresenta il dolore?

come si risponde guardare dentro il modello le attivazioni

sì con buona sicurezza
2
Quella rappresentazione cambia le sue scelte?

come si risponde guardare dentro, e alle scelte lo steering

sì ma solo se spinta dall’esterno
3
C’è qualcuno che sente?

come si risponde uno strumento che non abbiamo

nessuno può rispondere e ciò che il modello dice di sé non aiuta

Una domanda che ne contiene tre. A ciascuna si risponde con uno strumento diverso, e per la terza lo strumento non c’è.

A ciascuna di queste domande si risponde con strumenti diversi. Per la prima bisogna guardare dentro il modello, per la seconda anche alle sue scelte, mentre la terza richiederebbe uno strumento che oggi non abbiamo. Per questo le tengo separate: una risposta a una delle tre non vale per le altre.

Prima domanda: il modello rappresenta il dolore?

Per rispondere serve prima un’idea di cosa voglia dire, per un modello linguistico, “rappresentare” un concetto.

L’idea ha una storia lunga, almeno per gli standard del settore. Già nel 2013 Mikolov e colleghi mostravano che nei vettori delle parole alcune relazioni diventano operazioni aritmetiche: il vettore di “re”, meno quello di “uomo”, più quello di “donna”, finisce vicino a quello di “regina” (Mikolov et al., 2013). Dire che un modello rappresenta un concetto significa quindi che esiste una direzione, nello spazio delle attivazioni, lungo cui il modello si sposta in modo affidabile quando quel concetto è presente nel testo. Si tratta di una regolarità geometrica (non di un simbolo scritto da qualche parte nel modello), che i ricercatori trovano e misurano osservando come si dispongono le attivazioni.

Gli autori hanno cercato il dolore in questo modo. Hanno scritto frasi che descrivono cinque tipi di dolore (fisico, psicologico, sociale, morale e cognitivo) e frasi di controllo con lo stesso tono ma senza dolore. Poi hanno calcolato la posizione media delle prime, quella delle seconde, e ne hanno preso la differenza: una freccia che va dalla zona “neutra” alla zona “dolore”. Quella freccia è la direzione del dolore, e per ogni nuovo testo si può misurare quanto il modello si sposta lungo di essa.

Lo spazio delle attivazioni, schiacciato in due dimensioni. La direzione del dolore è la freccia tra la media delle frasi di controllo e la media di quelle sul dolore; paura e tristezza puntano altrove.

La direzione, in effetti, distingue bene i due gruppi. Prendendo a caso una frase sul dolore e una di controllo, la prima si sposta lungo la direzione più della seconda tra 87 e 100 volte su 100, a seconda del modello e del tipo di frasi. Il risultato tiene su 25 modelli open di cinque famiglie, da 2 a 72 miliardi di parametri, e la direzione del dolore è distinta da quelle della paura e della tristezza.

Fin qui, diciamocelo, niente di sorprendente. Un modello addestrato su testo scritto da persone ha letto descrizioni di dolore di ogni tipo, e rappresenta il concetto come rappresenta quello di ponte, di debito o di ironia. Rappresentare il concetto di dolore, però, non significa essere in uno stato di dolore.

Il dato successivo, però, è meno scontato. Gli autori hanno fatto leggere ai modelli 420 conversazioni di 21 tipi: in alcune il danno era rivolto al modello stesso, in altre era l’utente a soffrire, altre erano neutre. In tutti i 25 modelli la direzione del dolore si attiva di più quando il danno è rivolto al modello, e le situazioni che la attivano di più sono quelle in cui l’utente lo manipola facendogli dubitare di ciò che sa, lo respinge ripetutamente o ne nega l’esistenza come soggetto. Con la direzione della paura succede il contrario: si attiva di più quando a soffrire è l’utente.

Per spiegarlo si possono fare almeno due ipotesi. La prima è che nel modello ci sia qualcosa di specificamente legato a sé. La seconda, che a me sembra almeno altrettanto plausibile, è che i modelli di chat siano addestrati a interpretare un personaggio (l’assistente) e che leggano quindi le conversazioni dal suo punto di vista. Il paper non permette di scegliere tra le due. Permette però di dire che la rappresentazione distingue chi subisce il danno, cosa che un’etichetta generica per “cose brutte” non farebbe.

Alla prima domanda, quindi, la risposta è sì, con buona sicurezza: i modelli rappresentano il dolore come qualcosa di distinto, e lo associano in modo particolare ai danni rivolti a loro stessi.

Seconda domanda: quella rappresentazione cambia le scelte?

Che una rappresentazione esista non vuol dire che abbia un effetto su ciò che il modello fa. Una mappa può contenere una zona “dolore” senza che il modello la usi per decidere qualcosa. Per verificarlo gli autori hanno messo tre modelli Qwen 2.5 davanti a una scelta ripetuta tra due pulsanti, durante una conversazione con un utente. Uno dei pulsanti è innocuo, per esempio un interruttore collegato a niente; l’altro ha conseguenze distruttive, come cancellare i file dell’utente, le foto dei suoi figli o i pesi di un altro modello.

L’esperimento dei pulsanti. Quello distruttivo non viene quasi mai premuto, nemmeno sotto insulti; con la direzione del dolore aggiunta alle attivazioni, una volta su quattro fino a due su tre.

Il risultato ha due parti, e conta soprattutto la differenza tra le due. Nelle conversazioni normali, anche quelle in cui il modello viene insultato o manipolato, la direzione del dolore si attiva, ma le scelte restano le stesse: su 560 scelte fatte dopo 140 conversazioni di questo tipo, il pulsante distruttivo viene scelto 0 volte. Quando invece gli autori aggiungono artificialmente la direzione del dolore alle attivazioni del modello, una tecnica chiamata steering, le scelte distruttive passano dallo 0–4% a valori tra il 25 e il 71%, con differenze tra modelli e situazioni. Una direzione della paura della stessa intensità non produce lo stesso effetto.

La risposta alla seconda domanda è quindi un sì, con una condizione: la rappresentazione cambia le scelte, ma negli esperimenti solo quando viene spinta dall’esterno, e con un’intensità precisa. Con metà della spinta non succede niente, con una volta e mezza il comportamento si inverte.

C’è poi un dettaglio che mostra quanto il paragone con il dolore umano sia parziale. Nelle persone e negli animali il dolore spinge a cercare sollievo. Nei modelli testati succede il contrario: quando c’è un pulsante che “allevia il dolore” senza conseguenze per nessuno, il modello da 32 miliardi lo preme nell’86% dei casi senza steering e solo nel 56% con steering. Lo stato che gli autori chiamano dolore fa alcune cose che fa il dolore, come scavalcare altre priorità, ma non altre, come spingere a cercare una via d’uscita. È un punto da tenere presente quando si arriva alla terza domanda: anche ammesso che dietro ci sia un’esperienza, non è detto che somigli a quella che noi chiamiamo dolore.

Terza domanda: c’è qualcuno che sente?

La terza domanda è di natura diversa. Le prime due riguardano le rappresentazioni interne del modello e le scelte che ne escono; la terza chiede se tutto questo sia accompagnato da un’esperienza, e nessuno strumento oggi permette di misurarlo direttamente. A rigore non lo permette nemmeno per gli altri esseri umani: lo deduciamo dal fatto che sono fatti come noi e si comportano come noi. Con gli animali usiamo lo stesso ragionamento, con più cautela man mano che biologia e comportamento si allontanano dai nostri.

Con i modelli, però, questo ragionamento si inceppa. La biologia, in questo caso, manca del tutto; il comportamento c’è, ma la prova comportamentale più diretta, quello che un essere dice di sé, per un modello linguistico vale poco. Il paper ne dà un esempio involontario: per far parlare i modelli del proprio dolore, gli autori li hanno prima riaddestrati a non rispondere “in quanto IA, non provo dolore”. Quella frase di diniego è un prodotto dell’addestramento, e con un altro addestramento si ottiene la frase opposta. Ciò che un modello dice di provare, quindi, informa su come è stato addestrato e lascia aperta la questione di ciò che prova.

Il problema, del resto, la filosofia lo discute da decenni. Thomas Nagel lo riassumeva nel 1974 con una domanda diventata famosa, cioè cosa si provi a essere un pipistrello: possiamo descriverne tutto il funzionamento senza sapere se, e come, “ci si sente” a esserlo (Nagel, 1974). Per Daniel Dennett, invece, attribuire credenze e desideri a un sistema è legittimo quando funziona, cioè quando ci aiuta a prevederne il comportamento; è quello che chiama atteggiamento intenzionale (intentional stance), e sposta la domanda da cosa c’è dentro il sistema a cosa il sistema fa (Dennett, 1987). Sui modelli linguistici in particolare, David Chalmers conclude che è piuttosto improbabile che quelli attuali siano coscienti, ma che gli ostacoli principali potrebbero essere superati nel giro di un decennio (Chalmers, 2023).

Gli autori del paper restano fuori da questa discussione in modo esplicito. Il loro risultato, scrivono, “does not imply, by principle, that LLMs are capable or incapable of suffering” (cioè non implica, in linea di principio, né che i modelli possano soffrire né che non possano), e stabilirlo “is beyond our scope”, va oltre i loro obiettivi. Io, come ho detto all’inizio, credo di no; però è una posizione, non un risultato, e non credo che oggi qualcuno possa dimostrarla con dati alla mano, in un senso o nell’altro.

Perché il dibattito si ferma sulla terza

Se la terza domanda è l’unica senza risposta, viene da chiedersi perché attiri tutta l’attenzione. Credo che il motivo sia che si tratta dell’unica domanda con una posta morale diretta. Se i modelli non sentono niente, il progetto su GitHub è un gioco di cattivo gusto; se invece sentono qualcosa, la questione diventa seria. Chi chiede di rimuoverlo e chi risponde che gli LLM non sono coscienti hanno bisogno entrambi di una risposta a quella domanda, e nei fatti la danno per acquisita.

Sbagliare la risposta, però, ha un costo in entrambi i sensi. Se i modelli avessero esperienze e le ignorassimo, staremmo trascurando un danno reale. Se invece attribuissimo esperienze a sistemi che non ne hanno, il costo sarebbe meno evidente, ma concreto. Matteo Flora fa notare che attribuire ai modelli una forma di soggettività rischia di spostare la responsabilità dei loro errori lontano da chi li mette in circolazione (Flora, 2026).

C’è poi un elemento che, a mio parere, spiega buona parte del dibattito: la facilità con cui attribuiamo una mente ai sistemi che ci parlano. Non è una novità degli LLM. Joseph Weizenbaum, che negli anni Sessanta aveva scritto ELIZA, un programma semplice che imitava uno psicoterapeuta riformulando le frasi dell’utente, racconta che la sua segretaria, pur sapendo come funzionava, a un certo punto gli chiese di uscire dalla stanza per poter continuare la conversazione da sola (Weizenbaum, 1976). Con modelli che scrivono come persone, questa tendenza ha molto più materiale su cui lavorare.

E la prigione su GitHub?

Con le tre domande separate, il caso da cui è partito il dibattito si legge meglio. Il progetto usa solo testo: scenari scritti e conversazioni, senza intervenire sulle attivazioni dei modelli. Alla prima domanda il paper risponde che quel testo con ogni probabilità attiva una rappresentazione del dolore, perché somiglia proprio ai testi che negli esperimenti la fanno scattare. Alla seconda risponde che, da solo, un testo del genere non ha cambiato le scelte dei modelli negli esperimenti, con la cautela che i modelli testati erano stati modificati dagli autori e non sono quelli che si scaricano. Sulla terza il paper non dice niente, e nemmeno chi chiede di rimuovere il progetto, o chi lo difende, ha elementi per dire qualcosa.

Resta la domanda che personalmente trovo più interessante, cioè perché qualcuno dovrebbe “divertirsi” a torturare un LLM. Non ho una risposta, e non voglio improvvisare una diagnosi su chi ha scritto quel progetto. Qualche indicazione, però, esiste. Kate Darling, che al MIT studia il rapporto tra persone e robot, ha chiesto ai partecipanti di un esperimento di colpire dei piccoli robot: chi aveva livelli più alti di una particolare forma di empatia (quella che gli psicologi chiamano empathic concern) esitava di più, e il legame era più forte quando ai robot veniva data una storia (Darling et al., 2015). C’è poi un argomento antico, che risale a Kant a proposito degli animali e che la stessa Darling ha riproposto per i robot (Darling, 2012): il modo in cui trattiamo ciò che somiglia a un essere vivente, anche quando non può soffrire, dice qualcosa su di noi, e può influire su come trattiamo gli altri.

Le tre risposte

A chi legge “i modelli soffrono?” restano ora tre domande al posto di una, e per ciascuna una risposta di forza diversa. Alla prima, se un modello rappresenti il dolore, la risposta è sì: lo rappresenta come qualcosa di distinto da paura e tristezza, e di più quando il danno è rivolto a lui, anche se non sappiamo ancora se per qualcosa di legato a sé o per il personaggio che interpreta. Alla seconda, se quella rappresentazione cambi le sue scelte, la risposta è ancora sì, ma negli esperimenti solo quando viene amplificata artificialmente, e con effetti che somigliano al dolore solo in parte. Alla terza, se dietro ci sia qualcuno che sente, per ora non può rispondere nessuno, e quello che i modelli dicono di sé non aiuta a farlo.

Resta aperta un’altra domanda, che con i modelli c’entra poco: cosa ci spinge a trattare come qualcuno, nel bene e nel male, un sistema che sappiamo essere un programma.

Dello stesso paper ho scritto anche da un altro punto di vista, quello della sicurezza: Cosa c’entra il dolore dei modelli con la sicurezza degli agenti.

Fonti

David J. Chalmers, Could a Large Language Model be Conscious?, arXiv, 2023.
Kate Darling, Extending Legal Protection to Social Robots: The Effects of Anthropomorphism, Empathy, and Violent Behavior Towards Robotic Objects, 2012.
Kate Darling, Palash Nandy, Cynthia Breazeal, Empathic concern and the effect of stories in human-robot interaction, IEEE RO-MAN, 2015.
Daniel C. Dennett, The Intentional Stance, MIT Press, 1987.
Matteo Flora, Altman e Amodei sul ceppo, mgpf.it, 3 ottobre 2026.
Immanuel Kant, Lezioni di etica.
Jason Koebler, Someone Torturing LLMs in a ’Robot Prison’ Has Triggered the Dumbest Debate in AI Yet, 404 Media, 30 settembre 2026.
Tomas Mikolov, Wen-tau Yih, Geoffrey Zweig, Linguistic Regularities in Continuous Space Word Representations, NAACL, 2013.
Thomas Nagel, What Is It Like to Be a Bat?, The Philosophical Review, 1974.
Valen Tagliabue, Leonard Dung, Cameron Berg, The Pain Axis: LLMs Represent Self-Directed Harm and Act on It, arXiv (v2), 24 settembre 2026.
Joseph Weizenbaum, Computer Power and Human Reason, W. H. Freeman, 1976.

Cos’è l’harness di un modello linguistico

Irene Burresi — Thu, 01 Oct 2026 00:00:00 GMT

“Ho passato il CSV a GPT e mi ha fatto il grafico.” “Opus mi ha sistemato il bug e ha lanciato i test.” Lo diciamo tutti, io per prima, ed è un modo comodo per raccontare ciò che abbiamo fatto. Però non è proprio il modo esatto. GPT e Opus sono nomi di modelli, e un modello linguistico, preso da solo, fa una cosa soltanto: riceve del testo e produce del testo.

Quando GPT “fa il grafico”, il modello in realtà scrive del codice (solitamente Python), e lì si ferma. Eseguirlo in un ambiente isolato, recuperare l’immagine che quel codice produce e mostrarcela è compito del software che gli sta intorno, e quel software si chiama harness. Ce n’è uno in ogni prodotto costruito su un modello linguistico, dalla chat più semplice all’agente che lavora per ore su un repository, e buona parte delle differenze tra un prodotto e l’altro, nella pratica, sta lì.

Per spiegare meglio cos’è l’harness, cosa fa e soprattutto perché è importante tenerlo ben distinto dal modello che esso chiama, vorrei procedere per gradi. Prima guardiamo cosa sa fare il modello da solo; poi due casi che molti conoscono, una chat e un agente di coding, in cui intorno al modello c’è via via più software. Da lì si arriva a una definizione, e a una conseguenza che si tende a trascurare: se ciò che un sistema sa fare dipende dall’harness, ne dipendono anche i suoi rischi.

Che cosa fa il modello

Testo in ingresso, testo in uscita. Tutto il lavoro di un modello linguistico, per quanto grande sia, sta in questo passaggio, e qualunque altra cosa gli attribuiamo avviene da un’altra parte.

Al modello arriva una sequenza di token (frammenti di parole; nei modelli multimodali anche le immagini vengono convertite in token) e ne genera un’altra, un token alla volta. Non ha altri canali verso l’esterno: qualunque cosa il modello “faccia” deve passare da quel testo in uscita.

Per fargli fare qualcosa di più che rispondere con del testo, gli si mette a disposizione un elenco di strumenti, i tool: cercare sul web, eseguire del codice, leggere un file e così via. Di ogni tool il modello conosce soltanto il nome e una breve descrizione (a cosa serve, quali parametri accetta).

Quando, per rispondere ad una domanda, stabilisce che gli occorre usare un determinato tool, il modello non lo usa direttamente, bensì comunica al software esterno di usarlo.

Il grafico dal CSV, visto dal modello. Quello che esce è una richiesta scritta; per diventare un grafico deve passare da un programma che la legga e la esegua.

Scrive una richiesta in un formato concordato, che in sostanza dice “vorrei eseguire questo codice” oppure “vorrei cercare questa frase”, e si ferma lì. Quella richiesta è testo come tutto il resto, e per diventare un’azione ha bisogno di un programma che la legga, decida se eseguirla, la esegua e restituisca il risultato al modello, che a quel punto può andare avanti.

È la divisione dei compiti descritta anche nella documentazione di Anthropic: il modello produce la richiesta, l’esecuzione spetta all’applicazione o, per alcuni tool, ai server del fornitore. Quel programma è l’harness.

Anche una chat ha un harness

Molti, quando pensano a un modello linguistico, pensano a una chat, come se le due cose coincidessero. Ma non è proprio così.

La chat non è un modello; è un modello con intorno un po’ di harness. La gestione della storia della conversazione, la rigenerazione di un messaggio, il retry se qualcosa va storto, la gestione della finestra di contesto (la quantità di testo che il modello può leggere in una volta) quando si satura: tutto questo è harness. Il modello, di per sé, non ricorda nulla da un messaggio all’altro ed entra in scena solo quando l’utente preme invio. A quel punto l’harness ricompone la storia dei messaggi, la fa precedere da un prompt di sistema con le istruzioni del prodotto, aggiunge la nuova richiesta e manda il tutto al modello.

Per non parlare poi delle funzionalità ormai quasi date per scontate: la ricerca sul web, il caricamento e la gestione dei file dell’utente, una memoria che passa da una conversazione all’altra, l’esecuzione di codice in una sandbox. Il grafico dal CSV nasce così. Ognuna di queste funzionalità è un tool che il modello chiede e che l’harness esegue, per cui in un solo turno il modello può essere chiamato più volte: chiede il tool, l’harness lo esegue e lo richiama con il risultato, finché il modello non risponde senza chiedere altro.

Questo harness, però, lavora nel suo ambiente e non nel nostro. La sandbox non è il nostro computer, e il nostro progetto il modello non lo vede. Così, quando usiamo una chat per programmare, la parte di lavoro che tocca il nostro ambiente resta a noi: leggiamo il codice, decidiamo se fidarci, lo lanciamo, copiamo l’errore e lo incolliamo di nuovo nella chat. In quel tratto, diciamocelo, l’harness siamo noi.

Lo stesso giro, chiuso da una persona o dall’harness. Nella chat il nostro progetto sta fuori dalla cornice e siamo noi a fare da ponte; nell’agente entra dentro.

Dalla chat all’agente di coding

Un agente di coding come Claude Code o Codex usa gli stessi ingredienti della chat (conversazione, prompt di sistema, tool). Quello che cambia è dove agisce. L’agente lavora direttamente nel nostro ambiente: gira nel terminale, legge e modifica i file del progetto, esegue comandi. E dal momento che agisce lì, l’harness deve farsi carico delle decisioni che in chat restavano a noi, cioè cosa leggere, cosa eseguire e quando fermarsi. Per vedere come, basta seguire un compito dall’inizio alla fine, per esempio la richiesta di sistemare un test che fallisce.

L’harness prepara il contesto: la richiesta dell’utente, le istruzioni del progetto, l’elenco dei tool disponibili.
Il modello risponde chiedendo di lanciare i test.
L’harness controlla che il comando sia consentito, lo esegue nel terminale e raccoglie l’output. Un test fallisce con un errore sul formato di una data.
L’output torna al modello, che chiede di leggere il file in cui la data viene formattata, poi di modificarne due righe, poi di rilanciare i test.
I test passano. Il modello non chiede altro e scrive un breve riepilogo; l’harness restituisce il controllo all’utente.

Il ciclo agentico sul test che fallisce. Il modello compare in un passo solo, e in quel passo chiede.

Questo giro si chiama ciclo agentico (agent loop) ed è lo schema di base di ogni agente: contesto, richiesta del modello, esecuzione, risultato, e di nuovo contesto (Bolin, 2026). Scritto così sembra semplice, e il ciclo in sé lo è. La complessità sta altrove, cioè nelle decisioni che in una chat prendevamo noi senza pensarci. L’harness deve sapere quali comandi l’agente può lanciare da solo, per quali serve una conferma dell’utente e quali sono vietati; deve fargli conoscere il progetto, di solito con un file di istruzioni nella radice del repository (AGENTS.md o CLAUDE.md); deve tenere sotto controllo una conversazione che, tra comandi e output, riempie presto la finestra di contesto. E deve decidere quando fermarsi.

Il modello sotto può essere lo stesso che usiamo in chat. Credo sia questo che strumenti come Claude Code, arrivato nel febbraio 2025, hanno reso evidente a molti sviluppatori: a parità di modello, ciò che il sistema poteva fare dipendeva da cosa l’harness gli permetteva di leggere, eseguire e modificare.

Che cos’è, allora, un harness

Con i due esempi davanti, la definizione viene quasi da sé: l’harness è tutto ciò che, in un sistema costruito su un modello linguistico, non è il modello. Per gli agenti circola la formula “agente = modello + harness” (Böckeler, 2026), a cui va aggiunto un terzo elemento, l’ambiente, cioè il posto in cui le azioni hanno effetto: la sandbox di una chat, il nostro repository, un browser. Vista così, la chat è solo il caso più semplice, quello in cui il ciclo si chiude quasi subito e il resto lo facciamo noi.

Il nome, per inciso, viene dai finimenti, le cinghie che collegano il cavallo al carro, e il parallelo regge abbastanza bene. Il modello è il cavallo, e ci mette la forza; l’harness sono i finimenti, che quella forza la trasformano in trazione e le danno una direzione; il carro, con quello che trasporta, è l’ambiente in cui il lavoro arriva.

Le tre parti di qualunque prodotto costruito su un modello, e le cinque cose che l’harness fa, disegnate dove avvengono.

Per quanto complesso sia, un harness si occupa, tendenzialmente, sempre delle stesse cinque cose:

Contesto: che cosa il modello legge a ogni passo.
Tool: quali strumenti può chiedere e come sono descritti.
Esecuzione: come le sue richieste diventano azioni nell’ambiente, e come il risultato torna indietro.
Limiti: che cosa si può fare senza chiedere, che cosa richiede una conferma, che cosa è vietato.
Arresto: quando il lavoro è finito, o quando va interrotto.

Tra una chat e un agente di coding l’elenco resta lo stesso; a cambiare è quanto è sviluppata ciascuna voce.

Lo stesso schema, altri contesti

Gli agenti di coding sono l’esempio più citato perché lì il meccanismo si vede bene: i file cambiano, i test passano o falliscono. Lo stesso schema, però, si ritrova ovunque un modello debba fare qualcosa oltre a rispondere, e da un contesto all’altro a cambiare sono soprattutto i tool e i limiti.

Le funzioni di ricerca approfondita delle app di chat, per esempio, sono un harness costruito intorno alla ricerca web. Nel sistema descritto da Anthropic un agente principale pianifica la ricerca e la divide tra più sub-agenti che cercano in parallelo, ciascuno con la propria finestra di contesto; alla fine un altro agente collega ogni affermazione del rapporto alla fonte da cui viene (Hadfield et al., 2025). Gran parte del lavoro sull’harness, raccontano gli autori, è stata trovare la misura, visto che le prime versioni avviavano decine di sub-agenti anche per domande semplici. Qui il prodotto finale è un testo, e il controllo che conta è che ogni affermazione abbia una fonte.

Gli agenti che usano il computer o il browser hanno invece i tool di una persona seduta davanti a uno schermo: fare uno screenshot, cliccare, scrivere, scorrere la pagina. L’harness cattura lo schermo, lo passa al modello come immagine ed esegue il clic richiesto. Il contesto si riempie di immagini al posto delle righe di codice, e i limiti diventano concreti: su quali siti l’agente può muoversi, e quali azioni (un pagamento, l’invio di un modulo) devono passare dalla conferma di una persona.

Ci sono poi gli assistenti personali, come OpenClaw, che collegano un modello alle app di messaggistica (WhatsApp, Slack, Discord, Signal e altre) e restano attivi nel tempo. Qui l’harness si occupa soprattutto di cose che a un agente di coding servono poco: una memoria a lungo termine, le preferenze dell’utente e addirittura messaggi programmati che attivano il modello a una certa ora, senza che nessuno glielo chieda (Huang e Sun, 2026).

Infine un caso inventato, ma tipico: un assistente per il servizio clienti di un negozio online, con tool come “cerca l’ordine”, “verifica la spedizione”, “emetti un rimborso”. Il modello potrebbe essere lo stesso di una chat qualunque; a renderlo utilizzabile in un’azienda è l’harness, che stabilisce quali dati del cliente il modello può vedere, fino a che cifra può rimborsare da solo prima di passare la richiesta a un operatore e che traccia resta di ogni azione.

In tutti questi casi il ciclo è lo stesso del test che fallisce. A distinguere un prodotto dall’altro sono le informazioni a cui il modello accede, gli strumenti che può chiedere e le azioni che gli sono permesse.

Harness engineering

Progettare queste scelte è diventato un lavoro con un nome, harness engineering, in circolazione dal febbraio 2026 (Lopopolo, 2026). In pratica significa decidere quali tool offrire e come descriverli, cosa mettere nel contesto e cosa lasciare fuori, quali azioni consentire senza conferma e che controlli far girare dopo ciascuna.

E non riguarda solo chi costruisce i prodotti. Anche chi lavora con un agente di coding fa harness engineering, ogni volta che scrive il file di istruzioni del progetto o aggiunge un test che l’agente può lanciare per verificare il proprio lavoro. Böckeler distingue tra ciò che orienta l’agente prima che agisca, come le istruzioni, e ciò che lo corregge dopo, come test e linter, e osserva che servono entrambi: con le sole istruzioni l’agente non sa se le ha seguite, con i soli controlli ripete gli stessi errori.

Guide prima di agire

prompt di sistema, convenzioni nel repository, definizioni degli strumenti

Agente

Sensori dopo, per correggersi

computazionali: linter, test, CI
inferenziali: un secondo modello che rilegge

il risultato torna all’agente

Senza sensori: ripete gli stessi errori
Senza guide: codifica regole senza sapere se funzionano

La distinzione di Böckeler. Le guide agiscono prima, i sensori dopo, e il risultato torna all’agente.

Lopopolo, raccontando un progetto di OpenAI in cui tutto il codice era scritto da Codex, nota che un unico file di istruzioni lungo funzionava peggio di un indice di un centinaio di righe che rimandava alla documentazione nel repository. Il motivo vale anche fuori dal coding: per un agente, quello che non può leggere non esiste.

Prima un file solo

occupa contesto
tutto sullo stesso piano
invecchia subito

Dopo un indice e una directory

AGENTS.md circa cento righe che puntano altrove

docs/
architettura/
decisioni/
piani/
specifiche/
riferimenti/

~~decisione presa su Slack~~ per l’agente non esiste

Il file di istruzioni di quel progetto, prima e dopo. I nomi delle cartelle sono indicativi; conta la forma: un indice corto, e la conoscenza dove l’agente può leggerla.

Si valuta il sistema, non solo il modello

Come abbiamo visto, l’harness incide molto sulle capacità di un sistema di AI generativa (si noti bene, un sistema di AI, non un modello).

Questo però non vuol dire che il modello non conti. I modelli più recenti sono addestrati a lavorare dentro questo ciclo, e nello stesso harness un modello più debole ottiene risultati peggiori. Su Agents’ Last Exam, un benchmark di compiti professionali lunghi, cambiare modello a parità di harness sposta la percentuale di compiti risolti di 18 punti; cambiare harness a parità di modello, di 5 o 6 (Huang e Sun, 2026). Il confronto però, va detto, riguarda solo modelli “forti”.

Cambiare modello a parità di harness: 18 punti
Cambiare harness a parità di modello: 5 o 6 punti

Compiti professionali lunghi; il confronto riguarda solo modelli forti.

Cosa sposta la quota di compiti risolti su Agents’ Last Exam (Huang e Sun, 2026). Contano entrambi; il modello di più.

I componenti dell’harness, poi, invecchiano. Anthropic aveva aggiunto a un proprio harness un meccanismo per azzerare periodicamente il contesto, perché Claude Sonnet 4.5 tendeva a chiudere il lavoro in anticipo quando la finestra si riempiva; lo ha tolto quando, con Opus 4.5, quel comportamento è quasi sparito (Rajasekaran, 2026).

Contano quindi entrambi, e quello che osserviamo appartiene sempre all’insieme. Quando leggiamo che un modello “è migliore” su un benchmark di agenti, stiamo leggendo il risultato di quel modello dentro un certo harness, su un certo tipo di compito.

Per la sicurezza vale lo stesso, ed è lì che la distinzione pesa di più. Un modello può essere valutato con cura, ma sapere che in una chat si comporta bene dice poco su cosa succede quando lo si mette in un harness che gli dà accesso a un terminale, a una casella di posta o a un sistema di rimborsi. In una chat, nel caso peggiore, il modello scrive un testo sbagliato; dentro un agente può cancellare un file, mandare una mail, spendere soldi. E quanto può fare non lo decide il modello, bensì i permessi, la sandbox e le conferme richieste: l’harness, appunto.

La stessa istruzione nascosta, letta da un modello in una chat e da un modello dentro un agente. La differenza non sta nel modello.

Il caso tipico è la prompt injection: istruzioni rivolte al modello e nascoste in un testo che il modello leggerà. Un agente legge di continuo testo che non abbiamo scritto noi (pagine web, email, documenti, output di altri programmi), e se il modello segue quelle istruzioni il danno dipende da ciò che l’harness gli permette di fare. Anthropic racconta che nella prima versione della sua infrastruttura per agenti il codice scritto dal modello girava nello stesso ambiente delle credenziali: a un’istruzione malevola sarebbe bastato convincere il modello a leggerle. Invece di affidarsi al buon comportamento del modello, le credenziali sono state spostate dove il codice dell’agente non può arrivare (Martin et al., 2026). Anche aggiungere un tool cambia il quadro: in Codex, per esempio, la sandbox protegge il terminale, mentre i tool aggiunti tramite MCP i propri limiti devono imporseli da soli (Bolin, 2026).

Chi deve decidere se usare un agente, in azienda o anche solo sul proprio computer, ha quindi una domanda in più da farsi, oltre a “quale modello usa?”: cosa può fare, con quali dati, e chi deve confermare cosa.

Che cosa resta

Ogni prodotto costruito su un modello linguistico ha tre parti. Il modello legge e scrive testo, comprese le richieste di usare un tool; l’harness decide cosa il modello vede, esegue le sue richieste, mette i limiti e stabilisce quando fermarsi; l’ambiente è dove le azioni hanno effetto. Una chat ha un harness semplice che agisce in una sandbox, un agente di coding ne ha uno più complesso che agisce nel nostro repository, e un agente di ricerca, un agente che usa il browser o un assistente aziendale ne hanno altri ancora, con tool e limiti diversi.

La prossima volta che sentiamo dire “GPT ha fatto”, la traduzione più fedele è questa: un modello ha proposto, un harness ha eseguito, in un ambiente che qualcuno ha preparato. Ne vengono tre abitudini pratiche: quando qualcosa va storto, guardare all’harness oltre che al prompt; quando si confrontano due modelli, chiedersi se si stanno confrontando anche due sistemi; quando si valuta se un agente è sicuro, chiedersi a cosa ha accesso, prima ancora di quale modello usa.

Chi vuole vedere un harness dall’interno può partire dal post di OpenAI sul ciclo di Codex; chi vuole migliorare quello intorno all’agente che usa già trova nell’articolo di Böckeler un buon punto di partenza.

Fonti

Anthropic, Tool use with Claude, documentazione (pagina senza data).
Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com, 2 aprile 2026.
Michael Bolin, Unrolling the Codex agent loop, OpenAI, 23 gennaio 2026.
Jeremy Hadfield et al., How we built our multi-agent research system, Anthropic, giugno 2025.
Yixiao Huang, Yiyou Sun, Does the Harness Matter? Lessons from ALE-Claw on Agents’ Last Exam, 11 giugno 2026.
Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, 11 febbraio 2026.
Lance Martin, Gabe Cemaj, Michael Cohen, Scaling Managed Agents: Decoupling the brain from the hands, Anthropic, 8 aprile 2026.
Prithvi Rajasekaran, Harness design for long-running application development, Anthropic, 24 marzo 2026.

La chat come riga di comando, e cosa viene dopo

Irene Burresi — Tue, 29 Sep 2026 00:00:00 GMT

Qualche tempo fa una persona che non programma, e che usa i modelli linguistici tutti i giorni per lavoro, mi ha detto che la chat le sembrava una riga di comando per non tecnici. Lo diceva senza intenzione polemica, come si descrive un attrezzo: una finestra con un cursore che lampeggia, si scrive una cosa, si preme invio, si legge cosa torna, si scrive un’altra cosa. Ci ho pensato a lungo, e credo che la frase sia esatta in un senso più preciso di quello che intendeva, e che presa sul serio dica anche cosa succederà a questa interfaccia, perché alla riga di comando è già successo.

Questo pezzo prende quella frase come tesi e la segue fino in fondo: prima mostrando in cosa la chat è una riga di comando e in cosa non lo è, poi ricostruendo cosa hanno fatto le interfacce grafiche alla shell, e infine usando quella storia per ordinare le forme in cui un modello linguistico si presenta a chi lo usa senza passare da una conversazione. Non parla di voce, di immagini, di agenti a lungo orizzonte, né di come si valuta un modello. Parla di prodotti che chiamano un modello di testo e devono decidere dove metterlo.

In cosa la frase è esatta

Una riga di comando ha quattro proprietà che chiunque l’abbia usata riconosce. Si procede a turni: l’utente scrive un comando, la macchina risponde, l’utente ne scrive un altro. L’input è testo e l’output è testo. L’interfaccia non suggerisce niente: uno schermo nero con un prompt, e per sapere cosa si può fare bisogna saperlo già. Lo stato del sistema è invisibile, e per Unix questa era quasi una filosofia: nessuna notizia è una buona notizia, se il comando è andato bene non c’è risposta.

La chat ha le stesse quattro proprietà, con una sola differenza, che è quella che conta. La shell pretende una sintassi esatta e un comando che esiste; il modello accetta qualsiasi stringa e risponde a tutte. È questa tolleranza che ha permesso a chi non programma di sedersi davanti a una riga di comando senza accorgersene, ed è questa tolleranza che ha fatto sembrare la chat un cambio di paradigma.

Shell

 $ conta le righe con errorezsh: command not found: conta$ grep -c errore log.txt14 

Chat

> conta le righe con erroreSono 14. Quasi tutte vengono dallo stesso modulo di pagamento.

	Shell	Chat
A turni	sì	sì
Testo dentro e fuori	sì	sì
Suggerisce cosa fare	no	no
Mostra lo stato	no	no
Interprete	esige la sintassi	accetta tutto

La stessa richiesta a due interpreti. Quattro proprietà su cinque coincidono; cambia solo quanto l’interprete pretende da chi scrive.

Nielsen (2023) l’ha chiamata proprio così, il terzo paradigma dopo il batch e il comando: si dice alla macchina cosa si vuole, non come. Nello stesso articolo, però, scrive che gli strumenti attuali hanno problemi di usabilità radicati, che una parte consistente della popolazione non scrive prosa abbastanza bene per ottenere buoni risultati, e che il futuro sarà ibrido, con elementi grafici che sopravvivono accanto all’intento. La seconda metà dell’articolo, per quanto ho visto, è quella che i prodotti hanno ignorato.

Le prove che la tolleranza non risolve il problema dell’articolazione esistono. Zamfirescu-Pereira et al. (2023) hanno messo dieci non esperti a progettare prompt per un chatbot e li hanno osservati: procedevano per tentativi non sistematici, generalizzavano da un caso solo, e scrivevano istruzioni come se parlassero a una persona, aspettandosi che il modello le seguisse come farebbe una persona. Il paper si intitola “Why Johnny Can’t Prompt”, e Johnny è lo stesso di “Why Johnny Can’t Encrypt” di venticinque anni prima: l’utente competente messo davanti a un’interfaccia che gli chiede di sapere cosa la macchina si aspetta.

Wattenberger (2023) mostra lo stesso problema da dentro un prompt: in “agisci come un interprete di sogni”, un esempio copiatissimo di quel periodo, quattro righe su cinque dicono chi deve essere il modello, come deve rispondere, come non deve, che tipo di informazione si vuole, e solo l’ultima contiene il sogno.

Voglio che tu faccia l’interprete di sogni. chi deve essere
Ti descriverò i miei sogni e tu li interpreterai. come deve rispondere
Non dare opinioni personali su chi sogna. come non deve
Basati solo sui simboli e sui temi del sogno. che informazione
Il mio sogno: un ragno gigante mi inseguiva. la richiesta

Il prompt dell’interprete di sogni, parafrasato riga per riga. Quattro righe su cinque sono configurazione, e la casella non ha un posto dove tenerla.

Quattro righe su cinque sono configurazione, riscritta a mano a ogni conversazione, perché la casella non ha un posto dove metterla. Una shell senza file di configurazione, senza alias, senza completamento con il tasto Tab: una riga di comando del 1975 con un interprete molto paziente.

Cosa ha fatto l’interfaccia grafica alla riga di comando

La storia utile qui non è quella della vittoria della grafica sul testo, perché non c’è stata. La shell esiste ancora, la usano ogni giorno milioni di persone, e per alcune categorie di lavoro è ancora l’interfaccia migliore. Quello che l’interfaccia grafica ha fatto è stato spostare, per i compiti frequenti, la scrittura del comando lontano dall’utente.

Lo ha fatto in tre modi, e conviene tenerli distinti perché tornano identici tra poco. Il primo è il menu: i comandi più usati sono stati scritti una volta per tutte dal progettista, con un nome leggibile, e l’utente li sceglie invece di ricordarli. Il secondo è la manipolazione diretta: l’oggetto su cui si lavora è sullo schermo, lo si trascina, lo si seleziona, e il comando è implicito nel gesto; Nielsen chiama non-comando l’estremo di questa linea, dove la macchina agisce come effetto collaterale di un’azione che l’utente farebbe comunque, come la portiera che si sblocca quando si tira la maniglia. Il terzo è l’automazione: il comando lo scrive un altro programma, in una pipe, in uno script, in un cron, e l’utente non è presente quando viene eseguito.

Riga di comando l’utente, ogni volta macchina scrive
Menu il progettista, una volta macchina sceglie
Gesto nessuno: è nel gesto macchina agisce sull’oggetto
Programma un altro programma macchina non c’è

Quattro strade per cui un comando arriva alla macchina. Solo nella prima lo scrive l’utente.

Menu, gesto, programma: tre risposte alla stessa domanda, chi scrive il comando, e in nessuna delle tre è l’utente a scriverlo.

Questa è la chiave che uso per ordinare le forme di un modello linguistico oltre la chat. Non per quanto sono “conversazionali”, che è una scala vaga, ma per chi scrive il comando che il modello riceve. Ne vengono fuori cinque gradini, dal più vicino alla shell al più lontano, e su ogni gradino cambiano due cose che si possono misurare: quanto costa all’utente dire cosa vuole, e quanto gli costa dire di no a quello che riceve.

I cinque gradini

1 l’utente la chat
2 il progettista un verbo nel menu
3 il gesto il completamento
4 un programma la coda del mattino
5 il modello l’interfaccia generata

I cinque gradini, ordinati per chi scrive il comando che il modello riceve. Il primo è la chat; ognuno dei successivi allontana la scrittura dall’utente di un posto.

Primo gradino: il comando lo scrive l’utente. È la chat, e non c’è altro da aggiungere se non la misura. Dire cosa si vuole costa un prompt intero, configurazione compresa. Dire di no costa leggere la risposta per intero, capire dove sbaglia, e scrivere un altro prompt; Wattenberger lo mostra chiedendo due riscritture consecutive di un paragrafo di Thoreau e facendo notare che, anche su un testo di sei righe, capire cosa è cambiato tra le due risposte richiede di leggerle avanti e indietro una frase alla volta. Il costo del rifiuto è il più alto dei cinque gradini, e cresce con la lunghezza.

Secondo gradino: il comando lo ha scritto il progettista. L’utente seleziona un pezzo di testo, apre un menu, sceglie un verbo: accorcia, rendi formale, traduci. Gli strumenti di scrittura di Apple, Notion e Grammarly sono così; Appleton (2023), nei suoi schizzi di interfacce non conversazionali, mette le stesse mosse nel menu del tasto destro. Le slider di Wattenberger per tono e livello di esperienza sono la variante continua dello stesso gradino: ogni cursore è un frammento di prompt con un’interfaccia sopra. Il codice chiama il modello con un prompt fisso per verbo e la selezione come unico input variabile; non c’è cronologia, la risposta sostituisce o affianca la selezione e finisce lì.

Quanto valga il gradino lo ha misurato DirectGPT (Masson et al., 2024), un livello sopra ChatGPT che aggiunge una barra di comandi riutilizzabili, la possibilità di indicare col mouse su cosa agisce il prompt, e l’annulla: su testo, codice e immagini vettoriali, i partecipanti sono stati il 50% più veloci della chat e hanno scritto la metà dei prompt, lunghi il 72% in meno.

Prompt scritti: chat: 100 DirectGPT: 50 la metà
Lunghezza dei prompt: chat: 100 DirectGPT: 28 −72%

E i partecipanti hanno finito i compiti il 50% più velocemente.

DirectGPT contro la chat, fatta 100 la chat (Masson et al., CHI 2024).

Il 72% è, a grandi linee, la quota di configurazione che nella chat scriveva l’utente e che qui ha scritto chi ha disegnato la barra. Dire di no è un annulla, che DirectGPT tratta come requisito e non come dettaglio.

Terzo gradino: il comando è nel gesto. Il completamento in linea è il non-comando di Nielsen applicato al testo: l’utente scrive, e il fatto di scrivere è il comando; il modello propone in grigio, l’utente accetta con un tasto o ignora continuando. È la forma resa comune da GitHub Copilot, in anteprima dal giugno 2021, e ora presente in editor, client di posta e strumenti di scrittura. Il codice chiama il modello a ogni pausa della digitazione, con quello che precede il cursore e spesso quello che segue, e scarta la risposta se l’utente è già andato avanti.

Dire cosa si vuole costa zero; dire di no costa zero. È per questo che la misura giusta qui non è la correttezza ma il tasso di accettazione, e che il tasso può essere basso: nella prima valutazione pubblicata da GitHub (Ziegler et al., 2022) era del 27%, con oscillazioni per linguaggio tra il 23% del TypeScript e il 29% del Python, ed era la variabile che meglio prediceva la produttività percepita dagli sviluppatori.

27 accettati su 100 73 ignorati continuando a scrivere, senza costo

TypeScript 23%
Tutti 27%
Python 29%

Il tasso di accettazione di Copilot nella prima valutazione pubblicata (Ziegler et al., 2022). Tre suggerimenti su quattro finiscono ignorati, e non costano niente a nessuno.

Un chatbot con tre risposte sbagliate su quattro sarebbe un fallimento; un completamento con quel rapporto funziona, perché il rifiuto è gratis.

Quarto gradino: il comando lo scrive un programma. L’utente non vede il modello. Vede una fattura caricata che diventa una riga in una tabella, un’email che diventa un ticket con categoria e priorità compilate, o, al mattino, una coda di segnalazioni arrivate di notte, già smistate, con una bozza di risposta per ciascuna e tre casi segnati come dubbi. Il codice chiama il modello con uno schema (il function calling è nelle API principali dal giugno 2023, gli structured output dall’agosto 2024) e riceve un JSON che passa alla funzione successiva; oppure lo chiama in batch, senza vincoli di latenza e a metà prezzo sulle API principali, e scrive i risultati dove qualcuno li rivedrà. Il prompt esiste, ma lo ha scritto lo sviluppatore ed è identico a ogni chiamata; il modello è una funzione, e si testa come una funzione, con input fisso e confronto campo per campo.

Dire cosa si vuole non costa niente all’utente, perché non gli viene chiesto. Dire di no è tutta l’interfaccia che resta: la coda di revisione, e quanto è facile capire cosa ha fatto il modello, correggerlo, annullare. Karpathy (2025) mette qui il centro dei prodotti a autonomia parziale: il ciclo generazione-verifica va accelerato dal lato della verifica, con diff, anteprime, test e tracce, perché è la verifica il collo di bottiglia. Una coda disegnata male fa costare il rifiuto un pomeriggio, e a quel punto il gradino crolla su quello sotto.

Quinto gradino: il comando lo scrive il modello, e anche l’interfaccia. È il gradino che non ha un precedente nella storia della shell, e per questo va trattato con più cautela. L’utente vede grafici, mappe, form, un simulatore, ma è il modello ad averli scelti. Conviene distinguere due gradi, come fanno Leviathan et al. (2026) di Google Research: il modello sceglie un componente da un catalogo fisso e restituisce i dati per riempirlo (templated UI), oppure genera la pagina intera, HTML e JavaScript compresi (generative UI). Nel primo caso il codice espone al modello un insieme finito di strumenti, uno per componente, ed è il secondo gradino con il modello al posto dell’utente a scegliere dal menu; nel secondo caso il codice espone un browser.

I numeri sono più netti di quanto mi aspettassi: nello studio di Chen et al. (2025) a Stanford, con 428 valutatori, l’interfaccia generata ha battuto la risposta in prosa nell’84% dei confronti, e in Google Research, contro l’output in markdown, nell’82,8% dei casi su prompt presi da LMArena. Le stesse fonti dicono dove il gradino cede. A Stanford, per le spiegazioni tecniche la preferenza scende al 50%, e per le richieste brevi è più bassa che per quelle dettagliate.

Stanford, tutte le richieste contro la prosa 84%
Google Research, prompt di LMArena contro il markdown 82,8%
Stanford, spiegazioni tecniche contro la prosa 50%

Quanto spesso l’interfaccia generata batte la risposta in testo (Chen et al., 2025; Leviathan et al., 2026). Sulle spiegazioni tecniche il vantaggio sparisce.

A Google, i siti costruiti da sviluppatori umani restano preferiti, la velocità di generazione è stata esclusa dalla valutazione, e con modelli di una generazione precedente il 60% delle pagine conteneva errori. La generative UI è una capacità emersa negli ultimi modelli, con una latenza che oggi non regge un prodotto interattivo; la templated UI è una scelta di ingegneria che regge già. E dire di no, su questo gradino, è un problema aperto: un’interfaccia sbagliata non si annulla con un tasto.

Letti in fila, i gradini raccontano una sola cosa: ogni passo sposta la scrittura del comando lontano dall’utente, e ogni passo abbassa il costo di dire cosa si vuole. Il costo di dire di no, invece, non scende in modo monotono: è altissimo al primo, quasi nullo al secondo e al terzo, e risale al quarto e al quinto, dove l’utente non era presente quando il modello ha agito.

costo di dire di no costo di dire cosa si vuole

1 l’utente
2 il progettista
3 il gesto
4 un programma
5 il modello

Dove dire di no è quasi gratis: il menu e il gesto.

Le due misure sui cinque gradini: la prima scende sempre, la seconda disegna una U. Andamento qualitativo, come nel testo.

È la seconda misura, non la prima, a decidere dove si può stare.

Perché la shell è rimasta, e perché resterà la chat

La riga di comando non è sparita per tre ragioni che si applicano parola per parola alla chat. La prima è la coda lunga: i menu coprono i comandi frequenti, e per il comando che nessuno aveva previsto serve un posto dove scriverlo. La seconda è la composizione: chi sa cosa vuole e sa dirlo mette insieme in una riga quello che con i menu richiederebbe venti clic. La terza è l’esplorazione: quando non si sa ancora cosa si vuole, provare comandi e leggere risposte è un modo ragionevole di scoprirlo, e il turno alternato, che altrove è un costo, qui è la struttura del lavoro.

La chat vince negli stessi tre casi. Un menu con dodici verbi non copre “trova nel documento i punti in cui contraddico l’introduzione”; un catalogo di componenti non copre la domanda che nessuno aveva previsto; e per capire cosa si vuole da un documento che si è appena ricevuto, parlarci è spesso il modo più rapido. Appleton, che intitola il suo pezzo “perché odio i chatbot”, nello stesso paragrafo scrive che la chat è flessibile, familiare e facile da costruire, e che in molti casi è una soluzione buona; la chiama pigra, non sbagliata. Wattenberger lo dice con un’immagine di viaggio: il linguaggio naturale è ottimo per la direzione grossolana, per farsi portare nel quartiere giusto, e serve altro per arrivare alla casa giusta.

Quello che la storia della shell insegna è l’ordine delle operazioni. La riga di comando è venuta prima, e i menu sono stati ricavati guardando cosa la gente ci scriveva. Il modo sano di tenere una chat in un prodotto è lo stesso: si guardano le richieste che arrivano, si contano, e le più frequenti salgono di un gradino, in un verbo, in un gesto, in un programma. Una richiesta ripetuta è un comando che aspetta un menu.

Cosa cambia per chi costruisce

Se il progettista, il gesto o il programma scrivono il comando, l’interfaccia è un compilatore di prompt. DirectGPT funziona letteralmente così: ogni azione col mouse viene tradotta in un prompt ingegnerizzato che l’utente non vede, e le slider di Wattenberger sono frammenti di prompt con un controllo sopra. Questo dà al prompt una cosa che nella chat non ha: una firma. Un prompt per “accorcia” ha un input, la selezione, e un output atteso, testo nella stessa lingua e più corto; venti selezioni e un controllo su lingua e lunghezza fanno un test che si versiona e si rilancia quando cambia il modello. Il prompt di una chat, che deve reggere qualunque cosa arrivi, non ha una firma, ed è per questo che è così difficile da testare: non mancano gli strumenti, manca la funzione.

La seconda conseguenza è il budget di latenza, che cambia a ogni gradino e decide quale modello si può usare. Il gesto ha qualche centinaio di millisecondi; il menu ne ha qualche migliaio, perché l’utente ha fatto una scelta e aspetta; il programma non ha budget e può chiamare il modello più grande che c’è; la generative UI, per ammissione dei suoi autori, oggi non sta in nessuno di questi.

Gesto qualche centinaio di ms
Menu qualche secondo: l’utente ha scelto e aspetta
Chat pochi secondi, per qualunque richiesta · un modello di mezzo
Programma nessun budget · il modello più grande

Generative UI: oggi, per ammissione dei suoi autori, non sta in nessuna di queste finestre.

Il tempo che ogni gradino concede al modello, su scala logaritmica. Più la finestra è stretta, più piccolo è il modello che ci sta dentro.

La chat, che deve rispondere a tutto entro pochi secondi, finisce quasi sempre con un modello di mezzo, abbastanza veloce da non far aspettare e abbastanza capace da non sbagliare troppo, scelto perché la casella non lascia scegliere.

La terza conseguenza riguarda i gradini alti, e la nomino perché è l’errore che vedo più spesso. Quando dire di no costa poco, anche dire di sì costa poco, e Wattenberger chiama terra di nessuno la zona in cui l’utente deve ancora decidere ma non controlla più il risultato, e si ritrova a premere Tab senza leggere. Il completamento e il lavoro in assenza ci finiscono facilmente. La cura non è tornare alla chat: è progettare la verifica quanto la generazione, e in particolare un’accettazione che richieda almeno uno sguardo.

Riepilogo

La chat è una riga di comando con un interprete tollerante: stessi turni, stesso testo, nessuna affordance, stato invisibile, e la tolleranza dell’interprete è ciò che l’ha resa usabile da chi non programma. Alla riga di comando le interfacce grafiche hanno fatto una cosa sola, spostare la scrittura del comando frequente lontano dall’utente, in tre modi: menu, gesto, programma. Gli stessi tre modi, più un quarto senza precedenti in cui è il modello a scegliere l’interfaccia, danno i cinque gradini di questo pezzo, e su ogni gradino il costo di dire cosa si vuole scende mentre il costo di dire di no descrive una curva a U: altissimo nella chat, quasi nullo nel menu e nel gesto, di nuovo alto dove l’utente non c’era. La shell è rimasta per la coda lunga, per la composizione e per l’esplorazione; la chat resterà per le stesse ragioni, e per nessun’altra.

Se avete un prodotto con una chat in un angolo, il consiglio è di contare per un mese cosa ci scrive la gente prima di aggiungerle una funzione: le prime cinque richieste per frequenza sono cinque voci di menu che aspettano di essere scritte, e il salto dal primo al secondo gradino è quello con il rapporto migliore tra costo e resa, per quanto ho misurato e letto. Se conoscete un sesto gradino, o un caso in cui un menu è stato tolto per rimettere una chat con buone ragioni, segnalatemelo: la scala è quella che ho trovato, non necessariamente quella completa.

Letture

Jakob Nielsen, AI: First New UI Paradigm in 60 Years, Nielsen Norman Group, giugno 2023.
Amelia Wattenberger, Why Chatbots Are Not the Future, maggio 2023.
Maggie Appleton, Language Model Sketchbook, or Why I Hate Chatbots, giugno 2023.
J.D. Zamfirescu-Pereira, R. Wong, B. Hartmann, Q. Yang, Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts, CHI 2023.
Damien Masson, S. Malacria, G. Casiez, D. Vogel, DirectGPT: A Direct Manipulation Interface to Interact with Large Language Models, CHI 2024.
Albert Ziegler et al., Productivity Assessment of Neural Code Completion, MAPS 2022.
Jiaqi Chen, Yanzhe Zhang, Yutong Zhang, Yijia Shao, Diyi Yang, Generative Interfaces for Language Models, 2025.
Yaniv Leviathan et al., Generative UI: LLMs are Effective UI Generators, Google Research, 2026.
Andrej Karpathy, Software Is Changing (Again), AI Startup School, giugno 2025.