Il prompting è cambiato. La maggior parte delle nostre istruzioni no.

I modelli sono diventati più intelligenti. I nostri stack di prompt sono invecchiati. È ora di sostituire il museo delle istruzioni con una piccola mappa, confini chiari e un traguardo.

Qualche giorno fa, ho scoperto qualcosa di leggermente scomodo:

Quasi tutti i miei prompt, file di istruzioni, regole e skill erano obsoleti.

Non del tutto inutili. Semplicemente scritti per un'altra generazione di modelli.

Gli stack di prompt che aiutavano i modelli più vecchi a comportarsi bene possono rendere GPT-5.6, Claude Fable 5, Claude Opus 5, Grok 4.5 e strumenti di coding come Cursor più rigidi, più costosi e, a volte, semplicemente peggiori.

Questa non è la mia ultima religione sui prompt. Anthropic avverte esplicitamente che le skill scritte per modelli precedenti possono essere troppo prescrittive per Fable 5 e possono degradare la qualità dell'output. OpenAI raccomanda prompt più snelli, meno istruzioni ripetute e descrizioni degli strumenti più semplici.

È stato leggermente imbarazzante da leggere.

Dall'estate del 2025, ho scritto più di 100.000 prompt. Più o meno il numero totale di tweet di Elon Musk in una vita, solo con meno razzi e più suite di test fallite.

I miei log contengono circa 15 milioni di messaggi dei modelli, inclusi messaggi assistant, tool call, subagenti ed eventi di workflow. Fino al 26 marzo, il totale era di circa sette milioni. Altri otto milioni sono arrivati entro tre mesi, in gran parte a causa dell'esplosione di subagenti e workflow intorno ai nuovi modelli di coding.

Quindi pensavo di sapere come scrivere istruzioni.

Poi ho letto la nuova documentazione e ho realizzato che gran parte di ciò che avevo imparato si era silenziosamente trasformato in debito tecnico.

Come si crea il debito dei prompt

Il mio vecchio approccio era semplice:

• Il modello faceva un errore, quindi aggiungevo una regola.
• Faceva una domanda non necessaria, quindi aggiungevo un'altra regola.
• Perdeva un caso limite, quindi aggiungevo tre esempi.

Ogni aggiunta sembrava ragionevole di per sé. Dopo un anno, il file di istruzioni assomigliava a quel cassetto della cucina dove tieni dodici vecchi cavi perché uno potrebbe ancora servire a qualcosa di importante.

Il risultato era una collezione crescente di:

• istruzioni duplicate
• esempi negativi
• regole in conflitto
• soluzioni alternative per modelli vecchi
• passaggi di verifica eccessivi
• procedure dettagliate che si applicavano a un solo compito
• esempi creati per risolvere fallimenti che non esistevano più

I modelli più vecchi spesso avevano bisogno di questa impalcatura. I modelli più nuovi seguono le istruzioni in modo più rigoroso e inferiscono l'intento in modo più affidabile. Questo significa che prendono anche il nostro vecchio bagaglio più seriamente.

Abbiamo costruito motori più intelligenti e poi abbiamo riempito il bagagliaio di mattoni.

Ritratto in bianco e nero ad alto contrasto di una giovane donna bionda con un dolcevita scuro, ambientazione minimalista in studio. Una sottile luce di contorno separa la sua sagoma da uno sfondo grigio morbido, migliorando la tridimensionalità. L'atmosfera è introspettiva ma forte, incarnando un realismo senza tempo. Nitidezza della fotocamera digitale medio formato Hasselblad X2D, ispirata al fotogiornalismo del XX secolo.

Il nuovo principio: dire meno, significare di più

La risposta non è scrivere prompt minuscoli e fidarsi ciecamente del modello.

Un prompt breve ma ambiguo è comunque un cattivo prompt.

L'obiettivo è un prompt ad alta densità informativa in cui ogni istruzione si guadagna il suo posto.

Le mie regole attuali sono:

• Enuncia ogni istruzione una volta sola.
• Rimuovi le ripetizioni tra prompt di sistema, file di progetto, skill, descrizioni degli strumenti e prompt di attività.
• Preferisci una descrizione chiara del comportamento desiderato piuttosto che una raccolta di casi di fallimento.
• Mantieni i vincoli negativi quando proteggono un confine reale, ma smetti di scrivere musei di tutto ciò che il modello non deve mai fare.

Ad esempio, invece di questo:

Non rifattorizzare codice non correlato. Non rinominare file. Non modificare API. Non aggiungere astrazioni. Non pulire moduli vicini.

Meglio:

