Angolo

Dare una memoria a un assistente di sviluppo non significa scegliere un posto in cui scrivere: significa ripartire cinque decisioni — dove risiede la memoria, che cosa vi si trattiene, quando la si condensa, con quale cadenza la si scrive e quando la si rilegge. Quattro di esse si automatizzano senza perdite; la quinta, il ricaricamento, deve restare un'azione umana, perché è l'unica che consuma la risorsa scarsa di una sessione. Una memoria fallisce per questa ripartizione molto prima di fallire per il suo formato: un file Markdown ripartito male non vale più di un database, e una ripartizione giusta funziona con entrambi.

Sintesi

Il problema di partenza sembra un problema di archiviazione. Claude Code dimentica tutto tra una sessione e l'altra, quindi bisogna scrivere da qualche parte ciò che dovrebbe sapere. La questione sembra chiusa appena si è scelto il formato: file Markdown nel repo git invece di una directory nascosta sulla macchina.

In realtà questa scelta risolve una sola delle decisioni, ed è l'unica del tutto reversibile. Le altre quattro si pongono dopo, e ciascuna decide tra un umano e una macchina.

Che cosa si trattiene non si indica più a mano. Un modello leggero rilegge ogni scambio e decide da solo che cosa entra nel log del giorno e che cosa sale nella memoria a lungo termine. La decisione non è scomparsa: è passata dall'azione al testo — un prompt, delle sezioni imposte, un'istruzione di deduplicazione. Questo spostamento è il punto più discutibile dell'intero dispositivo, perché contraddice una posizione meglio fondata altrove, secondo cui ciò che dà valore a una persistenza è proprio che un umano abbia detto «questo conta». Le due reggono, ma non per lo stesso volume: venti scambi al giorno non si selezionano a mano.

Quando si condensa non è lasciato nemmeno alla buona volontà. Un tetto di trecento righe su long_memory.md fa scattare il consolidamento, ed è il vincolo di dimensione — arbitrario, e assunto come tale — a creare l'occasione di rileggere. Senza di esso, la manutenzione resta un'intenzione.

Con quale cadenza si scrive è imposto dal punto di aggancio scelto, ed è lì che comincia l'errore. Un hook chiamato Stop evoca una fine di sessione; si innesca dopo ogni turno. Questa frequenza decide poi tutto ciò che è sostenibile: il modello scelto, la durata accettabile, il budget per esecuzione. Una soglia trascurabile — meno di un dollaro al mese — non compra un risparmio, compra la scomparsa di una domanda, e un'automazione su cui si discute a ogni scambio finisce per essere spenta.

Quando si rilegge è l'unica decisione che non è stata ceduta. Scrivere non costa nulla a nessuno; caricare occupa la finestra di una sessione, e iniettare d'ufficio la memoria di un progetto in una sessione aperta per tre righe peggiora la risposta. Da qui /memory_load a mano, che sembra una limitazione ed è una scelta ponderata.

Restano i guasti propri di questa configurazione, e nemmeno loro vengono dal formato. Un automatismo che chiama lo strumento di cui sorveglia la fine si risveglia da solo. Un agente di servizio lanciato dalla directory del progetto eredita le regole di scrittura di quel progetto e smette di restituire la struttura che gli si chiede. Due difetti di progettazione, due decisioni ripartite male tra ciò che l'automatismo fa e ciò che deve riconoscere.

Ciò che l'insieme mostra: un sistema di memoria non si giudica da ciò che conserva, ma dal posto in cui ogni decisione è stata collocata — e si può spostare tutto tranne l'ultima.

Tensioni / contraddizioni

La contraddizione principale riguarda chi indica ciò che sopravvive. Una posizione stabilita altrove sostiene che il valore di una persistenza sta nell'atto con cui un umano dice «questo conta», e che una conservazione esaustiva non indica nulla; questo sistema delega la selezione a un modello, secondo un criterio scritto una volta per tutte. La linea di demarcazione non è tracciata: sembra dipendere dal volume e dalla tolleranza alla perdita silenziosa, ma nulla qui dice dove passi esattamente.

Seconda tensione, meno visibile: la memoria è scritta nel repo per essere ispezionabile e correggibile a mano, ma è prodotta a una cadenza che rende improbabile questa rilettura. L'ispezionabilità è reale come proprietà, incerta come pratica.

Domande

• Come si trasferisce una ripartizione di questo tipo a un team, dove la memoria scritta da uno diventa il contesto ricaricato da un altro?
• Quale segnale permetterebbe di sapere che un criterio di selezione delegato ha cominciato a scartare ciò che contava?