Questo post fa parte della serie “Prodotti riusabili” — esperienze concrete con Claude/GenAI che si possono adattare al proprio lavoro.
Prima dell'avvento del computer, le persone usavano i classificatori: cassetti etichettati, cartelle numerate, un posto preciso per ogni documento. Il sistema funzionava perché la fisicità definiva le regole di gestione: la struttura, di fatto, imponeva l’ordine.
L’informatica ha cambiato le regole del gioco. È possibile memorizzare un file ovunque (disco, cloud), assegnare qualunque nome, creare cartelle annidate senza sostanziali limiti. Spesso, il risultato di questa libertà totale è il caos che tutti conosciamo: più versioni dello stesso documento, cartelle chiamate “Varie”, “Roba”, “Da sistemare”, file che “sono da qualche parte ma non ricordo esattamente dove”, assenza di convenzioni nella denominazione dei documenti.
Questa deriva comporta un costo reale. Cercare un’informazione richiede tempo e concentrazione. Nella vita professionale, con decine di progetti e centinaia di documenti, la situazione è ancora peggiore. E la soluzione ovvia (“organizzo tutto con un sistema preciso”) si scontra con la realtà: i sistemi strutturati richiedono disciplina e costanza.
Johnny Decimal
Johnny Decimal è un sistema di organizzazione che ho adottato tempo fa e che offre una soluzione semplice a una parte del problema: la creazione di un metodo di lavoro. A ogni area della vita di ciascuno si associa un intervallo di categorie numeriche (10–19: vita personale, 20–29: lavoro, e così via). All'interno di ogni area, le categorie hanno un codice a due cifre (per esempio, 21 Clienti, 22 Progetti, 23 Fatturazione). Questo schema di numerazione viene utilizzato per strutturare il proprio albero di cartelle. Ogni contenitore riceve un ID del tipo XX.YY: per esempio, il 21.03 è il terzo elemento nella categoria “Clienti”.
Il risultato è un sistema molto preciso e privo di ambiguità. Ogni informazione ha una collocazione precisa derivabile dal codice numerico. Se si sta cercando il contratto di un cliente, si sa che è nella categoria 21 e lo si cerca nella cartella corrispondente. Non serve navigare l'intero filesystem.
Due proprietà rendono JD più solido rispetto ad altri approcci. Lo schema numerico rende la struttura stabile: se si aggiunge una nuova categoria, le categorie esistenti restano al loro posto, a differenza dell’ordine alfabetico che le riorganizza ogni volta. E c’è un limite: ogni area ha al massimo dieci categorie, ogni categoria al massimo cento ID. Questo costringe a ragionare su dove collocare un nuovo elemento dell’albero.
Tuttavia, il problema di JD è che tutto deve essere gestito “a mano”. Ogni volta che si crea un file, è necessario ricordare il codice associato a quel tipo di informazione oppure aprire il JDex (l’indice del sistema) per cercare la categoria corretta. In sé non è un problema insuperabile, ma è un attrito costante. Col tempo l'attrito porta a scorciatoie, e le scorciatoie generano disordine.
Claude come bibliotecario
La svolta è arrivata quando ho fornito a Claude il contesto completo del mio sistema JD. In un file chiamato jd-routing.md gli ho chiesto di ricostruire la mappa completa dell’albero di folder di JD (a partire dalla documentazione di JD): ogni area, ogni categoria, le convenzioni di naming, le regole su dove vanno i tipi di documento. Il file fa parte del contesto permanente di Claude in ogni sessione di lavoro. Il risultato pratico: Claude sa dove ogni documento deve essere memorizzato, senza che glielo debba dire ogni volta. A questo ho associato uno schema di naming standard, in modo che tutti i file possano essere facilmente identificati.
Se sto lavorando a una riunione con un cliente e scrivo “salva la minuta”, Claude non chiede quale sia la cartella corretta perché la ricava leggendo il file jd-routing.md. Se chiedo “dove ho messo il brief per il convegno di marzo?”, Claude è in grado di indicarmi il percorso esatto, non una lista di possibilità. Se creo un task su ClickUp, Claude compila automaticamente il campo JD Reference con il codice corretto collegando il task a tutte le informazioni rilevanti che ho sul mio disco. Questo elimina l’attrito. Non devo ricordare la categoria, non devo aprire il JDex, non devo fermarmi a decidere.
LLM Knowledge Base: l’approccio di Karpathy
Andrej Karpathy ha descritto un altro modo per affidare a un LLM la gestione delle proprie informazioni, denominato LLM Knowledge Base (o LLM Wiki). Tutti i documenti e le informazioni rilevanti per un determinato tema (paper, articoli, dataset, immagini, repository di codice) vengono memorizzati in una cartella raw/. Da quel materiale grezzo, l’LLM compila in modo incrementale un wiki: una rete di file Markdown con riassunti delle fonti, articoli derivati per i concetti chiave e backlink che collegano tutto. Il frontend è Obsidian, utilizzato per la navigazione visiva. Una volta che il wiki ha raggiunto una dimensione significativa, l’LLM è in grado di rispondere a domande complesse usando il wiki come base di conoscenza. A loro volta, i risultati delle nuove ricerche contribuiscono a far crescere il sistema. “You rarely ever write or edit the wiki manually, it’s the domain of the LLM”, scrive Karpathy. L’utente fornisce le fonti; l’LLM costruisce la conoscenza derivata.
JD + Claude è una cosa diversa, più semplice e leggera (e meno costosa in termini di elaborazione…). Il modello non genera contenuto: applica una mappa di indirizzamento definita una volta per tutte. Funziona per la gestione quotidiana di file, brief, minute, task. Una LLM Knowledge Base è molto più impegnativa: l’LLM scrive, sintetizza, collega e deve mantenere la coerenza semantica nel tempo. Serve quando il problema da risolvere non è dove si trovano i file, ma come si organizzano le idee, le fonti e le relazioni su un tema tipicamente molto strutturato.
Nel mio workspace i due sistemi coesistono: JD per il filing del lavoro quotidiano e una LLM Knowledge Base basata sul modello di Karpathy (più l’integrazione MCP con Reader/Readwise) per la conoscenza derivata dalle fonti che leggo. Sono due strati distinti, non alternativi.
Il classificatore fisico funzionava bene perché qualcuno aveva definito una volta per tutte la struttura e tutti la seguivano senza doverci pensare ogni volta. JD adatta questo criterio al filesystem digitale. Claude abbassa la frizione a regime: non è l’utente a dover aprire il cassetto.
Il sito di Johnny Decimal scrive: “Nobody can find anything any more. This is stressful, and a massive waste of time.” È vero. E la risposta, alla fine, è abbastanza semplice: un sistema ben fatto, affidato a qualcuno che aiuta ad applicarlo in modo sistematico.
Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it
Ottimi spunti, grazie. Mi è venuta voglia di riprendere l’adozione di Johnny Decimal, che avevo provato in passato e poi abbandonato. Ne sto già traendo benefici, anche grazie alla collaborazione con l’LLM.
interessante, come al solito, avendo come tutti il bisogno di “classificare”. Nel mio caso pero’ ho bisogno di potere attribuire un un doc anche a 2 o più 3 categorie diverse Cliente XY e Fatturazione e 2026 quindi Johnny non mi puo' servire...