Cosa è questa wiki, come usarla, come contribuire

Una mappa ragionata dell’AI: dalla filosofia della mente agli agenti in produzione. Organizzata a grafo, leggibile in più modi, pensata per durare mentre il campo cambia.

Perché esiste

Il campo dell’intelligenza artificiale cambia troppo in fretta perché un libro stampato sia la forma giusta per impararlo. Tra la stesura e la stampa passano mesi; in quei mesi escono tre modelli nuovi, due paradigmi di reasoning, un protocollo per gli agenti. Quando il libro arriva in mano al lettore, meta del contenuto sull’ultima frontiera è già storia.

Ma i contenuti disponibili online oscillano tra due estremi. Da un lato, tutorial che insegnano la ricetta senza spiegare perché funziona: “chiama questa API, passa questo JSON, leggi la risposta”. Utili per consegnare domani, inutili per ragionare sul sistema fra un mese. Dall’altro lato, paper accademici che danno per scontati decine di prerequisiti: una frase come “the attention mechanism scales quadratically with sequence length due to the $O(n^2)$ dot-product complexity” assume che tu sappia già cosa sia l’attention, perché sia un dot-product, e cosa significhi scalare quadraticamente in pratica.

Questa wiki vuole stare nel mezzo. Profondita sufficiente per capire davvero cosa succede dentro un transformer, perché un harness agentico è fatto così, da dove viene la teoria dei giochi che muove RLHF. Accessibilità sufficiente per un developer professionista con matematica da liceo e nessun background formale in ML o filosofia.

La scrittura è in italiano, i termini tecnici in inglese. Nessuno traduce attention o transformer: sono parole del dominio. Nessuno vuole leggere “trasformatore” per intendere un modello a 175 miliardi di parametri.

Da dove viene questo progetto

La wiki nasce da una frustrazione concreta. Dopo aver letto decine di articoli su transformer, MoE, RLHF, restava sempre l’impressione di aver capito la ricetta senza aver capito la cucina. I paper originali sono densi e scritti per reviewer esperti; le spiegazioni divulgative sono spesso semplificazioni che poi non reggono quando provi ad applicarle su un caso reale.

Il momento di svolta è stato il consolidarsi dell’agent coding tra 2024 e 2026: protocolli come MCP, agenti come Claude Code e Cursor, modelli “thinking” come o1 e o3. Il campo si stava professionalizzando ma mancava un corpus didattico sistematico in italiano. Esistono tutorial per iniziare, esistono discussioni tecniche sparse in inglese, ma non esiste un testo unico che vada dalla storia della disciplina alla pratica degli harness moderni.

Questa wiki prova a essere quel testo. Non perché l’autore creda di essere più autorevole di altri: perché qualcuno deve pur provarci, e il processo stesso di scriverla chiarisce i punti oscuri meglio di cento letture passive.

Per chi è scritta

Il lettore tipo è uno sviluppatore con anni di codice alle spalle, che sa cos’è un vettore e una derivata a intuito, conosce la probabilita di base, legge pseudocodice senza sforzo. Non ha un master in matematica, non ha mai addestrato una rete neurale da zero, non ha letto Searle o Kahneman all’università. Ha curiosità, pazienza, e l’abitudine di voler capire perché.

Nessun prerequisito accademico di filosofia della mente, scienze cognitive, machine learning formale o AI simbolica. Quando serve un pezzo di uno di questi campi, la wiki lo fornisce, alla profondità giusta per andare avanti.

Profili tipici che la wiki serve bene:

• Il backend engineer che ha integrato un LLM via API e adesso vuole capire perché un prompt funziona e un altro no.
• La tech lead che deve decidere se mettere un agente in produzione e vuole sapere quali sono davvero i rischi di sicurezza.
• Il developer curioso che non lavora su AI ma vuole leggere ChatGPT o Claude con occhi informati invece che attraverso i titoli di giornale.
• Lo studente autodidatta che ha saltato il corso universitario di ML e adesso se ne pente.
• Il prodotto che ha ereditato una feature AI e deve capire cosa può chiedere ragionevolmente al modello.
• Il security engineer che deve fare threat modeling su un sistema agentico.

