C'è un pattern che chiunque lavori con Claude Code, Cursor o strumenti simili per più di due settimane riconosce, anche se magari non l'ha mai messo a fuoco: le prime sessioni su un progetto nuovo sono quasi magiche. L'AI capisce in fretta, propone soluzioni sensate, il codice funziona quasi sempre al primo colpo. Poi, dopo la decima o la ventesima sessione, qualcosa cambia. Le risposte cominciano a contraddire scelte fatte due settimane prima. Compaiono due modi diversi di fare la stessa cosa nello stesso file. Un bug che pensavi risolto ritorna, perché l'AI ha rimesso mano a una funzione senza sapere che era già stata corretta per un motivo preciso.
La reazione istintiva è pensare che il modello "stia peggiorando", o che serva un modello più potente. Nella maggior parte dei casi non è questo il problema. Il problema è più semplice e meno raccontato: il contesto che l'AI ha del tuo progetto non cresce insieme al progetto. Resta fermo, o peggio, si degrada.
Cosa succede davvero sessione dopo sessione
Un modello linguistico non ha memoria propria tra una sessione e l'altra (ne parliamo più a fondo qui). Ogni volta che apri una nuova conversazione, riparte da quello che gli fai leggere in quel momento: i file del progetto, magari un file di istruzioni tipo CLAUDE.md, e quello che scrivi nel prompt. Tutto il resto, ogni decisione presa insieme nelle sessioni precedenti, è perso a meno che non sia finito da qualche parte di persistente.
Nelle prime sessioni questo non si nota, perché il progetto è piccolo: leggere tutto il codice esistente basta a ricostruire il contesto necessario. Ma un progetto che cresce accumula anche decisioni che non sono scritte nel codice. Perché hai scelto quella libreria e non un'altra. Perché quella funzione sembra scritta in modo strano ma è un workaround per un bug specifico di una dipendenza. Quale pattern segue il resto della codebase, anche se in quel file particolare non è ancora stato applicato. Queste informazioni vivono nella tua testa, non nel codice, e un'AI che legge solo i file non ci arriva.
Il risultato è quello che si può chiamare debito di contesto: la differenza tra quello che l'AI dovrebbe sapere per lavorare bene sul progetto e quello che effettivamente riesce a ricostruire leggendo solo i file. Più il progetto cresce, più quel divario si allarga, e più le proposte dell'AI iniziano a discostarsi da come il progetto è pensato davvero.
Non è (solo) un problema di "prompt migliori"
Una risposta comune è: scrivi prompt più dettagliati, spiega meglio il contesto ogni volta. È un cerotto, non una cura. Funziona per una sessione, ma il costo di ricostruire il contesto a voce ricade su di te ogni singola volta, e cresce con la complessità del progetto invece di diminuire. Un altro rimedio comune, allungare il file di istruzioni del progetto con sempre più dettagli, funziona fino a un certo punto e poi comincia a soffrire dello stesso problema di ogni contesto troppo lungo: informazioni chiave in mezzo a molte altre pesano meno di quanto dovrebbero, semplicemente perché il modello fatica a distribuire attenzione uniforme su un testo molto lungo.
Il punto non è "spiegare meglio". È smettere di affidarsi solo alla rispiegazione, e dare all'AI un posto dove il contesto rilevante è già organizzato e recuperabile su richiesta, invece che riversato per intero ogni volta.
I tre sintomi da riconoscere prima che diventino un problema serio
Codice duplicato con logica leggermente diversa. Due funzioni che fanno praticamente la stessa cosa, scritte in momenti diversi, perché l'AI non sapeva che la prima esisteva già.
Decisioni architetturali reversibili senza preavviso. Una scelta presa con un motivo preciso (un formato di dati, uno schema di autenticazione, una struttura di cartelle) viene silenziosamente cambiata in una sessione successiva, perché quel motivo non era scritto da nessuna parte che l'AI potesse leggere.
Bug risolti che ritornano. Il caso più frustrante: un problema corretto con un fix mirato, che ricompare perché una sessione futura tocca lo stesso codice senza sapere che quel dettaglio era già stato affrontato.
Nessuno di questi tre è un segnale che "il modello è peggiorato". Sono tutti segnali che il progetto ha accumulato più contesto implicito di quanto l'AI riesca a recuperare dai soli file.
Cosa aiuta davvero
La differenza pratica che abbiamo visto funzionare, e su cui è costruito il VibeCoded Orchestrator, è separare due cose che spesso si confondono: il codice, che descrive cosa fa il progetto, e le decisioni, che descrivono perché è fatto in un certo modo. Le prime vivono bene nei file sorgente. Le seconde hanno bisogno di un posto proprio, ricercabile, che sopravviva alle sessioni: un knowledge graph con nodi collegati tra loro, non un altro file di testo che cresce all'infinito.
Non è un cambiamento che si vede il primo giorno. Si vede al mese tre, quando riapri il progetto dopo una pausa, o quando un collega ci mette mano per la prima volta, e la domanda "perché è fatto così?" ha già una risposta scritta da qualche parte, invece di doverla ricostruire leggendo commit vecchi o chiedendo in giro.
Se vuoi la guida pratica per collegare questo tipo di memoria al tuo progetto, passo per passo, è qui.