Dall'LLM Wiki di Karpathy a un Second Brain che funziona: la mia implementazione con Amazon Quick Desktop

Dima Kramskoy — Senior Cloud Architect in DoiT International Oltre 20 anni di software engineering · 10 certificazioni AWS · AWS Community Builder 2026 · Alumni dell'Architect Master Class di Juval Löwy (2022)

Il problema: ogni conversazione riparte da zero

Ecco l'anti-pattern che mi fa impazzire: fai una conversazione di 45 minuti con un assistente AI sulle tue scelte architetturali, sui trade-off, sui vincoli. Chiudi la scheda. Il giorno dopo apri una nuova chat. Non sa nulla. Si ricomincia dall'onboarding.

Ora moltiplica tutto questo per l'intera superficie del tuo sapere: thread Slack con un contesto che non sarà mai più ricercabile, catene di email in cui le decisioni si sono perse nella risposta numero 14, documenti che esistono in tre versioni su due drive diversi e conoscenza tribale che vive solo nella testa delle persone.

Nessuno vorrebbe fare l'onboarding del proprio sostituto avendo a disposizione solo la cronologia di Slack. Ma è di fatto quello che stiamo facendo con i nostri strumenti AI: gli forniamo frammenti e ci aspettiamo coerenza.

Il problema di fondo non è l'intelligenza. GPT-4, Claude, Gemini sono tutti brillanti. Il problema è l'amnesia. Ogni sessione è un cold start. Il tuo contesto è sparso in una dozzina di strumenti e nessuno di loro dialoga con gli altri attraverso un modello unificato di te e del tuo lavoro.

Ci ragiono da mesi. Poi Karpathy ha pubblicato un tweet che ha cristallizzato la soluzione.

L'ispirazione di Karpathy: il RAG recupera, una wiki capitalizza

Nell'aprile 2026 Andrej Karpathy ha pubblicato su X un post sull'"LLM Wiki": 17 milioni di visualizzazioni e in crescita. L'intuizione di fondo mi ha colpito come un design pattern che va al suo posto:

"Il RAG recupera. Una wiki capitalizza."

Il suo framework è elegante. Tre livelli:

1. Fonti grezze — articoli, paper, tweet, conversazioni, appunti
2. Wiki — pagine di conoscenza distillata, strutturata e interconnessa
3. Schema — l'ontologia che governa il modo in cui la conoscenza viene organizzata

L'analogia che usa è perfetta: "Obsidian è l'IDE. L'LLM è il programmatore. La wiki è il codebase."

Matt Paige ne ha scritto un'analisi eccellente. Il cambio di prospettiva è questo: invece di riversare documenti grezzi in un vector database sperando che il retrieval peschi il chunk giusto, costruisci una knowledge base viva e strutturata che l'LLM mantiene e arricchisce nel tempo.

Il RAG è una lookup. Una wiki è un sistema. Una è O(1) per query. L'altra capitalizza.

Ma ecco cosa mi tormentava della versione di Karpathy: è manuale. L'operatore sei tu. Tu fai il prompt, tu revisioni, tu incolli, tu organizzi. L'LLM ti assiste, ma sei tu a guidare. Volevo qualcosa di diverso: un assistente che facesse tutto questo al posto mio, non un sistema da mantenere in prima persona.

Perché Amazon Quick Desktop

Quando ho valutato gli strumenti per questa implementazione, avevo una checklist derivata direttamente dall'architettura di Karpathy:

• ✅ Memoria a lungo termine che persiste tra le conversazioni
• ✅ Knowledge graph (estrae automaticamente entità e relazioni da Slack, email, calendario)
• ✅ Ricerca semantica sui file locali
• ✅ Accesso in lettura/scrittura al mio filesystem
• ✅ Task in background (ricerca mentre lavoro ad altro)
• ✅ Strumenti connessi (Gmail, Slack, Google Calendar, server MCP)
• ✅ Action layer (può preparare bozze di email, creare documenti, fissare riunioni)

Amazon Quick Desktop offriva già quello che Karpathy descrive, ma in modo nativo e collegato agli strumenti di lavoro reali. Non è una finestra di chat. È un runtime.

Confronto rapido:

La scelta di fondo è stata questa: volevo un assistente che capitalizzasse conoscenza PER me, non un sistema da mantenere in prima persona. Il costo di manutenzione di una wiki manuale uccide l'adozione. L'ho visto succedere decine di volte.

Cosa ho costruito (in 1 settimana)

Struttura delle cartelle