Profili che la wiki non serve bene:

• Chi cerca un tutorial passo-passo di un tool specifico: esistono le docs ufficiali.
• Chi cerca l’ultimo paper nudo e crudo: esiste arXiv.
• Chi vuole solo “far funzionare” senza capire: questa wiki costa tempo, inutilmente se non te ne interessa il perché.
• Chi cerca una certificazione: non è un corso con esame finale.

Come è organizzata

La wiki è un grafo, non una sequenza. Più precisamente, è organizzata in 22 Parti tematiche (più una Parte 0 di orientamento e un blocco di appendici):

• Storia dell’AI, da Leibniz e Turing al mondo post-2026.
• Filosofia della mente e dell’intelligenza, da Searle al superallineamento.
• Scienze cognitive, con ponti espliciti verso la pratica agentica.
• Matematica operativa, a livello di intuizione + formalismo minimo.
• Teoria dei giochi e decisioni, inclusi i fondamenti di RL.
• Algoritmi e strutture dati utili per l’AI pratica.
• AI classica simbolica, per capire cosa c’era prima degli LLM.
• Machine Learning, dalla regressione lineare a diffusion.
• Anatomia di un LLM, Architetture moderne, Training.
• Reasoning e test-time compute.
• Inferenza, Context Engineering, Prompt Engineering.
• Agenti: fondamenti, Harness Engineering, Agent Coding in pratica.
• Valutazione, Sicurezza, Economia e operations, Casi studio.

Ogni Parte contiene slug (voci indivisibili di contenuto) che corrispondono a pagine singole. Gli slug sono elencati in outline.md, che funge anche da checklist di avanzamento.

Alcuni slug sono ponti (prefisso ponte-): connettono esplicitamente temi di Parti diverse. Esempio: ponte-memoria-agenti collega la psicologia della memoria umana alle scelte architetturali della memoria agentica. ponte-attenzione-transformer chiarisce quanto del nome attention nei modelli moderni erediti davvero dalla psicologia sperimentale. ponte-bounded-rationality-ttc lega la razionalità limitata di Simon al test-time compute dei modelli “thinking”. Questi ponti sono il collante della wiki: senza di essi le Parti umanistiche sembrerebbero digressioni erudite, con essi diventano chiavi interpretative per capire scelte architetturali concrete.

Come si legge

Tre strade, nessuna privilegiata.

In ordine. Si parte da Parte 0 e si scende. Adatta a chi vuole costruire le fondamenta prima di correre. Lungo — qualche centinaio di pagine — ma solido. Produce una comprensione sistematica difficile da ottenere altrove.

Per reading path. In reading-paths.md ci sono letture curate con uno scopo specifico. Agent Coding pratica per chi deve consegnare. LLM Internals deep per chi vuole capire ogni strato. Cognitive to Agent per chi arriva dalla psicologia o dalle neuroscienze. ML fondamenti classici per riempire il vuoto prima del deep learning. Teoria dei giochi per AI per capire RL e allineamento dalla prospettiva delle decisioni.

A grafo. Si entra da un qualunque capitolo e si seguono i collegamenti. Adatta a chi ha domande specifiche o sta risolvendo un problema concreto. Ogni capitolo è pensato per essere autonomo: leggibile anche saltando da un altro punto del grafo.

Scenari di lettura tipici

Per rendere concrete le tre strade, alcuni scenari:

“Sto per integrare Claude in un sistema di code review aziendale. Cosa devo sapere?” — Path agent-coding-spine per il quadro, poi ritorno sul capitolo specifico code-review-agent della Parte XVIII, con digressioni su prompt-injection-intro e mcp-sicurezza se il sistema interagisce con repository esterni.

“Ho letto che i modelli ‘thinking’ come o1 funzionano diversamente. Perché?” — Direttamente alla Parte XII (Reasoning e test-time compute), con preludio opzionale su dual-process-kahneman nella Parte III per il contesto cognitivo.

