Il problema: quando gli strumenti diventano distrazioni
Gestisco una decina di progetti contemporaneamente. Cliente A ha un bug urgente sul suo ecommerce, cliente B vuole aggiungere una feature al gestionale, e mentre sto nel mezzo di questi due mi arriva un’email con una proposta per un nuovo progetto. Nel frattempo, alle 2 di notte, mi viene in mente la soluzione perfetta per quel refactoring che rimandavo da settimane.
Il cervello umano non è fatto per tenere traccia di tutto questo. Il mio di sicuro no.
La trappola degli strumenti perfetti
Uso Notion. Tutt’ora. È un ottimo tool, e probabilmente non lo abbandonerò tanto presto. Ha un grande vantaggio: lo metti in mano a chiunque e capisce. Cliente, collaboratore, parente. Intuitive, visuale, facile.
Ma come developer, c’è un problema: diventi ossessionato dall’ottimizzare lo strumento invece di usarlo.
Passi ore a creare template perfetti, a decidere se quella proprietà deve essere un select o un multi-select, a costruire relazioni tra database. Ti ritrovi a pensare “potrei fare uno script per automatizzare questo”, “potrei usare le API per integrare quello”, “potrei personalizzare quest’altra cosa”.
E così lo strumento che doveva salvarti tempo diventa un progetto a sé. Un meta-progetto. Per questo Notion è perfetto per chi non smanetta, ma diventa pericoloso per chi smanetta troppo.
Il ritorno alle origini
La svolta è stata rendermi conto che avevo già gli strumenti giusti. Da sempre.
File di testo: Markdown è solo un modo elegante per dire “file di testo con un po’ di formattazione”. Niente formati proprietari, niente lock-in. Tra 20 anni questi file saranno ancora leggibili.
Ma c’è di più. Una decente quantità di file di testo, ben strutturati, crea un NoSQL che a tratti diventa quasi un SQL. Puoi fare query, relazioni, aggregazioni. Solo che invece di tabelle hai file, invece di SQL hai grep e script.
E la cosa interessante: spesso non li modifico neanche io direttamente. Li faccio modificare a Claude, o li modifico su GitHub web interface. L’importante è che siano file di testo standard.
Git: Lo conoscevo, lo usavo per il codice, ma nell’ultimo anno mi ha affascinato per un altro aspetto. Non è solo version control per software. È version control per qualsiasi cosa. Pensieri, note, diari, documentazione. Ogni modifica è tracciata. Ogni cambiamento ha un commit message. Puoi vedere l’evoluzione nel tempo, fare diff, tornare indietro.
La convergenza
Poi è arrivato Claude Code. E più in generale, il mondo delle AI da riga di comando.
Improvvisamente questi tre pezzi – editor di testo, Git, AI CLI – si sono incrociati nel punto perfetto.
L’AI capisce il contesto dei miei file. Non un database proprietario, non una struttura complessa. Solo markdown, con una struttura coerente. Sa cosa ho fatto ieri perché legge il diario. Sa quali progetti seguo perché sono documentati. Sa che pattern uso perché vede i commit.
E quando dico “aggiungi questo al progetto X”, Claude non ha bisogno di un tutorial di 20 pagine su come usare Notion. Crea un file, lo commita, push. Fine.
Quello che ho costruito
Il risultato è quello che chiamo “brain”. Non è un tool particolare, non è un software. È solo una directory Git con dentro file markdown ben strutturati:
brain/
├── log/ # diari tecnici/progetti
├── diary/ # diari personali
├── database/ # entità (progetti, persone, aziende)
└── tools/ # script e utility
Nei prossimi post della serie vedrai:
- Parte 2: Come è strutturato il brain e perché funziona
- Parte 3: L’automazione con Claude e gli agent specializzati
E alla fine, forse, ti renderai conto che anche tu non hai bisogno di tool complessi. Solo di file di testo, Git, e un po’ di disciplina.
| *Serie “Brain”: Parte 1 | Parte 2 | Parte 3* |