Context engineering è il termine su cui si è assestato il mercato per una domanda che gli agenti di coding hanno reso inevitabile: non cosa chiedi a un modello, ma cosa può vedere quando risponde. Le guide che occupano la SERP, da vendor di infrastruttura a blog tecnici, sono per lo più brave a spiegare come costruire quella pipeline, retrieval, memoria, definizioni degli strumenti, indicizzazione del codebase. Quasi nessuna chiede cosa resta a un team, a sessione chiusa, per dimostrare cosa c'era davvero nella finestra che ha prodotto una modifica specifica.
Questo divario pesa di più per un agente di coding che per un chatbot. Il contesto di un chatbot forma una risposta che qualcuno legge una volta. Il contesto di un agente di coding forma una modifica che va in produzione, e di cui qualcun altro deve fidarsi mesi dopo.
Cos'è il context engineering, oltre il prompt engineering
Il termine nasce da due tweet, a sei giorni di distanza, nel giugno 2025: prima Tobi Lütke, CEO di Shopify, che lo definisce "l'arte di fornire tutto il contesto perché il task sia plausibilmente risolvibile dall'LLM", poi Andrej Karpathy, che lo descrive come "l'arte delicata e la scienza di riempire la finestra di contesto con esattamente l'informazione giusta per il passo successivo". Entrambi tracciavano la stessa linea: il prompt è l'istruzione che scrivi. Il contesto è tutto il resto che il modello vede quando agisce su quell'istruzione, documenti recuperati, contenuto dei file, output degli strumenti, turni precedenti, istruzioni di sistema, gran parte del quale nessuno ha scritto a mano.
Per un agente di coding, quel "tutto il resto" non è astratto. Sono i file che l'agente ha letto prima di modificare, le definizioni degli strumenti a cui aveva accesso, le parti del codebase che il passo di retrieval ha deciso fossero rilevanti, e le istruzioni scritte nella configurazione stessa del repository. Il prompt engineering chiede come formulare la richiesta. Il context engineering chiede da cosa partiva l'agente quando ha risposto, una domanda che fissa il tetto della risposta indipendentemente da quanto bene sia stata formulata la richiesta.
Cosa costruiscono oggi i team: retrieval, memoria, contesto degli strumenti
Nella pratica, il context engineering per un agente di coding è una pipeline di assemblaggio, non un'impostazione singola. Un passo di retrieval decide quali file o porzioni del repository sono rilevanti per un task e li porta dentro la finestra. Uno strato di memoria porta avanti fatti tra un turno e l'altro, o tra una sessione e l'altra, che altrimenti andrebbero persi quando il contesto si azzera. Le definizioni degli strumenti, i server MCP tra questi, dicono all'agente cosa può chiamare e cosa restituisce ogni chiamata. Claude Code e strumenti simili aggiungono un altro strato sopra: file di istruzioni a livello di repository che vengono caricati in automatico, e che modellano il comportamento dell'agente prima ancora che venga scritto un solo token specifico del task.
Ognuno di questi pezzi risolve un problema reale: senza, un agente lavora con quello che entra in un singolo prompt, il che non basta per un task che attraversa un codebase vero. Insieme, sono anche il motivo per cui il contesto di lavoro effettivo di un agente di coding, su un dato task, è qualcosa che nessuno ha scritto a mano e che quasi nessuno riesce a ricostruire per intero dopo il fatto.
Perché più contesto non è automaticamente contesto migliore
L'istinto, una volta che un team ha retrieval e memoria in piedi, è dare in pasto all'agente più materiale: più file, più storico, più istruzioni permanenti. Uno studio arXiv dell'ETH di Zurigo è un buon controllo su quell'istinto. Testando file di contesto a livello di repository su SWE-bench e su repository reali scritti da sviluppatori, gli autori hanno trovato che aggiungerli riduce il tasso di successo dei task e alza il costo di inferenza di oltre il 20%, rispetto a nessun contesto di repository. Più contesto, assemblato senza disciplina, ha reso l'agente sia peggiore sia più costoso sugli stessi task.
Questo risultato non è un argomento contro il context engineering. È un argomento contro il trattare il volume come metrica. Una pipeline che recupera di più, ricorda di più e istruisce di più non è ingegnerizzata, è solo più grande, e una finestra di contesto riempita senza criterio è più vicina al rumore che all'"arte delicata" descritta da Karpathy.
La domanda che manca: quale contesto è stato usato davvero in questa sessione
Anche una pipeline ben costruita lascia scoperta una domanda precisa, e le guide attuali non se la pongono: per una data modifica, cosa aveva davvero l'agente nella finestra quando l'ha fatta, e qualcuno può verificarlo dopo. Un passo di retrieval può recuperare il file sbagliato senza segnalarlo. Uno strato di memoria può portare avanti un'istruzione di un task non correlato. Una definizione di strumento può restituire dati non aggiornati che l'agente non aveva modo di segnalare come tali. Niente di tutto questo compare nel diff. Compare, se compare, in un log tenuto nel formato che lo strumento usa, lo stesso divario che cosa lasciano indietro gli agenti di coding a fine sessione descrive già per il loop nel suo complesso.
Il context engineering fatto bene sta a monte di quel divario, non lo risolve. Far entrare i documenti giusti nella finestra al momento giusto è un problema di retrieval. Poter mostrare, dopo il fatto, quali documenti sono entrati davvero, e che l'agente era autorizzato a vederli, è un problema diverso, ed è quello che ogni guida di context engineering oggi salta. È la stessa distinzione che il loop di pianifica, modifica, esegue, verifica dell'agentic coding traccia tra verificare che un output funzioni e verificare che l'intero processo corrisponda a cosa è stato chiesto e autorizzato: verificare il disegno della pipeline non è lo stesso che verificare cosa una sessione specifica ha davvero attinto da essa.
Dal context engineering a un registro di contesto verificabile
Una pipeline di contesto che un team sa solo descrivere, mai ricostruire per una sessione passata specifica, lascia lo stesso buco di ogni altro strato dello stack agentico: intento e output esistono, ma il mezzo, cosa l'agente era davvero autorizzato a vedere e cosa ha visto, non sopravvive alla sessione che l'ha prodotto. Colmare questo buco richiede qualcosa di più vicino a un registro che a un diagramma di pipeline: una traccia, legata a una modifica specifica, di quali fonti erano nel perimetro, quali sono state effettivamente recuperate, e chi o cosa ha autorizzato quel perimetro fin dall'inizio.
È un livello diverso da un buon setup di retrieval, e nessuna guida di context engineering sul mercato è oggi costruita per raggiungerlo. È lo stesso livello che il layer sopra i singoli agenti di coding esiste per tenere, applicato un passo più a monte, al contesto da cui quegli agenti hanno lavorato, non solo al codice che hanno prodotto.