Save Early, Save Often: la memoria di progetto per lavorare con l’AI

Ultimo aggiornamento: 19 Agosto 2026 — di Marco Regazzo

In breve. Ogni chat con un assistente AI vive dentro una finestra di contesto finita. Quando si riempie viene compressa, e quando la chiudi sparisce: restano le conclusioni, si perde il perché. La conseguenza è che a ogni ripresa ripaghi il contesto in token e riprendi gli stessi errori. La soluzione non è uno strumento nuovo: è un’abitudine vecchia di quarant’anni, presa dai videogiochi. Salvare presto e salvare spesso — ma salvare la memoria di progetto, non la conversazione.

Da dove arriva «Save early, save often»

Chi ha usato un computer negli anni Ottanta lo riconosce senza bisogno di spiegazioni: è un meme da videogiocatori, stampato su magliette e schermate verdi a 8 bit.

Serviva perché allora il salvataggio automatico non esisteva. C’erano un floppy, una presa della corrente e la certezza statistica che prima o poi qualcosa si sarebbe piantato: un crash, un blocco, uno sbalzo di tensione. Non c’era il cloud, non c’era la cronologia delle versioni, non c’era nessuno da chiamare. Sei ore di partita sparivano e si ricominciava dall’inizio.

Da lì la regola: salva presto, salva spesso. Non alla fine, non «quando ho finito». Presto, e ripetutamente.

Poi sono arrivati l’autosave, il salvataggio continuo e il versionamento, e quella disciplina è diventata un ricordo divertente. È il momento esatto in cui è tornata utile.

Perché riguarda chi lavora con l’AI

Un assistente AI non ha memoria nel senso in cui la intendi tu. Ha un contesto: una finestra di lavoro finita, dentro la quale sta tutto ciò che sa in quel momento — le tue istruzioni, i file che gli hai dato, quello che vi siete detti.

Quella finestra si misura in token, che sono i pezzi di testo con cui il modello ragiona (all’incirca, una parola comune vale un token; una parola lunga o tecnica ne vale due o tre). E ha un tetto.

Quando il contesto si riempie, viene compresso

Le conversazioni lunghe non si fermano: vengono compattate. Il sistema tiene un riassunto e scarta il resto.

Il problema è cosa finisce nel riassunto. Sopravvivono le conclusioni («abbiamo scelto l’opzione B»). Sparisce tutto il resto: perché avete scartato la A, quale verifica sembrava valida e invece mentiva, quale scorciatoia avete provato alle undici di sera prima di scoprire che rompeva un’altra cosa.

Cioè sparisce esattamente la parte che è costata tempo.

Quando chiudi la chat, non resta niente

La conversazione può restare consultabile, ma non è memoria operativa: non viene riletta da sola all’apertura di una chat nuova, e nessun altro nella tua azienda andrà a scorrersi quattrocento messaggi per capire cosa avevate deciso a marzo.

Il risultato lo conosci se lavori così tutti i giorni. Riapri dopo due settimane, rispieghi il progetto da capo, e l’assistente ti ripropone con entusiasmo la soluzione che avevate già provato e buttato. Non è una sua colpa: nessuno gli ha mai detto che era stata buttata.

I due costi che paghi senza vederli

Il costo in token

Ogni ripartenza è un investimento di contesto che rifai da zero. «Allora ti spiego: il progetto è questo, il cliente vuole quello, abbiamo deciso così, e attento che quella cosa lì non funziona.» Sono token, e li ricompri ogni volta.

Trenta o quaranta messaggi per rimettere in piedi una situazione che un file da due pagine consegna in tre secondi. Su un progetto seguito per mesi, moltiplicato per ogni chat nuova, il conto smette di essere trascurabile — in denaro se paghi a consumo, in tempo sempre.

C’è anche un effetto collaterale meno ovvio: più contesto bruci per raccontare il passato, meno finestra ti resta per il lavoro di oggi. La chat si compatta prima, e ti ritrovi nella condizione di partenza.

Il costo in allineamento

