Novembre 2023. OpenAI ha lanciato l’API di function calling con supporto stabile e, senza che nessuno facesse un annuncio formale, il mestiere del “prompt engineer” ha iniziato il suo declino. Non perché i prompt smettessero di contare, ma perché smisero di essere ciò che contava di più.
In Soamee costruiamo prodotti con LLM da anni. Siamo passati per la fase dei prompt magici, per la fede cieca che la stesura perfetta del messaggio fosse il segreto del successo. E abbiamo imparato, a volte dolorosamente, che quella fede era sbagliata.
Questo articolo è la mia opinione diretta su cosa è successo, perché il prompt engineering come disciplina isolata è morto, e cosa muove davvero l’ago nei prodotti AI nel 2026.
L’Era dei Prompt Magici (2022-2024)
Quando GPT-3 è arrivato al mainstream e GPT-4 lo ha popolarizzato, il mondo tech si è diviso in due gruppi: gli scettici che pensavano fosse tutto fumo, e gli entusiasti che credevano di aver trovato l’oracolo definitivo. Gli entusiasti avevano ragione su una cosa: i LLM erano genuinamente potenti. Ma hanno tratto la conclusione sbagliata sul perché funzionassero.
La narrativa dominante era: “La chiave sta nel saper parlare con il modello.” Sono emersi corsi di “prompt engineering” a centinaia di dollari. Sono apparsi repository con migliaia di stelle pieni di “prompt definitivi”. LinkedIn si è riempito di profili che si autodefinivano “Prompt Engineer” come se fosse la professione del futuro.
Il problema non era che i prompt non contassero. Il problema era la conclusione che se ne traeva: che la differenza tra un prodotto AI eccellente e uno mediocre risiedesse nell’aver trovato la formulazione corretta del messaggio. Che ci fossero prompt magici in attesa di essere scoperti.
Questa idea era sbagliata. E il mercato ha impiegato tra 18 e 24 mesi per rendersene conto.
Cosa ha Ucciso il Prompt Engineering
1. Gli structured outputs hanno reso obsoleti i prompt di formato
Per anni, una parte importante del lavoro di “prompt engineering” consisteva nel fare in modo che il modello rispondesse nel formato corretto. Chiedevi JSON e a volte ottenevi JSON, a volte testo con JSON all’interno, a volte qualcosa che sembrava JSON ma non lo era. Esistevano intere librerie dedicate a fare il parsing e correggere l’output dei modelli.
Oggi, OpenAI, Anthropic e Google supportano nativamente gli structured outputs: definisci uno schema JSON e il modello garantisce che la sua risposta rispetti quello schema. Nessuna magia, nessuna stesura perfetta. Un contratto tecnico.
# Prima: pregare che il modello rispondesse in JSON
response = client.messages.create(
model="claude-3-5-sonnet",
messages=[{"role": "user", "content": "Estrai il nome e l'email. Rispondi SOLO in JSON con i campi 'nome' e 'email'. NON includere testo aggiuntivo."}]
)
# Risultato: imprevedibile
# Ora: definire il contratto
class ExtractedContact(BaseModel):
nome: str
email: str
response = instructor.from_anthropic(client).messages.create(
model="claude-3-5-sonnet",
response_model=ExtractedContact,
messages=[{"role": "user", "content": "Estrai il contatto dal testo"}]
)
# Risultato: garantitoIl prompt di formato è morto. L’ha ucciso l’ingegneria.
2. Il tool use ha reso obsoleti i prompt di azione
Il secondo grande pilastro del prompt engineering era fare in modo che il modello prendesse le decisioni giuste: “Se l’utente chiede X, fai Y. Se chiede Z, fai W.” Prompt con condizionali, alberi decisionali scritti in linguaggio naturale.
Il function calling lo ha sostituito con eleganza. Invece di cercare di far simulare al modello la logica di business attraverso il testo, gli dai strumenti reali e lo lasci decidere quando usarli. Il modello è bravo a prendere decisioni di alto livello; il codice è bravo a eseguire azioni con precisione.
tools = [
{
"name": "cerca_ordine",
"description": "Cerca un ordine per ID o email del cliente",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"tipo": {"enum": ["id", "email"]}
}
}
},
{
"name": "aggiorna_stato",
"description": "Aggiorna lo stato di un ordine",
"input_schema": {
"type": "object",
"properties": {
"ordine_id": {"type": "string"},
"nuovo_stato": {"enum": ["in_elaborazione", "spedito", "annullato"]}
}
}
}
]Non hai bisogno di scrivere “Se l’utente menziona un numero d’ordine, cercalo prima di rispondere.” Il modello lo inferisce dal contesto degli strumenti. Quello che una volta era un paragrafo di istruzioni nel prompt è ora una definizione di funzione.
3. Il context engineering conta più della stesura del prompt
Ecco l’insight che è costato di più alla nostra industria interiorizzare: ciò che inserisci nel contesto conta molto più di come formuli la domanda.
Puoi avere il prompt più elegante del mondo, ma se il modello non ha accesso alle informazioni rilevanti, allucinera o darà risposte generiche. E puoi avere un prompt basilare, quasi telegrafico, ma se gli dai le informazioni giuste, il modello renderà bene.
Il context engineering è la disciplina di progettare cosa arriva al modello prima che risponda:
- RAG ben implementato: Non solo embeddings e cosine similarity. Selezione di chunk rilevanti, reranking, filtraggio per metadati, contesto sufficiente senza superare il limite.
- Few-shot examples dinamici: Non esempi statici nel prompt. Esempi selezionati dinamicamente in base alla query corrente.
- Gestione del contesto conversazionale: Quali turni precedenti conservare, quali comprimere, quali scartare.
- Dati strutturati vs. testo: A volte è meglio dare al modello una tabella ben formattata che un paragrafo che spieghi i dati.
Nei nostri progetti, l’80% dei miglioramenti di qualità è venuto dal migliorare il contesto, non dal riscrivere il prompt.
4. La valutazione ha sostituito l’istinto
Il prompt engineering classico era fondamentalmente guidato dall’intuizione. Provavi una variazione, sembrava migliore, la pubblicavi. Non c’era modo rigoroso di misurare se fosse davvero migliore in tutti i casi o solo in quelli che avevi testato manualmente.
La maturità del campo ha portato le evals: insiemi di casi di test con criteri di valutazione espliciti, spesso valutati da un altro LLM. Framework come RAGAS, LangSmith, Braintrust o PromptFoo permettono di farlo sistematicamente.
Quando hai le evals, puoi fare quello che facevi con il codice: misurare prima di cambiare, confrontare versioni, rilevare regressioni. Il prompt smette di essere un artefatto artigianale che nessuno tocca per paura di rompere qualcosa e diventa codice versionato con test.
Questo cambia la natura del lavoro. Non è intuizione, è ingegneria.
Cosa ha Sostituito il Prompt Engineering: LLM Engineering
Ciò che sta emergendo non è il prompt engineering evoluto. È una disciplina completamente diversa che prende in prestito il nome dall’ingegneria del software perché è, essenzialmente, quello che è.
L’LLM engineering tratta il modello di linguaggio come un componente di sistema: con interfacce definite, contratti di dati, test automatizzati, osservabilità e deployment continuo. Il prompt è un file di configurazione versionato in git, non un testo salvato in una variabile d’ambiente che tocca solo l’esperto del team.
I pilastri di questa disciplina:
System prompt come specifiche software: Versionati in git, revisionati in pull request, con test di regressione. Se qualcuno cambia il system prompt, la pipeline CI esegue le evals e blocca il merge se la qualità cala.
Structured outputs come contratti API: Il modello è un servizio interno con un’interfaccia definita. Quello che restituisce ha uno schema. Il resto del sistema si fida di quello schema, non del parsing di testo libero.
Tool use come architettura di agenti: Invece di cercare di far fare tutto al modello, gli dai strumenti specializzati e lo lasci orchestrare. La logica di business vive negli strumenti (codice testabile), non nel prompt.
Osservabilità e tracciabilità: Ogni chiamata al modello viene registrata con il suo contesto completo, token usati, latenza, risultato. Quando qualcosa fallisce in produzione, c’è una trace che ti dice esattamente cosa è successo.
Evals come CI/CD per i prompt: Prima di deployare qualsiasi modifica al system prompt o all’architettura RAG, esegui la suite di evals. Se il punteggio scende, non si deploya.
Dove il Prompting Conta Ancora
Sarebbe disonesto dire che i prompt non contano affatto. Contano. Ma in contesti specifici:
Compiti creativi: Quando vuoi che il modello generi testo con uno stile particolare, la stesura del prompt rimane un’arte. “Scrivi nello stile di un giornalista dell’Economist che copre la tecnologia” produce risultati diversi da “Scrivi un articolo sulla tecnologia”. Qui la sfumatura linguistica conta.
Prototipazione rapida: Quando stai validando un’idea in poche ore, non ha senso costruire tutta l’infrastruttura di evals e structured outputs. Un prompt ben scritto in Cursor o nella console di Anthropic è perfettamente valido per esplorare la fattibilità.
Edge case e comportamento del ragionamento: Per compiti che richiedono ragionamento a catena (chain-of-thought), il modo in cui strutturi il problema nel prompt continua ad avere impatto. “Pensa passo per passo” e le sue variazioni non sono magia, ma sono istruzioni che influenzano il processo di ragionamento.
Modelli senza tool use o structured outputs: Se per qualche motivo lavori con modelli più piccoli o deployati localmente che non supportano queste capacità, il prompting classico rimane rilevante.
Ciò che è morto non è il prompt in sé. Ciò che è morto è l’idea che il prompt sia il manufatto centrale attorno al quale ruota tutto il resto.
Cosa Dovrebbe Imparare il Tuo Team
Se stai costruendo prodotti con LLM nel 2026, queste sono le competenze che contano davvero:
1. Design di schemi JSON: Saper definire strutture di dati chiare per gli output del modello. Pydantic, Zod, JSON Schema. Questo è più importante che saper scrivere prompt.
2. Architetture di agenti: Capire come progettare sistemi dove l’LLM orchestra strumenti specializzati. Pattern come ReAct, Plan-and-Execute, e quando usare ciascuno.
3. RAG in produzione: Non il tutorial da 5 minuti con ChromaDB ed embeddings basilari. Il RAG reale include chunking strategico, reranking, valutazione della rilevanza, e monitoraggio della qualità.
4. Design ed esecuzione di evals: Saper definire cosa significa “buono” per il proprio caso d’uso, costruire insiemi di test rappresentativi, ed eseguire valutazioni sistematicamente.
5. Osservabilità degli LLM: Tracing, logging, monitoraggio di costi e latenza. Strumenti come LangSmith, Langfuse, o Helicone. Non puoi migliorare ciò che non riesci a misurare.
6. Gestione del contesto: Capire i limiti del contesto, quando e come comprimere, quando usare memoria esterna vs. contesto in-context.
I prompt fanno parte di tutto questo. Ma sono un componente tra tanti, non il centro.
Conclusione: Costruisci Sistemi, Non Prompt
La differenza tra un team che usa l’AI in modo produttivo e uno che non lo fa non sta in chi sa scrivere prompt migliori. Sta in chi ha costruito l’infrastruttura giusta attorno al modello: i contratti di dati, gli strumenti, la pipeline di valutazione, l’osservabilità.
Il prompt engineer che sa solo scrivere messaggi è l’equivalente di un frontend developer che sa solo copiare codice da Stack Overflow senza capire perché funziona. Utile per compiti puntuali, insufficiente per costruire prodotti di qualità.
Ciò che il mercato richiede ora sono ingegneri che capiscano gli LLM come componenti di sistema: le loro capacità, i loro limiti, e come integrarli in architetture software reali.
In Soamee lavoriamo esattamente così da un po’ di tempo. Non vendiamo prompt magici né workshop di ChatGPT. Costruiamo prodotti di intelligenza artificiale con la stessa disciplina ingegneristica con cui costruiremmo qualsiasi altro sistema software: con contratti definiti, test, osservabilità e deployment continuo.
Se la tua azienda sta valutando come integrare l’AI seriamente, oltre il prototipo iniziale, raccontacelo. Prenota una consulenza gratuita e parliamo di architettura, non di prompt.