Prompt Engineering nel 2026: 10 Tecniche Che Funzionano Ancora (e 4 Morte con i Reasoning Model)

Prompt Engineering nel 2026: 10 Tecniche Che Funzionano Ancora (e 4 Morte con i Reasoning Model)

Il prompt engineering non è morto nel 2026. Si è diviso in due. La documentazione ufficiale di OpenAI sul reasoning ora dice esplicitamente di smettere di scrivere «pensa passo dopo passo», e un paper arXiv del 2024 (2410.21333) ha misurato un calo di accuratezza fino al 36,3% quando il chain-of-thought viene forzato sul task sbagliato. Ecco la parte strana: la metà casual del prompt engineering è diventata più facile, mentre la metà da produzione, quella che va in produzione su GPT-5 e Claude, è diventata molto più rigorosa. Questa guida separa le 10 tecniche che valgono ancora il tuo tempo dalle 4 abitudini che i reasoning model hanno mandato in pensione.

Punti chiave:

• Nel 2026 il prompt engineering si è diviso in prompting casual (più facile) e prompting da produzione (più rigoroso).
• Sui reasoning model, forzare «pensa passo dopo passo» è ridondante e può ridurre l'accuratezza. OpenAI consiglia di evitarlo.
• Quattro abitudini in pensione: CoT forzato, few-shot pesante per riflesso, response prefilling e tuning manuale di budget_tokens.
• Cosa vince ancora: chiarezza, structured outputs, task decomposition e iterazione guidata dalla valutazione.

Cos'è Davvero il Prompt Engineering nel 2026

Il prompt engineering è la pratica di progettare e perfezionare le istruzioni che dai a un modello linguistico di grandi dimensioni per ottenere output accurati e pertinenti. Le tecniche principali includono zero-shot, few-shot, chain-of-thought e role prompting. Nel 2026 si divide in due mestieri: il prompting casual in chat e il prompting da produzione dentro un sistema.

Ecco la cosa che nessuno ha detto ad alta voce fino a quest'anno: sono due competenze diverse. Ottenere una buona risposta da ChatGPT oggi è quasi banale, perché i modelli perdonano una formulazione sciatta. Ottenere una risposta affidabile da un sistema che gira mille volte al giorno, in dieci lingue, senza nessuno che lo controlli, non lo è affatto. Questa guida parla proprio di quel secondo mestiere.

Scriviamo per la fascia di produzione: sviluppatori e AI engineer che hanno bisogno di istruzioni che reggano su GPT-5, Claude Opus 4.8 e Gemini. L'introduzione, questa definizione e le FAQ restano leggibili per chiunque altro. Se cerchi la tassonomia neutra di ogni tecnica con nome, il riferimento promptingguide.ai di dair-ai resta la migliore enciclopedia del web. Nel 2026 il prompt engineering non è una sola competenza. Sono due.

Prompt Engineering vs Context Engineering: Qual È la Differenza?

Il prompt engineering riguarda la creazione dell'istruzione. Il context engineering riguarda la progettazione di tutto ciò che entra nella finestra di contesto attorno ad essa: retrieval, memoria, tool, ordinamento. Il prompt engineering è un sottoinsieme del context engineering. Questa guida copre la metà legata alla creazione del prompt; la guida collegata copre il resto.

Quindi di quale hai bisogno? Se il tuo contesto è statico e sta in un solo messaggio, il prompt engineering ti basta. Nel momento in cui il tuo input cambia a ogni richiesta, sei già entrato nel context engineering, e il prompt engineering diventa solo uno strumento al suo interno. Abbiamo tracciato il quadro completo nella nostra guida completa al context engineering; questo articolo resta sul lato della creazione del prompt.

Una nota per chi colleziona entità: il completamento automatico di Google sta ormai allargando questo tema in una suddivisione a quattro discipline di engineering, e noi trattiamo le prime due, prompt e context. In parole semplici: il prompt engineering è scegliere le parole giuste per la domanda; il context engineering è decidere cosa c'è sulla scrivania prima ancora che la domanda venga posta.

Le 10 Tecniche Fondamentali di Prompt Crafting (in Ordine di ROI nel 2026)

Le dieci tecniche che vale la pena conoscere nel 2026, ordinate approssimativamente per ritorno sullo sforzo: zero-shot, few-shot, role prompting, chain-of-thought, task decomposition, prompt chaining, self-consistency, structured outputs, prompt template e meta-prompting. Alcune sono il pane quotidiano; due si comportano diversamente sui reasoning model, ed è quello che chiarisce la prossima sezione.

