Il contesto è la risorsa più preziosa — e più sprecata — quando si usa un agente di coding. Il modello non vede il tuo progetto: vede solo ciò che gli metti davanti. Se gli metti davanti un file di 2000 righe copiato e incollato, il contesto è rumore. Se gli indichi il punto esatto, il contesto è un raggio laser. La differenza tra i due casi non è una sfumatura: è la differenza tra un suggerimento utile e un suggerimento che ignori.

Il contesto non è lo schermo che hai aperto: è tutto ciò che il modello riceve come input in un dato momento. Gestirlo significa decidere cosa entra, cosa resta fuori e quando si resetta.

Context hygiene 🔧

La prima regola della context hygiene è controintuitiva: meno contesto è spesso più contesto. Non stiamo parlando di risparmiare token per risparmiare token — stiamo parlando di non inquinare la finestra con roba che distrae.

Le pratiche concrete:

• Non incollare file interi quando puoi indicare un percorso e una riga. La maggior parte degli strumenti moderni ha comandi per leggere file specifici: usali.
• Chiudi le schede residue del progetto se usi un IDE. Ogni file aperto contribuisce al rumore di fondo che il modello deve processare.
• Nuovo thread per ogni task. Il contesto di una sessione precedente non scompare: resta come rumore residuo. Un task di refactoring e uno di bugfix non devono coesistere nella stessa conversazione.
• Chunking dei task grandi. Un task che tocca 15 file è un task di 15 sotto-task. Ogni sotto-task ha il suo contesto focalizzato.

Un ben configurato AGENTS.md riduce gli output token del ~20% perché dà al modello le coordinate prima che le chieda.

Non è solo questione di quantità: è di densità informativa. Un contesto di 500 token ben calibrato batte 5000 token di rumore.

Il codice come contesto ad alta densità 📝

Il contesto più efficiente è il codice stesso — ma solo se il codice è leggero da leggere. Questo significa:

• Nomi descrittivi: una funzione chiamata processData non dice nulla; normalizeUserEmails dice tutto. Il modello si orienta meglio quando i nomi portano informazione semantica.
• Funzioni brevi: una funzione di 20 righe è un’unità di contesto che il modello può processare in blocco. Una funzione di 200 righe è un labirinto in cui il modello perde il filo.
• Coesione: file che fanno una sola cosa bene forniscono contesto prevedibile. Il modello impara la struttura del progetto più velocemente quando i moduli sono coerenti.

La leggibilità del codice non è un lusso estetico: è il formato di compressione più efficace per il contesto di un LLM.

Un modello che riceve codice pulito fa meno domande, genera suggerimenti più mirati e commette meno errori di contesto. Non è magia: è informazione densa che entra nel prompt senza rumore.

Cache e stabilità della sessione ⚡

La sessione di lavoro con un agente ha una dinamica propria, e gestirla male ha costi concreti:

• Non cambiare modello a metà task. Ogni modello ha un “stato interno” leggermente diverso — pattern di ragionamento, gestione degli errori, lunghezza delle risposte. Cambiare a metà è come cambiare il pilota durante una curva.
• Mantieni istruzioni e skill stabili. Se hai definito delle regole in AGENTS.md o in una skill, non alterarle a metà sessione. Le istruzioni sono il vincolo che tiene il modello sul binario.
• Output costa più di input. Un singolo token di output costa tipicamente 3-5x un token di input. Questo significa che ogni riga di contesto inutile che aggiungi non solo distrae — aumenta il costo della risposta.

La gestione dello stato è implicita nella maggior parte degli strumenti: il modello non ricorda la sessione precedente (a meno che tu non lo forzi con copia-incolla). Ma questo è un vantaggio: puoi resettare il contesto quando il task cambia, senza residui.

La stabilità del contesto non è rigidezza: è la garanzia che il modello lavori con le stesse regole dall’inizio alla fine del task.

Quando NON usare l’agente ⛔

• Task dove il contesto è troppo ampio per entrare in una singola sessione — frammentali prima, poi delega.
• Situazioni dove il codice è troppo opaco — se non riesci a spiegare il contesto nemmeno tu, il modello non farà miracoli.
• Quando il contesto cambia continuamente — refactoring in corso, dipendenze instabili, branch in conflitto. Aspetta che si stabilizzi.

Checklist finale ✅

• Ho indicato i file e le righe specifiche, oppure ho incollato l’intero contenuto?
• Il thread è dedicato a un singolo task, o ci sono conversazioni precedenti che residuano?
• I task complessi sono stati scomposti in sotto-task con contesto focalizzato?
• Il codice è leggibile — nomi descrittivi, funzioni brevi, coesione?
• Ho evitato di cambiare modello o istruzioni a metà sessione?

Approfondimenti 📚

• Blog: Context engineering — il fondamento teorico di tutto questo.
• Blog: Maintain a rich context — come costruire e mantenere un contesto denso nel tempo.
• Scrivere prompt che funzionano — il livello precedente: il prompt è il veicolo del contesto.
• Blog: Modularity = less tokens — la modularità come forma di compressione del contesto.