È il più caro, ed è quello di cui non parla nessuno.

Una chat è individuale. Vive nel tuo account, nella tua sessione, con il tuo modo di dire le cose. Il collega che deve prendere in mano il progetto mentre sei in ferie non ce l’ha. L’agenzia esterna non ce l’ha. Tu stesso, fra sei mesi, praticamente non ce l’hai.

Un file di memoria invece si apre, si legge, si passa, si commenta e si corregge. È la differenza fra un rapporto privato con una finestra di testo e un lavoro di squadra.

Il vero prodotto di una sessione di lavoro con l’AI non è la risposta che hai ottenuto: è quello che avete capito insieme. Se quella parte non esce dalla conversazione, non esiste.

Che cos’è SOSE

SOSE — Save Often, Save Early — è la procedura che usiamo per trasformare ciò che è stato fatto e appreso in una chat di lavoro in una memoria durevole che vive nella cartella del progetto, non nella conversazione.

L’obiettivo, detto per intero, è uno solo: che chi riprende il lavoro fra sei mesi — un collega, o l’assistente in una chat nuova — non debba ripartire da zero né ripagare i bug già pagati.

Produce due file:

File	Cosa è	A cosa serve
MEMORIA_<AREA>_<PROGETTO>.md	Il manuale	Decisioni, ragionamenti, problemi e fix di quell’area
CLAUDE.md (o equivalente)	L’indice	Dice a chi arriva quali manuali esistono e quando aprirli

Notare il singolare-plurale: una memoria per area, non un file unico. Un progetto ha più fronti — il tracciamento, i contenuti, le performance — e un file gigante non lo aggiorna nessuno. Se la memoria di quell’area esiste già, si aggiorna: si integra il nuovo, si corregge il superato, non si duplica. Due memorie sullo stesso tema sono peggio di nessuna, perché nessuno sa quale sia quella buona.

Il principio è nel nome: si salva a fine lavoro, ma prima di archiviare o di far compattare il contesto. Se la conversazione è già stata compressa, una parte della verità è andata e la memoria uscirà più povera — e in quel caso va scritto che è incompleta, invece di far finta di niente.

C’è anche un momento in cui SOSE va proposta senza aspettare che qualcuno la chieda: quando una sessione ha prodotto decisioni non ovvie, bug risolti o configurazioni delicate. Sono esattamente le cose che nessuno ricorda e che costano care due volte.

SOSE non è la memoria di Claude, e non è la cartella del progetto

Qui va sciolto un equivoco, perché è il motivo per cui in tanti pensano di avere già risolto il problema. Ci sono tre meccanismi diversi che sembrano fare la stessa cosa — ricordare — e ne fanno tre completamente diverse.

1. La compattazione del contesto: non è memoria

Su Claude è una funzionalità dichiarata: quando la conversazione si avvicina al limite della finestra, il modello riassume i messaggi precedenti per fare spazio ai nuovi (release note del 24 novembre 2025). L’unico segnale che ricevi è che Claude mostra di stare «organizing its thoughts». La cronologia della chat resta consultabile: è il contesto attivo a essere compresso. Dettaglio poco noto: la compattazione automatica richiede che l’esecuzione di codice sia abilitata.

Su ChatGPT, invece, il comportamento in caso di overflow non è documentato ufficialmente: le pagine di supporto dichiarano le finestre di contesto dei modelli, ma non cosa succede quando le superi. Diffida di chi te lo racconta con sicurezza.

In ogni caso: la compattazione la decide il modello senza chiederti niente, e muore con la conversazione. Non è un oggetto, non si esporta, non si passa a nessuno.

2. La memoria interna del modello: ricorda chi sei, non cosa avete deciso

È la funzionalità «memoria» dentro Claude e ChatGPT, ed è utilissima — ma fa un mestiere diverso.

Claude la gestisce come un insieme di voci individuali e categorizzate che legge e aggiorna mentre chatti (architettura in vigore dal 10 luglio 2026). Va attivata, si ispeziona, si corregge e si cancella voce per voce. Ed è isolata per progetto: ogni progetto ha il suo spazio di memoria separato, per scelta di sicurezza.