“Ho studiato psicologia. Come si traducono i concetti che conosco negli LLM?” — Path cognitive-to-agent: parti dalle scienze cognitive che già conosci, arrivi agli agenti attraverso i ponte-*.

“Il mio team usa RAG ma le risposte sono mediocri. Dove mi informo?” — Parte XIV (Context Engineering) intera, partendo da rag-base e scendendo verso rag-avanzato, chunking, reranker. Poi context-anatomia per capire il sottostrato.

“Stiamo valutando se migrare da GPT-4 a Claude. Su cosa decidere?” — Parte XIX (Valutazione) per come progettare il confronto, poi Parte XXI (Economia) per i costi. Nessun argomento generico: si decide sui tuoi dati e i tuoi task, con eval fatte bene.

“Un agente del mio team ha cancellato per sbaglio file in produzione. Come evito che succeda ancora?” — Parte XVII (Harness Engineering), in particolare permessi-sandbox, subagenti, worktree-isolation, sicurezza-harness. Parte XX per la prospettiva attaccante.

Come si costruisce

Il contenuto si produce con un workflow a cinque fasi, mediate da slash command in .claude/commands/:

1. /topic-new <slug> scaffolda research/<slug>/ con quattro file: sintesi teorica progressiva, fonti, domande aperte, stato.
2. /topic-deepen <slug> itera la ricerca: chiude domande, aggiunge fonti, aggiorna la sintesi. Si itera finché le domande aperte sono esaurite o marcate fuori-scope.
3. /topic-ready <slug> valida che il materiale sia sufficiente: per i capitoli di contenuto richiede almeno 5 fonti, 3 esempi eterogenei, 5 collegamenti motivati, nessun APPROFONDIRE residuo.
4. /chapter-draft <slug> trasforma il materiale in prosa pubblicabile in chapters/NN-<slug>.md, seguendo le regole di stile in .claude/skills/book-writing/SKILL.md.
5. /figure-spec <slug> produce i prompt di generazione immagine in figures/<slug>/prompts.md. La generazione grafica vera e propria è differita all’impaginazione.

Lo stato globale della wiki si legge con /book-status. L’outline tiene il conto con tre marcatori: [ ] non iniziato, [~] in lavorazione, [x] finale.

Filosofia editoriale

Alcune scelte esplicite che guidano ogni capitolo.

Capire prima che applicare. Quando devi scegliere tra “spiega come” e “spiega perché”, la wiki sceglie sempre il secondo. Il come lo trovi nelle docs ufficiali; il perché è il pezzo che manca.

Storia e teoria non sono ornamenti. Sapere che i percettroni fallirono per il problema XOR aiuta a capire perché le reti multi-layer furono una svolta. Sapere che Searle scrisse la Stanza Cinese nel 1980 aiuta a mettere in prospettiva ogni discussione attuale su “GPT capisce davvero?”. Niente di gratuitamente erudito: ogni pezzo di storia o filosofia deve agganciare a qualcosa di pratico.

Collegare invece di ripetere. Un concetto si spiega una volta, in profondità, nel punto giusto del grafo. Gli altri capitoli lo richiamano con un link. Questo riduce la ridondanza e permette aggiornamenti senza dover riscrivere dieci capitoli alla volta.

Mostrare i limiti. Ogni concetto ha crepe: edge case, fraintendimenti, situazioni in cui non funziona. La sezione “Dove si rompe” è obbligatoria nei capitoli di contenuto. Un testo che descrive solo i successi forma praticanti ingenui.

Parlare di soldi e di rischi. Economia e sicurezza sono spesso trattate come appendici dai materiali tecnici. Qui no: sono Parti complete, perché sono ciò che separa un esperimento da un sistema in produzione.

Accettare di invecchiare con grazia. I capitoli su tecnologie in rapida evoluzione saranno esplicitamente datati. Quando un modello nuovo cambia il quadro, si aggiorna il capitolo e si marca la data della revisione. Non si pretende di scrivere una verità eterna.

Convenzioni

