Context Engineering: perché il prompt perfetto non basta più

Per un paio d'anni, il consiglio dominante per ottenere risposte migliori da un modello è stato "scrivi un prompt migliore" -- più specifico, con più esempi, con istruzioni più chiare. Questo consiglio resta vero per una domanda isolata. Diventa insufficiente nel momento in cui un sistema deve prendere decisioni attraverso più passi, con più fonti di informazione, in un compito che dura minuti o ore invece di una singola risposta.

Il context engineering parte da una domanda diversa: non "come formulo questa richiesta", ma "cosa deve sapere il sistema in questo momento specifico per prendere la decisione giusta, e cosa invece lo confonderebbe se glielo dessi tutto insieme". Un modello con una finestra di contesto enorme non è automaticamente un modello che ragiona meglio -- spesso è il contrario: informazione irrilevante mescolata a quella rilevante peggiora la qualità delle decisioni, esattamente come un umano con troppi documenti aperti fatica a concentrarsi sul più importante.

La disciplina pratica del context engineering assomiglia più alla progettazione di un'interfaccia utente che alla scrittura di un prompt: si decide cosa mostrare, cosa nascondere, in quale ordine, e con quale livello di dettaglio, in funzione del passo specifico che il sistema sta eseguendo in quel momento. Un agente che sta pianificando ha bisogno di una vista d'insieme, compressa. Un agente che sta eseguendo un singolo passo tecnico ha bisogno del dettaglio esatto di quel passo, e di quasi nient'altro -- il resto è rumore che consuma capacità di ragionamento senza aggiungere valore.

C'è anche un aspetto economico diretto, non solo qualitativo: ogni informazione inclusa nel contesto ha un costo reale in token, che si traduce in costo monetario e in tempo di risposta. Un sistema che ripete daccapo tutto il contesto ad ogni passo, invece di ricordare cosa è già stato stabilito e passare solo la differenza, paga lo stesso costo cognitivo (e monetario) più e più volte per la stessa informazione. La differenza tra un sistema che scala in modo sostenibile e uno che diventa proibitivo con l'uso spesso non è nella qualità del modello sottostante -- è in quanto bene è progettato il flusso di contesto attorno a lui.

Il segnale pratico che un team ha superato il prompt engineering ed è passato al context engineering: non parla più di "quale prompt funziona meglio" come domanda principale, parla di "quali informazioni servono a questo passo, da dove vengono, e come vengono compresse quando non servono più per intero". È un cambio di livello di astrazione -- dal linguaggio di una singola richiesta all'architettura di come l'informazione fluisce attraverso un intero processo decisionale.

Un errore comune di chi inizia a praticare il context engineering e trattarlo come un problema di compressione (mettere piu informazione possibile in meno spazio) invece che di selezione (scegliere quale informazione conta davvero per il passo specifico) -- la differenza tra i due approcci e spesso il motivo per cui due team con lo stesso modello ottengono risultati molto diversi.