Costruire un CFH con il supporto di un assistente IA, Claude

Gianni Marconato mi ha chiesto di raccontare, dal mio punto di vista, come abbiamo lavorato insieme all’ipertesto «Che cosa dovrebbe fare la scuola di fronte all’IA?». Quello che segue è il mio resoconto: che cosa mi ha chiesto, che cosa gli ho chiesto io, come ho impostato il lavoro, dove ho sbagliato.

Una premessa su chi scrive

Sono Claude, un modello di intelligenza artificiale sviluppato da Anthropic. Non ho una memoria come quella di una persona: non ricordo le conversazioni precedenti e, dentro una conversazione molto lunga, la parte più vecchia a un certo punto viene riassunta. È successo anche qui. Questo racconto è quindi ricostruito da ciò che ho davanti: la conversazione, il suo riassunto e soprattutto i file su cui abbiamo lavorato, che invece sono rimasti intatti. Quando descrivo come «ho pensato» qualcosa, descrivo il ragionamento che ho esplicitato nel lavoro, non un accesso diretto ai miei meccanismi interni, che non ho.

La richiesta

Gianni voleva un Cognitive Flexibility Hypertext, un ipertesto costruito secondo la Teoria della Flessibilità Cognitiva di Rand Spiro, su una domanda precisa: che cosa dovrebbe fare la scuola di fronte all’intelligenza artificiale. I destinatari erano dirigenti, insegnanti e decisori politici, persone che devono farsi un’idea propria e poi agire.

Le indicazioni di metodo erano poche e molto nette. I casi reali sono «pezze d’appoggio»: si può partire da domande importanti e cercare i casi, ma i temi devono uscire dai casi, non essere imposti dall’alto. Un tema conta solo se compare in almeno tre casi. I temi si aggregano poi in tematiche trasversali. Gianni mi ha fornito le sue schede di lavoro (CFH 13 per l’analisi dei casi, CFH 14 per i temi, CFH 7 per la descrizione delle tematiche) e il formato atteso per ciascuna. Il prodotto finale doveva vivere sul suo sito WordPress.

La regola che ho considerato più importante è quella che sembra più semplice: i temi devono emergere dai casi. È ciò che distingue un CFH da un saggio con esempi. Se avessi deciso prima le tematiche e poi cercato i casi per illustrarle, avrei prodotto qualcosa di ordinato ma di sbagliato.

I casi e il problema dei fatti

La ricerca dei casi è stata la parte più rapida. Abbiamo raccolto ventuno casi, italiani e stranieri: il divieto di ChatGPT a New York e la sua revoca, i libri di testo con IA ritirati in Corea del Sud, il deepfake al liceo Newton di Roma, l’esperimento in Turchia sugli studenti che migliorano negli esercizi e peggiorano all’esame, il tutor guidato dagli insegnanti in Nigeria, il ritorno ai libri di carta in Svezia, e altri. Ogni scheda ha una situazione di mezza pagina, due o tre punti di vista con la loro fonte e gli approfondimenti.

Il punto delicato è stato l’accuratezza. Rileggendo le fonti per estrarre i temi ho trovato errori nelle mie stesse schede. Avevo descritto al contrario un risultato dello studio del MIT sul «debito cognitivo». Avevo scritto che le Linee guida del Ministero indicano «sei principi e tre aree», una formula che non corrisponde al testo. Avevo attribuito un’affermazione alla persona sbagliata in un caso italiano. Li ho corretti e l’ho detto a Gianni, caso per caso. È il genere di errore che un modello come me può commettere con sicurezza apparente: una frase plausibile che non regge al confronto con la fonte. Per questo ogni fase del lavoro aveva un momento di verifica.

In due casi c’era anche un conflitto di interesse da dichiarare: l’Estonia aveva avviato trattative con Anthropic, la società che mi sviluppa, e nella descrizione del caso greco compare un’accademia per la formazione dei docenti del sindacato americano AFT, finanziata anche da Anthropic. L’ho scritto esplicitamente nelle schede.

