Il Prompt Engineering è Morto. Lunga Vita alla Prompt Navigation.

Quando ChatGPT è esploso a fine 2022, il prompt engineering è diventato la skill del momento. Faccio una domanda, voglio una risposta. Migliore è la domanda, migliore sarà la risposta.

Questa idea ha avuto lo stesso effetto dell'imprinting su un anatroccolo appena nato. Ha condizionato profondamente il modo in cui pensiamo e usiamo l'AI ancora oggi.

È ora di aggiornarla.

I Cinque Principi (Teaser)

Prima di entrare nel dettaglio, ecco la sintesi di quello che propongo. Se non hai tempo per l'articolo intero, porta a casa questi:

Inizia vago, restringi iterando — non cercare di specificare tutto subito
Verifica prima di procedere — se non puoi verificare, stai andando troppo veloce
Accetta le deviazioni — spesso portano in posti migliori
Il fallimento è informazione — usalo per correggere la rotta
La chiarezza emerge, non si impone — la navigazione stessa ti aiuta a capire cosa vuoi

Ora vediamo il perché.

L'Era dei Framework

Ne abbiamo viste di tutti i colori. Framework su framework, acronimi su acronimi:

RISEN — Role, Instructions, Steps, End goal, Narrowing constraints

COSTAR — Context, Objective, Style, Tone, Audience, Response

CARE — Context, Ask, Rules, Example

E poi quelli italianizzati: PRECISO, CLARO, e via dicendo.

C'era chi diceva che il "prompt engineer" sarebbe stato il mestiere dei prossimi cinquant'anni. Che le aziende avrebbero pagato fior di quattrini per chi padroneggiava il framework giusto.

Non è che quei framework fossero sbagliati. Il problema è più sottile: quelle regole valgono in generale, ma in momenti diversi valgono alcune più di altre, meno di altre, o per niente.

Il prompt engineering trattava l'interazione con l'AI come input optimization: trova l'input perfetto, ottieni l'output perfetto. Una formula da scoprire.

Ma gli LLM non funzionano così.

Il Mondo È Cambiato

Siamo nel 2026. Il panorama è irriconoscibile rispetto a due anni fa.

Context Window: Il Cambio Qualitativo

Le context window oggi sono abbastanza grandi da spostare il problema. Non è più "come comprimo tutto nel primo prompt", ma "come organizzo e seleziono contesto mentre lavoro".

Quando il contesto disponibile era piccolo, il prompt era praticamente tutto. Ottimizzarlo aveva senso. Oggi puoi caricare file di codice, documentazione, conversazioni precedenti — e il prompt diventa solo il punto di partenza di una navigazione più ampia.

Il prompt engineering non sparisce: smette di essere la leva principale. Diventa una checklist locale dentro un processo più ampio.

Context Engineering: L'Infrastruttura

Oggi abbiamo file di configurazione che definiscono il comportamento dell'AI prima di scrivere un prompt. Il concetto generale si chiama agents.md — contesto persistente letto all'avvio di ogni sessione.

CLAUDE.md per Claude Code, .cursorrules per Cursor — ogni tool lo chiama a modo suo, ma il concetto è lo stesso: regole del progetto, convenzioni, comandi, errori noti. Non prompt: infrastruttura.

Tool Use e MCP

I modelli non si limitano più a generare testo. Leggono file, eseguono comandi, chiamano API, navigano documentazione. Il protocollo MCP ha standardizzato l'accesso a tool esterni. L'agente decide autonomamente quali usare.

Commands e Skills

I commands sono istruzioni dirette: /commit, /test. Attivano workflow predefiniti.

Le skills sono diverse: cartelle con istruzioni, script, template ed esempi che l'agente carica on demand. Funzionano con "progressive disclosure" — Claude carica solo quelle rilevanti per il task, evitando di sovraccaricare il contesto. Sono conoscenza approfondita, non semplici comandi.

Ecco il cambio che propongo: il prompt non è una destinazione. È uno strumento di navigazione.

Lo chiamo Prompt Navigation.

Quando scrivi un prompt, stai navigando uno spazio vettoriale multidimensionale che nessuno comprende del tutto — nemmeno chi ha costruito il modello. Non stai "programmando" l'AI. Stai cercando di avvicinarti a una regione dove le risposte assomigliano a ciò che hai in mente.

Prompt Engineering	Prompt Navigation
Trova l'input perfetto	Esplora lo spazio delle soluzioni
Una domanda, una risposta	Un processo iterativo
Il prompt è il prodotto finale	Il prompt è il punto di partenza
Successo = risposta corretta al primo colpo	Successo = convergenza verso la soluzione
Unità di lavoro: prompt singolo	Unità di lavoro: ciclo ipotesi → prova → feedback

Obiezioni Oneste

Prima di andare avanti, affrontiamo le critiche legittime:

"A volte un prompt ben scritto risolve tutto in un colpo." Vero. Ma non è affidabile come metodo. Quando funziona, ottimo. Quando non funziona, sei punto a capo.

"Più contesto può aiutare." Vero. Ma spesso peggiora. Contesto ≠ comprensione. Serve selezione, non accumulo.

"I framework sono utili come checklist." Vero. RISEN e COSTAR possono servire come promemoria. Ma non come paradigma dominante.

La Prompt Navigation non nega il valore del prompt engineering. Lo riposiziona: da strategia principale a tattica locale.

Tre Esempi Pratici

Debug di un Bug

Prompt Engineering:

