Questo articolo non è nato in un foglio bianco.
L’ho pensato e strutturato dentro il sistema di cui sto per parlarti…
Prima di scrivere una riga ho chiesto al mio second brain cosa avessi già raccolto sull’argomento, e mi ha restituito le fonti che avevo salvato, le persone con cui ne avevo parlato, i pensieri collegati lasciati lì nei mesi. Quello che stai leggendo, in un certo senso, è il sistema che racconta sé stesso.
Alla fine trovi un template gratuito per crearti un second brain partendo dalla mia stessa struttura.
Ma prima capiamo perché ho mollato un Notion che funzionava benissimo.
Se ti va di seguirmi, ricevi i prossimi articoli direttamente via email. 👇
Un passo indietro.
Da un paio d’anni gestisco tutto il mio lavoro in un second brain su Notion.
L’idea della struttura l’ho presa dal grande Luca Mezzalira (se non lo conosci ti consiglio assolutamente di seguirlo): ci eravamo confrontati a una conferenza a Berlino qualche anno fa ne e poi ne aveva parlato in un video su YouTube.
Ho riadattato l’idea al mio modo di lavorare.
Tre parti: i task (cosa fare adesso, cosa più avanti), un daily journal (ogni giorno cosa ho fatto, cosa ho imparato, cosa mi serve per il giorno dopo) e una exploration board, dove ogni argomento che stavo esplorando aveva il suo spazio.
Ha funzionato, e bene. Per due anni ho sempre saputo cosa dovevo fare e dove trovare le cose. Con un limite di cui mi sono accorto solo col tempo: non c’era compounding. Un po’ per come l’avevo strutturato (con ogni topic chiuso nel suo silo), un po’ perché ogni collegamento me lo dovevo tracciare a mano, come tutta la manutenzione del resto.
Una connessione tra un’idea di Febbraio e una di Giugno non emergeva mai da sola: se non la scrivevo io, non esisteva.
Poi ho visto come Andrej Karpathy usa il suo “LLM wiki”. Non l’ho letto come “il mio sistema è sbagliato”, ma come un’opportunità: potevo tenere la stessa struttura e renderla più flessibile. Un sistema che si mantiene, e si collega, da solo.
Il modello mentale di Andrej Karpathy si riassume in una riga:
“Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.”
Tratti la tua conoscenza come un codebase: i file di testo sono il codice, l’editor è l’ambiente di lavoro, e l’LLM è chi ci lavora dentro. Punti l’AI a una cartella di file markdown e lei li legge, li scrive, li collega, li tiene in ordine. Il vault di Karpathy è fatto di un centinaio di articoli e centinaia di migliaia di parole, quasi tutto scritto e mantenuto dall’agente: a mano ci mette le mani di rado. (il post originale di Karpathy)
È qui che il mio Notion cambia forma. Stessa filosofia, ma al posto di database che sincronizzo a mano, cartelle di file di testo che un agente (per me Claude Code) mantiene al posto mio.
Come ci lavoro. Non serve niente di speciale: il second brain è una cartella di file markdown. Ci lavoro dentro dal mio IDE (Cursor) con Claude Code, l’agente che legge, scrive e mantiene tutto. Ma restano file di testo normali, e la stessa cartella la apro in Obsidian quando voglio navigarla a vista: seguire i link tra le pagine, guardare il grafo delle connessioni. Stessi file, due modi di guardarli. L’IDE è dove ci faccio lavorare l’AI, Obsidian è dove li sfoglio come un wiki.
Com’è strutturato. Tre livelli, divisi da una domanda semplice: chi scrive?
Livello 1: le fonti grezze. Mie e intoccabili: le catturo io, l’AI le legge ma non le riscrive.
Inbox, quello che catturo al volo: articoli salvati, appunti, dump grezzi, prima di lavorarli.
Journal, la nota del giorno: incontri, idee, cose imparate. Il mio diario di bordo.
Livello 2: il wiki. Il cuore, mantenuto dall’AI, dove la conoscenza vive come pagine collegate.
Persone, una pagina per ognuno che conosco: chi è, di cosa ci siamo detti, a chi e a quali temi è collegato.
Aziende, le organizzazioni: cosa fanno, che rapporto ho, chi ci lavora.
Libreria, libri e articoli che leggo, con i takeaway e i collegamenti ai temi che toccano.
Topic, i temi evergreen su cui torno spesso: fanno da indice a tutto ciò che ci ruota attorno.
Esplorazioni, le domande aperte su cui sto ragionando, ognuna con la sua domanda-guida.
Progetti, il lavoro attivo, con un esito e una scadenza.
Idee di contenuto, la pipeline dei post: quando un concetto torna in tre fonti diverse, finisce qui come candidato.
Profilo, la mia pagina: chi sono e cosa sto ottimizzando. È il contesto che l’AI legge per prima, così ogni risposta parte da me.
Livello 3: lo schema. Le regole del sistema, che io e l’AI evolviamo insieme: come è fatto e cosa va dove, l’indice di tutte le pagine (il motore di ricerca interno del vault) e il log delle operazioni.
Le entità di Persone, Aziende ed Esplorazioni sono la mia aggiunta rispetto a un archivio di soli appunti: Karpathy ha una biblioteca di paper, io ho un contenitore fatto di relazioni e domande aperte, e la struttura lo riflette.
Quella a cui tengo di più sono le persone. Incontro e parlo con tante persone e ho un network ampio, ma i collegamenti non mi vengono in mente al momento giusto: chi presentare a chi, quale conversazione di sei mesi fa parla con quella di oggi, quale opportunità è lì e non la vedo. Ogni volta che conosco qualcuno registro l’interazione, e il sistema la aggancia a chi conosco già, ai temi, al contesto. Le introduzioni e le occasioni che prima mi sfuggivano ora emergono da sole. Quando ho testato questo approccio per la prima volta ho avuto davvero un “aha moment”.
E se il wiki è una codebase, lo tratto con i gesti di chi scrive software. Le tre operazioni di base sono quelle che Karpathy descrive per la sua LLM Wiki: ingest, query, lint. Io le ho rese esecutive: le ho codificate come tre skill di Claude Code (le richiamo come /ingest, /query, /lint), ognuna con un protocollo scritto da me, così non sono un prompt improvvisato ogni volta ma un comando ripetibile.
ingest, la skill che trasforma una fonte grezza in conoscenza. Prende un appunto dall’Inbox o la nota del giorno dal Journal, ne discute con me i punti chiave, crea le pagine nuove che servono, aggiorna le entità collegate (persone, aziende, temi, esplorazioni), aggiorna l’indice e archivia la fonte come lavorata. È il gesto che fa crescere il wiki.
query, la skill con cui interrogo mesi di pensiero. Parte dall’indice per trovare le pagine giuste, le apre, segue i link tra loro e mi restituisce una risposta con le fonti citate. Non è una ricerca per parole chiave: è il sistema che ragiona su ciò che ho raccolto e mi propone di archiviare la risposta come nuova pagina, così ogni domanda lascia un sedimento.
lint, la skill di manutenzione. Passa il wiki al setaccio a caccia di contraddizioni tra pagine, affermazioni superate da fonti più recenti, pagine orfane senza collegamenti, concetti che meriterebbero una pagina propria. Mi restituisce una lista di cose da sistemare. È esattamente il lavoro che prima tenevo in piedi a mano su Notion, ridotto a un comando.
Tre skill al posto di una disciplina quotidiana. È qui che il sistema smette di essere un archivio da curare e diventa qualcosa che uso, vediamolo nel dettaglio.
Alimentare il sistema costa pochi secondi, ed è il punto. Ho due modi di farlo, a seconda di cosa catturo.
Un articolo. Leggo qualcosa che mi interessa e lo salvo nell’Inbox con un clic, usando Obsidian Web Clipper: la pagina diventa un file markdown nel vault, senza copia-incolla. Poi lancio /ingest. L’AI lo legge, ne ragioniamo insieme i punti chiave, crea la scheda in Libreria coi takeaway e la collega da sola ai temi che tocca e alle persone che ne avevano già parlato.
Una persona. Dopo un incontro, invece di prendere appunti detto una nota vocale con i miei pensieri (uso Wispr), me la ritrovo trascritta, la butto nel Daily Journal e lancio /ingest: il sistema crea la pagina della persona, agganciata a chi conosco già e ai temi su cui lavora.
Se invece ho parlato con la persona su Meet, prendo il transcript e lo butto direttamente nel Daily Journal e lancio allo stesso modo /ingest.
In entrambi i casi catturare è banale, il lavoro di collegare lo fa il sistema.
Il payoff non è “ricordare”, è comporre. E la differenza vera rispetto a Notion è quando nascono i collegamenti. Prima un collegamento esisteva solo se lo andavo a cercare, e quasi sempre non lo cercavo. Adesso il legame si crea nel momento in cui inserisco qualcosa di nuovo: appena aggiungo una fonte, il sistema la confronta con tutto il resto e traccia da solo le connessioni che vede. Risponde a una domanda che non ho ancora fatto.
Così un articolo salvato a febbraio e una persona conosciuta a giugno si ritrovano legati allo stesso tema senza che io abbia mosso un dito, e quel legame me lo trovo davanti quando serve. Un paio di volte è emersa una connessione tra due cose che in testa tenevo separate: non l’avrei mai disegnata a mano. È il vantaggio che il vecchio Notion non poteva darmi: lì il valore emergeva solo quando cercavo, qui si accumula mentre alimento.
(E il sistema sa anche distinguere cosa resta privato e cosa può diventare condiviso, ma ci torno tra poco.)
C’è una regola che ho impostato dentro al sistema: quando parlo dello stesso concetto in tre ingest diversi, l’AI lo segnala come candidato post e apre una pagina nella pipeline delle idee. Così non parto quasi mai dal foglio bianco: il second brain diventa un partner creativo che ha notato un pattern prima di me. Questo articolo è nato proprio così: il tema è tornato in tre punti diversi del vault, e il sistema mi ha proposto di scriverne.
Prima di una call cerco quello che so già: cosa ho raccolto su un tema, chi conosco che ci lavora, cosa mi ero detto l’ultima volta. Lancio /query e ottengo una sintesi con le fonti collegate. Ogni conversazione parte dal contesto pieno invece che da zero. È una differenza che si accumula: chi riapre una chat vuota ogni volta riparte da capo, e intanto quello che aveva già capito resta indietro.
Stai trovando questo contenuto utile?
Iscriviti per ricevere i prossimi direttamente nella tua casella email 👇
Non è un sistema finito, e non voglio raccontarlo come se lo fosse. Due limiti che vedo bene, e come penso evolveranno.
La domanda difficile, quella che nessuno ha davvero risolto, è come far parlare il brain personale, quello di team e quello aziendale senza tenerli in silos (e perdere il compounding) ma senza nemmeno mischiare cose che devono restare separate.
La mia risposta, per ora, è pragmatica: non punto a un cervello unico. Parto da un sistema con uno scope preciso e curo cosa ci entra. Oggi ne ho uno per il lavoro e uno legato a un contesto aziendale; quello puramente personale non l’ho ancora costruito. E in quello di lavoro importo solo i dati che mi servono davvero. Tenerli separati non è un limite tecnico, è una scelta di rilevanza e di discrezione: non tutto deve fluire ovunque. È la stessa logica dei file, tra cartelle private e cartelle condivise.
Il limite tecnico lo vedo arrivare: più documenti aggiungo, più cresce l’entropia (ridondanze, contraddizioni, deriva dei temi) e il rapporto segnale/rumore peggiora. Oggi navigo index-first: un indice di tutte le pagine più i link tra loro, un “poor man’s RAG” che regge bene fino a qualche centinaio di pagine (lo dice lo schema stesso del vault). Oltre, servirà un ibrido con il retrieval vero: ricerca semantica sugli embedding.
Ma la leva non è una sola. Sono due: retrieval e manutenzione, ed è esattamente il lavoro di /lint, che deduplica e risolve le contraddizioni per tenere bassa l’entropia. Da onesto: i context window che crescono spostano la soglia, non la eliminano, e il retrieval ha i suoi modi di sbagliare. La direzione è passare dal full-context all’ibrido con retrieval, non “il RAG risolve tutto”.
Se sei arrivato o arrivata fin qui, il rischio è portarti via la parte sbagliata. Il punto non è Obsidian, non è Claude Code, non sono le mie tre skill: quelli cambieranno.
Il punto è che la conoscenza: quando la tratti come un sistema vivo invece che come un archivio, diventa un asset che compone, ogni cosa che aggiungi vale più della precedente, perché si lega a tutte le altre. È lo stesso principio per cui un buon contenuto continua a lavorare per te per anni, solo che qui vale per quello che sai, non per quello che pubblichi.
E qui c’è la parte da ingegnere. Non copiare il mio sistema: modellalo sui tuoi vincoli.
Io ho messo al centro persone, progetti ed esplorazioni, il tuo magari è fatto di cose diverse. La struttura che ho descritto è giusta per me, non è un modello da ricalcare per forza. La disciplina che conta è un’altra: decidere cosa tenere e cosa collegare, esattamente come un product engineer decide cosa vale la pena costruire e cosa no. Il valore non è nel tool, è nei tagli che fai.
Se ti è venuta voglia di provarci, ti do un punto di partenza. Ho preparato un template gratuito: una copia clonabile di questo stesso sistema (la struttura delle cartelle, le skill /ingest, /query, /lint, lo schema), svuotata di tutto ciò che è mio, con qualche pagina d’esempio per capire come si popola.
Trovi il template qui 👇
Poi apri la cartella con il tuo agente (Claude Code o altro) e incollagli questo, per partire con un’azione concreta:
Fai da agente che mantiene questo second brain. Leggi prima CLAUDE.md e README.md per capire lo schema a 3 livelli e le skill /ingest, /query, /lint. Poi aiutami a partire:
1. Intervistami e compila Profile.md: chi sono, cosa sto ottimizzando, come lavoro, i temi su cui torno.
2. Cancella le pagine d’esempio fittizie e resetta index.md e log.md.
Clonalo, puntaci il tuo agente, e comincia ad alimentarlo.
Sono proprio curioso di sapere cosa ne pensi, se lo testi scrivimi!
A presto,
Omar
Affianco founder e team post-MVP a costruire prodotti che gli utenti usano davvero. Se può servirti, parliamone
Se questo articolo ti è stato utile, condividi The Builders Log con qualcuno a cui potrebbe servire 👇
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.