Salta ai contenuti

I reading path disponibili e per chi sono

La wiki è una città. I reading path sono itinerari curati per attraversarla con uno scopo preciso.

Una wiki non ha un inizio ovvio. Trecento pagine collegate tra loro sono utili a chi sa già cosa cercare, ma intimidatorie per chi arriva nuovo. I reading path risolvono questo: sono letture lineari curate che selezionano un sottoinsieme degli slug, li ordinano, dichiarano esplicitamente per chi sono e cosa portano via.

Ogni path ha uno scopo. Diventare praticante di agent coding è diverso dal capire cosa succede dentro un transformer, che è diverso dal costruire sistemi sicuri in produzione. Un unico ordine lineare imposto a tutti sarebbe sbagliato per quasi tutti: chi vuole consegnare domani non ha bisogno di Dartmouth 1956, e chi vuole scrivere un paper non ha bisogno di sapere come si configura MCP in Claude Code.

I path non sono esaustivi. Chi completa agent-coding-spine sa molto più del lettore medio di articoli online, ma non è un ricercatore di attention mechanisms. Per quello c’è llm-internals-deep. I path sono percorsi minimi per uno scopo, non enciclopedie di sotto-dominio.

Ogni path in reading-paths.md dichiara sei cose:

  • Scopo: cosa si porta via chi lo completa.
  • Lettore ideale: il profilo esplicito.
  • Prerequisiti: cosa si da’ per scontato (in genere uno dei path di fondamenta).
  • Libro derivato (opzionale): nome del libro stampabile che nascerà esportando questo path.
  • Sequenza: elenco ordinato degli slug.
  • Eventuali digressioni: sottoinsiemi opzionali per chi vuole più profondità su un punto.

Gli slug di un path possono coprire intere Parti (“Parte XIV intera”), singoli capitoli nominati, o un sottoinsieme selettivo (“di Parte IX solo attention-intuizione, qkv-da-zero, transformer-block”).

Otto path, organizzati per scopo.

agent-coding-spine — per diventare praticante esperto di agent coding. Il path più corposo: attraversa il minimo necessario di matematica, internals LLM, training, inferenza, e poi tutta la spina pratica (context, prompt, agenti, harness, casi studio). È il path che diventerà il primo libro: Agent Coding — la bibbia pratica.

llm-internals-deep — per capire davvero come funziona un LLM. Dalla matematica al transformer, dalle architetture moderne al training, fino a reasoning e inferenza. Per developer che vogliono oltre l’API.

storia-filosofia-ai — per l’inquadramento umanistico prima del tecnico. Storia da Dartmouth a oggi, filosofia della mente da Turing al superallineamento, slice di scienze cognitive. Per chi arriva da sfondi umanistici o vuole il contesto prima dei dettagli.

cognitive-to-agent — un path “a ponte”. Parte dalle scienze cognitive (memoria, attenzione, dual-process, theory of mind) e arriva agli agenti software attraverso i parallelismi espliciti. Gli slug ponte-* sono il collante. Per chi ha background in psicologia, neuroscienze o scienze cognitive e vuole agganciare l’AI moderna.

ml-fondamenti-classici — per riempire il vuoto ML prima del deep learning. Dalla regressione lineare alle reti neurali classiche, passando per SVM, random forest, gradient boosting. Indispensabile per developer che non hanno mai avuto un corso di ML formale.

teoria-dei-giochi-per-ai — per capire RL, allineamento e multi-agent dalla prospettiva della teoria delle decisioni. Bandits, MDP, Bellman, Q-learning, policy gradient, PPO. E poi il ritorno sugli argomenti AI: RLHF, agent orchestration, alignment come principal-agent.

practitioner-quick — per consegnare subito. Niente filosofia, niente storia lunga, niente training. Prompt engineering, RAG, agenti, harness essenziale, sicurezza base. Per chi ha una deadline.

safety-e-sicurezza — per costruire sistemi agentici sicuri. Prompt injection, supply chain MCP, harness security, red teaming, observability. Per security engineer, SRE, tech lead che devono mettere agenti in produzione senza aprire crepe.

Dettaglio completo di ogni path con le sequenze slug in reading-paths.md.

Shortcut per decidere in trenta secondi. Leggi comunque la descrizione completa del path prima di impegnarti.