"Sei un senior developer. Analizza questo errore: Cannot read property 'map' of undefined"

Risultato: risposta generica su come verificare se l'array esiste. Tecnicamente corretta. Praticamente inutile.

Prompt Navigation:

Turno 1: "Ho questo errore in produzione. Ti mostro lo stack trace."

Turno 2: "Il file è questo. Leggi il componente UserList."

Turno 3: "I dati arrivano da questa API. Controlla il tipo di risposta."

Turno 4: "Il backend ritorna null invece di array vuoto. Proponi un fix."

La soluzione emerge dalla navigazione. Ogni turno restringe lo spazio fino a convergere sul problema reale.

Refactoring Legacy

Prompt Engineering:

"Refactorizza questo componente React di 500 righe. Usa hooks, separa logica e presentazione."

Risultato: componente riscritto che non compila e rompe metà applicazione.

Prompt Navigation:

Turno 1: "Prima dimmi cosa fa questo componente — analizzalo senza modificare."

Turno 2: "Gestisce auth + form + API. Qual è il pezzo più rischioso?"

Turno 3: "Estrai solo la validazione in un hook. Nient'altro."

Turno 4: "Funziona. Prossimo pezzo."

Turno 5: "Stop. Questo rompe il test X. Perché?"

Ogni step verificabile. Il refactoring emerge incrementalmente.

Feature Nuova

Prompt Engineering:

"Implementa notifiche push per React Native con Firebase, deep linking e gestione permessi."

Risultato: 2000 righe che nessuno sa come integrare.

Prompt Navigation:

Turno 1: "Qual è l'architettura minima per un MVP?"

Turno 2: "Partiamo da Android. Cosa serve lato app?"

Turno 3: "Ora il backend: endpoint per registrare il token."

Turno 4: "Come testo in locale senza deployare?"

Turno 5: "iOS. Cosa cambia?"

Alla fine hai la stessa feature, costruita capendo ogni pezzo.

Il Vero Problema È A Monte

L'unica cosa che possiamo valutare è quanto la risposta si avvicina alla soluzione che avevamo in mente. Ma quella soluzione potrebbe non essere quella giusta.

Se la tua idea di partenza è confusa o sbagliata, nessun framework salverà il prompt.

La Prompt Navigation aiuta anche qui. Navigando — esplorando alternative, vedendo risultati intermedi — spesso scopri che:

Il problema era diverso da come lo avevi formulato
Esisteva una soluzione più semplice
La tua assunzione iniziale era sbagliata

Il prompt iniziale diventa irrilevante. Quello che conta è il percorso.

Il Bias Che Non Vediamo

C'è un problema sottile: spesso pensiamo di avere ragione quando non è così.

Quando l'AI conferma quello che pensavamo, accettiamo. Quando dice qualcosa di diverso, pensiamo che abbia sbagliato.

Ma l'AI non ha ego. Se ti dice qualcosa di inaspettato, vale la pena chiedersi: "E se avesse ragione?"

La navigazione aiuta: esplorando alternative, vedendo il problema da angolazioni diverse, è più difficile rimanere ancorati all'idea iniziale.

Il Prossimo Errore: Context Overload

Un avvertimento per il futuro.

Stiamo già vedendo i primi segnali di un errore speculare: l'idea che più contesto sia sempre meglio.

CLAUDE.md di 2000 righe. Cursorrules che coprono ogni caso. Memory che accumula tutto.

Ma serve davvero sapere come far partire il backend quando lavori su un componente frontend?

Il contesto ha un costo: rumore, distrazione, pattern non rilevanti. Non è mai questione di ottimizzare l'input — è questione di navigare con intelligenza.

Questo è territorio ancora in esplorazione.

I Cinque Principi (Espansi)

1. Inizia Vago, Restringi Iterando

Non specificare tutto nel primo messaggio. Dai una direzione, poi usa le risposte per capire dove andare.

2. Verifica Prima di Procedere

Ogni step dovrebbe essere verificabile. Se non puoi verificare, stai andando troppo veloce.

3. Accetta le Deviazioni

A volte la navigazione porta in posti inaspettati. Spesso sono migliori di dove pensavi di andare.

4. Il Fallimento È Informazione

Una risposta sbagliata ti dice qualcosa sullo spazio che stai esplorando. Usala per correggere la rotta.

5. La Chiarezza Emerge, Non Si Impone

Se non sai cosa vuoi, inizia comunque. La navigazione ti aiuterà a capirlo.

Template Pratico

Vuoi provare la Prompt Navigation? Ecco un template da copiare:

GOAL: [cosa vuoi ottenere — 1 riga]

VINCOLI:
- [cosa non deve succedere]
- [cosa non deve succedere]

PRIMO PASSO: Fammi solo [X] e dimmi come verifico che funziona.

CHECKPOINT: Se fallisce, dammi 3 ipotesi e la prova più economica per testarle.

Non serve di più per iniziare.

Conclusione

Il prompt engineering non è "morto" nel senso che le sue tecniche siano inutili. Ma l'idea che esista un prompt perfetto, una formula magica, un framework definitivo — quella sì, ha fatto il suo tempo.

Benvenuti nell'era della Prompt Navigation.

Il prompt è una bussola, non una mappa. Ti indica una direzione, non una destinazione. E come ogni bussola, è utile solo se sei disposto a camminare, guardare dove sei arrivato, e correggere la rotta.

La vera skill non è scrivere prompt. È navigare con intenzione.

Se non puoi verificare lo step, non hai navigato: hai solo immaginato.