Idea principale

Claude Code tiene già una memoria di ciò che gli si è detto, ma la archivia sotto ~/.claude/projects/: appartiene all'installazione, non al progetto. Cambiare computer, rileggerla, sapere quando una certa decisione vi è entrata, condividerla con un collega — nulla di tutto ciò è previsto, perché il luogo in cui viene archiviata non è mai stato pensato come un oggetto di lavoro.

Scrivere la stessa memoria in file Markdown collocati nel repo git del progetto cambia quattro cose in un colpo solo, e tutte derivano dalla stessa scelta. Si sposta con il repo, quindi un clone su un'altra macchina la ritrova. È versionata, quindi git log memory_sessions/ racconta l'evoluzione delle decisioni tecniche. Si apre nell'editor, quindi la si può correggere a mano quando l'agente ha capito male. E si suddivide come si suddivide il repo.

Il formato flat non è una rinuncia tecnica in attesa di meglio: è ciò che rende la memoria ispezionabile da un umano, e una memoria che nessun umano rilegge non viene mai corretta.

Contributo di «I sistemi informativi non spariranno. Cambierà la loro forma.» (2026-07-08). La stessa divisione vale su scala aziendale, e lì il formato conta ancora meno di quanto si creda: Markdown, JSON, base documentale, grafo o database vettoriale vanno ugualmente bene, la linea passa tra ciò che si può spostare e ciò che non si può. Un'intelligenza di lavoro rimasta nelle cronologie delle chat è utile solo finché l'interfaccia esiste, l'abbonamento è attivo e si ritrova la conversazione giusta: è una traccia d'uso, non una memoria aziendale. Il criterio che decide è un elenco di operazioni, non una preferenza estetica — poter essere riletta da un umano, ripresa da un'altra IA, spostata, salvata, arricchita, sottoposta ad audit.

Perché è importante

Sposta la domanda che ci si pone davanti a uno strumento di memoria. Di solito si chiede che cosa trattiene; la domanda che conta per prima è dove lo scrive, perché è questa scelta a decidere tutto il resto — portabilità, storico, rilettura, condivisione.

Spiega anche perché una memoria nativa, anche buona, lascia un vuoto: ciò che vive nello strumento è fuori dalla portata degli strumenti con cui si lavora davvero.

Sfumature e limiti

Collocare la memoria nel repo la rende visibile a chiunque abbia accesso al repo. Ciò che vi si scrive automaticamente — il nome di un cliente, un errore commesso, un'esitazione — diventa un contenuto pubblicato a livello di team, senza che nessuno l'abbia riletto.

E un file versionato si rilegge male quando cresce: l'ispezionabilità dipende dalla dimensione quanto dal formato.

Domande aperte

• Che fare della memoria di un branch abbandonato, scritta per un lavoro che non è mai stato oggetto di merge?