Se il tuo obiettivo è…Path consigliato
Costruire un agente in produzioneagent-coding-spine
Capire un paper su transformerllm-internals-deep
Ragionare su AGI con fondamentistoria-filosofia-ai
Agganciare la tua psicologia all’AIcognitive-to-agent
Prepararti a un corso universitario di MLml-fondamenti-classici
Lavorare su RLHF o RLteoria-dei-giochi-per-ai
Consegnare un prototipo entro il mesepractitioner-quick
Fare security review di agentisafety-e-sicurezza
Capire perché o1 è diversoParte XII direttamente (non un path)
Migliorare un RAG che va maleParte XIV diretta (non un path)
Decidere se migrare da un modello a un altroParte XIX + Parte XXI

La prima domanda è lo scopo: cosa vuoi poter fare dopo? La seconda è il tempo: quanti capitoli puoi realisticamente leggere nei prossimi mesi? La terza è il punto di partenza: cosa sai già bene?

Alcuni scenari per rendere la scelta concreta.

“Sono un backend engineer Python. Il mio team sta integrando tool use per la prima volta. Devo contribuire alla progettazione entro tre mesi.” — Path agent-coding-spine, ma saltando la Parte IV (matematica) nelle prime letture se ti senti a tuo agio. Concentrati su XVI (agenti), XVII (harness), XVIII (agent coding pratica), XX (sicurezza). Matematica e internals LLM quando ti servono, a richiesta.

“Ho un dottorato in filosofia della mente. Voglio capire cosa ha a che fare Chalmers con Claude.” — Path storia-filosofia-ai per il quadro, poi cognitive-to-agent per i collegamenti operativi. Le Parti tecniche (IX-XVIII) le affronti dopo, con il vantaggio di avere già un’ossatura concettuale solida.

“Sono uno studente di ingegneria informatica al primo contatto serio con ML. Voglio colmare il gap prima del corso di deep learning.” — Path ml-fondamenti-classici puro. Parte IV (matematica), Parte VII (AI classica, selettiva), Parte VIII (ML) intera. Poi puoi passare a llm-internals-deep.

“Faccio il security engineer in una fintech. Stiamo valutando di dare accesso a un agente interno con tool di lettura su database produttivi. Ho paura.” — Path safety-e-sicurezza con precedenza assoluta. Poi, solo dopo, Parte XVII (harness) per capire il layer di contenimento. La decisione di dare o non dare quell’accesso deve essere informata.

“Gestisco un team di cinque dev. Non ho tempo di leggere trecento pagine ma voglio indirizzare bene le persone.” — Path practitioner-quick per te, poi assegni a ciascun membro il path più adatto al suo scopo e rivedete insieme ogni due settimane.

“Sono un prodotto senior. Devo decidere quale feature AI lanciare nel prossimo quarter e cosa promettere ai clienti.” — Path practitioner-quick per il minimo tecnico, poi Parte XXI (Economia) e Parte XIX (Valutazione) per il lato decisionale. Parte XX (Sicurezza) se la feature tocca dati sensibili.

“Sono una ricercatrice accademica in NLP classica. Voglio capire come si è passati dai miei metodi ai transformer.” — Parte VIII (ML, selettivo su seq2seq, attention-ml) + Parte IX (Anatomia LLM). Poi storia-filosofia-ai per contestualizzare, e Parte XII (Reasoning) per la frontiera attuale.

Si sceglie il path più vicino al proprio scopo. Si segue la sequenza. Se durante la lettura si incontra un rimando interessante fuori dal path, ci sono due opzioni: proseguire dritto e tornare al rimando dopo, oppure digredire e ritornare alla sequenza al proprio ritmo. Nessuna delle due è sbagliata.

I path non sono mutuamente esclusivi. Un lettore può completarne più di uno. agent-coding-spine seguito da llm-internals-deep produce un praticante con fondamenta tecniche solide. cognitive-to-agent seguito da agent-coding-spine produce qualcuno che capisce perché un harness è fatto così e non solo come usarlo.

Mescolare path è possibile ma produce incoerenza di profondità se fatto a caso. Meglio completare un path prima di iniziarne un altro, o decidere esplicitamente di farne due in parallelo con un ritmo regolare (ad esempio un capitolo della spine + un capitolo di filosofia a settimana).

Una stima realistica.

Un capitolo di contenuto richiede 45-90 minuti di lettura attenta, a seconda della densita e del background. Un capitolo meta 10-30 minuti.