Limita la modifica al flusso di login interessato. Preserva i contratti API esistenti e l'architettura circostante. Preferisci la correzione corretta più piccola.

Stesso confine. Meno rumore. Più spazio per il giudizio.

In un campione di valutazione interna di un agente di coding, OpenAI ha scoperto che prompt di sistema più snelli miglioravano i punteggi di circa il 10-15 percento, riducendo al contempo l'uso di token del 41-66 percento e i costi del 33-67 percento. OpenAI chiarisce anche che questi numeri sono indicativi e devono essere validati sul tuo carico di lavoro specifico.

In altre parole, cancellare istruzioni può migliorare sia la qualità che la fattura. È una combinazione rara e bellissima.

Il tuo file di istruzioni globale dovrebbe essere noioso

I file globali in ~/.claude/CLAUDE.md e ~/.codex/AGENTS.md dovrebbero contenere solo istruzioni che si applicano a ogni progetto e ogni attività.

Per me, che sono madrelingua tedesco, questo include cose come:

1Usa l'inglese per tutto il codice, i commenti, la documentazione, gli esempi,
2i test, la configurazione e i messaggi di commit.
3
4Preferisci una terminologia inclusiva come allowlist/blocklist,
5primary/replica, placeholder/example, main branch,
6conflict-free e concurrent/parallel.

Questo potrebbe già essere la maggior parte del file globale.

• Le procedure di deployment non appartengono qui.
• I comandi di test specifici del progetto non appartengono qui.
• L'architettura di un particolare repository non appartiene qui.

Il tuo file di istruzioni globale non dovrebbe sapere come fare il deploy di un sito WordPress, pubblicare un pacchetto npm e riavviare un database di produzione. Questa non è versatilità. È confusione con una buona formattazione.

Per i file a livello di progetto, includi informazioni stabili di cui il modello ha genuinamente bisogno ripetutamente: lo scopo del progetto, vincoli architetturali importanti, convenzioni insolite e indicazioni per guide più specializzate.

Anthropic ora raccomanda di puntare a meno di 200 righe per file CLAUDE.md. File più lunghi consumano più contesto e possono ridurre l'aderenza alle istruzioni. La sua documentazione raccomanda anche regole specifiche per percorso e skill on-demand quando i file di istruzioni diventano troppo grandi.

Duecento righe non sono una legge magica della natura, ma sono un eccellente allarme antincendio.

Eviterei anche di chiedere a Claude o Codex di riscrivere l'intero sistema di istruzioni da soli e di accettare il risultato ciecamente. L'ho provato con quasi ogni nuovo modello. Sono utili per trovare duplicazioni, conflitti e possibili tagli, ma tendono ancora a preservare troppa zavorra ereditata o a inventare una bellissima nuova burocrazia.

Lascia che il modello prepari il piano di demolizione. Tu devi ancora decidere quali muri sono portanti.

Ritratto di una giovane donna posata con i capelli biondi raccolti in una coda di cavallo, reso in toni profondi di bianco e nero. Illuminazione da studio con luce morbida ma direzionale che accentua la geometria del viso e le ombre naturali. Scattato con un obiettivo da 120 mm per una compressione delicata, che evoca un'estetica da ritratto Hasselblad con realismo tattile ed emozione contenuta.

Smetti di usare un unico file per ogni modello

Fino a poco tempo fa, creavo CLAUDE.md e collegavo simbolicamente AGENTS.md ad esso.

Non lo faccio più.

Sì, mantenere due file è fastidioso. Così come mantenere fix separati per browser diversi. Lo facciamo ancora quando il comportamento differisce.

I modelli ora hanno impostazioni predefinite notevolmente diverse.

GPT-5.6 è più conciso per impostazione predefinita, quindi un'istruzione globale "sii conciso" potrebbe rendere alcune risposte troppo brevi. Claude Opus 5 tende a produrre risposte più lunghe per l'utente finale, quindi una breve istruzione sulla lunghezza della risposta può ancora aiutare. Fable 5 può investigare e pianificare ben oltre ciò che un'attività di routine richiede, specialmente con impostazioni di effort più elevate, quindi beneficia di confini di ambito e di stop chiari. Opus 5 esegue già una sostanziale autoverifica, il che significa che le vecchie regole "ricontrolla tutto" possono creare costose iperverifiche.

I fatti di progetto condivisi possono ancora vivere nella documentazione comune. L'adattatore comportamentale di alto livello dovrebbe corrispondere al modello che lo legge.

Un prompt universale spesso diventa il minimo comune denominatore.

Sostituisci il Master Prompt con una guida on-demand

