Secondo cervello AI: come strutturo Obsidian per i miei agenti
Come ho costruito un secondo cervello AI che recupera davvero: la struttura Obsidian che fa leggere a Claude risposte vere invece di inventarle.
La tua AI non ti conosce
Ogni conversazione con un’AI parte da zero, per quanto riguarda te. Il modello sa tutto quello che internet ha pubblicato e niente dei tuoi clienti, delle tue ultime tre campagne o della decisione che hai preso stamattina. Quel vuoto è l’intero problema, e io l’ho risolto con un secondo cervello AI che sa leggere davvero.
Incollo quaranta pagine di contesto. Lui annuisce. Poi inventa l’unica pagina che ti sei dimenticato di incollare, con sicurezza totale. Uso l’AI ogni giorno nel mio lavoro di marketing, e so dirti esattamente da dove arriva. Ho scritto il resoconto completo qui. La versione breve: il modello non è rotto. È il modo in cui gli consegniamo la nostra memoria che lo è.
Il momento che mi ha fatto scattare è stato banale. Ho chiesto a un modello di un progetto di cui avevamo parlato la settimana prima. Ha risposto liscio, a frasi intere, e metà della risposta era sbagliata. Non aveva memoria della settimana prima, ed era troppo educato per dirlo. Ha tirato a indovinare, e sembrava sicuro. È peggio del silenzio.
Quindi ho smesso di sistemare il prompt e ho cominciato a sistemare la struttura. Ho costruito un vault Obsidian con delle regole dentro, non solo delle note dentro. Il risultato è un agente che recupera risposte vere invece di indovinarne di nuove. Questo articolo è la struttura esatta, con i numeri di un vault che uso ogni singolo giorno.