ChatGPT dal 4 giugno 2026 usa un sistema che OpenAI chiama dreaming: gira in background, sintetizza da molte conversazioni e cattura il contesto «senza che tu debba chiedere esplicitamente di ricordare qualcosa». Le vecchie saved memories — quelle che scrivevi tu — sono ormai indicate come legacy.

I limiti li dichiarano i fornitori stessi, e sono i due che contano:

• Non la vedi tutta. OpenAI scrive che il riepilogo della memoria «non includerà tutto ciò che ChatGPT ricorda in base alle tue chat»: esistono elementi che influenzano le risposte e non compaiono nel pannello. E indica staleness e correctness fra i problemi che il nuovo sistema mitiga ma non elimina — cioè la memoria può essere vecchia o sbagliata.
• Non si passa a un collega. Su Claude l’esportazione è artigianale (chiedere al modello di trascrivere le proprie memorie) e l’importazione è dichiarata sperimentale. Su ChatGPT le fonti di memoria non vengono incluse nelle chat che condividi. Su Perplexity, invitare qualcuno in un progetto non gli dà accesso alla tua memoria: ogni task gira con le credenziali di chi lo lancia.

È un acceleratore personale. Opaco, e tuo.

3. Il «Progetto»: è la cartella, e resta ferma dove l’hai lasciata

Claude Projects, ChatGPT Projects, Perplexity Projects — che dal 2026 hanno sostituito gli Spaces, con migrazione automatica. Contengono i file che carichi tu, le istruzioni personalizzate e la cronologia. È l’unico dei tre pensato fin dall’inizio per essere condiviso: Claude sui piani Team ed Enterprise, ChatGPT su tutti i piani, Perplexity con ruoli e permessi.

Su Claude il funzionamento è documentato: finché la knowledge base sta nella finestra di contesto entra tutta; quando la supera si attiva da sola una ricerca che recupera solo i pezzi rilevanti. Su ChatGPT il meccanismo non è documentato — e quindi non va dato per scontato.

Ma il punto è un altro, ed è il difetto che riguarda tutti:

I file di progetto non si aggiornano da soli. Restano alla versione che hai caricato. Se la decisione cambia il martedì, il progetto lo sa solo se glielo dici tu. L’unica eccezione fra i tre è Perplexity, che con Brain rielabora file e sessioni fra un task e l’altro.

Dove sta SOSE, allora

Il progetto è la cartella. La memoria interna è l’assistente che si ricorda di te. SOSE è il verbale di cosa è successo: la disciplina che tiene la cartella allineata a quello che accade dopo averla creata.

	Chi la scrive	Si aggiorna da sola	Si passa a un collega
Compattazione del contesto	il modello, senza chiedere	sì, ma muore con la chat	no
Memoria interna del modello	il modello	sì	no
File caricati nel progetto	tu	no	sì
Memoria SOSE	tu, a fine lavoro	no: la aggiorni apposta	sì

SOSE non compete con nessuno dei tre. Vive dentro il terzo e ne cura il difetto.

E per onestà, il caso in cui non serve: se quello che ti manca è che l’assistente ricordi che scrivi in italiano, che preferisci le tabelle e che lavori nel settore eventi, quella è esattamente la memoria interna, funziona bene e SOSE è sovradimensionata. SOSE serve quando ci sono decisioni con un perché e problemi già pagati che non vuoi ricomprare.

Gli otto principi

La skill è solo la confezione. Se ne prendi i principi puoi costruirti la tua versione con qualunque assistente.