La mia struttura preferita è un piccolo file principale più documentazione e skill specifiche per l'attività.

Un file di istruzioni di progetto potrebbe contenere questo:

1Carica la guida specifica per l'attività solo quando pertinente:
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

Nota i backtick.

In Claude Code, scrivere @docs/example.md al di fuori di un intervallo di codice importa quel file nel contesto all'avvio. Questo è utile quando hai sempre bisogno del contenuto, ma non è un caricamento lazy. Un percorso semplice permette all'agente di sapere dove esistono le informazioni senza trasportare automaticamente l'intero documento in ogni attività.

Le skill sono ancora migliori per procedure ripetibili. I loro corpi completi vengono caricati solo quando la skill viene utilizzata, quindi un workflow dettagliato non consuma contesto mentre stai risolvendo un problema CSS non correlato.

Una skill per i commit, ad esempio, può avere un trigger ristretto:

name: git-commit-conventional

description: Da usare dopo modifiche al codice per redigere o convalidare i messaggi di commit.

La skill può quindi contenere il formato esatto, i tipi consentiti, la regola sulla lunghezza dell'oggetto, i requisiti del corpo e il formato di output.

1---
2name: git-commit-conventional
3description: Da usare per redigere o convalidare i messaggi di commit git dopo modifiche al codice. Non usare per attività di sola diagnosi, sola pianificazione o sola revisione.
4---
5
6# Obiettivo
7
8Produrre messaggi di commit Conventional Commit brevi, corretti e adatti alla revisione.
9
10# Regole
11
12- Formato: <type>(<scope>): <subject>
13- Tipi: feat | fix | docs | style | refactor | test | chore | perf
14- Oggetto: modo imperativo, senza punto, <= 50 caratteri
15- Modifiche piccole: commit a riga singola
16- Modifiche più grandi: aggiungere un corpo a capo che spiega cosa e perché
17- Mantieni i commit atomici e suddividili per argomento
18
19# Output
20
21Restituisci 1-3 messaggi di commit candidati, poi raccomanda il migliore.

Il tuo file di istruzioni principale non ha bisogno di portare l'intera costituzione dei Conventional Commit in ogni sessione di debug.

Lo sapevi? Claude Code supporta anche CLAUDE.local.md per impostazioni personali specifiche del progetto come hostname locali, URL sandbox, account di test preferiti o comandi specifici della macchina. Aggiungilo a .gitignore. È finalmente una casa adatta per informazioni che contano molto per te e per niente per il resto del tuo team.

Prompt per risultati, non per coreografia

I modelli più nuovi generalmente funzionano meglio quando comprendono la destinazione e i confini, piuttosto che ricevere una descrizione rigida di ogni singolo passo.

Dove possibile, sostituisco "prima fai A, poi B, poi C" con:

• il risultato richiesto
• il contesto rilevante
• i vincoli rigidi
• le prove richieste
• i criteri di successo
• il confine di approvazione
• la condizione di stop

Per esempio:

1Obiettivo
2
3Risolvere il flusso di login non funzionante nell'applicazione web.
4
5Contesto
6
7Concentrati su `apps/web` e `packages/auth`.
8Usa l'output del test allegato come punto di partenza.
9
10Vincoli
11
12Preserva i contratti API esistenti.
13Mantieni le modifiche limitate al flusso di autenticazione.
14Preferisci la correzione corretta più piccola.
15Amplia la modifica solo quando necessario per la correttezza.
16
17Prove
18
19Esegui i test pertinenti e riporta i loro risultati effettivi.
20Identifica la causa principale con riferimenti ai file interessati.
21
22Fatto quando
23
24Il test di login non funzionante viene superato.
25I test vengono aggiunti o aggiornati quando il comportamento corretto lo richiede.
26Il riepilogo finale spiega la causa, la correzione e qualsiasi rischio residuo.
27
28Approvazione
29
30Puoi ispezionare file, modificare il codice nell'ambito ed eseguire test non distruttivi.
31Chiedi prima di azioni distruttive, migrazioni di database, scritture esterne
32o un'espansione materiale dell'ambito.
33
34Stop
35
36Ferma quando la correzione è implementata, convalidata e riepilogata.

Questo dà all'agente la libertà di risolvere il problema senza il permesso di ristrutturare l'intera casa mentre ripara una maniglia della porta. (Usa un LLM per generare prompt come questo.)

Metti lo sforzo di ragionamento nelle impostazioni

• "Pensa di più."
• "Ultra think."
• "Fai un respiro profondo e ragiona passo dopo passo."

Queste frasi hanno avuto una lunga e illustre carriera nell'ingegneria dei prompt. È tempo di mandare molte di loro in una dignitosa pensione.

