Perché i prompt migliori nascono alla fine di una conversazione, non all’inizio.
C’è stato un tempo, e non parlo di secoli ma di un paio d’anni appena, in cui la formula magica per ottenere risposte decenti da un modello linguistico cominciava quasi sempre con le stesse quattro parole: “Sei un esperto di…”. Esperto di marketing, di diritto tributario, di pasticceria siciliana, a seconda delle necessità, come se bastasse appuntare un distintivo sul petto del modello per trasformarlo nel professionista desiderato (e, a dire il vero, un po’ funzionava, il che spiega perché quella formula sia sopravvissuta in centinaia di guide, corsi e caroselli su LinkedIn).
Il ruolo era una scorciatoia ragionevole. Diceva al modello quale porzione del suo sapere attivare, con quale registro esprimersi, da quale punto di vista guardare il problema. Il suo limite, però, stava proprio nella sua natura di dichiarazione: affermava una competenza senza costruirla, e lasciava al modello il compito di immaginare che cosa, esattamente, quell’esperto avrebbe dovuto sapere nel caso specifico.
Negli ultimi mesi mi sono accorto che il mio modo di lavorare si è spostato altrove, quasi senza che lo decidessi. I prompt che funzionano davvero, quelli che producono risultati riutilizzabili, oggi li scrivo alla fine di un percorso, non all’inizio. E quel percorso ha un nome che vale la pena di chiarire, perché il settore ne ha appena adottato uno molto simile per indicare tutt’altra cosa.
Che cosa è cambiato nel settore
A fine giugno 2025 Tobi Lütke, CEO di Shopify, ha proposto di sostituire “prompt engineering” con “context engineering”, e pochi giorni dopo Andrej Karpathy ha rilanciato l’idea con l’autorevolezza che gli viene riconosciuta. Il suo argomento, in sostanza: nelle applicazioni serie conta molto più ciò con cui si riempie la finestra di contesto che il modo in cui si formula la richiesta.
A settembre dello stesso anno è arrivata la versione istituzionale. Il team di Applied AI di Anthropic ha pubblicato un lungo articolo tecnico, Effective context engineering for AI agents, che presenta il context engineering come la naturale evoluzione del prompt engineering. Non più soltanto scrivere buone istruzioni, ma curare l’intero stato del contesto: istruzioni di sistema, strumenti, connettori, dati esterni, cronologia dei messaggi. Con un principio guida che merita di essere ricordato: trovare il più piccolo insieme di informazioni ad alto segnale capace di massimizzare la probabilità del risultato desiderato.
Tutto vero, tutto utile. Ma basta scorrere i temi di quell’articolo (recupero dinamico delle informazioni, compattazione della cronologia, note persistenti fuori dalla finestra di contesto, architetture a sub-agenti) per capire a chi si rivolge: a chi costruisce agenti e sistemi, non a chi apre una chat il lunedì mattina per preparare una campagna o una lezione. Il context engineering, nel senso in cui il settore usa il termine, è un mestiere da sviluppatori.
Engineering e design: due mestieri diversi
Propongo allora una distinzione semplice, che il dibattito corrente tende a confondere. Il context engineering progetta i sistemi che riempiono il contesto in modo automatico. Il context design progetta il dialogo con cui il contesto viene costruito, un passaggio alla volta, da chi usa il modello.
Il primo lavora su pipeline, database e regole di selezione, e il suo prodotto è un’architettura. Il secondo lavora su domande, verifiche e correzioni, e il suo prodotto è una comprensione condivisa del problema, che alla fine si può condensare in un prompt. Il primo riguarda poche migliaia di professionisti; il secondo riguarda chiunque usi un modello linguistico per lavoro, cioè, ormai, quasi tutti.
Non si tratta di contrapporre le due cose (chi mi legge da tempo sa quanto diffidi delle dicotomie nette), ma di riconoscere che l’utente evoluto ha bisogno di un nome per ciò che sta già facendo, e che quel nome non può essere preso in prestito da un manuale per ingegneri.
Il metodo: dal ruolo dichiarato alla competenza costruita
Il context design, in fondo, è ciò che resta del vecchio ruolo quando si smette di dichiararlo e si comincia a costruirlo. Invece di scrivere “Sei un esperto di comunicazione visiva”, si porta il modello a “diventarlo”, per quel compito specifico, attraverso una conversazione.
Prendiamo un caso che mi capita spesso: preparare un meta-prompt, cioè un prompt che genera altri prompt, per esempio uno che serva a produrre immagini efficaci in ambito marketing. L’approccio classico consisterebbe nello scriverlo subito, elencando stile, formato e qualche aggettivo ben scelto. Il mio, oggi, parte da tutt’altra parte. Prima chiedo al modello quali caratteristiche rendono efficace un’immagine pubblicitaria, poi discuto le sue risposte, le correggo dove sono generiche, le specifico dove restano vaghe. Composizione, gerarchia visiva, rapporto tra immagine e testo, coerenza con il marchio, differenze tra un post social e un manifesto: ogni punto diventa oggetto di domande, verifiche e chiarimenti, spesso posti dal modello stesso.
Solo verso la fine allego alcuni esempi di immagini pubblicitarie celebri e chiedo che siano analizzate nell’ottica di quanto discusso. L’ordine non è casuale. Gli esempi mostrati all’inizio orientano tutto il resto e tendono a essere imitati; mostrati alla fine, quando i criteri sono già definiti, servono invece a metterli alla prova e a raffinarli. A quel punto, e soltanto a quel punto, chiedo di scrivere il meta-prompt. Che a volte può risultare anche più breve di quanto ci si aspetterebbe, ma in ogni caso molto più preciso di un prompt “progettato a mano da zero”.
Lo stesso schema funziona per una scaletta di corso, per la revisione di un capitolo, per l’analisi di un mercato. Cambia la materia, non la sequenza: prima si costruisce la competenza, poi la si mette per iscritto.
Perché funziona
Il primo meccanismo riguarda l’implicito. Quando scriviamo un prompt a freddo omettiamo proprio le informazioni che per noi sono ovvie, e che per il modello non lo sono affatto. Le domande del modello fanno emergere questi vuoti meglio di qualsiasi autoanalisi, perché arrivano da chi, letteralmente, non sa ciò che noi invece diamo per scontato.
Il secondo riguarda i punti fermi. Ogni verifica superata, ogni definizione concordata, ogni correzione accettata diventa un pezzo di terreno comune su cui il resto del lavoro può appoggiarsi senza bisogno di ripetere tutto da capo. È la stessa differenza che passa tra spiegare un progetto a un collaboratore nuovo e discuterne con qualcuno che aveva partecipato alla riunione precedente.
Il terzo riguarda la compressione. Il prompt finale funziona così bene perché è il distillato di tutto il lavoro precedente, ed è per questo che può anche essere composto da poche righe che rimandano a un contesto ricco, già costruito e già verificato. In questo caso è corto non perché sia semplice, ma perché tutto il resto è già stato discusso e infine sintetizzato.
Le due trappole
La prima è il contesto “contaminato”. Ciò che il modello scrive durante la conversazione entra a far parte del contesto, compresi gli errori, le approssimazioni e le generalizzazioni sbrigative. Una verifica sbagliata lasciata passare non resta isolata: orienta le risposte successive e finisce, puntualmente, nel prompt finale. Il context design richiede quindi una lettura attenta di ogni passaggio, e la disponibilità a correggere subito anche ciò che sembra un dettaglio.
Il rimedio più efficace che ho trovato è anche il più semplice: prima di chiedere il prompt, chiedo un recap. Il modello riassume ciò che è stato stabilito durante la conversazione, distinguendo quanto è stato effettivamente confermato da quanto è rimasto un’ipotesi, una sua proposta mai discussa o un punto lasciato in sospeso. Io lo rileggo, correggo ciò che non torna, elimino ciò che non avevo mai approvato, e solo allora chiedo di distillare il prompt da quel recap, non dall’intera conversazione. È un passaggio che costa due minuti e che fa da filtro: nel prompt finale entra soltanto ciò che ha superato la discussione, non tutto ciò che vi è stato detto.
La seconda è la portabilità. Un prompt eccellente dentro la conversazione che lo ha generato può risultare mediocre se lo si incolla in una sessione nuova, perché la sua efficacia dipendeva da tutto ciò che lo precedeva. Se lo si vuole riutilizzare bisogna fare un ultimo passaggio, il più trascurato: chiedere al modello di rendere esplicito nel prompt ciò che nella conversazione era rimasto implicito, e poi verificarlo in una chat pulita. Qui il recap torna utile una seconda volta: un prompt distillato da un riepilogo già esplicito e già controllato ha molto meno implicito da recuperare, e sopravvive meglio al trasloco in una conversazione nuova.
Il prompt come distillato
Il prompt design, dunque, non è morto, nonostante i necrologi che circolano da un anno a questa parte. Ha soltanto cambiato posizione: prima era l’intero lavoro, oggi è il momento conclusivo di un lavoro più ampio, quello in cui la conversazione si condensa in uno strumento.
E gli strumenti, a differenza delle conversazioni, si conservano. Il meta-prompt per le immagini di marketing, una volta reso esplicito e verificato, diventa un modello riutilizzabile, una skill, una parte del proprio metodo di lavoro. Il vecchio “Sei un esperto di…” chiedeva al modello di fingere una competenza; il context design gliela fa costruire, e poi la consegna a noi in una forma che possiamo usare ancora, e ancora.
Fonti
- Anthropic, Effective context engineering for AI agents, 29 settembre 2025
- Interventi di Tobi Lütke e Andrej Karpathy su X, fine giugno 2025.
P.S. Durante la stesura cooperativa di questo articolo Claude ha attivato la nuova modalità Claude Docs, che essendo ancora in beta non credo sia stata resa accessibile a tutti gli utenti. Rispetto a quanto già avevamo visto con le modalità di editing nei documenti prodotti sia in Claude sia in ChatGPT e Gemini (Artifact, Canvas ,ecc.) in questo caso l’IA partecipa attivamente e non solo se “interpellata”. Vi lascio qui sotto tre screenshot che ho catturato durante la sessione.