1. È un manuale, non un diario. «Prima abbiamo fatto A, poi B, poi C» non lo rilegge nessuno. Si scrive per chi arriva fra sei mesi senza sapere niente — e quel qualcuno, statisticamente, sei tu.
2. Il perché vale più del cosa. Registrare la decisione senza il ragionamento produce obbedienza, non competenza. Chi legge deve poter dissentire con cognizione: significa scrivere anche le alternative scartate e il motivo per cui sono state scartate.
3. I guasti valgono più dei successi. La sezione più importante non è cosa ha funzionato: è cosa si è rotto. Per ogni problema servono quattro righe — sintomo (cosa si vede), causa reale, perché ci ha ingannati, fix. Numerali, così l’indice può rimandarci.
4. Le diagnosi sbagliate si scrivono, non si nascondono. È il principio che fa la differenza fra una memoria utile e un curriculum. Se hai dato la colpa alla cosa sbagliata per due settimane, quello va scritto: è ciò che impedisce di rifarlo. Una memoria che racconta un lavoro lineare è una memoria che mente.
5. Concreto, mai generico. «Abbiamo migliorato le performance» non serve a niente. «Abbiamo escluso X da Y perché altrimenti Z» sì. Nomi di file, ID, comandi, numeri veri.
6. Se qualcosa è fragile, scrivi come si romperà. E se ha funzionato per coincidenza invece che per costruzione, scrivi anche quello.
7. Mai una data ambigua. «Ieri», «la settimana scorsa», «di recente» fra sei mesi non significano nulla. E soprattutto: la data del lavoro non è la data in cui scrivi la memoria. Se stai archiviando una chat di tre settimane fa, la memoria deve dire quando è stato fatto il lavoro e in base a quale indizio verificabile l’hai stabilito — un timestamp visto in una dashboard, la data di modifica di un file, un log. L’orologio di sistema dice solo quando stai scrivendo.
8. Ogni output va tracciato. La memoria chiude con un Registro degli output: nome esatto e percorso assoluto di ogni file prodotto o modificato nella sessione, cosa serve, se è bozza o definitivo, e — cruciale — se quella copia è durevole o effimera. È la sezione che impedisce al deliverable di sparire: «nella cartella» non è un percorso, e un file consegnato in chat non è un file salvato. Se in una sessione non è stato prodotto nulla, si scrive che non è stato prodotto nulla: la sezione non si salta mai.

La procedura, passo per passo

Passo 0 — Decidere dove e cosa

Prima di scrivere una riga, si stabiliscono tre cose.

Dove. La cartella del progetto, quella che sopravvive alla sessione. Mai una cartella temporanea: una memoria in uno scratch è un lavoro buttato con un ritardo.

Quale area. Se una memoria per quell’area esiste già, si aggiorna: si integra il nuovo, si corregge il superato, non si duplica. Due memorie sullo stesso tema è peggio di nessuna, perché nessuno sa quale sia quella buona.

Quando è stato fatto il lavoro. Con un indizio verificabile, dichiarato nel file. Se gli indizi si contraddicono, si scrive qual è il dubbio invece di sceglierne uno a caso.

Quali file sono usciti dalla sessione. L’inventario si fa prima di scrivere, verificando i percorsi reali invece di ricordarli. È quello che diventerà il Registro degli output.

Passo 1 — Scrivere la memoria

Struttura da coprire, adattando i titoli al contenuto:

1. Intestazione con doppia data — memoria generata il / conversazione originale del / come è stata datata. Più autore, perimetro e le regole d’oro del progetto in cima: i vincoli dichiarati che non si violano mai.
2. Il problema di partenza — cosa era stato chiesto, incluso ciò che è emerso strada facendo e non era nella richiesta. Quasi sempre è la parte più preziosa.
3. Decisioni e ragionamento — con le alternative scartate.
4. Regole non negoziabili — cosa non va toccato, spostato o «ottimizzato», e cosa succede se qualcuno lo fa.
5. I guasti, numerati — sintomo, causa reale, perché inganna, fix.
6. Registro degli output — la tabella di ogni file prodotto o modificato: nome, percorso assoluto verificato, formato, a cosa serve, stato. Inclusi i backup iniziali.
7. Procedura e collaudo — l’ordine delle operazioni, cosa non si può invertire, e come si verifica davvero il risultato. Inclusi i modi di verificare che sembrano validi e mentono.
8. Cosa aspettarsi nei dati nelle settimane dopo, così nessuno scambia un effetto previsto per un guasto.
9. Aperto / da fare.