I nomi qui sotto seguono la tassonomia di "The Prompt Report", una rassegna sistematica di oltre 50 tecniche di prompting. Considerala una cassetta degli attrezzi da cui pescare, non una checklist da seguire dall'inizio alla fine.

1. Zero-shot prompting

Zero-shot significa dare un'istruzione chiara senza esempi, lasciando che sia il modello a capire da solo cosa fare. Sui modelli del 2026 è la tua prima mossa di default, perché un'istruzione precisa e specifica batte quasi sempre un'istruzione confusa. Il trucco non è una formulazione magica, è eliminare l'ambiguità: dì che output vuoi, in che formato, per chi.

# Target: GPT-5 / Claude Opus 4.8
Classify this support ticket as: billing, technical, or account.
Return only the single lowercase label.

Ticket: "My card was charged twice this month."

2. Few-shot prompting

Few-shot significa includere da due a cinque esempi per plasmare il formato o il comportamento che vuoi ottenere. È il modo più rapido per bloccare uno stile di output da cui il modello continua a deviare. Un avvertimento: sui reasoning model, le best practice di reasoning di OpenAI dicono di provare prima con zero-shot e aggiungere esempi solo se aiutano in modo misurabile. Sui modelli del 2026, zero-shot è il default e few-shot è il ripiego, non il contrario.

# Target: GPT-5
Extract the product and sentiment. Follow the examples.

Input: "The battery dies in an hour." -> product: battery, sentiment: negative
Input: "Setup took two minutes, loved it." -> product: setup, sentiment: positive
Input: "The screen is gorgeous but it's heavy." ->

3. Role / persona prompting

Il role prompting definisce chi è il modello prima che risponda, e questo plasma tono, vocabolario e formato più di quanto plasmi il ragionamento puro. «Sei un commercialista senior che rivede una dichiarazione dei redditi» produce un linguaggio diverso rispetto a un prompt vuoto. Tienilo funzionale, non teatrale. Il ruolo dovrebbe codificare vincoli reali: pubblico, formato, cosa omettere. La nostra futura raccolta di esempi di system prompt riunirà i pattern che riutilizziamo più spesso.

# Target: Claude Opus 4.8
You are a senior tax accountant. Review the figures below for a
small-business owner who is not an accountant.
Format: 3 bullet points, plain English, flag any number that looks wrong.

4. Chain-of-thought (CoT)

Il chain-of-thought chiede al modello di mostrare i suoi passaggi di ragionamento prima della risposta finale. Sui modelli GPT classici resta uno dei trucchi a più alto valore per matematica, logica e problemi multi-step. Ma sui reasoning model può essere ridondante o addirittura dannoso, ed è quello che copre la prossima sezione con numeri reali. Il nostro futuro approfondimento sul chain-of-thought prompting analizzerà la tecnica per intero. Per ora, ricorda che non è più un riflesso da applicare a tutto.

5. Task decomposition

La task decomposition significa scomporre una richiesta grande in sotto-task ordinati che il modello gestisce uno alla volta. Invece di «scrivi un piano di lancio», chiedi prima il pubblico, poi i canali, poi il calendario. Passaggi più piccoli significano meno punti in cui qualcosa può andare storto, e un debug più semplice quando succede.

# Target: any 2026 model
Task: draft a product launch email.
Work in order and label each step:
1) Identify the audience and their main objection.
2) Write one subject line that answers that objection.
3) Write a 90-word body.
4) End with a single CTA.

6. Prompt chaining

Il prompt chaining fa passare l'output di un prompt come input al prompt successivo. È la decomposizione resa concreta nel codice: il prompt A estrae i fatti chiave, il prompt B scrive una bozza a partire da quei fatti, il prompt C verifica la bozza rispetto a una regola. Ogni anello è semplice, testabile e sostituibile. Quando un passaggio regredisce, sistemi quell'anello invece di dover districare un enorme prompt monolitico.

7. Self-consistency

La self-consistency campiona la stessa domanda più volte e poi prende la risposta di maggioranza. Scambia token per affidabilità sui ragionamenti difficili dove un singolo passaggio è instabile, ma stai pagando da tre a cinque completion per ottenerne una. Sui reasoning model più forti il vantaggio spesso si riduce, quindi riservala ai task davvero ambigui dove avere ragione conta più del conto finale.

8. Output formatting / structured outputs

