Prompt engineering e context engineering: non un rebranding, ma un cambio di ciò che si ottimizza

Il prompt engineering consiste nel formulare bene un'istruzione. Il context engineering consiste nel decidere che cosa il modello vede in assoluto. Il termine è stato reso popolare nel giugno 2025 da Tobi Lutke di Shopify e rilanciato da Andrej Karpathy, che lo ha descritto come l'arte di riempire la finestra di contesto con esattamente l'informazione giusta per il passo successivo. La distinzione più chiara viene da Philipp Schmid: il contesto è tutto ciò che il modello vede prima di generare una risposta, ed è un sistema, non una stringa di testo.

I due non sono rivali; il prompt engineering è un sottoinsieme. Quando scrivete un buon system prompt, quello è prompt engineering. Quando decidete quali tre documenti recuperare, quali strumenti abilitare, quanta cronologia mantenere, che cosa scartare e quale schema di output richiedere, tutto sotto un budget di token, quello è context engineering. Le linee guida di Anthropic lo inquadrano come la gestione dell'intero stato del contesto attraverso i turni, e la frase più tagliente, quella che vale la pena ricordare, è questa: il contesto è una risorsa finita con rendimento marginale decrescente.

Il motivo per cui il context engineering è diventato una disciplina a sé è che l'assunto comodo si è rotto sotto la misurazione. L'assunto era che i modelli a contesto lungo permettessero di riempire la finestra fino all'orlo senza smettere di ragionare bene. Lo studio Context Rot di Chroma ha testato 18 modelli di frontiera nel luglio 2025 e ha scoperto che ognuno degrada man mano che l'input cresce, spesso in modo incoerente: il modello non tratta il decimillesimo token con la stessa affidabilità del centesimo. Anche il precedente riscontro lost-in-the-middle andava nella stessa direzione.

Due forze hanno reso il payload, non il prompt, la cosa da ingegnerizzare. Primo: agenti, uso di strumenti, retrieval e memoria significano che il contesto viene composto da un sistema su molti turni, non scritto a mano una sola volta. Secondo, l'economia: in produzione presso Manus il rapporto tra token di input e di output è di circa 100 a 1, e il riutilizzo della key-value cache genera una grande differenza di costo, quindi ciò che entra nella finestra è tanto una decisione di costo quanto una decisione di qualità. Più contesto non è meglio; lo è il contesto budgetato e rilevante. Questo è il fondamento empirico dietro il nostro precedente approfondimento sul context engineering e sul perché conta.

Spogliato dall'etichetta, il context engineering è un insieme di pratiche verificabili, non un sussurrare al prompt. Le tecniche più citate ricorrono in Anthropic, LangChain e nel rapporto di produzione di Manus:

• Retrieval. Recuperate i pochi documenti rilevanti nel momento in cui servono, invece di incollare tutto. È la disciplina dietro la Retrieval-Augmented Generation.
• Compattazione e riepilogo. Comprimete i turni precedenti in un riepilogo continuo, così il budget viene speso per ciò che è vivo, non per la trascrizione.
• Memoria e appunti. Esternalizzate lo stato in appunti o file esterni che l'agente può rileggere, invece di trasportarlo nella finestra.
• Curation degli strumenti. Tenete caricati da tre a cinque strumenti principali e recuperate il resto appena in tempo. Caricare ogni strumento diluisce il segnale e rompe la cache.
• Output strutturati. Richiedete uno schema, così il modello spende token per la risposta, non per prosa di formattazione.
• Isolamento. Suddividete il lavoro tra sub-agenti, così ognuno vede solo il contesto di cui ha bisogno.

LangChain inquadra lo stesso insieme come scrivere, selezionare, comprimere e isolare. Il punto è che ognuno di questi elementi è misurabile: potete testare in A/B un retriever, una soglia di compattazione o una dotazione di strumenti, ed è esattamente questo che rende tutto ciò engineering e non formulazione.

In parte, ed è normale. Sì, i bravi ingegneri già curavano ciò che il modello vede; il valore del nome è che orienta l'ottimizzazione verso il payload e il sistema, non verso la frase, dove affidabilità e costi vivono davvero. Il dibattito in corso è più utile della disputa terminologica. Nel giugno 2025 Cognition ha argomentato contro i sistemi multi-agente, sostenendo che è difficile condividere il contesto in modo pulito tra agenti, e ha raccomandato di tenere il lavoro singolo e di condividere trace complete. Nella stessa settimana Anthropic ha descritto un sistema di ricerca multi-agente che dipende da un isolamento disciplinato del contesto. Stessa disciplina, conclusione architetturale opposta.

Per un team che costruisce con gli LLM, le lezioni sono semplici. Gestite i token a budget come gestite la potenza di calcolo, perché averne di più non è gratis e non è sempre meglio. Trattate il lavoro come impiantistica (qualità del retrieval, compattazione, memoria, curation degli strumenti, output strutturati), non come formulazione. E scegliete la vostra architettura in base a quanto in modo affidabile riuscite a condividere il contesto, non in base a quale approccio suona più avanzato. Il nome continuerà a mutare, alcuni chiamano già il prossimo strato harness engineering, ma l'oggetto resta stabile: il sistema che decide che cosa il modello arriva a vedere.