Succede sempre nello stesso momento. Stai lavorando da un'ora, Claude Code ha appena capito come è strutturato il tuo progetto, e poi chiudi la sessione per pranzo. Il pomeriggio riapri, fai una domanda che sembra ovvia visto quanto discusso la mattina, e ricevi una risposta che ignora tutto. Non è un bug. È come funziona un modello linguistico, e capire perché aiuta a smettere di combatterlo.
Cosa c'è davvero dentro una "sessione"
Un modello come Claude non ha una memoria nel senso in cui la intendiamo per una persona. Ogni volta che gli invii un messaggio, l'intera conversazione fino a quel punto (il tuo prompt di sistema, i file che ha letto, i comandi che ha eseguito, le tue domande e le sue risposte) viene reimpaginata in un unico blocco di testo e data in pasto al modello da capo. Non c'è uno stato persistente nella sua "testa" tra un messaggio e l'altro: c'è solo quel blocco di testo, chiamato finestra di contesto, che cresce a ogni scambio.
Quando chiudi la sessione, quel blocco di testo scompare. Non viene salvato da nessuna parte a meno che tu (o lo strumento che stai usando) non lo scriva esplicitamente su disco. Riaprendo il giorno dopo, Claude Code parte con una finestra di contesto vuota, o quasi: sa cosa c'è scritto nei file del progetto, se glieli fai leggere di nuovo, ma non sa cosa avete deciso insieme ieri, a meno che quella decisione non sia finita da qualche parte nel codice o in un file di testo.
Il problema non è la memoria a breve termine, è quella a lungo termine
Dentro una singola sessione, finché la finestra di contesto non si riempie, Claude Code si comporta bene: ricorda cosa hai detto dieci minuti fa, tiene traccia dei file aperti, capisce i riferimenti impliciti ("quella funzione di prima"). Il problema comincia quando la sessione finisce, oppure quando il progetto è abbastanza grande che rispiegare tutto da capo ogni volta costa più tempo di quanto ne faccia risparmiare l'AI.
Qui entra in gioco un secondo limite meno discusso: anche dentro la stessa sessione, più la finestra di contesto si riempie, più il modello fatica a dare peso uniforme a tutto quello che contiene. È un fenomeno documentato e noto come "lost in the middle": le informazioni all'inizio e alla fine della finestra vengono pesate meglio di quelle nel mezzo. Un progetto con una storia lunga di decisioni architetturali, se rimesso tutto in coda ogni volta, non garantisce che il modello dia davvero peso a un vincolo deciso tre giorni prima solo perché "è scritto da qualche parte" nel contesto.
Le soluzioni che non risolvono il problema
La reazione più comune è compensare a mano: tenere un file di note personali, ricopiare pezzi di conversazioni precedenti, scrivere riassunti prima di chiudere. Funziona, in un senso limitato: il contesto sopravvive, ma il costo di mantenerlo ricade tutto su di te. Ogni sessione nuova diventa un rito di ricostruzione manuale, e più il progetto cresce, più quel rito si allunga.
Un'altra reazione comune è allungare semplicemente il prompt di sistema, incollando dentro sempre più contesto del progetto a ogni richiesta. Funziona finché il progetto è piccolo. Superata una certa soglia, non solo il costo per richiesta cresce (più testo nella finestra di contesto significa più token da processare, e i token si pagano), ma si torna dritti nel problema del "lost in the middle": più contesto grezzo non è la stessa cosa di più contesto rilevante.
Cosa cambia con una memoria esterna strutturata
L'alternativa che gira negli strumenti più recenti (incluso il nostro) non prova a far ricordare di più al modello. Prova a smettere di chiedergli di ricordare, e a dargli invece un posto dove cercare.
L'idea è semplice: invece di riversare tutta la storia del progetto nella finestra di contesto a ogni sessione, un sistema esterno (un knowledge graph, nel nostro caso, gestito dal VibeCoded Orchestrator) tiene le decisioni, i pattern e i vincoli del progetto come nodi ricercabili. Quando serve, l'AI interroga quel sistema con una domanda mirata ("cosa abbiamo deciso sull'autenticazione?") e riceve indietro solo ciò che è rilevante, non l'intera cronologia. Il contesto torna piccolo e mirato invece che grande e diluito, e questo aiuta proprio il problema del "lost in the middle": meno rumore nella finestra, più peso a ciò che conta davvero.
Non è una soluzione che elimina il limite strutturale dei modelli linguistici, quello resta: nessun modello ha oggi una memoria persistente nativa tra sessioni diverse. Ma sposta il lavoro di mantenimento del contesto da "rispiegare tutto a mano ogni volta" a "scrivere una volta, in un posto strutturato, e lasciare che sia l'AI a cercarlo quando serve". La differenza pratica, su un progetto che vive per mesi, è tra passare i primi dieci minuti di ogni sessione a fare da segretaria del contesto o passarli a lavorare.
Se vuoi capire più a fondo come funziona un knowledge graph applicato al coding con AI, e perché è diverso da un semplice database vettoriale, ne parliamo in dettaglio nell'articolo su knowledge graph e AI coding. Se invece vuoi subito i passi pratici per collegarne uno al tuo progetto, la guida operativa è qui: come dare memoria persistente a Claude Code.