Gli structured outputs significano vincolare la risposta a uno schema invece di sperare che il modello restituisca un JSON pulito. Questa tecnica si merita una sezione tutta sua più avanti. La versione in una riga: non implorare JSON nel prompt, vincola il modello a uno schema e smetti di tirare a indovinare.

9. Prompt templates & variables

I template trasformano un buon prompt estemporaneo in un asset parametrizzato e riutilizzabile: istruzioni fisse più slot per le parti variabili. È così che i prompt smettono di essere testo ad-hoc e diventano artefatti versionati che puoi testare, il che è proprio la storia della pipeline più avanti. I file di regole di progetto riutilizzabili, come le cursor rules che gli sviluppatori tengono nei loro repository, sono prompt template viventi sotto un altro nome.

10. Meta-prompting

Il meta-prompting consiste nell'usare un modello per scrivere o migliorare il tuo prompt. È diventato il percorso più rapido da una casella vuota a una bozza solida, e ha dati reali a supporto, trattati proprio qui sotto. Versione breve: parti da una bozza migliorata dal modello, poi modificala a mano.

Quali Tecniche di Prompt i Reasoning Model Hanno Reso Facoltative (o Rotto)?

Quattro abitudini che un tempo erano ottimi consigli ora si ritorcono contro di te sui reasoning model come l'o-series di OpenAI, GPT-5 e le thinking mode di Claude: forzare il chain-of-thought esplicito, impilare few-shot pesanti per default, il response prefilling e il tuning manuale di budget_tokens. I reasoning model ragionano già internamente, quindi scrivere i passaggi passo per passo è ridondante, e a volte peggio che ridondante.

Ognuna di queste è morta per un motivo diverso.

Forzare il chain-of-thought. Le best practice di reasoning di OpenAI sono dirette: «Evita i prompt chain-of-thought», perché questi modelli ragionano internamente, quindi dire loro di «pensare passo dopo passo» è «superfluo» e «potrebbe non migliorare le prestazioni (e a volte può persino peggiorarle)». Il paper arXiv 2410.21333 ha messo un numero su questo svantaggio: fino al 36,3% in meno di accuratezza assoluta per o1-preview rispetto a GPT-4o su un task dove il ragionamento deliberato passo dopo passo danneggia davvero il risultato. Un secondo studio, 2412.21187, mostra che i reasoning model sprecano compute su problemi banali. Abbiamo smesso di aggiungere «pensa passo dopo passo» ai prompt dei reasoning model mesi fa, e non è peggiorato nulla.

Few-shot pesante per riflesso. L'indicazione di OpenAI è «mantieni i prompt semplici e diretti» e «prova prima zero-shot, poi few-shot se necessario». Ammucchiare esempi per default ora costa token e può ingabbiare un modello capace. Aggiungi esempi quando aiutano in modo misurabile, non come rituale di riscaldamento.

Response prefilling. Mettere parole in bocca al modello per forzare un formato era un trucco standard. Su Claude 4.6+, Fable 5 e Mythos 5, i turni prefilled dell'assistente non sono più supportati e restituiscono un errore 400, secondo le best practice di prompting di Anthropic. Usa invece gli structured outputs, di cui parla la prossima sezione.

Micromanagement manuale di budget_tokens. Anche impostare a mano un budget di thinking-token è deprecato (restituisce un 400 su Opus 4.7+ e versioni successive). I modelli di Anthropic ora usano l'adaptive thinking, e guidi lo sforzo con il parametro effort invece di scrivere manualmente un numero. OpenAI ha fatto la stessa mossa: i developer message sono i nuovi system message, e lo sforzo di ragionamento è un'impostazione. Il trucco classico, «pensiamo passo dopo passo», adesso, sui reasoning model, è a volte proprio ciò che li peggiora.

Come Ottenere JSON Affidabile da un LLM nel 2026?

Structured outputs vincolati a uno schema, non supplicare nel prompt. Nel 2026 la strada affidabile è dare al modello uno schema JSON e far garantire dall'API un output valido rispetto a quello schema. Scrivere «per favore restituisci JSON» nel prompt è fragile; il vecchio trucco del prefill è stato deprecato. Sia OpenAI che Anthropic offrono una funzionalità di structured outputs proprio per questo.

Perché «per favore restituisci JSON valido» è così fragile? Perché stai chiedendo a un sistema probabilistico di essere perfettamente sintattico sulla parola. Un commento di troppo o una virgola finale e il tuo parser va in errore. Structured Outputs risolve il problema a livello di API: passi uno schema e il modello è vincolato a rispettarlo. Anthropic nota che i modelli più recenti «possono rispettare in modo affidabile schemi complessi quando gli viene chiesto».

