Se non sei pienamente soddisfatto della qualità del tuo coding agent, probabilmente stai trascurando la gestione del contesto.
Il contesto fa lavorare il language model in una zona intelligente, cioè lo sfrutta al meglio delle sue potenzialità. Gestirlo bene è la differenza tra un assistente brillante e uno che svalvola. In questo articolo esploriamo cos’è il contesto, come influenza le risposte del modello e quali tecniche usare per ottenere il massimo dal tuo coding agent.
Cos’è il contesto di un language model
Il contesto è tutto quello che il language model può vedere quando gli facciamo una richiesta. Vale per ChatGPT, Claude Code, GitHub Copilot: funzionano tutti così.
Quando mandiamo un prompt a un LLM, la risposta viene generata sulla base di due macro-gruppi di informazioni:
- I dati di training — la conoscenza acquisita durante l’addestramento (es. GPT-5.4 è stato allenato con dati fino a novembre 2025). Su questo non abbiamo alcuna influenza.
- Il contesto — tutto ciò che inseriamo nella conversazione corrente. Su questo abbiamo un peso importantissimo.
Come si costruisce il contesto in una conversazione
Quando avviamo una sessione con un coding agent, dietro le quinte accade questo:
- Viene passato un system prompt che indirizza il modello (es. “sei Copilot, un agente di assistenza allo sviluppo”)
- C’è il messaggio dell’utente — quello che scriviamo nella chat
- C’è la risposta dell’assistente
Il primo blocco sono i token di input, il secondo i token di output. Insieme costruiscono il contesto della conversazione, che si allunga mano a mano che la sessione procede.
Come il contesto influenza le risposte del coding agent
Facciamo un esempio concreto. Se nel mio file AGENTS.md scrivo:
La mia preferenza assoluta in caso di belle giornate è andare in riva al Lago di Garda in provincia di Verona.
E poi nella chat scrivo “oggi è una bella giornata, dove andiamo?”, Copilot risponderà al Lago di Garda. Se cambio quella riga con “andare in spiaggia in provincia di Venezia”, la risposta cambia di conseguenza.
Non ho influenzato il training del modello. Ho influenzato il contesto. Questo vale anche per il codice generato, perché per un LLM è sempre testo.
Cosa viene inserito nel contesto di GitHub Copilot
Nell’ambito di GitHub Copilot (ma il concetto vale per tutti i coding agent) nel contesto vengono inserite:
- Istruzioni di sistema e linee guida — il system prompt di base
- Istruzioni personalizzate — file come
AGENTS.md,copilot-instructions.md - Storia della conversazione — tutti i messaggi precedenti nella sessione
- Contesto implicito — file aperti, selezione corrente nell’editor
- Referenze esplicite — file o documenti aggiunti manualmente con
@ - Stato di git — branch, diff, modifiche pendenti
- Output degli strumenti — risultati della lettura di file, ricerche web, esecuzione di comandi
Quanto è grande la context window
La dimensione del contesto dipende dal language model. Ad esempio, Claude 4.5 ha un context limit di 200.000 token. Esistono modelli che arrivano a un milione. Un riferimento utile per confrontare le specifiche è models.dev.
I due nemici del contesto: context rot e lost in the middle
Perché sforzarsi di capire il contesto? Perché ha caratteristiche che possono sviare il comportamento del language model. La ricerca ha documentato due fenomeni critici.
Context rot (deterioramento del contesto)
Mano a mano che riempiamo la context window con migliaia di token, la qualità delle risposte cala drasticamente. Più informazioni mettiamo, più il language model fa fatica a scegliere quali utilizzare.
È come quando qualcuno ci spiega qualcosa dandoci troppe informazioni tutte insieme: alla fine siamo persi e non riusciamo a fare un riassunto sensato.
Lost in the middle (ago nel pagliaio)
La ricerca ha dimostrato che la posizione delle informazioni nel contesto ha un peso nella capacità del modello di utilizzarle. Le informazioni all’inizio e alla fine del contesto sono quelle che il language model sfrutta meglio. Quelle nel mezzo vengono recuperate con più fatica.
È come quando guardiamo un film: ricordiamo bene l’inizio e la fine, ma tutto quello che succede in mezzo è un po’ più confuso.
Zona intelligente vs zona stupida
Data una context window (es. 200.000 token), possiamo individuare due fasi:
- Zona intelligente — la prima parte della sessione, dove il contesto è pulito e il modello lavora al meglio
- Zona stupida — quando la conversazione si allunga troppo e il modello perde le sue potenzialità
Non c’è un numero preciso che segni il confine. C’è chi dice 100.000 token fissi, chi il 50% della finestra teorica. Il punto pratico è: prima o poi il modello degrada, e serve un reset.
3 tecniche per gestire il contesto
1. Una nuova sessione per ogni task
Quando con il coding agent hai raggiunto un obiettivo — che sia la correzione di un bug, il refactoring di una classe o l’implementazione di una feature — avvia una nuova conversazione.
Il contesto si resetta a ogni sessione. Le conversazioni sono completamente separate l’una dall’altra. Quando vuoi svuotare il contesto e ritornare nella zona intelligente, fai una nuova sessione. Una per ogni task.
2. Seleziona solo gli strumenti che servono
Tutti i server MCP che colleghi, tutti gli strumenti che abiliti, vengono inseriti nel contesto per spiegare al modello che esistono e come usarli.
In Visual Studio Code, dal pulsante Configure Tools puoi attivare o disattivare gli strumenti disponibili. Nella Show Chat Debug View puoi vedere esattamente come viene assemblato il contesto e quanti token occupa ogni componente:
- Istruzioni di sistema: ~2,5%
- Definizione strumenti: ~3%
- Messaggi utente: ~0,7%
- Output degli strumenti: ~3,4%
Ogni strumento ha nome, descrizione e istruzioni d’uso. Se ne hai 54 attivi (il default), occupano contesto prezioso. Disattiva quelli che non ti servono per la sessione corrente.
Anche in Copilot CLI e Claude Code puoi monitorare il consumo del contesto con il comando /context.
3. Delega ai sub-agent
I sub-agent sono processi separati dalla conversazione principale. Viene avviato un coding agent dedicato per una sottoattività specifica, con il suo contesto indipendente.
Il flusso è questo:
- Nella conversazione principale chiedi un’attività specifica (o il coding agent decide autonomamente di delegarla)
- Viene avviato un sub-agent con la sua context window (es. 200.000 token)
- Il sub-agent esplora, legge file, fa ricerche — riempie il suo contesto
- Quando ha finito, restituisce solo un riassunto/output alla conversazione principale
Invece di riempire il contesto principale con migliaia di token di esplorazione, nella conversazione main finisce solo l’output compatto del sub-agent. Un risparmio enorme.
Esempio pratico in Copilot CLI:
“Spiegami come funziona la login in questa codebase usando un sub-agent con haiku”
Il sub-agent esplorativo parte con Claude Haiku (veloce nel recupero informazioni), mentre la conversazione principale resta su GPT-5.4 mini. Al termine, il contesto occupato è solo il 7% perché tutto il lavoro pesante è rimasto nel contesto separato del sub-agent.
Conclusione
La gestione del contesto è ciò che separa chi usa un coding agent in modo efficace da chi si lamenta della qualità dei risultati. Tre regole semplici:
- Una sessione per task — resetta il contesto spesso
- Solo gli strumenti necessari — meno rumore, più segnale
- Sub-agent per le esplorazioni — proteggi il contesto principale
Queste tecniche funzionano con qualunque coding agent e permettono di ottenere risultati eccellenti anche con language model più piccoli, senza dover sempre ricorrere ai modelli più costosi e lenti.
Azioni
- Monitora il consumo del contesto nella tua prossima sessione con il tuo coding agent
- Prova a separare un’attività di esplorazione in un sub-agent e osserva la differenza nella qualità delle risposte successive