Alcuni esempi di tempo totale per path:

  • practitioner-quick (~40 slug): 25-40 ore per la lettura primaria, più il tempo di praticare. Fattibile in 4-8 settimane con 3-5 ore a settimana.
  • agent-coding-spine (~150 slug): 100-200 ore. Sei mesi-un anno con ritmo regolare.
  • storia-filosofia-ai (~80 slug): 50-80 ore. Tre-quattro mesi.
  • cognitive-to-agent (~60 slug): 40-60 ore. Due-tre mesi.
  • ml-fondamenti-classici (~50 slug): 40-70 ore. Tre-cinque mesi.

Non è una gara. Un path completato in sei mesi con pratica costante vale più di un path completato in tre settimane di binge reading senza applicazione.

Rallentare è spesso giusto. Un capitolo difficile può richiedere più letture, appunti, esperimenti sul codice. La comprensione profonda si sedimenta con il tempo, non con il volume.

Tre ritmi validi a seconda del tempo disponibile.

Immersivo (5-10 ore a settimana): due-tre capitoli a settimana, con pratica sul codice tra uno e l’altro. Ideale per chi sta cambiando ruolo o ha un progetto attivo che richiede queste competenze. Rischio: burnout se il livello non corrisponde al background.

Sostenuto (2-3 ore a settimana): un capitolo a settimana, qualche nota presa, pratica mensile. Ideale per chi lavora già in ambito vicino e integra gradualmente. È il ritmo più sostenibile per la maggior parte dei profili.

Ambientale (1 ora a settimana o meno): letture sporadiche, navigazione a grafo invece di path lineari, riferimento al bisogno. Ideale per chi non lavora direttamente sull’AI ma vuole restare informato con profondità.

Qualsiasi ritmo è preferibile a “leggo tutto in un weekend e poi non ci penso più”. La memoria a lungo termine si consolida con ripetizione distanziata, non con immersione breve.

Succede. Il tuo obiettivo può essere trasversale ai path esistenti, o così specifico da non meritare un path dedicato.

In quel caso, la wiki resta navigabile liberamente. Due strategie:

Costruisci il tuo path. Parti dallo slug più vicino al tuo obiettivo (usando outline.md come indice), segui i collegamenti in fondo a ogni capitolo, ramifica quando serve. Se il path che stai costruendo si rivela utile ad altri, aggiungilo a reading-paths.md: diventa patrimonio collettivo.

Chiedi. Se stai usando la wiki in una conversazione assistita (Claude Code o altro), puoi descrivere il tuo scopo in linguaggio naturale e chiedere un path su misura. L’output sarà una sequenza di slug giustificati, che puoi salvare come tuo path personale.

Un terzo modo, più rozzo ma valido: leggi in ordine tutta una Parte. Se sei convinto che il tuo interesse sia concentrato in una Parte (es. solo Parte XIV Context Engineering), leggila intera e ignora le altre. La coerenza interna di una Parte è garantita.

Quando finisci un path, tre opzioni naturali.

Path parallelo di fondamenta: se hai fatto agent-coding-spine senza toccare le Parti filosofiche, torna indietro con storia-filosofia-ai o cognitive-to-agent. La spine ti avrà lasciato domande che quei path chiudono. La direzione opposta funziona anche: dopo aver fatto storia-filosofia-ai, agent-coding-spine diventa molto più digeribile.

Approfondimento verticale: scegli 3-5 slug specifici che durante il path ti hanno incuriosito e scava a fondo seguendo i link. Diventa locale-esperto di quei punti. Esempio: dopo la spine, potresti voler diventare esperto di prompt caching e tutta l’economia che ne deriva.

Costruzione: applica. Fai un progetto serio che usi quello che hai letto. Un agente reale, un RAG reale, un sistema valutato con eval vere. Leggere senza costruire non produce competenza. La wiki è propedeutica, non sostitutiva.

Quando si aggiunge uno slug nuovo all’outline, va collocato nei path coerenti. Un path troppo corto (meno di quindici slug) si fonde con un altro. Un path troppo lungo (più di cento) si divide in volumi.

I path non sono scolpiti nella pietra. Quando un reading path si rivela poco utile (nessuno lo finisce, il feedback dice che è sbilanciato, lo scopo dichiarato non viene raggiunto) si riscrive. Quando la tecnologia cambia in modo strutturale (esempio ipotetico: se gli SSM soppiantano davvero i transformer), un path può essere dichiarato “legacy” e sostituito.