Ecco un piccolo schema di risposta realistico per un classificatore di ticket di supporto:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

Passalo agli structured outputs di OpenAI o di Anthropic e otterrai JSON analizzabile ogni volta, senza cicli di retry. Per il pattern completo cross-provider, inclusa la validazione con Pydantic e Zod, guarda la nostra guida su come ottenere JSON affidabile da qualsiasi LLM. Nel 2026 non chiedi JSON a un modello. Lo vincoli a uno schema e smetti di sperare.

Meta-Prompting: Lascia Che il Modello Scriva il Tuo Prompt

Il meta-prompting significa usare un LLM per abbozzare o perfezionare il prompt che userai davvero. È la strada più rapida per passare da un'idea grezza a un prompt funzionante, e lo strumentario è già integrato: il prompt improver di Anthropic e il prompt optimizer di OpenAI riscrivono entrambi la tua bozza seguendo le best practice. Parti dalla versione della macchina, poi modificala a mano.

Funziona davvero o è solo un trucco da salotto? Anthropic ha calcolato i propri numeri: il loro prompt improver ha portato un guadagno di accuratezza del 30% su un test di classificazione multilabel e un'aderenza del 100% al conteggio parole su un task di riassunto, secondo il loro articolo. Il prompt optimizer di OpenAI svolge lo stesso compito.

Il workflow che preferiamo: descrivi il task, lascia che lo strumento produca una prima bozza strutturata, poi rifiniscila a mano per i tuoi dati. Proprio quest'ultima modifica manuale è il motivo per cui i prompt hanno ancora bisogno di una persona e di un test. Il modo più rapido per ottenere un prompt migliore nel 2026 è far riscrivere il tuo al modello, e poi modificarlo. Non fissare una casella vuota.

Cheat Sheet di Prompting per Modello (OpenAI vs Anthropic vs Google)

Stesso lavoro, tre dialetti. OpenAI vuole i developer message e nessun chain-of-thought forzato. Anthropic vuole i tag XML, l'adaptive thinking e il parametro effort. Il Gemini di Google vuole un thinking budget. I reasoning model sono i tuoi pianificatori; i modelli in stile GPT classico sono i tuoi cavalli da lavoro. Abbina la tecnica al livello giusto.

Le differenze sono piccole ma mordono. Su OpenAI, i developer message hanno sostituito il vecchio system message per l'o-series in su, e la documentazione ti allontana dal CoT esplicito. Su Anthropic, i tag XML restano il modo consigliato per strutturare un prompt complesso, e il thinking è adattivo di default. I file di prompt a livello di progetto, come i file CLAUDE.md che i team di sviluppo tengono nei loro repository, contengono gran parte di questo cablaggio specifico per provider. Su Gemini, consegni al modello un thinking budget.

Dal Prompt alla Pipeline: Template, Versioning e Valutazione

In produzione, il prompt engineering smette di riguardare la formulazione e diventa una disciplina empirica. Versioni i prompt come fai col codice, li blocchi con gli eval e aggiungi test di regressione in modo che un cambiamento che rompe silenziosamente l'output venga intercettato prima che gli utenti lo vedano. È qui che il prompt engineering incontra la valutazione, ed è la parte che decide davvero se la tua app funziona.

Ecco come funziona su un sistema reale. Questo blog gira su una content pipeline basata su Claude di 17 sub-agent specializzati, ognuno un ruolo con un prompt separato: un researcher, un brief-creator, un content-writer, un validator, un language-translator, un sanity-publisher, un image-handler e altri ancora. Su tre di queste fasi, brief, writer e validator, applichiamo 8 regole di guardrail anti-detection. Il validator passa ogni bozza al setaccio contro una blocklist di 52 frasi vietate, e un solo riscontro blocca la pubblicazione, supportato da uno script separato di controllo lessicale. Questa pipeline ha pubblicato circa 194 articoli in inglese su 4 siti, ciascuno tradotto fino a 10 lingue da agenti paralleli, uno per lingua.

Niente di tutto questo è nato da una formulazione ingegnosa. È nato dal trattare i prompt come artefatti versionati e bloccati dagli eval, e due incidenti ci hanno insegnato il perché.

Il primo fu un bug sui diacritici. Il nostro prompt di traduzione a volte restituiva ASCII invece di Unicode, così la parola turca «karşılaştırma» tornava come «karsilastirma». Silenzioso, brutto, e facile da non notare su larga scala. La soluzione non fu una frase migliore, fu un'istruzione irrobustita più un gate grep che conta i caratteri nativi e rilancia automaticamente la traduzione se il conteggio arriva a zero. Un test di regressione, su un prompt.