In sintesi
- La tua AI parte da zero su di te, ogni volta. Nessuna quantità di prompt engineering lo risolve. La soluzione è una memoria che l’agente può leggere, non altre istruzioni.
- Un secondo cervello AI è un problema di routing, non di tooling. Il lavoro avviene in un file di regole e in un indice di recenza, non in un plugin.
- CLAUDE.md è il file che cambia tutto. Vive dentro il vault, così l’agente legge le regole da sé invece di sentirtele dire da te.
- Il retrieval batte le congetture, e la differenza la puoi misurare. Un query log con quattro esiti ti mostra esattamente quando il vault risponde e quando manca.
- L’archivio non è fatto per essere letto. 623 checkbox aperte in 26 file di task vivono in un posto solo, e i file morti vivono in un posto che l’agente non apre mai.
- I plugin Obsidian AI sono quasi tutti rumore. Non ne uso quasi nessuno, e ti dico quali ho tenuto.
Perché ogni guida al secondo cervello AI sbaglia bersaglio
Cerca secondo cervello AI e trovi un certo tipo di pagina. Una carrellata di tool. Una lista di plugin. Una promessa vaga che la macchina organizzerà i tuoi pensieri al posto tuo. Le ho lette tutte prima di costruire il mio, e nessuna descriveva un sistema funzionante.
I primi risultati sono eloquenti. Una storia su LinkedIn. La homepage di un vendor. Un thread su Reddit che chiede perché qualcuno dovrebbe prendersi la briga di avere un secondo cervello. Nessuno mostra un vault vero. Nessuno mostra un layout di cartelle. Nessuno mostra un log delle query e se la cosa ha risposto oppure no. La domanda che chi cerca si sta ponendo non trova risposta in nessuna delle prime dieci pagine.
Ecco cosa sbaglia ogni guida. Tratta l’AI come se fosse il cervello. Assume che la parte difficile sia pensare, e che la macchina se ne occuperà. La parte difficile è l’opposto. Il pensiero ormai costa poco. La parte difficile è il retrieval, il lavoro noioso di trovare il fatto giusto al momento giusto senza inventarne uno nuovo.
Un secondo cervello AI dovrebbe recuperare, non indovinare. Quando un agente risponde a una domanda sul tuo business leggendo le tue note vere, quello è retrieval. Quando risponde facendo la media di tutti i blog che ha letto, quello è indovinare. La maggior parte delle persone ha costruito una macchina che indovina e l’ha chiamata cervello. Le guide li aiutano a costruirla più in fretta.
Nessuno dei primi risultati mostra un sistema con feedback. Nessuno logga le proprie query e segna quali hanno fallito. Nessuno mostra un file che indirizza l’agente alla cartella giusta. La cosa più vicina a una risposta da praticante è un thread su Reddit che fa la domanda di base, il che ti dice che il mercato sta ancora aspettando una risposta dritta da qualcuno che ne gestisce uno.
Le guide si fissano anche sul livello sbagliato. Ti vendono un’app per prendere appunti più intelligente. Il prendere appunti non è mai stato il problema. Il problema è che nessuno legge le note al momento della domanda. Una cartella piena di note brillanti in cui l’agente non sa navigare è un cassetto di fogli, non una memoria.
Se vuoi il livello strategico sopra tutto questo, ho scritto il playbook di AI marketing qui. Questo articolo è l’infrastruttura che ci sta sotto. La parte che tutti saltano, perché è noiosa. Il noioso è dove vive il vantaggio.
Il vault non è un quaderno. È un livello di memoria
La maggior parte delle persone usa Obsidian come usava un quaderno. Scrive note e le archivia da qualche parte. Poi cerca. Funziona per un umano con tempo e una memoria vaga di dove stanno le cose. Fallisce per un agente con una finestra di contesto e nessuna memoria.
Io tratto il vault come un livello di memoria con un indirizzo fisso per ogni cosa. Ogni cartella ha un numero, e il numero è l’ordine. Ecco il layout:
- 00 Inbox: la zona di scarico, dove le catture atterrano prima di essere smistate.
- 10 Daily: un file per giorno, con un log timbrato di cosa è successo.
- 20 Tasks: il lavoro, ogni loop aperto come checkbox.
- 30 Wiki: la conoscenza durevole, la roba curata.
- 40 Notes: pensieri autonomi che non sono né task né wiki.
- 50 Sources: file grezzi, PDF e immagini, immutabili dopo l’atterraggio.
- 60 Output: risultati temporanei, le bozze e i report.
- 90 Archive: dove i vecchi file vanno a dormire, e dove l’agente non va mai.
La numerazione non è cosmetica. È routing. L’agente sa che una domanda sui task parte da 20 Tasks. Una domanda di conoscenza parte da 30 Wiki. Niente parte mai da 90 Archive. Quella sola decisione, codificata in un file, elimina una quantità enorme di congetture prima che accadano.
Ogni cartella si guadagna il suo posto per la regola che vi è associata. 00 Inbox è per le catture che non hanno ancora casa. 10 Daily è la fonte di verità per quello che è successo, timbrata con l’ora. 20 Tasks è dove i loop aperti vivono come checkbox, una per riga. 30 Wiki è il livello curato, l’unica cosa che l’agente cita come fatto. 40 Notes tiene pensieri autonomi che non sono né task né wiki. 50 Sources è materiale grezzo immutabile, PDF e screenshot, mai modificato dopo l’atterraggio. 60 Output è effimero, le bozze e i report che o muoiono o vengono promossi alla wiki. 90 Archive è l’unica cartella che l’agente è istrucito a ignorare.
Un quaderno serve a scrivere le cose. Un livello di memoria serve a ritrovarle su richiesta, da parte di un lettore che non le ha mai viste prima. Quel lettore è il tuo agente. Se la cartella non ha una regola, il lettore indovina, ed è così che l’allucinazione entra.
Un umano può tenere l’intero vault in testa, vagamente, e vagare fino alla nota giusta a memoria. Un agente non può vagare. Ha bisogno di un indirizzo. Le cartelle numerate sono l’indirizzo. Quando chiedo della decisione sul pricing che abbiamo preso a giugno, l’agente non cerca in tutto il vault. Va su 30 Wiki, trova la pagina della decisione, e la cita. Questa è la differenza tra un livello di memoria e un cassetto di fogli.

