La chat come riga di comando, e cosa viene dopo

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

Due finestre affiancate. Nella shell la richiesta in italiano fallisce con «command not found» e serve il comando esatto grep; nella chat la stessa frase riceve una risposta. Sotto, una tabella: a turni, testo dentro e fuori, nessun suggerimento, stato invisibile valgono per entrambe; l’interprete della shell esige la sintassi, quello della chat accetta tutto.

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.

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

configurazione, riscritta a ogni conversazione richiesta

Cinque righe di prompt. Le prime quattro, in grigio, dicono chi deve essere il modello, come deve rispondere, come non deve e che informazione si vuole. Solo la quinta, evidenziata, contiene la richiesta: il sogno. Una barra sotto divide il prompt in quattro quinti di configurazione e un quinto di richiesta.

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.

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

Quattro righe. Riga di comando: l’utente scrive il comando ogni volta. Menu: il progettista lo ha scritto una volta, l’utente sceglie. Gesto: nessuno lo scrive, è implicito nel gesto sull’oggetto. Programma: lo scrive un altro programma, l’utente non c’è.

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

chi scrive il comando sempre più lontano dall’utente →

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

Una scala di cinque gradini. Gradino 1: il comando lo scrive l’utente, la chat. Gradino 2: il progettista, un verbo nel menu. Gradino 3: il gesto, il completamento in linea. Gradino 4: un programma, la coda di lavoro trovata al mattino. Gradino 5: il modello, l’interfaccia generata.

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.

chat DirectGPT

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.

Due coppie di barre con la chat a 100. Prompt scritti: DirectGPT 50, la metà. Lunghezza dei prompt: DirectGPT 28, il 72% in meno. I partecipanti hanno anche finito i compiti il 50% più velocemente.

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%

Una griglia di cento quadrati, ventisette pieni: 27 suggerimenti accettati su 100, gli altri 73 ignorati continuando a scrivere. Per linguaggio: TypeScript 23%, tutti i linguaggi 27%, Python 29%.

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%

50%: nessuna preferenza

Tre barre con una linea tratteggiata alla parità del 50%. Stanford, tutte le richieste, contro la prosa: 84%. Google Research, prompt di LMArena, contro il markdown: 82,8%. Stanford, spiegazioni tecniche: 50%, cioè nessuna preferenza.

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

alto nullo

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

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

Un grafico qualitativo con i cinque gradini sull’asse orizzontale. Il costo di dire cosa si vuole, tratteggiato, parte alto alla chat e scende fino a quasi nulla dal terzo gradino. Il costo di dire di no parte altissimo alla chat, crolla a quasi nulla al secondo e al terzo gradino, evidenziati come la zona favorevole, e risale al quarto e ancora di più al quinto.

È 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

0,1 s1 s10 s1 min1 h

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

Quattro intervalli su un asse logaritmico da 0,1 secondi a un’ora. Gesto: qualche centinaio di millisecondi. Menu: qualche secondo, perché l’utente ha scelto e aspetta. Chat: pochi secondi per qualunque richiesta, quindi un modello di mezzo. Programma: nessun budget, quindi il modello più grande. La generative UI oggi non sta in nessuna di queste finestre.

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.