L’evoluzione dei path seguirà un principio di stabilità: prima di cambiare radicalmente un path, si valuta se vale la pena rompere l’esperienza dei lettori che lo stanno seguendo. Piccole aggiunte sono benvenute; riscritture si concentrano in release dichiarate.

I “libri” stampabili nascono come export di reading path. Quando il materiale di un path è maturo, si esporta in un formato stampabile (Word per Amazon KDP, in prospettiva), si aggiungono copertina, prefazione e indice analitico, e si pubblica.

Il path resta il sommario vivente; il libro è una sua fotografia datata.

Concretamente, due esempi di come questo si traduce:

  • Il path agent-coding-spine produrrà il libro Agent Coding — la bibbia pratica.
  • Il path storia-filosofia-ai produrrà L’AI da Dartmouth agli agenti: storia e filosofia.

Altri libri potranno nascere da path futuri o da combinazioni. L’importante è che il sorgente markdown del grafo resta unico: i libri sono viste, non copie divergenti. Quando esce una seconda edizione del libro, non si riscrive il libro: si rifa l’export dal path aggiornato.

Ogni libro includerà una nota esplicita sulla data di export e sul fatto che la wiki online resta autoritativa per il contenuto vivo.

“Posso seguire due path in parallelo?” — Si, ma imposta un ritmo (es. un capitolo di ciascuno a settimana). Altrimenti ne segui uno e l’altro si accumula. Se i due path si sovrappongono su alcuni slug, leggi lo slug condiviso una volta sola.

“Ho saltato un capitolo che sembrava difficile. Posso andare avanti?” — Si, ma segnalo. Quando incontri un collegamento che puntava li, torna. I capitoli difficili saltati tendono a tornare come pareti più avanti nel path.

“Il path non menziona un concetto che mi serve. Cosa faccio?” — Cerca lo slug in outline.md, aggiungilo al tuo percorso personale. Se molti altri hanno lo stesso bisogno, vale la pena aggiornare il path.

“Posso proporre un path nuovo?” — Si, quando il progetto avrà canali pubblici. Nel frattempo, il repo è privato: tieni il tuo path in una nota locale.

“I path sono adatti a principianti assoluti?” — Dipende dal path. ml-fondamenti-classici parte davvero dalle basi. agent-coding-spine assume saper programmare. practitioner-quick assume familiarita con API. Nessun path parte da “cosa è un algoritmo”.

“E se non finisco un path?” — Non succede niente. Non c’è un esame. I capitoli letti restano utili anche isolatamente.

“Come tengo traccia di dove sono?” — Per ora manualmente, con un tuo file note o un bookmark sul capitolo corrente. Quando il progetto diventerà un sito, la navigazione conserverà lo stato.

“Posso cambiare path a meta strada?” — Si, se il nuovo path risponde meglio al tuo scopo. Non sprechi i capitoli letti: restano validi indipendentemente dal path.

I path sono inevitabilmente autoriali. Riflettono opinioni su cosa conta di più, cosa viene prima, cosa si può saltare. Un lettore con scopi leggermente diversi può trovare un path quasi-giusto che lo porta fuori strada per una scelta di ordinamento che non condivide. La soluzione non è discutere il path, ma costruirsene uno.

I path non sono corsi. Non c’è un istruttore, non c’è un esame, non c’è un ritmo imposto. Funzionano per chi ha autonomia e fame; faticano per chi si aspetta una struttura didattica guidata.

I path non sostituiscono la pratica. Completare agent-coding-spine senza mai scrivere un agente è come leggere un manuale di chitarra senza toccare lo strumento: hai un vocabolario ma non sai suonare.

I path non garantiscono aggiornamento puntuale. Se un capitolo cambia significativamente, il path che lo include resta valido nell’ordine ma il contenuto del capitolo è stato riscritto. Rileggere un capitolo dopo un anno può sorprendere.

  • intro-wiki — struttura generale della wiki.
  • convenzioni-notazione — stile e notazione, utili per seguire qualsiasi path con fluidita.
  • mappa-concettuale — vista d’insieme sulle connessioni trasversali, utile per scegliere un path.
  • ../reading-paths.md — il file sorgente con tutti i path e le loro sequenze complete.
  • ../outline.md — elenco degli slug, per navigazione libera o costruzione di path personali.