Chiedi all’AI di analizzare come le parli: un metodo pratico

Una conversazione con un’AI contiene più informazioni di quelle che i due interlocutori si scambiano esplicitamente. Oltre al contenuto (cosa si chiede, cosa si risponde) c’è un livello di informazioni implicito che riguarda la struttura delle interazioni. L’ordine in cui arrivano le informazioni, il modo in cui vengono formulati i feedback, la precisione o la vaghezza delle richieste, la gestione degli imprevisti.

Queste informazioni sono nel testo della conversazione ma nessuno le osserva. L’utente è concentrato sul risultato, non sul proprio modo di chiederlo. L’AI è concentrata sull’esecuzione, non sull’analisi della dinamica.

Però quei dati sono presenti e può valere la pena analizzarli alla fine di una sessione, tramite lo stesso Claude a cui si può chiedere di analizzare i pattern di interazione dell’intera conversazione, evidenziando sia i comportamenti efficaci che quelli migliorabili. Il risultato non è un elenco di consigli generici su come scrivere prompt migliori. È un’analisi specifica, ancorata a scambi reali, del proprio modo di lavorare con l’AI.

Come funziona e perché è diverso dal prompt engineering

La differenza rispetto al prompt engineering classico è la direzione. Il prompt engineering propone regole generali come «sii specifico», «dai contesto», «usa esempi». Sono indicazioni valide ma appunto generiche. Invece l’analisi dei pattern delle conversazioni reali restituisce osservazioni concrete. E sono analisi dei pattern specifici dell’utente.

Una richiesta che ha prodotto il risultato corretto al primo tentativo ha una forma diversa da una che ha richiesto tre correzioni. Un feedback che include dati verificabili si distingue da una descrizione vaga del problema. Una sequenza dove i vincoli e il contesto precedono la richiesta operativa ha un esito diverso da una dove arrivano dopo, in un messaggio separato.

Ognuno di noi tende a ripetere le modalità di interazione, di fatto si seguono degli schemi. E quando si chiede all’AI di analizzare questi pattern rileggendo gli scambi, identifica le regolarità e restituisce quello che trova. È un lavoro di analisi testuale applicato a una conversazione di cui è stata parte, il che gli permette di collegare la forma delle richieste ai risultati che hanno prodotto.

L’utilità sta nel fatto che il modo in cui si comunica con un’AI è in gran parte un comportamento automatico, difficile da osservare mentre lo si pratica. Un osservatore esterno lo noterebbe, ma in assenza di un vero osservatore estreno Claude stesso può prenderne il posto.

Dove funziona e dove no

Il metodo ha un vincolo tecnico preciso, l’analisi può essere fatta solo sulla conversazione accessibile all’AI nel momento in cui si chiede l’analisi. Parlando di Claude Desktop questo significa che il metodo funziona bene in due contesti.

Il primo è la Chat, dove la cronologia della conversazione resta disponibile fino al limite della finestra di contesto di 200.000 token, una quantità che copre sessioni di lavoro molto lunghe. Se la conversazione supera quel limite, le parti più vecchie escono dalla finestra e non sono più direttamente accessibili.

Il secondo è Code, con una finestra di contesto di un milione di token se si usa Opus.

In Cowork succede una cosa strana, non è chiaro se voluta oppure sia un problema temporaneo, le conversazioni vengono tagliate dopo pochi scambi e le parti precedenti vengono eliminate senza possibilità di recupero. In quei casi l’AI ha a disposizione solo gli scambi più recenti e l’analisi risulta inevitabilmente poco efficace.

Questo ci porta al secondo vincolo, la lunghezza della sessione. Pochi messaggi non producono abbastanza materiale per identificare pattern significativi. Il metodo diventa utile dopo sessioni sostanziali, con almeno una ventina di scambi che coprono attività diverse, come richieste operative, decisioni, correzioni, feedback, cambi di direzione. Anche la varietà delle interazioni rende l’analisi ricca, non solo la quantità.