Passo 2 — Aggiornare l’indice

L’indice è il file che l’assistente incontra per primo quando lavora in quella cartella. Per ogni area deve dire, in due o quattro righe: prima di toccare quest’area, leggi il file di memoria di quell’area — più le regole d’oro e le trappole peggiori.

Non ci si copia dentro l’intera memoria: l’indice serve a mandarti al manuale giusto, non a sostituirlo. E se aggiorni una regola nella memoria, allinei la sintesi nell’indice nello stesso passaggio. Un indice che diverge dal manuale è peggio di un indice assente, perché è credibile.

Passo 3 — Chiudere onestamente

Due cose da dire a voce alta a fine procedura: quali file sono stati scritti e dove, e la verità sulla persistenza.

Perché c’è un equivoco diffuso: un file nella cartella non viene letto automaticamente in ogni chat nuova. Viene raccolto quando l’assistente lavora in quella cartella. La garanzia vera è agganciare la memoria (o l’indice) alle istruzioni del progetto nel pannello dello strumento che usi: quello sì viene iniettato in ogni conversazione.

È il passo che salta sempre. Ed è quello che rende inutili tutti gli altri.

Gli anti-pattern

• Il riassunto cronologico. Serve un manuale di riferimento, non il verbale della riunione.
• La versione edulcorata. Vicoli ciechi e diagnosi sbagliate omessi per far sembrare il lavoro lineare.
• Il salvataggio nella cartella sbagliata. Temporanea, scratch, desktop.
• La memoria doppia. Se esiste, si aggiorna.
• L’indice che diverge dal manuale.
• L’autocelebrazione. La memoria serve a lavorare, non a fare bella figura.

I limiti veri

Nessuno racconta i limiti dei propri metodi. Questi sono quelli che abbiamo pagato.

Due chat che salvano insieme si sovrascrivono in silenzio. È il limite più cattivo, perché non dà nessun segnale. Due sessioni aperte contemporaneamente sullo stesso progetto scrivono entrambe sull’indice, e l’ultima vince — riportando una copia vecchia. A noi è successo: l’indice è passato da 106.926 byte a 67.623 e sette aree sono sparite in un colpo, senza un errore a schermo e senza un avviso.

I sintomi da riconoscere: il file cala di dimensione, spariscono sezioni, la data di modifica è più recente della tua ultima scrittura. Le contromisure: una sola sessione scrive; si rilegge il file dal disco immediatamente prima di scrivere, senza fidarsi della copia in sessione; dopo aver scritto si rilegge e si contano le sezioni. E se il file è calato, non si ripristina alla cieca: si fa un recupero sezione per sezione, perché la versione mutilata può contenere l’unica copia aggiornata di qualcosa.

Se la chat è già stata compattata, salvi quello che è rimasto. Non c’è rimedio: si segnala nella memoria che è incompleta e si recupera ciò che si può dai file toccati. È letteralmente il motivo per cui la regola dice early.

Una memoria non si scrive da sola e non si mantiene da sola. Va aggiornata quando le cose cambiano. Una memoria vecchia che sembra attuale fa più danni di una pagina bianca.

Non sostituisce il pensiero. Se le decisioni erano sbagliate, la memoria le tramanderà con precisione notarile.

La ricetta: fatti la tua SOSE

Non serve la nostra. Serve una tua, che parli la lingua dei tuoi progetti. Il minimo sindacale sta in cinque mosse.

1. A fine lavoro, prima di chiudere, chiedi all’assistente la memoria del progetto. Prima di archiviare, non dopo.
2. Imponi la struttura. Regole che non si violano, decisioni e perché, problemi numerati con sintomo-causa-fix, file toccati, cosa resta aperto.
3. Pretendi gli errori. Testuale: «scrivi anche le diagnosi sbagliate e i vicoli ciechi, non farmi sembrare il lavoro lineare».
4. Falla datare con un indizio verificabile, non con l’orologio di sistema.
5. Agganciala alle istruzioni del progetto. Il file in cartella è un promemoria; nelle istruzioni permanenti è memoria.