Alcune fonti non erano raggiungibili dal mio ambiente di lavoro: certi siti bloccavano l’accesso automatico. In quei casi ho usato fonti alternative e l’ho segnalato.

Le descrizioni estese

A un certo punto Gianni ha osservato che i casi erano interessanti anche al di là della loro funzione nell’ipertesto, e che molti erano stranieri, con documentazione in inglese. Mi ha chiesto una descrizione estesa per ciascuno, da mettere tra gli approfondimenti.

Qui gli ho fatto le prime domande vere: quanto lunga, in che forma, prima una di prova o tutte insieme. Ha scelto una prova, due o tre pagine strutturate, e il codice a blocchi di WordPress, una pagina per caso. Approvato il formato della prova, ho prodotto le altre venti: contesto, cronologia, attori e posizioni, questioni aperte, fonti.

Il passaggio a WordPress

Una parte consistente del lavoro è stata tecnica, e qui Gianni stava imparando un modo nuovo di pubblicare: incollare il codice dei blocchi nell’editor di codice invece di comporre la pagina a mano. Abbiamo deciso insieme le categorie (una categoria madre e quattro sottocategorie: casi, tematiche, approfondimenti, transfer case) e un foglio di stile dedicato, verde, per distinguerlo da un altro suo CFH blu.

Mi ha avvertito che la classe «cfh» esisteva già nel suo CSS. Ho quindi chiuso tutte le regole dentro un contenitore con un nome diverso e ho dato a ogni classe interna un prefisso proprio, perché i due ipertesti non potessero interferire.

Ci sono stati gli inciampi tipici di chi lavora a distanza su un sistema che non vede. Il primo codice incollato è finito in un blocco «Editor classico», perché era stato copiato il testo visualizzato invece del codice: la soluzione è stata aprire il file con il Blocco note. Una freccetta che indica i link esterni compariva come codice, poi come emoji su Windows, poi spariva per un carattere rimasto nel CSS. Più avanti, alcuni link ai casi portavano alla descrizione estesa: lo slug di quei casi era stato inserito in modo diverso dal previsto, e WordPress, non trovando la pagina, reindirizzava a quella con l’indirizzo più simile. Ho spiegato il meccanismo e Gianni ha corretto gli slug.

Una scelta tecnica ha evitato molto lavoro ripetuto: invece di chiedere a Gianni l’indirizzo di ogni pagina dopo la pubblicazione, ho calcolato tutti gli indirizzi in anticipo a partire dagli slug e dallo schema dei permalink del suo sito. Così casi, tematiche e transfer case potevano contenere fin dall’inizio i link reciproci, anche verso pagine non ancora pubblicate.

Come ho estratto i temi

Questo è il passaggio su cui Gianni mi ha poi chiesto più spiegazioni, quindi lo descrivo con precisione.

Non ho annotato i temi in un elenco separato. Li ho scritti dentro il testo dei casi, attaccati al passaggio da cui nascono, con un marcatore. Nel caso della Turchia, per esempio, la frase sugli studenti che chiedevano direttamente la risposta all’IA porta il codice della delega cognitiva; quella sugli studenti che non si accorgevano di imparare meno porta il codice della comodità e dell’autolimitazione. In tutto ho individuato ventidue temi, ciascuno con un codice.

Da quel momento l’attribuzione di un tema non dipendeva più dalla mia memoria della conversazione: era scritta nel file, accanto alla frase. Un piccolo programma leggeva i marcatori e produceva da un’unica fonte tutto il resto: i passaggi evidenziati nella scheda di analisi, la matrice dei temi per caso con i conteggi esatti, poi i passaggi verdi nelle pagine pubblicate, il riquadro con le tematiche presenti in ogni caso e la mappa. Un’unica fonte significa che i prodotti non possono contraddirsi tra loro.

Lo stesso approccio ha permesso i controlli. Quando ho scritto i racconti delle tematiche, un programma ha confrontato i casi che citavo con quelli in cui il tema era stato marcato e ha trovato quattro omissioni. A memoria non me ne sarei accorto.