I tre file che fanno funzionare un secondo cervello AI
Togli i plugin e un secondo cervello AI si riduce a tre file. Tutto il resto è arredamento.
Il primo è CLAUDE.md, il file delle regole. Sta alla radice del vault e dice all’agente come comportarsi prima che tu apra bocca. Il secondo è hot.md, l’indice di recenza. Risponde alla domanda su cui ogni agente continua a fallire: dove ho lasciato questa cosa. Il terzo è _query log.md, il file di misurazione. Registra ogni domanda seria e se il vault ci ha risposto.
Tre file. Uno dice all’agente le regole. Uno dice all’agente cosa è recente. Uno dice a te se l’intera cosa funziona. Nota cosa manca: un database di note. Ce l’hai già. Le note non sono il sistema. Le istruzioni, l’indice e il log sono il sistema.
hot.md è il file che non sapevo di avere finché non mi è servito. La domanda non è dove ho archiviato questa cosa. La domanda è dove ho lasciato il lavoro a metà. Un indice di recenza risponde alla seconda domanda, ed è la seconda che salta fuori in ogni sessione di lavoro.
La maggior parte costruisce la cosa al contrario. Versa mille note in una cartella e si chiede perché l’agente ci anneghi dentro. I tre file sono ciò che trasforma una cartella in un secondo cervello. Le note sono l’inventario, non il motore.