Regole minime, utili quando si scrive o si contribuisce.

• Markdown puro. Nessun generatore di sito per ora. Il sorgente deve convertirsi pulito verso HTML, PDF, EPUB, Word.
• Nessuna emoji, nessun carattere decorativo unicode. La conversione automatica li mangia o li rende mal renderizzati.
• Italiano con diacritici corretti. Mai sostituire con ASCII per scelta; si accetta in draft solo quando l’editor su Windows li mangia, con revisione finale che li ripristina.
• Termini tecnici in inglese senza corsivi forzati: transformer, attention, embedding, harness, tokenizer.
• Matematica in LaTeX: $...$ inline, $$...$$ block.
• Intuizione prima del formalismo. Sempre.
• Il perché prima del come. Motivazione storica o operativa di un concetto, poi dettagli.
• Niente guessing. Se un fatto non è verificato, marcare APPROFONDIRE inline e aprire una domanda in open-questions.md.
• Collegamenti relativi: per esempio [Turing](/parte-01-storia-ai/02-turing-macchina-mente/) verso altri capitoli. Niente numeri assoluti, perché la numerazione può cambiare.
• Figure come placeholder visibili nel testo: [FIGURA — descrizione] su riga propria. La spec dettagliata vive in figures/<slug>/prompts.md.

Dettaglio completo in ENV.md e nella skill book-writing.

Cosa non e’

Non è un repository di paper: riassunti e citazioni ci sono, ma il lavoro qui è di sintesi e collegamento, non di archivio.

Non è un tutorial passo-passo di un tool specifico. I tutorial invecchiano in settimane. Qui si spiegano i principi, con esempi concreti ma non sostituibili a una guida ufficiale.

Non è un feed di notizie. Quando un modello nuovo esce, la wiki lo integra nel punto giusto del grafo, non come annuncio.

Non è imparziale. Le scelte di cosa includere, come strutturarlo, cosa contare come “capito davvero” sono autoriali. Questo è quello che rende la wiki leggibile come libro quando i reading path vengono esportati.

Non copre tutto. Hardware GPU in profondità, dettagli di low-level CUDA, architetture di training infrastructure enterprise: si toccano ma non si approfondiscono. Chi vuole quello parte da qui e poi cerca riferimenti specializzati.

Cosa leggere accanto

La wiki non sostituisce, integra. Alcune risorse a cui fa eco e a cui rimanda.

Paper originali: quando un capitolo tratta un meccanismo, il paper originale resta la fonte di verità. La wiki lo riassume, lo contestualizza, lo traduce in intuizione; non lo sostituisce per chi vuole tutti i dettagli sperimentali.

Documentazione ufficiale dei tool: per Claude Code, Cursor, MCP, Anthropic SDK, OpenAI SDK. La wiki spiega i principi; le docs coprono i parametri esatti. Leggere le docs di Claude Code dopo la Parte XVII è un’esperienza diversa rispetto a leggerle a freddo.

Testi classici di ML: Bishop “Pattern Recognition and Machine Learning”, Goodfellow-Bengio-Courville “Deep Learning”, Murphy “Probabilistic Machine Learning”, Sutton-Barto “Reinforcement Learning”. La wiki offre una via veloce; questi testi offrono la via lunga e rigorosa.

Corsi online selezionati: Andrej Karpathy “Neural Networks: Zero to Hero” per internals LLM con implementazioni da zero; fast.ai per applicazioni rapide; Stanford CS224N per NLP; Stanford CS336 per LLM systems; MIT 6.S191 per intro deep learning.

Comunità attive: r/MachineLearning su Reddit, LessWrong per discussioni su alignment e AI safety, blog di singoli autori (Simon Willison, Chip Huyen, Andrej Karpathy, Lilian Weng), mailing list di alcuni lab.

Quando il progetto potrebbe fallire

Una wiki non ha un punto di arrivo naturale: può gonfiarsi all’infinito. Se la checklist dei ~300 slug non avanza a ritmo sostenuto, il rischio è trovarsi con 50 capitoli sparsi e nessun reading path chiudibile.