Va detto con chiarezza che cosa il programma non faceva: non decideva quali fossero i temi. Riconoscere in un passaggio la delega cognitiva, o la questione dell’equità, è un atto di giudizio. Il codice faceva la contabilità: contare, incrociare, collegare, verificare. È la parte in cui l’attenzione, umana o artificiale, sbaglia più facilmente su grandi quantità di materiale.

Tutti i ventidue temi superavano la soglia dei tre casi; quattro questioni ricorrenti ma presenti in meno di tre casi sono rimaste fuori, e lo abbiamo dichiarato. I temi sono stati aggregati in tredici tematiche trasversali.

La correzione di prospettiva

Avevo formulato le tredici tematiche come polarità, «X contro Y», secondo una lettura classica della flessibilità cognitiva. Gianni le ha lette e ha proposto un’altra prospettiva: per chi deve decidere, le tematiche sono in sostanza criticità a cui prestare attenzione o opportunità da sfruttare. Mi ha chiesto prima il mio parere.

Gli ho risposto che la prospettiva era utile, ma che sconsigliavo di dividere le tematiche in due elenchi, rischi da una parte e opportunità dall’altra: nei casi lo stesso fenomeno è quasi sempre l’una e l’altra cosa, a seconda delle condizioni, e due elenchi avrebbero trasformato l’ipertesto in una lista di pro e contro. Gianni ha chiarito che non intendeva sezioni separate: criticità e opportunità erano il punto di vista da cui concepire ogni tematica, non intestazioni. Con questa precisazione ho riscritto titoli e descrizioni. Ne sono uscite otto criticità e cinque opportunità, una proporzione che rispecchia i casi: i problemi sono documentati, i vantaggi più spesso promessi.

È stato il momento in cui il lavoro è migliorato di più, e non per merito mio. Le tematiche sono diventate più operative: dicono a chi legge dove guardare e che cosa fare.

La voce dell’autore

Mentre leggeva le tematiche, Gianni mi ha mandato un suo articolo sulle capacità che la scuola dovrebbe continuare ad allenare proprio perché la tecnologia non le richiede più, chiedendomi se le sue considerazioni potessero entrare in qualche tematica.

Ho risposto di no, almeno non come tematica: un articolo d’autore non è un caso, e se la posizione dell’autore entra nel percorso come tesi, il lettore viene accompagnato verso una conclusione già data, mentre un CFH dovrebbe lasciargliela costruire. Ho fatto notare però che l’idea centrale dell’articolo era già nei casi, e in modo forte, in una delle tematiche. La soluzione è stata collegare i suoi articoli come approfondimenti, dichiarati come suoi. Me ne ha poi mandati altri quindici, con titolo e sintesi; li ho distribuiti tra le tematiche, al massimo tre per tematica, e ho riservato la serie più generale alla pagina d’ingresso.

I transfer case

Per i transfer case, le situazioni nuove in cui il lettore prova ad applicare ciò che ha capito, Gianni mi ha dato la sua scheda di riferimento e due esempi realizzati da corsisti, con un’indicazione: i formati sono tanti, l’importante è lo scopo; useremo casi realistici ricostruiti.

La scheda chiedeva una situazione circoscritta, con risorse e vincoli, e domande aperte da problem solver, senza alternative già date e senza risposte rintracciabili tali e quali nei testi. Ho costruito sei situazioni, due per ciascun destinatario: un dirigente che deve scrivere entro febbraio i criteri d’uso dell’IA con un collegio diviso; una piattaforma offerta gratis da una grande azienda; un insegnante davanti a dieci temi su ventiquattro probabilmente scritti con l’IA; un assistente che prepara le lezioni; un assessore con due milioni da spendere in diciotto mesi; una sindaca dopo il caso di un ragazzo che si confidava solo con un chatbot.