Il sistema hot gira su due livelli
La maggior parte pensa che un indice di recenza sia un file solo. Quello che gestisco io ha due livelli, e il secondo è dove avviene il lavoro vero.
Il livello superiore è hot.md alla radice. È il radar globale. Ha tre sezioni. Active project radar elenca ogni progetto attivo in una riga, con il link al suo file hot. Last 7 days è una cronologia mista di tutto ciò che è recente in ogni progetto. Stale comprime tutto ciò che ha più di trenta giorni in una riga sola.
Il secondo livello è _hot.md dentro ogni area. Ogni topic ha il suo file di recenza. Quello del lavoro del mio datore sta sotto la cartella work. Quello dei miei side project sta sotto la loro cartella. Ognuno risponde alla domanda dove ho lasciato questa cosa per quel topic specifico.
Un indice globale singolo annega a una certa dimensione. hot.md nel mio vault è intorno ai 380 kilobyte. Nessun umano lo legge in una seduta. Un agente può, ma solo se ha un file più corto per il topic di cui hai chiesto. Il _hot.md per topic è quel file più corto.
Quando apro una conversazione su un cliente, l’agente legge prima il suo _hot.md. Ottiene lo stato attuale, le ultime cose che ho toccato e chi aspetta cosa da chi. È un rapporto segnale-rumore migliore del file globale. È il motivo per cui l’intera cosa resta veloce mentre il vault cresce.
La regola di rotazione tiene onesti entrambi i livelli. Tutto ciò che ha più di una settimana esce dalla lista attiva. Tutto ciò che ha più di trenta giorni si sposta su Stale. Dopo è sparito del tutto da hot. Continua a vivere nel log cronologico, che è append-only e non viene mai tagliato.
CLAUDE.md: il livello di routing che i tuoi agenti leggono davvero
Ecco il file che fa la maggior parte del lavoro, e non è affatto una nota. CLAUDE.md è un file di istruzioni che vive dentro il vault. Quando Claude Code apre il vault, legge quel file per primo. È il livello di routing.
Il file contiene le regole che altrimenti dovrei ripetere in ogni conversazione. Scrivi in prima persona. Niente trattini lunghi, perché suonano come testo generato. Timbra tutto. Non leggere mai l’archivio. Preferisci la wiki alle fonti grezze. Queste non sono preferenze che ripeto ogni sessione. L’agente le legge da sé, ogni volta, prima di toccare una singola nota.
La parte che conta di più è una tabella di retrieval. È una lista di tipi di query e di dove guardare per primi. Le domande sui task partono da 20 Tasks. Le domande di recenza partono da hot.md. Le domande di prodotto partono dalla wiki. L’archivio non è mai in lista. Quella tabella è la differenza tra un agente che guarda e un agente che indovina.
Una regola del file dice che quando chiedo cosa devo fare oggi, l’agente legge prima la nota giornaliera, poi scansiona i file di task in cerca di checkbox aperte, poi le raggruppa per progetto. Lo fa senza che io digiti una singola istruzione.
Un’altra regola dice di non inventare mai una scadenza. Se dico che un task scade la prossima settimana, prende una data. Se non ne do una, il campo resta vuoto. Quella sola regola mi ha salvato da una dozzina di impegni inventati.
Una terza regola gestisce l’ambiguità. Quando nomino un progetto senza contesto, l’agente fa una domanda breve a scelta multipla invece di assumere. Mi costa tre secondi e mi salva dal modificare il file sbagliato.
Questo è context engineering per una sola persona. Non è un modello nuovo. Non è una finestra più grande. È un piccolo file che dice alla macchina dove guardare, così la macchina smette di guardare ovunque e di allucinare il resto. Il file è lungo qualche pagina. L’effetto è che ogni conversazione parte dalla tua memoria vera invece che da zero. Anthropic ha poi riscritto le regole per file come questo: io ho tagliato il mio del 79% e ho messo per iscritto le best practice per CLAUDE.md che seguo oggi.
Come si svolge una sessione di lavoro
Le regole contano solo quando le vedi girare. Ecco una sessione nel mio vault, dall’inizio alla fine.
La prima cosa che l’agente fa è timbrare data e ora. Apre la nota giornaliera di oggi, o la crea. Ogni azione vera riceve una riga con l’ora, scritta mentre accade. La nota giornaliera diventa un tracciatore di tempo, non un diario. Posso guardare indietro e vedere che ho deciso la cosa del pricing alle 14:30 e ho mandato l’email al cliente alle 15:10.
Poi faccio una domanda vera, in linguaggio naturale. Cosa mi resta da fare sul sito del cliente questa settimana. L’agente legge la nota giornaliera, trova i task aperti, e me ne cita tre con le loro scadenze. Nessun riassunto del settore. Nessun action item inventato. Solo le mie note, trovate e restituite.
Quando finisco qualcosa, lo dico. L’agente trova la checkbox corrispondente, la spunta come fatta, e timbra l’ora. Aggiorna il file di recenza per quel topic. Non mi chiede di ridire l’intera cosa. Il diff nel vault è il record, e la chat resta corta.
Questo è il loop che conta. Chiedi, recupera, agisci, timbra, aggiorna. Ogni passo scrive nella struttura, così la sessione successiva parte più calda di questa. Questo è l’effetto dell’interesse composto, e non è una caratteristica del modello. È una caratteristica dei file.
Faccio un esempio concreto, perché è qui che la gente vuole i dettagli. Mercoledì apro il vault e chiedo: cosa devo a quel cliente dell’e-commerce. L’agente legge il daily, scansiona 20 Tasks, e mi restituisce tre checkbox aperte: la pagina prodotto da sistemare, il report analytics da consegnare, la domanda del cliente sulla spedizione rimasta senza risposta da quattro giorni. L’ultima non l’avrei trovata da solo in una settimana. L’agente l’ha trovata in pochi secondi, perché la checkbox stava dove doveva stare, con la data giusta accanto.
Il punto non è che l’agente è intelligente. Il punto è che ha un indirizzo. Senza la struttura, quella checkbox sarebbe stata una riga persa in mezzo a 623 altre. Con la struttura, è la risposta alla domanda.
Claude Obsidian: come Claude Code legge il mio vault
Il setup per claude obsidian è quasi imbarazzante da quanto è semplice, ed è quello il punto. Punto Claude Code sulla cartella del vault. Lui legge CLAUDE.md dalla radice da solo. Poi faccio domande in linguaggio naturale, come le farei a un collega sveglio che ha letto le mie note.
Niente colla API. Nessun plugin custom. Nessun database. Claude Code è il lettore, e Obsidian è la biblioteca. Ho scritto altrove di questo stile di lavoro, costruire con l’AI guidandola come faresti con un developer junior. La versione vault è lo stesso muscolo: la macchina fa il lavoro, e la struttura fa la guida.
Ecco una ricevuta dal vault che gestisco. Tiene 623 checkbox aperte in 26 file di task. Il file di recenza al livello superiore, hot.md, è intorno ai 380 kilobyte. Un umano non può leggerlo in una seduta. Un agente sì, se gli dai una tabella che dice da dove partire. Questo è l’intero trucco.
Quando funziona, sembra che l’agente si sia ricordato qualcosa di te. Non si è ricordato. Ha letto un file, come faresti tu con le tue note se fossero in un posto solo ed etichettate. La memoria non è nel modello. È nella struttura.
C’è un dettaglio che la maggior parte delle guide non dice: il motivo per cui funziona è che Obsidian salva file markdown piatti. Niente formato proprietario, niente database chiuso. Qualsiasi modello che legge file può leggere il vault. Non sei legato a un vendor. Se domani esce un lettore migliore, punti quello sulla stessa cartella e hai finito. La struttura resta tua.