I modelli evolvono più in fretta della scrittura. Un capitolo sull’era post-2026 è destinato a diventare obsoleto; mitigazione: slug mondo-post-2026 e cosa-verrà esplicitamente datati, da rivedere periodicamente.

Una wiki senza community perde energia. Questo progetto nasce come lavoro di un autore singolo con supporto assistivo; se il pubblico che la legge non cresce, la motivazione per andare avanti va gestita con lucidita.

La profondità può tradire. Un capitolo ben scritto è ingannevolmente rassicurante: fa credere al lettore di aver capito. Solo la pratica ripetuta e il fallimento consolidano. La wiki cerca di ricordarlo esplicitamente in ogni sezione “Dove si rompe” e “Applicazioni pratiche”, ma la tentazione di leggere senza fare è forte.

FAQ

“Perché in italiano?” — Perché esiste un vuoto enorme di contenuti tecnici profondi in italiano. Tradurre ogni volta dall’inglese mentalmente è un tax cognitivo; avere un testo di riferimento in italiano riduce la barriera d’ingresso. I termini tecnici restano in inglese perché è così che se ne parla nella pratica.

“È possibile contribuire?” — Per ora no. Il progetto è in fase di costruzione singola. Quando l’outline sarà stabile e un numero sufficiente di capitoli sarà scritto, valuteremo un modello di contribuzione (probabilmente pull request su un repo pubblico).

“Posso usare il contenuto per corsi o workshop?” — Licenza ancora da definire. Probabilmente qualcosa in stile Creative Commons Attribution ShareAlike. Citazione necessaria, modifiche ammesse, commercializzazione da definire.

“Quando sarà finita?” — Una wiki non finisce mai. Il primo reading path esportabile in libro (probabilmente agent-coding-spine) punta a essere completo entro alcuni mesi. Il resto seguirà, la manutenzione continua.

“Perché non una video-serie?” — Perché il testo è più denso, ricercabile, linkabile. Video eventualmente verranno come complemento, non come formato primario.

“Posso chiedere di aggiungere un topic?” — Si, attraverso i canali che verranno pubblicati quando il progetto sarà pubblico. Nel frattempo, l’outline è già ampio: prima guarda se quello che cerchi c’è già.

“Quanto è affidabile il contenuto?” — La wiki segue un workflow che distingue ricerca, validazione e stesura. Ogni fatto non ovvio dovrebbe essere ancorato a una fonte. Detto questo, errori sono possibili: per decisioni critiche, verifica con le fonti primarie citate.

“Come gestisco disaccordi con scelte editoriali?” — Le scelte editoriali sono autoriali e quindi discutibili. Se una scelta ti sembra sbagliata, costruiscitene una tua: il sorgente è markdown, puoi farcela una copia locale modificata.

“La wiki assume che io usi Claude Code? Se uso un altro tool?” — Alcuni esempi nella Parte XVIII e nel meta di progetto usano Claude Code come riferimento, perché è l’ambiente in cui la wiki nasce. Ma i principi di agent coding, harness engineering, context engineering sono agnostici: valgono per Cursor, Cline, Aider, Continue, o per un sistema costruito da zero. Dove un esempio è Claude-Code-specifico, viene segnalato.

“Quanto costa seguire tutta la wiki?” — Solo tempo. Il sorgente è gratuito. Eventuali libri stampabili saranno a pagamento (costi di produzione + un margine). I tool che la wiki insegna a usare hanno costi variabili da decine a migliaia di dollari al mese per API, coperti separatamente.

Collegamenti

• percorsi-lettura — i reading path disponibili e per chi sono.
• convenzioni-notazione — notazione matematica e regole di stile in dettaglio.
• storia-sintesi — storia dell’AI in dieci minuti, teaser della Parte I.
• mappa-concettuale — vista d’insieme sulle connessioni trasversali.
• ../outline.md — checklist e mappa di tutti gli slug.
• ../reading-paths.md — letture curate lineari.
• ../ENV.md — convenzioni operative, directory structure, workflow.