Il secondo fu peggio. Un prompt di ri-traduzione iniziò a coniare slug localizzati leggermente diversi, così il publisher creava un documento completamente nuovo mentre quello vecchio restava online. Questo produsse 54 documenti live duplicati, che fecero scattare le esclusioni per duplicati di Google Search Console. La soluzione fu un guardrail nel prompt che forza il riutilizzo dello slug esistente, più una regola di risoluzione-prima-della-creazione nel publisher.

La lezione ha colpito duro: il prompt che ha pubblicato 194 articoli in dieci lingue non ha vinto per la formulazione. Ha vinto perché un gate grep lo rilanciava nel momento esatto in cui deviava. È la valutazione degli LLM all'opera, ed è per questo che abbiniamo ogni prompt importante a degli strumenti di gestione dei prompt per versionarli e fare rollback. Per un prefisso stabile ripetuto su migliaia di chiamate, lo mettiamo in cache per abbattere i costi. È esattamente il tipo di pipeline prompt-e-eval che costruiamo per i clienti.

Errori Comuni di Prompt Engineering (e le Soluzioni del 2026)

Gli errori costosi nel 2026 non sono refusi. Sono strutturali: istruzioni vaghe, script eccessivi sui reasoning model, pubblicare senza un ciclo di eval, ignorare il comportamento specifico del modello, riempire il prompt quando il vero problema è il contesto, e fidarsi di input non fidati. Ognuno ha una soluzione pulita, e la maggior parte costa solo un po' di attenzione.

Scorri la lista e sii onesto su quali di questi hai commesso:

• Istruzioni vaghe. «Rendilo migliore» non dà al modello nessun bersaglio a cui puntare. Dì cosa intendi per «migliore»: più corto, più amichevole, JSON valido, sotto le 120 parole.
• Script eccessivi sui reasoning model. Forzare «pensa passo dopo passo» su un modello o-series o thinking è l'errore trattato sopra. Lascialo ragionare; alza invece l'effort.
• Nessun ciclo di eval. Se non riesci a dire se una modifica al prompt ha aiutato o danneggiato, stai tirando a indovinare. Aggiungi casi di test e un controllo pass/fail.
• Ignorare il comportamento specifico del modello. Il prompt che vola su GPT-5 potrebbe aver bisogno di tag XML su Claude. Leggi la cheat sheet qui sopra.
• Prompt-stuffing. Stipare sempre più roba in un'unica istruzione quando il vero vuoto è nel retrieval o nella memoria significa che ti serviva context engineering, non un prompt più lungo.
• Fidarsi di input non fidati. I contenuti degli utenti e i documenti recuperati possono nascondere istruzioni. Aggiungi dei guardrail attorno a loro; il nostro futuro approfondimento sul prompt-injection-prevention copre per intero il lato sicurezza.

L'errore di prompt più costoso nel 2026 non è un refuso. È pubblicare senza un eval che avrebbe intercettato la regressione.

Il Prompt Engineering È Morto? Una Risposta Onesta per il 2026

No. Il prompt engineering non è morto, si è biforcato. Il prompting casual è diventato più facile perché i modelli sono diventati più intelligenti e più tolleranti. Il prompting da produzione è diventato più difficile, perché affidabilità, structured outputs e valutazione ora contano più di una formulazione ingegnosa. La parola «engineering» finalmente significa quello che dice.

Allora perché tutti continuano a dichiararlo morto? Perché la metà visibile, digitare una richiesta in ChatGPT, è diventata davvero banale. La metà che non è diventata più facile, pubblicare un prompt che regge su migliaia di chiamate e dieci lingue, non fa notizia. La vera competenza del 2026 non è una frase magica. È la valutazione, la scelta del livello di modello (pianificatore vs cavallo da lavoro) e sapere quando un problema è cresciuto oltre il prompt ed è diventato context engineering. La metà facile è diventata più facile e la metà difficile è diventata più difficile, e solo una delle due finisce sui titoli.

Se c'è un solo punto da portare a casa: 10 tecniche continuano a valere il loro costo, 4 vecchie abitudini ora ti costano care sui reasoning model, e la valutazione è la competenza che separa una demo da un prodotto. Stai costruendo qualcosa in cui i prompt devono reggere in produzione? Richiedi una consulenza gratuita e ti aiuteremo a impostare per primo il ciclo di eval.