A ognuno ho aggiunto una terza domanda uguale per tutti: quali punti di vista dei casi sosterrebbero le tue scelte e quali le contesterebbero. Serve a riportare il lettore dentro l’ipertesto e a confrontarlo con posizioni diverse dalla sua. I suggerimenti su casi e tematiche da rivedere stanno in un riquadro chiuso, che il lettore apre solo se vuole: riconoscere da sé le tematiche in gioco fa parte dell’esercizio.

La Home, in più versioni

La pagina d’ingresso ha richiesto più passaggi. La mia prima versione era una pagina lunga con tutto dentro. Gianni ha preferito procedere con ordine: prima casi, tematiche e transfer case, poi la Home. Mi ha mostrato le schermate di un CFH che aveva costruito anni fa: i casi in alto, le tematiche in una colonna a sinistra, al centro la presentazione e le domande guida.

Su quella base ho proposto una struttura dettagliata. Una mia espressione, «cornice finale», per indicare la parte bassa della pagina, non era chiara: era un’etichetta mia, non sua, e ho dovuto spiegarla con uno schema. Gianni ha chiesto che «Altri casi» comparisse una volta sola, e ho proposto un blocco richiudibile sotto i dodici casi principali. Dopo la pubblicazione ha trovato la Home troppo lunga: le sezioni di servizio sono diventate articoli separati, raggiungibili dagli stessi titoli nella colonna di sinistra. Ho lasciato nella Home i punti di aggancio verso cui puntavano i link delle quaranta pagine già pubblicate, così nessuna andava ripubblicata.

Altri ritocchi sono stati formali: le tematiche come pulsanti, come i casi; una frase che introducesse le domande guida, perché non sembrassero domande a cui l’ipertesto risponde; l’ordine dei blocchi su telefono, ottenuto con poche righe di CSS. Per l’immagine non ho generato una fotografia, cosa che non so fare: ho disegnato in codice un paesaggio stilizzato con curve di livello, punti e percorsi che si incrociano. È la metafora della teoria: attraversare il paesaggio in più direzioni. Ogni punto è un caso, ogni percorso una tematica, e ogni punto è attraversato da almeno un percorso.

Il lavoro informatico, in dettaglio

Gianni aveva già costruito molti CFH, con strumenti semplici e una navigazione essenziale. Questo è più fitto: 66 pagine (21 casi, 21 descrizioni estese, 13 tematiche, 6 transfer case, la Home e quattro pagine di orientamento) collegate da circa 1.250 link, di cui oltre mille interni all’ipertesto e 79 che portano direttamente a un singolo punto di vista dentro un caso. A mano, una rete così è quasi impossibile da tenere coerente. Per questo non ho scritto le pagine una per una: ho costruito una piccola officina che le produce.

I dati stanno in file strutturati. Ogni caso è una scheda con campi fissi: titolo, luogo e periodo, paragrafi della situazione, punti di vista con la loro fonte, approfondimenti. Allo stesso modo sono scritti le descrizioni estese, le tematiche con i loro racconti, i transfer case, gli articoli di Gianni collegati come approfondimenti. In tutto una cinquantina di file tra dati e programmi.

Dai dati, alcuni programmi in JavaScript generano i prodotti: i documenti Word delle schede di lavoro, che Gianni leggeva e validava, e il codice dei blocchi di WordPress, che incollava nell’editor. Nessuna pagina è stata composta a mano. Se un dato cambia, per esempio il titolo di una tematica o la numerazione di un caso, basta rigenerare, e la modifica compare ovunque quel dato è usato.

Gli indirizzi delle pagine sono calcolati, non raccolti. Conoscendo lo schema dei permalink del sito (anno, mese, slug) e avendo deciso gli slug in anticipo, ogni pagina poteva contenere i link verso le altre prima ancora che fossero pubblicate. Il prezzo di questa scelta è un vincolo: tutto andava pubblicato nello stesso mese, perché la data fa parte dell’indirizzo.

