Context Engineering
Il prompt engineering riguarda le parole che scegli. Il context engineering riguarda lo spazio di lavoro che consegni al modello — cosa c'è dentro, in che ordine è e cosa hai deliberatamente lasciato fuori.
La distinzione conta perché una context window non è un blocco per appunti. È una risorsa attentiva limitata e costosa. Come la riempi cambia su cosa si concentra il modello, quanto ti costa e se resta utile man mano che le sessioni crescono.
Il budget di contesto
Ogni modello ha una dimensione massima di contesto — un tetto rigido misurato in token. Pensalo come un budget. Lo spendi in:
- Il tuo system prompt e le istruzioni permanenti
- Documenti recuperati, frammenti di codebase, definizioni di strumenti
- Cronologia della conversazione
- L'output del modello (che conta anch'esso contro la window nelle sessioni multi-turno)
Quando lo esaurisci, qualcosa deve cedere. O i contenuti vecchi vengono scartati, o la sessione sbatte contro un muro.
La maggior parte delle guide per principianti tratta la context window come "più è meglio". Il context engineering la tratta come una risorsa da allocare con attenzione: spendila su ciò di cui il modello ha davvero bisogno per questo turno, non su tutto ciò che potrebbe essere rilevante.
Context rot e "lost in the middle"
C'è un fenomeno ben documentato negli LLM a contesto lungo: i modelli prestano un'attenzione sproporzionata ai contenuti vicini all'inizio e alla fine del loro contesto, e il loro ricordo dei contenuti sepolti nel mezzo peggiora. I ricercatori che hanno studiato questo effetto lo hanno chiamato "lost in the middle" (perso nel mezzo).
La conseguenza pratica: se riempi un contesto da 100.000 token con documenti e seppellisci l'istruzione più critica alla posizione 60.000, il modello potrebbe di fatto ignorarla — non perché sia incapace di leggere fin lì, ma perché l'attenzione non è distribuita uniformemente lungo la window.
Il "context rot" (deterioramento del contesto) è il pattern più ampio: man mano che una sessione cresce, la qualità delle risposte tende a derivare. Le istruzioni iniziali si diluiscono. Il continuo botta e risposta soffoca il compito originale. Il modello inizia a tergiversare, ripetersi o perdere il filo di ciò che hai effettivamente chiesto.
Questi non sono bug che puoi correggere del tutto con un prompt migliore. Sono proprietà strutturali di come funziona l'attenzione su scala. La risposta ingegneristica è mantenere il contesto più piccolo e più affilato, non riempirlo e sperare.
L'ordine conta
Dove collochi i contenuti è importante quanto cosa includi. Buona pratica consolidata:
| Posizione | Cosa metterci |
|---|---|
| Proprio in cima (system prompt) | Istruzioni stabili e durevoli. Persona, regole, requisiti di formato. |
| Dopo il system prompt | Il compito corrente, in termini semplici. |
| Appena prima dell'ultimo turno utente | Il contesto più critico e specifico per esattamente questa richiesta. |
| Mezzo | Documenti di supporto, frammenti recuperati — ordinati per rilevanza, non per cronologia. |
| Cronologia della conversazione | Solo ciò che è necessario per la continuità. Pota in modo aggressivo. |
La regola generale: più sei vicino al turno corrente, più attenzione ottieni. Le istruzioni critiche che vivono solo nel mezzo di una lunga cronologia sono a rischio.
Recupero anziché riempimento
La tentazione è metterci tutto dentro: tutti i documenti, l'intera codebase, l'intera conversazione. Resisti.
L'approccio migliore è il recupero selettivo: identifica ciò di cui il modello ha davvero bisogno per questa specifica richiesta, e inietta solo quello. Un frammento ben recuperato di 2.000 token del documento giusto batte uno scarico di 40.000 token in cui la risposta è da qualche parte nel mezzo.
È per questo che esiste la generazione aumentata dal recupero (RAG) — non solo per superare i limiti di contesto, ma per migliorare la qualità mantenendo il contesto curato.
Per le sessioni interattive vale la stessa logica: invece di accumulare tutto, compatta o pulisci periodicamente la cronologia per rimuovere i contenuti non più rilevanti per il compito corrente. I comandi /compact e /clear di Claude Code sono strumenti di context engineering, non solo di gestione della sessione.
L'angolo dei costi
I token che invii sono token che paghi — sia in denaro che in latenza. Riempire il contesto con materiale vagamente rilevante gonfia entrambi. Context engineering ed efficienza di costo sono lo stesso problema.
Più concretamente:
- Un system prompt gonfio che copi-incolli da un template viene pagato a ogni singola chiamata.
- La vecchia cronologia della conversazione che ti porti dietro perché "potrebbe essere utile" viene pagata a ogni singola chiamata.
- I documenti che inietti "per ogni evenienza" vengono pagati a ogni singola chiamata.
Tagliare ciò che non deve esserci è contemporaneamente meglio per la qualità e più economico da far girare.
Tattiche pratiche per gli utenti di Claude
In Claude.ai:
- Usa conversazioni distinte per compiti distinti. Non lasciare che un pomeriggio di divagazioni inquini il contesto di un progetto focalizzato.
- Riassumi i thread lunghi prima di porre una domanda complessa che dipende da essi. Un riepilogo esplicito è spesso più utile della cronologia grezza.
- Metti la cosa specifica che vuoi alla fine di un messaggio lungo, non sepolta nel mezzo.
In Claude Code:
- Mantieni snello il tuo file
CLAUDE.md. Ogni riga in esso viene iniettata in ogni sessione. Vedi CLAUDE.md e Gestione del Contesto. - Usa
/clearquando passi a un compito genuinamente diverso. Usa/compactquando vuoi continuare ma la sessione sta crescendo. - Fai riferimento ai file per percorso anziché incollarne i contenuti quando l'intero file non serve per il passo corrente.
A livello di API:
- Progetta i system prompt in modo che contengano solo ciò di cui ogni richiesta ha davvero bisogno. Sposta le istruzioni specifiche del compito nel turno utente.
- Per i casi d'uso ricchi di documenti, recupera e inietta i frammenti rilevanti invece di caricare un intero corpus.
- Struttura il prompt in modo che il prefisso stabile e riutilizzabile venga prima — questo abilita anche il prompt caching, un compagno naturale del context engineering.
Il cambio di mentalità
Il prompt engineering chiede: "Cosa dovrei dire?" Il context engineering chiede: "Cosa dovrebbe vedere il modello, in che ordine, e cosa dovrei deliberatamente tenere fuori?"
La seconda domanda è più difficile, ma è quella che determina davvero la qualità su scala.