Domande Frequenti

Cos'è il prompt engineering nel contesto dell'IA generativa?

Il prompt engineering è la pratica di progettare e perfezionare le istruzioni che dai a un modello linguistico di grandi dimensioni per ottenere un output accurato e pertinente. Copre tecniche come zero-shot, few-shot, chain-of-thought e role prompting. Nel 2026 si divide in prompting casual in chat e prompting rigoroso da produzione dentro un sistema.

Il prompt engineering è morto nel 2026?

No, il prompt engineering non è morto nel 2026, si è biforcato. Il prompting casual è diventato più facile man mano che i modelli sono diventati più tolleranti. Il prompting da produzione è diventato più rigoroso, perché structured outputs, valutazione e affidabilità ora contano più di una formulazione ingegnosa. La competenza non è sparita; è solo che la metà facile ha smesso di aver bisogno di te.

Qual è la differenza tra prompt engineering e context engineering?

Il prompt engineering crea l'istruzione; il context engineering progetta tutto il resto nella finestra di contesto: retrieval, memoria, tool e ordinamento. Il prompt engineering è un sottoinsieme del context engineering. Ti serve il context engineering nel momento in cui i tuoi input cambiano a ogni richiesta, come negli agenti e nei sistemi RAG.

Serve ancora il chain-of-thought prompting con i reasoning model?

Di solito no. Sui reasoning model come l'o-series di OpenAI, GPT-5 e le thinking mode di Claude, forzare «pensa passo dopo passo» è ridondante perché questi modelli ragionano già internamente, e OpenAI dice che può danneggiare le prestazioni. Il chain-of-thought aiuta ancora sui modelli in stile GPT classico, quindi abbina la tecnica al livello giusto.

Il prompt engineering richiede di saper programmare?

No, non per iniziare. Chiunque può scrivere istruzioni chiare e ottenere risposte migliori da ChatGPT o Claude. Ma il prompt engineering da produzione, il versionamento dei prompt, il cablaggio degli structured outputs e la costruzione di cicli di eval, è una disciplina da sviluppatore. La metà casual non richiede codice; quella professionale sì.

Qual è la differenza tra zero-shot e few-shot prompting?

Lo zero-shot prompting dà un'istruzione chiara senza esempi; il few-shot include da due a cinque esempi per plasmare il formato o il comportamento dell'output. Sui modelli del 2026, parti con lo zero-shot perché seguono bene le istruzioni, e aggiungi few-shot solo quando gli esempi migliorano i risultati in modo misurabile. Il few-shot è il ripiego, non il default.

Come faccio a ottenere JSON affidabile da un LLM?

Usa structured outputs vincolati a uno schema, non supplicare nel prompt. Invece di scrivere «per favore restituisci JSON», passa uno schema JSON attraverso la funzionalità Structured Outputs di OpenAI o di Anthropic, che vincola il modello a un output valido e analizzabile. Il vecchio trucco del prefill ora restituisce un errore 400 sui modelli Claude più recenti.

Cos'è il meta-prompting?

Il meta-prompting consiste nell'usare un modello per abbozzare o migliorare il prompt che userai. Strumenti come il prompt improver di Anthropic e il prompt optimizer di OpenAI riscrivono la tua bozza seguendo le best practice; Anthropic ha misurato un guadagno di accuratezza del 30% su un test. Genera una prima bozza, poi modificala a mano per i tuoi dati.

Il prompt engineering è un vero mestiere o lavoro?

Sì, è una competenza reale, anche se il titolo autonomo di «prompt engineer» sta sfumando in ruoli più ampi di AI engineering. I datori di lavoro vogliono persone in grado di creare prompt e progettare eval, structured outputs e pipeline di contesto. Come carriera, è più solida come una delle componenti della cassetta degli attrezzi di un AI engineer.

Come cambia il prompting tra ChatGPT, Claude e Gemini?

Il compito è lo stesso; cambia il dialetto. OpenAI usa i developer message e ti allontana dal chain-of-thought esplicito sui reasoning model. Il Claude di Anthropic preferisce i tag XML, l'adaptive thinking e il parametro effort. Il Gemini di Google usa un thinking budget. I reasoning model sono pianificatori; i modelli in stile GPT classico sono cavalli da lavoro.

Fonti

• OpenAI: Reasoning best practices
• OpenAI: Structured Outputs
• OpenAI: Prompt optimizer
• Anthropic: Claude prompting best practices
• Anthropic: Structured Outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Prompt improver announcement
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)