Un terzo fattore è il tipo di sessione. Le sessioni operative, dove si costruisce qualcosa insieme (un codice, un documento, un progetto), producono analisi più utili delle sessioni puramente informative. Nelle sessioni di domande semplici e risposte altrettanto semplici c’è meno materiale comportamentale da analizzare.

In realtà c’è un’altra possibilità, che utilizza la capacità di Claude di accedere alle chat del progetto in cui viene interrogato, per questa modalità conviene partire con una nuova conversazione all’interno del progetto che si vuole analizzare, chiedendo di analizzare le richieste fatte nelle altre conversazioni di quel progetto. In questo modo i risultati si basano su un insieme di dati decisamente superiore e vario.

Come chiedere l’analisi

Il momento migliore per chiedere l’analisi è la fine di una sessione di lavoro sostanziale, quando il testo della conversazione contiene abbastanza varietà di interazioni. Una sessione dove si è solo chiesto informazioni produce poco materiale utile. Una sessione dove si è costruito qualcosa insieme, con decisioni, errori, correzioni e cambi di direzione, contiene il tipo di materiale su cui l’analisi funziona bene.

La richiesta può essere semplice. Qualcosa come «analizza il mio modo di farti le richieste in questa conversazione, evidenziando sia i punti efficaci che quelli deboli». Non serve una formulazione elaborata perché il materiale su cui l’AI lavora è già nella conversazione. Il valore sta nel chiedere esplicitamente sia i punti di forza che i limiti. Chiedere solo cosa si fa bene produce complimenti generici. Chiedere solo cosa si fa male produce un elenco di errori senza contesto. Chiedere entrambi produce un quadro utile.

Il risultato va interpretato come un dato, non come un giudizio. L’AI non sa se un certo comportamento è intenzionale o automatico, se è una scelta consapevole o un’abitudine. Può dire che in tre occasioni il contesto è arrivato dopo la richiesta e che questo ha richiesto correzioni, ma non sa se in quei casi il contesto non era ancora disponibile al momento della prima richiesta. Quella distinzione spetta a chi legge l’analisi.

Un ultimo punto operativo. Il metodo è ripetibile. Si può rifare dopo qualche settimana per verificare se i pattern sono cambiati. I comportamenti nella comunicazione con le AI tendono a stabilizzarsi, ma non sono immutabili. Un’abitudine segnalata come inefficace può essere corretta e il miglioramento diventa visibile nell’analisi successiva.

Un caso concreto

La sessione da cui è nata l’idea di questo articolo è durata due giorni e ha riguardato lo sviluppo di Agent Discussion Arena, un tool che orchestra discussioni strutturate tra agenti AI. Il progetto è stato realizzato interamente in vibe coding con Claude Code.

A fine sessione ho chiesto a Claude di analizzare il mio modo di fargli le richieste. L’analisi ha identificato alcuni comportamenti efficaci.

Il primo era l’abitudine di testare ogni modifica e riportare il risultato esatto, inclusi log di errore e screenshot della console.

Il secondo era la tendenza a mettere in discussione le proposte con ragionamento pratico.

Il terzo avere in mente l’utente finale anzichè pensare a come l’avrei utilizzato io.

L’analisi ha anche identificato dei limiti. Il più ricorrente era la tendenza a comprimere troppe richieste eterogenee in un singolo messaggio, mescolando bug report, feature request e decisioni strategiche. Un altro era la sequenza in cui arrivavano le informazioni, in più di un’occasione informazioni sui vincoli e sull contesto sono arrivate dopo la richiesta operativa.

Non è prompt engineering, è consapevolezza

Quello che ho descritto potrebbe essere descritto come un metodo per osservarci attraverso gli occhi di un “altro”, partendo da dati concreti. Il testo della conversazione contiene le informazioni, si tratta di fare la domanda giusta.