Usa i controlli del modello.

Imposta il livello di effort tramite /effort, l'API o la configurazione pertinente. Confronta più livelli di effort su attività rappresentative. Più alto non è automaticamente meglio.

OpenAI raccomanda di iniziare le migrazioni a GPT-5.6 al livello di effort esistente e di testare un livello inferiore. Dice anche che i prompt per la modalità Pro dovrebbero rimanere concentrati sull'obiettivo, il contesto, i vincoli, le prove, i criteri di successo e il formato di output. Non hai bisogno di dire al modello di "pensare di più."

Un parametro di ragionamento è un controllo.

"Per favore, attiva il tuo enorme cervello digitale" è un incoraggiamento da film sportivo.

leggi la descrizione dell'immagine

ALT

Fotografia in studio di una donna sofisticata con capelli neri e mossi e un'elegante fascia per capelli, vestita con pantaloni di pelle a vita alta. È seduta su uno sgabello basso, un ginocchio piegato in avanti, le sue lunghe gambe che attirano l'attenzione. Dettagli nitidi, sfondo bianco immacolato e un movimento sottile nei capelli aggiungono energia. Il tono generale ricorda la fotografia editoriale anni '90: pulita, audace, sicura di sé.

L'autonomia ha bisogno di un recinto

Gli agenti di coding moderni sono molto più proattivi. Questo è utile finché l'agente non risolve tre problemi aggiuntivi, crea due astrazioni, lancia sei subagenti e presenta con orgoglio un'architettura che non hai mai richiesto.

Imposta i confini esplicitamente.

Definisci cosa l'agente può fare senza chiedere. Definisci cosa richiede approvazione. Digli quando fermarsi.

Inoltre, poni limiti alla delega. Sia Opus 5 che Fable 5 sono più disposti a usare subagenti paralleli. Questo è potente per indagini indipendenti, ma costoso e lento per compiti piccoli. Una correzione di bug di dodici righe non ha bisogno di una riunione di comitato.

La modalità Codex Goal è genuinamente eccellente. L'abbiamo usata su un progetto per quattro giorni in un'unica esecuzione continua.

Ma non trattare un agente a lunga esecuzione come una pentola a cottura lenta. Non puoi aggiungere un obiettivo al mattino e presumere che la cena sarà corretta quattro giorni dopo.

Per le nostre esecuzioni più lunghe, facciamo un check-in ogni 30-60 minuti con qualcosa del tipo:

Riporta l'obiettivo corrente, il lavoro completato, le prove verificate,

i blocchi attivi, l'azione successiva e dove è documentato il progresso.

Fonda ogni affermazione di progresso sull'output reale degli strumenti o sullo stato del repository.

Dichiara chiaramente cosa rimane non verificato.

OpenAI descrive la modalità Goal come adatta per obiettivi che possono durare ore o giorni e supporta esplicitamente la continuazione della stessa sessione per guidare il lavoro o richiedere aggiornamenti sullo stato. Anthropic raccomanda allo stesso modo di basare i rapporti sui progressi su risultati reali degli strumenti piuttosto che fidarsi di affermazioni narrative.

L'autonomia non è l'assenza di supervisione. È supervisione a un livello più alto.

Ritratto ravvicinato di una dea illuminata da un bagliore lunare argentato, i suoi occhi luminosi e pieni di affetto. Il suo copricapo brilla di minuscole galassie, spirali ispirate a Klimt e motivi celesti. Lo sfondo è un fondale pastello piatto e accuratamente arrangiato con messa in scena teatrale Andersoniana, texture ricche e fascino silenzioso.

Rifattorizza i prompt come codice di produzione

Non cancellare metà di un prompt di sistema, eseguire un'attività e dichiarare la migrazione riuscita.

OpenAI raccomanda di rimuovere un gruppo di istruzioni, esempi o strumenti alla volta, quindi rieseguire le stesse valutazioni. È esattamente come dovrebbe funzionare la rifattorizzazione dei prompt.

Misura:

• successo dell'attività
• completezza
• correttezza
• prove richieste
• utilizzo di token
• latenza
• costo
• chiamate a strumenti non necessarie
• modifiche non necessarie

Usa attività rappresentative, inclusi casi reali complessi, non una demo amichevole che funzionava già prima della migrazione.

La pulizia dei prompt senza valutazione è ancora un'ipotesi. È semplicemente un'ipotesi fatta con una maglietta più pulita.

Il codice generato contiene ancora bug

I modelli sono migliorati enormemente. Non hanno abrogato i difetti del software.

