Ogni utente di Claude Code ha assistito all'inizio di una nuova sessione da zero. Apri un sistema che hai costruito la scorsa settimana, chiedi una piccola funzionalità e l'agente inizia ridiscovrendo la tua stessa architettura: quale servizio possiede i dati, quale frontend lo chiama, quale tipo condividono i due. La conversazione che ha spiegato tutto questo è andata persa o compressa in un riassunto, e i file sorgente mostrano ciò che esiste senza dire cosa dipende da cosa.
Finora, la risposta principale è la memoria. Claude Code carica le istruzioni CLAUDE.md e le proprie note di auto-memoria all'inizio di ogni sessione, e dal 17 settembre, i Progetti ridisegnati, in beta nelle sessioni cloud di Claude Code, mantengono una memoria condivisa tra i thread, in modo che Claude possa ricordare che "il rilascio è stato spostato a venerdì" o "chi controllare prima di toccare il servizio di fatturazione". Volevo testare una fonte diversa di contesto: i record di dipendenza che una piattaforma di build scrive quando crea ogni versione di un componente.
Ho chiesto a Claude di costruire su Bit Cloud, una piattaforma che costruisce, ospita e distribuisce anche una singola app dal suo primo componente, con agenti di codifica che lavorano su di essa tramite MCP. Il progetto e i suoi record di build sono pubblici.
Cosa può recuperare una sessione fresca senza memoria?
Il sistema era una piccola console di supporto che avevo costruito con Claude Code in precedenza, e ho scritto come l'ho costruita e distribuita separatamente. Il prompt che ha avviato quella build ha menzionato il tooling in due parole, "usando Bit", e altrimenti ha descritto il prodotto. Ha quattro componenti: un'app React, un servizio Express supportato da MongoDB, un'entità ticket condivisa e un componente della piattaforma che mette l'app e il servizio dietro un gateway. Tutti e quattro sono versionati in una portata pubblica, bit-oss.support, e la console funziona in produzione su HTTPS.
Per testare cosa potevano portare i record da soli, ho aperto una nuova sessione di Claude Code in uno spazio di lavoro vuoto, senza cronologia delle conversazioni e senza codice locale, e ho chiesto:
“Aggiungi la filtrazione per stato del ticket e assegnatario alla console di supporto in bit-oss.support.”
Claude ha controllato lo spazio di lavoro e non ha trovato componenti locali. Il suo messaggio successivo è stato: “Lo spazio di lavoro è vuoto, quindi la console di supporto si trova in remoto. Lasciami leggere la portata bit-oss.support tramite MCP.” Ha chiamato `readscope` per `bit-oss.support`. Questo ha restituito i quattro componenti e le loro dipendenze. Ha quindi chiamato `readcomponents` per l'app, il servizio e l'entità ticket, recuperando riferimenti API e inventari di file prima di importare il codice sorgente o modificarlo.
L'app e il servizio dipendevano entrambi dalla stessa versione dell'entità ticket. La sua documentazione della classe recitava, “condivisa tra il servizio di supporto e l'app rivolta agli agenti”, e il riferimento API includeva quella frase. Il progetto poteva fornire questo contesto senza la conversazione originale.
Claude ha importato tutti e quattro i componenti con `bit import`, ha ispezionato il codice sorgente e ha implementato la filtrazione lato client all'interno dell'app. La convalida ha riportato 41 test superati, tra cui nove nuovi test di filtrazione. MCP ha aiutato a scoprire il sistema; l'ispezione del codice sorgente e i test hanno stabilito come cambiarlo. La modifica è rimasta all'interno dell'app, lasciando l'entità ticket condivisa e il servizio intatti. Sapere cosa è condiviso dice anche a un agente cosa non toccare.
Dove sono finiti i record?
Sono finiti al comportamento. Il riferimento API dell'app elenca le rotte che chiama, `GET /tickets`, `POST /tickets`, `PATCH /tickets/:id` e `POST /tickets/:id/comments`, nella documentazione di un servizio falso che utilizza nei test, ma nulla verifica quell'elenco contro il servizio reale. I record hanno detto a Claude quali componenti condividevano il contratto del ticket; se le rotte su ogni lato corrispondevano ancora doveva essere letto a mano e testato.
Un build verde dimostra anche meno di quanto sembra. I test di integrazione di MongoDB saltano quando il loro database temporaneo non può avviarsi sul runner CI, quindi un build superato non mostra che sono stati eseguiti. Ho controllato la persistenza a mano: creare un ticket, aggiungere un commento, riavviare la piattaforma contro lo stesso database e vedere che entrambi sono ancora lì.
E questo è un demo, con un account demo predefinito e un segreto di firma pubblico. Controllo di concorrenza, migrazioni, procedure di recupero e test di database obbligatori sono tutti ancora da fare. Questo è lavoro di ingegneria ordinario, ed è dove voglio che vada il tempo di un ingegnere.
File di memoria o record di dipendenza?
La memoria contiene ciò che qualcuno ha scelto di scrivere. In Claude Code, questo significa le istruzioni CLAUDE.md (o AGENTS.md) che una persona scrive, e le note di auto-memoria che Claude scrive dalle correzioni e dalle preferenze, e i Progetti ridisegnati aggiungono decisioni, come il motivo per cui un'esportazione è stata eliminata, che nessun sistema di build registrerà mai. Ogni nota è accurata al momento in cui è stata scritta. Claude Code registra l'ora di scrittura di ogni file di memoria, e la sua documentazione spiega perché: “il timestamp mostra quanto è attuale il fatto”.
Il sistema di build scrive un record di dipendenza quando crea una versione di componente, ed è parte di quella versione. Quando l'app di supporto è stata versionata, il sistema di build ha registrato la sua dipendenza da una versione specifica dell'entità ticket, senza che qualcuno decidesse che valesse la pena annotarlo, e il record non può discostarsi dalla versione che descrive. E poiché `read_scope` restituisce ogni componente alla sua versione più recente, i record che Claude ha letto erano aggiornati. Una nota di memoria trasporta l'ora in cui è stata scritta, ma nulla la lega a una versione del codice. Nel test, la sessione non aveva conversazione e nessun codice locale. L'unica memoria nello spazio di lavoro era l'AGENTS.md generico che `bit new` scrive, che dice all'agente di cercare cose sulla piattaforma, e i record hanno fatto il resto: erano sufficienti per trovare il contratto condiviso.
Le due coprono terreni diversi e funzionano meglio insieme: la memoria per l'intento, come la data di rilascio, la persona da chiedere o il motivo per cui una funzionalità è stata tagliata, e i record per la struttura e il significato, quale versione di cosa dipende da quale. Nx serve il suo grafico di progetto agli agenti tramite MCP, e Sourcegraph serve la ricerca e la navigazione del codice tra i repository; entrambi lo fanno bene. Per questo test, volevo qualcosa di più ristretto: un record per componente, scritto quando la sua versione è stata creata, che valga ancora quando l'altra parte di una dipendenza vive in un posto che l'agente non ha indicizzato.
Quando dovrebbe iniziare un team?
Al primo componente. I record in questo test non hanno avuto costi aggiuntivi, perché sono stati scritti mentre ogni versione veniva creata, fin dal primo giorno. Avevo creato lo spazio di lavoro con `bit new`, che ha fornito la connessione MCP di Bit Cloud in `.mcp.json` e un AGENTS.md con istruzioni per l'agente, e all'inizio della build originale Claude ha utilizzato quella connessione per guardare attraverso una portata di design-system esistente per parti che poteva riutilizzare; i quattro componenti ora dipendono da 16 che già esistevano, dieci dei quali da quel design system. Ricostruire quella mappa in seguito, dopo che un team rinomina un campo condiviso e un altro scopre dai suoi log di errore, è la versione costosa dello stesso lavoro.
Nessuno di tutto ciò richiede il nostro prodotto; ha solo bisogno che le dipendenze siano registrate dove avviene il lavoro.
Gli agenti possono già raggiungere la produzione, e ciò che ancora manca, in ogni richiesta dopo la prima, è una vista del sistema che stanno per cambiare. Questa vista è più economica da costruire prima che esista il secondo componente.