~/SecondBrain/
├── raw/                          # Input non processati
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # Conoscenza distillata
│   ├── concepts/                 # Modelli mentali, framework
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # Persone, organizzazioni, strumenti
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # Lavoro attivo
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # Riferimenti indicizzati
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # Tracciamento output giornaliero
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # L'ontologia
└── mkdocs.yml                    # Documentazione auto-servita

SCHEMA.md (estratto)

# SecondBrain Schema v1.0

## Tipi di pagina
- **concept**: un modello mentale, un pattern o un framework. Deve includere: definizione, quando usarlo, anti-pattern, concetti correlati.
- **entity**: una persona, un'organizzazione o uno strumento. Deve includere: ruolo/scopo, relazione con il mio lavoro, data dell'ultima interazione.
- **project**: lavoro attivo o completato. Deve includere: stato, stakeholder, log delle decisioni, prossime azioni.
- **source**: un articolo/talk/paper acquisito. Deve includere: URL, insight chiave (max 5), connessione ai concetti esistenti.
- **log**: voce giornaliera. Auto-generata. Tiene traccia di: pagine create, pagine aggiornate, domande a cui è stata data risposta, azioni intraprese.

## Convenzione di naming
kebab-case. Niente date nei nomi dei file (vanno nel frontmatter).

## Regole di cross-reference
Ogni nuova pagina DEVE collegarsi ad almeno 1 pagina esistente. Le pagine orfane sono un campanello d'allarme.

Lo stack

• MkDocs + tema Material — serve in automatico la wiki in locale su localhost:8000
• launchd plist — avvia MkDocs al login (macOS). Zero attrito per la consultazione.
• Amazon Quick — legge e scrive la wiki, propone aggiornamenti, risponde alle domande basandosi su di essa
• Indicizzazione semantica — Quick indicizza ~/SecondBrain/ e la interroga in modo contestuale

Il workflow di approvazione

È il punto critico. Niente viene scritto senza il mio OK. Il flusso:

1. Dico "acquisisci questo articolo" o condivido un link
2. Quick lo legge e propone una nuova pagina wiki (o aggiornamenti a quelle esistenti)
3. Vedo il diff: contenuti nuovi evidenziati, cross-reference in chiaro
4. Approvo, modifico o rifiuto
5. I contenuti approvati vengono scritti su disco, MkDocs si aggiorna automaticamente

Oltre 15 pagine wiki nella prima settimana. Non a forza di sforzo, ma dalle conversazioni che stavo già facendo.

Una giornata tipo

Mattina:

"Buongiorno"

Quick risponde con: email prioritarie (segnalate o da persone chiave), thread Slack che attendono una mia risposta, calendario del giorno con note di preparazione per le riunioni. Niente diluvio: un briefing.

Durante la giornata:

"Acquisisci questo: [link a un blog post di architettura]"

Quick lo legge, individua 3 concetti chiave, propone una nuova pagina in sources/ e aggiornamenti a due pagine esistenti in concepts/. Scorro il diff, approvo, fatto. 90 secondi.

"Scrivi una bozza di blog post sull'implementazione del Second Brain"

Attinge dalle mie pagine wiki, conosce la mia voce (dalla memoria dei testi precedenti), la struttura secondo il formato che preferisco. Faccio editing, non scrivo da zero.

"Blocca 2 ore di deep work sulla voice capture pipeline per domani"

Controlla il mio calendario, trova uno slot, lo prenota, aggiunge note di preparazione dalla pagina projects/voice-capture-pipeline.md.

In background:

Mentre sono in riunione, alcuni task in background fanno ricerca sui temi che avevo messo in coda. Al rientro: "Ho trovato 3 paper rilevanti sulla manutenzione dei knowledge graph. Vuoi che li acquisisca?"

L'effetto cumulativo è reale. Al quinto giorno rispondeva a domande sintetizzando da più pagine wiki che mi ero dimenticato di aver approvato.

L'estensione Voice Capture (PoC)

Le idee migliori arrivano quando cammino, non alla scrivania. Così ho costruito una pipeline:

Architettura

iPhone Shortcuts (o wearable Plaud NotePin)
    → API Gateway (REST)
        → Lambda (upload handler)
            → S3 (audio bucket)
                → S3 Event → Lambda (trigger di trascrizione)
                    → AWS Transcribe
                        → Lambda (post-processing)
                            → Knowledge Base di Amazon Quick
                                → Pagina wiki proposta

Come funziona