Se vuoi partire subito, questo prompt funziona così com’è:

Prima di chiudere questa conversazione, scrivimi la memoria di progetto in markdown, da salvare nella cartella del progetto. Non un riassunto cronologico: un manuale per chi riprenderà il lavoro fra sei mesi senza sapere niente. Apri con la data in cui è stato fatto il lavoro e l’indizio verificabile che hai usato per stabilirla, poi le regole che non si violano. Copri: il problema di partenza e cosa è emerso strada facendo; le decisioni e il perché, con le alternative scartate; i problemi incontrati numerati, ognuno con sintomo, causa reale, perché ci ha ingannati e fix; i file toccati e dove stanno; come si verifica davvero il risultato, compresi i controlli che sembrano validi e mentono; cosa resta aperto. Scrivi anche le diagnosi sbagliate. Niente autocelebrazione, niente frasi generiche: nomi di file, numeri e comandi veri.

Vuoi il metodo o vuoi il file?

Sono due cose diverse, e conviene dirlo chiaro invece di far finta che sia una sola.

Il metodo è tuo, gratis, senza cancelli. Tutto quello che serve per costruirti la tua versione è in questa pagina: la procedura passo per passo, gli otto principi, gli anti-pattern, i limiti veri e il prompt pronto da copiare e incollare. Non c’è un pezzo tenuto fuori per costringerti a lasciare qualcosa. Chiudi questa pagina e ce l’hai.

Poi c’è il file già fatto. La skill che usiamo sui progetti veri, pronta da mettere nella cartella: zero lavoro, zero decisioni da prendere. Per quella l’indirizzo email è il pedaggio — ed è l’unico che c’è.

Come funziona: lasci la mail, ti arriva un link di conferma, lo clicchi e parte il download. Nessuna sequenza di vendita, nessuno che ti richiama. Ogni tanto qualcosa che vale la pena leggere, e il link per uscire in ogni email.

Se invece la ricetta qui sopra ti è bastata — ed è il caso più probabile — il modo di dircelo è lasciare un «grazie» nei commenti del post LinkedIn da cui probabilmente sei arrivato. Vale come un download.

Fonti

• Anthropic, Use Claude’s chat search and memory to build on previous context: memoria come voci categorizzate, spazio di memoria separato per progetto, pausa e reset.
• Anthropic, Release notes: compattazione della finestra di contesto (24 novembre 2025); nuova architettura della memoria (10 luglio 2026).
• Anthropic, Retrieval augmented generation (RAG) for projects (16 marzo 2026): passaggio automatico da contesto integrale a recupero selettivo nei progetti.
• Anthropic, Import and export your memory from Claude: export manuale, import dichiarato sperimentale.
• OpenAI, Dreaming: Better memory for a more helpful ChatGPT (4 giugno 2026): nuova architettura di memoria in background; staleness, correctness e scalabilità indicati come problemi mitigati ma non risolti.
• OpenAI, Memory FAQ: il riepilogo non include tutto ciò che il modello ricorda; le fonti di memoria non entrano nelle chat condivise; saved memories come sistema legacy.
• OpenAI, Projects in ChatGPT: contenuto dei progetti, limiti di file per piano, memoria confinata al progetto, condivisione.
• Perplexity, What are Projects? (30 luglio 2026): sostituzione degli Spaces con migrazione automatica; Brain che rielabora file e sessioni fra un task e l’altro; le credenziali restano di chi lancia il task.

Nota di metodo. Queste funzionalità cambiano in fretta e non sono documentate allo stesso modo: dove la fonte ufficiale tace — per esempio sul comportamento di ChatGPT quando il contesto trabocca, o sul meccanismo con cui i file di progetto raggiungono il modello — in questo articolo è scritto che tace, invece di riempire il buco. Verifica sempre sulla documentazione del giorno in cui leggi.

Domande frequenti