Plugin Obsidian AI: cosa uso e cosa salto
Sei arrivato qui chiedendoti dei plugin obsidian ai, quindi rispondo in fretta. Ne salto quasi tutti.
Il ragionamento è semplice. La maggior parte dei plugin cerca di mettere l’AI dentro la nota, così è la nota a pensare. È esattamente l’errore che fanno le guide. Io voglio l’AI fuori dalle note, che le legge, come un lettore legge una biblioteca. Quando l’intelligenza vive nella nota, ogni nota litiga con ogni altra nota. Quando vive nel lettore, le note restano stupide e restano utili.
Quello che uso è una lista corta. Claude Code puntato sul vault come lettore. Il sync ufficiale di Obsidian per i file. Un plugin di daily notes così ogni giorno ha un file in 10 Daily. Tutto qui. Il resto dell’ecosistema obsidian ai è una carrellata per un problema che ho già risolto con un file di regole.
La versione onesta: non mi serve un plugin per riassumere le mie note. Mi serve che l’agente trovi la nota giusta e la citi. I plugin riassumono. La struttura recupera. Se vuoi la mia lista completa di tool, tengo documentato lo stack marketing attuale qui. La parte vault è la più piccola e la più noiosa. Non è un caso.
Facciamo un esperimento mentale, giusto per essere chiari. Prendi un plugin che riassume le tue note con un pulsante. Clicchi, e ottieni un riassunto. Carino. Ma il riassunto è generico per definizione: ha dovuto buttar via i dettagli. Il momento in cui ti serve il dettaglio esatto, la cifra del contratto, il nome della persona, la data della decisione, il riassunto non ce l’ha. L’aveva la nota originale, che non hai più aperto perché il riassunto era comodo. Hai costruito uno strato che nasconde l’unica cosa che conta.

Cosa si rompe quando il vault cresce: contesto, freschezza, duplicazione
Un secondo cervello funziona benissimo a cento note e si rompe in silenzio a mille. Conosco i tre modi in cui si rompe, perché il mio vault è ben oltre le mille.
Il primo è il contesto. Un file cresce finché non entra più nella conversazione. Il mio hot.md è intorno ai 380 kilobyte. È l’intero punto di un indice di recenza, e diventa anche il problema. Troppa recenza è rumore, quindi l’indice ha bisogno della sua scadenza. Le voci con più di una settimana escono dalla lista attiva. Con più di un mese, si comprimono in una riga o si spostano nell’archivio.
Il secondo è la freschezza. Una nota scritta a marzo suona vera a settembre e non lo è. Lo stesso task viene registrato in tre posti nell’arco di sei mesi, e l’agente cita il più vecchio con sicurezza totale. La soluzione è di nuovo la tabella di routing: la nota giornaliera è la fonte di verità per cosa è successo, e la wiki è la fonte di verità per cosa è vero. Nient’altro viene citato come fatto.
Il terzo è la duplicazione. La stessa idea atterra in una nota giornaliera, in una pagina wiki e in un file di task. Non le unisco a mano. Le segnalo, e la struttura sceglie una casa canonica. L’archivio è dove vanno i perdenti, e all’agente viene detto di non leggerlo mai per il retrieval. Una nota stantia che l’agente legge è peggio di nessuna nota, perché si legge come un fatto attuale.
La cadenza che lo tiene sano è poco affascinante. Ogni settimana guardo l’indice di recenza e sposto fuori dalla lista attiva ciò che è stantio. Ogni mese controllo il query log per le domande che hanno richiesto tre file e li unisco. Il sistema non è set and forget. È un giardino, e l’archivio è il compost.
Vale la pena dirlo esplicitamente, perché è la parte che tutti mollano. La disciplina settimanale e mensile non è opzionale. È il sistema. Un vault senza rotazione non è un secondo cervello, è un archivio che finge di essere vivo. La differenza non sta nello strumento. Sta nel fatto che io faccio la manutenzione, e la maggior parte delle persone no. Per questo il loro secondo cervello funziona per due settimane e poi diventa un posto dove i pensieri vanno a morire.