1. Avvio uno Shortcut sull'iPhone (oppure il NotePin registra l'audio ambientale)
2. L'audio viene caricato su S3 tramite API Gateway + Lambda
3. L'evento S3 attiva la trascrizione via AWS Transcribe
4. La trascrizione viene ripulita, suddivisa in chunk e inviata alla knowledge base di Quick
5. Alla successiva apertura di Quick: "Hai una voice capture su [argomento]. Vuoi che ne crei una pagina wiki?"

Costo AWS complessivo: frazioni di centesimo per ogni capture. Le funzioni Lambda sono banali: 50 righe l'una. Il valore sta nella chiusura del ciclo: pensiero → capture → conoscenza strutturata → azione.

Recensione onesta: 7/10

Cosa funziona

• Struttura — Lo schema impone coerenza. Le pagine sono trovabili e utili.
• Effetto cumulativo — Le risposte della settimana 2 sono nettamente migliori di quelle della settimana 1. Sa delle cose.
• Strumenti connessi — Il contesto di Slack arricchisce le pagine wiki. La consapevolezza del calendario rende possibile lo scheduling reale.
• Action layer — Non si limita a sapere: fa. Bozze, slide, prenotazioni.
• Ricerca semantica — "Cosa avevo deciso su X?" funziona davvero su tutta la wiki.

Cosa va migliorato

• Cross-reference — Non ancora del tutto automatiche. Alcune pagine restano sotto-collegate.
• Health check — Non ho ancora implementato audit pianificati per pagine obsolete o orfane.
• Acquisizione pianificata — Niente cron per "controlla questi 5 feed RSS ogni giorno". Trigger ancora manuale.
• Rilevamento delle contraddizioni — Non testato. Cosa succede quando informazioni nuove entrano in conflitto con le pagine wiki esistenti?

Cosa abbiamo fatto MEGLIO rispetto alla visione originale di Karpathy

La sua visione è il blueprint. Ma è in sola lettura: file da interrogare. La mia produce: scrive bozze di email, crea slide, fissa riunioni, scrive blog post. La wiki non è solo un riferimento: è una fonte di azione.

Come puoi iniziare (5 passi)

Non ti serve il mio setup completo per ottenere valore. Ecco la progressione:

I 5 passi

1. Collega i tuoi strumenti — Slack, Gmail, Calendar, una cartella locale. Bastano 10 minuti nelle impostazioni.
2. Inizia a parlarci — La memoria capitalizza dal giorno 1. Ogni conversazione gli insegna qualcosa di te.
3. Dì "ricorda questo" dopo le conversazioni importanti — Ancore di memoria esplicite.
4. Crea ~/SecondBrain/ + SCHEMA.md — Se vuoi andare più a fondo, dagli una struttura.
5. Fai una domanda trasversale — "Quali sono state le mie decisioni chiave della scorsa settimana?" Da qui non si torna indietro.

Tre livelli di impegno

Parti da 🟢. Sul serio. L'effetto cumulativo arriva comunque, che tu costruisca l'infrastruttura o no. La struttura wiki lo rende solo visibile e verificabile.

Conclusione

La tua AI non dovrebbe ripartire da zero a ogni conversazione.

Gli strumenti ci sono. Il pattern è collaudato. Karpathy ha mostrato l'architettura; Amazon Quick offre il runtime. La distanza tra "assistente AI" e "second brain" sta tutta in struttura + persistenza + strumenti connessi.

Capitalizzare > Recuperare. Ogni conversazione, ogni articolo acquisito, ogni pagina wiki approvata rende più intelligente l'interazione successiva. Non è retrieval: è crescita.

Parti in piccolo. L'effetto si accumula. È esattamente il punto.

Un ultimo pensiero, e arriva da Jocko Willink, non dalla ricerca sull'AI: Extreme Ownership applicata alla conoscenza. Se un'informazione è nel tuo mondo — un thread di Slack, un talk di conferenza ricordato a metà, un'idea durante una passeggiata mattutina — e non la catturi, non è tua. È lei a possedere te, rendendosi indisponibile proprio quando ne hai più bisogno.

Catturala. Strutturala. Lasciala capitalizzare.

Questo post è stato scritto con l'aiuto del mio Second Brain, attingendo dalle pagine wiki costruite nella settimana precedente. L'ironia non mi sfugge. Ed è esattamente il punto.

Presentato al GenAI Community Skill Share di DoiT, 22 maggio 2026. Grazie ai circa 27 colleghi che hanno fatto domande affilate e hanno spinto il ragionamento più in là.