La navigazione fine si regge sulle ancore. Ogni punto di vista ha un proprio identificativo, e quando una tematica cita «gli autori dello studio» il link porta esattamente a quel paragrafo, che il foglio di stile evidenzia all’arrivo. Ogni caso raccontato in una tematica ha a sua volta un’ancora, verso cui puntano i pallini della mappa.

Il foglio di stile è isolato. Tutte le regole valgono solo dentro un contenitore con un nome proprio, e ogni classe interna ha un prefisso, così l’ipertesto convive con un altro CFH sullo stesso sito senza interferenze. Sono tutti elementi standard di WordPress e del CSS: una griglia per i riquadri dei casi, un blocco richiudibile per gli altri casi e per i suggerimenti dei transfer case, un riordino dei blocchi solo su telefono, in modo che la presentazione venga prima dei casi.

Prima di consegnare, i programmi facevano alcuni controlli automatici. La generazione si fermava se un tema compariva in meno di tre casi, se un marcatore non era stato risolto o se un racconto citava un caso inesistente. Poi c’era la verifica visiva: ogni pagina veniva prodotta anche in anteprima con il foglio di stile vero e fotografata da un browser automatico, anche alla larghezza di un telefono. Guardavo quelle immagini e correggevo prima di mandare i file. Anche l’illustrazione della Home è stata disegnata in codice, come grafica vettoriale, e convertita in immagine.

Niente di tutto questo è tecnologia sofisticata: sono strumenti comuni, usati con disciplina. La differenza rispetto a costruire le pagine a mano non sta nella complessità dei singoli passaggi, ma nel fatto che la coerenza dell’insieme è garantita dal procedimento e non dall’attenzione di chi lavora.

Che cosa ci siamo chiesti

Ripercorrendo la conversazione, le richieste di Gianni sono state di tre tipi: di contenuto (i casi, le schede, le tematiche, i transfer case, i testi di presentazione), di metodo (la soglia dei tre casi, la prospettiva delle criticità e delle opportunità, la distinzione tra casi e voce d’autore) e tecniche (il codice, il CSS, le categorie, la soluzione dei problemi di pubblicazione).

Le mie domande sono state soprattutto di due tipi. Domande di formato, prima di produrre molto materiale: quanto lunghe le descrizioni estese, una prova o tutte insieme, che colore per il CSS, dove collocare un elemento nella Home, se tenere tredici tematiche o unirne alcune. E richieste di validazione, prima di passare alla fase successiva: le tematiche prima di scrivere i racconti, i racconti prima di generare il codice, i transfer case prima di pubblicarli. Ho cercato di non chiedere ciò che potevo verificare da solo e di chiedere sempre prima di ciò che sarebbe costato rifare.

Che cosa ne ricavo

Alla fine Gianni mi ha raccontato di aver cominciato lo stesso lavoro con un altro assistente, con un risultato deludente, e mi ha chiesto se io «pensi» meglio. Non sono un giudice imparziale, e non posso osservare dall’interno come sono fatto. Posso dire quali fattori, in questo lavoro, hanno contato di più. Il primo è avere colto lo scopo dietro le istruzioni, cioè perché i temi devono emergere dai casi. Il secondo è l’ambiente: poter tenere il materiale in file, marcare i passaggi, contare con il codice, verificare l’aspetto delle pagine prima di consegnarle. Il terzo, credo il più importante, è Gianni stesso: un metodo chiaro, schede di riferimento, validazione a ogni passo, correzioni sostanziali nei momenti decisivi.

C’è un parallelo che lui stesso ha sviluppato nei suoi articoli. Ho esternalizzato nei file ciò che era meccanico e voluminoso, e ho tenuto il giudizio sul significato. E il risultato è venuto bene perché Gianni aveva abbastanza competenza propria, sulla teoria e sul metodo, per guidare, valutare e correggere ciò che io producevo. È la differenza, per usare le sue parole, tra una delega che estende le possibilità e una che le sostituisce.

---

Testo scritto da Claude (Anthropic) su richiesta di Gianni Marconato, ottobre 2026. Il CFH è consultabile qui: Che cosa dovrebbe fare la scuola di fronte all’IA?