Come misuro il retrieval: il query log
Le opinioni costano poco. Io voglio un numero. Quindi il vault ha un query log, e ogni domanda seria prende una riga.
La riga registra la domanda, quali file ha toccato e un esito. L’esito è una di quattro parole. ok significa che il vault ha risposto in modo efficiente. gap significa che l’informazione non c’era. consolidate significa che ho dovuto leggere tre file per una sola risposta, il che è un segnale per unirli. noise significa che ho letto file che non aiutavano.
È così che un secondo cervello migliora invece di diventare più grande. Quando la stessa domanda due volte di fila restituisce consolidate, unisco i file. Quando una domanda continua a restituire gap, so che al vault manca qualcosa e lo aggiungo. Il log trasforma un mucchio di note in un sistema con feedback.
Una riga vera si presenta così. La domanda, i file che ha toccato e la parola consolidate. Quella parola è il segnale. Dice che tre file tenevano pezzi di una sola risposta, ed è ora di scrivere una pagina unica. La volta dopo che chiedo, la risposta arriva da un file invece che da tre. Questo è il loop che rende il vault più intelligente invece che più grande.
La maggior parte non lo fa mai, e si vede. Il loro secondo cervello è un museo. Il mio è una macchina con un manometro sopra. Il manometro è brutto e poco affascinante, ed è l’unico motivo per cui l’intera cosa continua a funzionare mentre cresce. La qualità del retrieval è un risultato misurabile, e io la misuro.
Ti faccio un esempio di quanto questo sia concreto. A un certo punto ho notato che ogni volta che chiedevo dei prezzi di un certo servizio leggevo tre file diversi. Tre. Ogni volta. Li ho segnati come consolidate per due settimane di fila, poi mi sono preso venti minuti e li ho uniti in una pagina wiki sola. Da quel giorno la risposta arriva da un file. Venti minuti di lavoro, risparmiati per sempre. Questo non è un trucco di produttività. È manutenzione di un database, fatta da una persona che si rifiuta di leggere la stessa risposta tre volte.

Un secondo cervello AI è un sistema, non una cartella
Ecco la cosa che voglio che ti porti via da tutto questo. Un secondo cervello AI non è qualcosa che compri, e non è qualcosa che installi. È un sistema che costruisci, e il sistema è per lo più tre file noiosi e un layout di cartelle numerate.
I vendor continueranno a venderti il cervello. I plugin continueranno a promettere di organizzare i tuoi pensieri. La verità è più silenziosa. Un secondo cervello AI è una cartella con delle regole dentro, un indice che dice cosa è recente e un log che dice se funziona. Puoi costruire l’intera cosa in un pomeriggio, e poi compone interessi per anni.
Il mio lo uso ogni giorno. L’agente trova la nota giusta, la cita, e io smetto di riscrivere decisioni che ho già preso. Non è magia. È routing. Quando l’AI Overview per questo topic arriverà finalmente, sarà una lista di nomi di tool. La risposta vera è una frase sola, e ora ce l’hai tu. Costruisci la struttura, e lascia che l’agente recuperi invece di indovinare.
Non serve che tu parta con tutto. Inizia con le cartelle numerate e un file di regole. Il resto cresce intorno. L’unica cosa che non puoi rimandare è la disciplina di loggare le query e archiviare le note morte, perché è quella che tiene in vita la macchina quando i file superano il migliaio. La struttura la costruisci in un pomeriggio. Il sistema lo mantieni per anni. La differenza è lì.
Domande frequenti
Obsidian va bene per costruire un secondo cervello AI?
È lo strumento migliore che ho trovato, e non per qualche plugin. Obsidian salva file markdown piatti con una struttura di cartelle che controlli tu, ed è esattamente quello che un agente legge in modo pulito. Il valore è la struttura che ci costruisci sopra, il file di regole e l’indice di recenza, non l’app in sé.
Mi serve Claude Code, o posso usare qualsiasi AI con Obsidian?
Puoi usare qualsiasi modello che legge file, ma il livello di routing conta più del modello. Il punto di CLAUDE.md è che l’agente legge le regole da sé invece di sentirtele dire ogni volta. Qualunque tool usi, la domanda è la stessa: legge un file che gli dice dove guardare, o indovina.
Quanto ci vuole a mettere in piedi un secondo cervello AI?
Il layout delle cartelle e i tre file richiedono un pomeriggio. Il valore arriva dopo, man mano che il vault cresce e il routing lo tiene utilizzabile. La parte costosa non è il setup. È la disciplina di loggare le query e archiviare le note morte, che è l’unica cosa che lo tiene funzionante oltre i mille file. Un secondo cervello AI che sa leggere si costruisce in un pomeriggio. Tenerlo leggibile è l’abitudine.