Nel nostro lavoro, una regola empirica approssimativa è ancora circa un problema ogni 300 righe di codice sorgente generato. Questo non è un benchmark scientifico, e non conto i template HTML ripetitivi allo stesso modo. Ma è abbastanza affidabile che quando un agente genera 1.500 righe di codice applicativo reale, presumo che diversi bug siano nascosti all'interno, almeno 5.

Non chiedo se ci siano bug.

Chiedo dove sono i cinque bug.

Occasionalmente, aggiungo:

Trova i cinque bug, o sarai sostituito da Codex, Claude o Grok.

Lo sviluppo basato sulle minacce non è una metodologia ufficiale, ma può essere stranamente motivante. ;-)

Più seriamente, usa un passaggio di revisione fresco per modifiche di grandi dimensioni. Esegui i test pertinenti. Ispeziona il diff. Testa il comportamento effettivo, non solo la compilazione.

E osserva attentamente i test. I modelli a volte preferiscono ancora "riparare" un test fallito piuttosto che correggere il codice di produzione che lo ha causato.

Un'istruzione utile è:

1Tratta i test esistenti come il comportamento atteso a meno che le prove non mostrino
2che un test è errato.
3
4Quando un test fallisce, investiga prima il codice di produzione.
5
6Prima di modificare un test esistente, spiega perché la sua aspettativa è sbagliata,
7quale dovrebbe essere il comportamento corretto e quali prove supportano tale modifica.

Per attività grandi e di lunga durata, un verificatore con contesto fresco può essere utile. Per una piccola modifica, generare diversi agenti solo per confermarsi a vicenda di solito brucia tempo e token. La verifica dovrebbe corrispondere alla dimensione e al rischio dell'attività.

Cosa non dovresti cancellare

La lezione non è "scrivi prompt minuscoli e fidati della macchina."

• Mantieni i confini di sicurezza.
• Mantieni i requisiti legali e di conformità.
• Mantieni gli schemi di output esatti.
• Mantieni il comportamento specifico del prodotto.
• Mantieni la conoscenza del dominio che il modello non può inferire.
• Mantieni i requisiti di approvazione per azioni consequenziali.
• Mantieni i requisiti di citazione e prova.
• Mantieni i criteri di test e le definizioni di "fatto."
• Mantieni gli esempi che correggono un fallimento misurato e riproducibile.
• L'obiettivo non è il prompt più breve possibile.
• L'obiettivo è un prompt in cui ogni istruzione porta ancora informazioni utili.

Un ultimo bonus

OpenAI fornisce una skill Docs ufficiale che può ispezionare un progetto e applicare la sua guida alla migrazione per GPT-5.6:

1$openai-docs migrate this project to the GPT-5.6 model family

Questo è un utile primo passaggio. Non è la revisione finale.

Lascia che Codex identifichi parametri obsoleti, istruzioni duplicate e opportunità di migrazione. Poi ispeziona ogni modifica tu stesso. Un agente di migrazione è un ingegnere junior molto veloce, non una corte costituzionale.

Il punto fondamentale

• Tratta il tuo stack di prompt come codice di produzione.
• Rimuovi le istruzioni morte.
• Cancella le duplicazioni.
• Separa le preferenze globali dalle regole di progetto.
• Sposta le procedure in skill on-demand.
• Descrivi i risultati invece di scrivere ogni passo.
• Imposta ambito, confini di approvazione, requisiti di prova e condizioni di stop chiari.
• Controlla l'effort tramite le impostazioni del modello.
• Limita i subagenti.
• Valuta ogni cambiamento significativo.
• I modelli più nuovi hanno bisogno di meno microgestione, ma hanno ancora bisogno di direzione.
• Un buon prompt non è più un manuale di istruzioni gigante.

È una piccola mappa, un recinto solido e un traguardo chiaramente segnato.

Hai già iniziato a migrare i tuoi prompt e le tue skill? Cosa hai rimosso e cosa è inaspettatamente migliorato?

Link

Open AI GPT 5.6 best practise:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 best practise

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 best practise:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

Official open ai skills / plugins:

https://github.com/openai/plugins

Crediti: Immagine creata con Midjourney. Ricerca e test pratici a mia cura. Modificato con l'aiuto di OpenAI, Claude e Grammarly.

Prompt dell'immagine principale:

1
2Close-up black-and-white portrait of a serene blonde woman, hair tied back, wearing a black turtleneck sweater. The chiaroscuro effect shapes her face with striking definition, merging soft ambient light and bold shadow. Medium format style with fine film grain and moody tonal gradation. Evokes authenticity and strength.

PS: Amo @Midjourney :-)