L’ho raccontata come una sconfitta, ma non è solo così. Ci sono diversi elementi che hanno una valenza positiva, anche se non completa, e che vale la pena mettere in evidenza. Il primo è che è assolutamente possibile realizzare applicazioni HTML, anche molto semplici nell’interfaccia, capaci di affrontare problemi di una certa importanza. Questo è un punto decisivo: a essere complessi possono essere i problemi, ma le soluzioni tecnologiche, operative e cognitive devono restare semplici per chi le usa. Non necessariamente semplici nella loro struttura interna, ma comprensibili rapidamente dal punto di vista dell’interfaccia.

Un altro aspetto importante è che non è affatto necessario concentrare moltissime funzioni in una sola applicazione. Anzi, farlo rischia di generare confusione. È più sensato costruire applicazioni specifiche per singoli problemi e, eventualmente, organizzare poi portali di accesso che le raccolgano. In questo modo si rimane entro confini di comprensibilità e di uso concreto.

Ciò che, almeno al momento, resta utopico è svincolarsi del tutto da strumenti come Google Antigravity o GitHub Copilot. Servono infatti la loro potenza di calcolo, i modelli a cui hanno accesso e l’infrastruttura necessaria per costruire applicazioni internamente complesse: complesse per quantità di codice, stabilità delle funzioni, interconnessioni interne e articolazione complessiva, ovvero – più correttamente – utilmente complicato. In ogni caso, è ormai chiaro che si possono realizzare applicazioni anche sapendo poco o quasi nulla di codice.

Il punto, per me, non è affrontare la questione dal lato del codice, ma da quello della prototipazione. Si tratta di poter arrivare a una trattativa con programmatori senior partendo da qualcosa di già definito, almeno in parte. Questo è un passaggio fondamentale, perché restituisce a chi individua le situazioni, analizza i problemi e riconosce le esigenze la funzione di definire bisogni e necessità, invece di delegarla interamente agli specialisti tecnici.

Detto questo, gli aspetti negativi non mancano. Non riguardano soltanto il fatto di dover ricorrere, almeno in parte, alle risorse del cloud recintato e dell’impero tecnologico. Riguardano anche il disinteresse di molte persone, che è forse l’elemento più devastante. Uno dei problemi più importanti che ho affrontato, in molti modi e con soluzioni diverse, è quello del plain language, cioè dello scrivere in modo chiaro. Eppure, una soluzione a un problema complesso di questo tipo sembra interessare a pochissimi.

Pesano molti pregiudizi sul funzionamento delle tecnologie. Molte persone non sono disposte ad accettare che sia possibile adottare strategie di avvicinamento, uso, gioco ed esplorazione diverse da quelle a cui si sono auto-inchiodate. Tendono a pensare che l’interfaccia vada semplicemente subita, che occorra imparare “come funziona” qualcosa prima di poterla usare. Ne deriva una mentalità rigida, spesso incapace di apprendere come si apprendeva un tempo andando in bicicletta: provando, sbagliando, accettando l’errore.

Un’altra questione è la fiducia. Probabilmente molte persone non si fidano di applicativi come quelli che produco io, proprio perché sono esplicitamente fuori mercato. Sono forme di condivisione della conoscenza che non rientrano nei meccanismi abituali del copyright, delle royalties, delle pubblicazioni accademiche o delle logiche di riconoscimento personale. Mi interessa invece affermare un principio diverso: quello dei dispositivi adeguati, con una vocazione sociale, fuori mercato, attenti all’ecosostenibilità e il più possibile sottratti alla cattura del digitale da parte del profitto.

Anche la parola “digitale” è problematica. Molti la trattano come se avesse un significato forte, come se fosse un concetto in sé. In realtà, spesso è solo una verniciatura di marketing. Di conseguenza si parla di educazione digitale o di scuola digitale come se fossero espressioni automaticamente significative, mentre si abbandona il pensiero analitico. Paradossalmente, gli stessi che sostengono queste formule difendono poi l’uso dell’intelligenza artificiale generativa come stimolo al pensiero critico, senza però esercitare una vera intenzione critica nei confronti dei dispositivi che usano.

C’è poi l’uso superficiale di parole come “tool” o “strumento”, che mostra spesso una scarsa consapevolezza teorica. Bisognerebbe distinguere tra qualcosa che potenzia davvero le nostre capacità operative e qualcosa che, invece, condiziona fortemente la situazione in cui operiamo, anche quando lo fa in modo almeno apparentemente positivo. È vero che certi ambienti possono offrire più opportunità, ma solo a condizione che diventino conviviali, non estrattivi.

Un altro aspetto spiacevole riguarda il modo in cui sono stati accolti alcuni tentativi di uscire dagli schemi tradizionali dell’istruzione, valorizzando maggiormente una vocazione sociale e cooperativa. Ho realizzato, per esempio, applicazioni pensate per problemi molto concreti: una era destinata a supportare migranti e caregiver dei migranti nelle procedure di legalizzazione e di integrazione formale nella comunità. L’applicazione è arrivata nelle mani di tre diverse organizzazioni o associazioni che si occupano quotidianamente di questi temi. Il messaggio era semplice: provatela, ditemi se funziona, segnalatemi che cosa va corretto. Non ho ricevuto alcuna risposta.

Al di là della maleducazione e dell’arroganza implicite in un atteggiamento di questo tipo, mi sembra evidente che qui agiscano proprio i meccanismi descritti prima. Dentro molte associazioni le procedure sono ormai irrigidite: costruiscono ruoli, mettono in moto flussi consolidati e definiti, e rendono difficile riconoscere il valore di un dispositivo capace di automatizzare e velocizzare operazioni molto meccaniche. Eppure, ottenere lo stesso risultato con meno fatica, più rapidità e maggiore chiarezza dovrebbe essere percepito come un valore aggiunto.

Un’esperienza analoga l’ho avuta con un’altra applicazione, rivolta a medici, infermieri e rappresentanti delle case farmaceutiche. In quel caso il problema era la scarsa comprensibilità di alcuni materiali informativi, nonostante gli interventi dell’Agenzia del farmaco. Si tratta di una difficoltà particolarmente rilevante per persone con un background culturale ridotto, per chi parla un’altra lingua o per chi ha comunque un’altra lingua come riferimento principale. In questo caso ho ricevuto commenti positivi da parte di specialisti a cui mi ero rivolto: mi è stato detto che l’impianto era corretto e utile. Ma, ancora una volta, non c’è stato un interesse reale a fare qualcosa.

Forse perché un lavoro del genere richiederebbe anche una forma di militanza sociale, che pure alcune di queste persone praticano in altri modi. Credo che in questo caso operino anche una sudditanza sostanziale nei confronti della macchina e una visione distorta della mia persona: vengo facilmente considerato un fissato, oppure un esperto irraggiungibile, quasi un guru. Non lo dico per vantarmi, ma per provare a capire perché molte persone non tentino nemmeno di avvicinarsi a questi dispositivi. Non colgono che, dal punto di vista delle interfacce, delle indicazioni operative e persino del contenuto cognitivo e culturale, molte cose sono molto più semplici di quanto immaginino.

Il bilancio, però, non è completamente negativo. Ho realizzato molti applicativi, alcuni dei quali sono utili e soddisfacenti. Inoltre, è verificato che possono funzionare appoggiandosi anche a modelli locali di intelligenza artificiale generativa. Via via che questi modelli vengono distillati e resi qualitativamente più accettabili, anche le risposte possono diventare più rapide ed efficaci. La costruzione di system prompt, per esempio, è stata un buon allenamento a scomporre problemi complessi, dividerli in elementi, costruire schemi e fornire indicazioni articolate a un applicativo con un esito preciso.

L’obiettivo resta quello di costruire un punto di intersezione con gli utenti. Utenti che però non devono essere addestrati a usare passivamente l’applicazione, ma devono poter proporre e attuare modifiche. Tutto deve restare aperto, non coperto da copyright, vicino all’idea di pubblico dominio. La prospettiva è attivare meccanismi di mutualismo, cooperazione ed emancipazione, uscendo dai recinti del digitale proprietario e recuperando almeno idealmente la dimensione conflittuale del software libero e dell’open source.

In conclusione, l’elemento più negativo rimane il disinteresse per la demercificazione della conoscenza. Molti sono attratti piuttosto dalla visibilità, dal successo personale, dal mercato dell’attenzione e dalla costruzione di comunità gergali fondate su un linguaggio superficiale. Si organizzano così lobby culturali che servono alla proiezione pubblica, alla partecipazione a convegni, alla proposta di workshop, più che alla soluzione di questioni reali. Al contrario, sarebbe assolutamente possibile identificare problemi concreti — come quello del plain language e molti altri — e costruire ambienti di allenamento e applicazioni capaci di affrontarli davvero.

Continuano invece a circolare proposte di laboratori astratte, fuori dal mondo, pensate più per colpire l’immaginario che per rispondere alle problematiche riscontrate. Questo è, a mio avviso, scandaloso. È il frutto di un rapporto tossico con i dispositivi digitali, anche quando vengono presentati come conviviali: un rapporto che genera comportamenti competitivi, estrattivi e orientati alla prestazione, invece che alla cooperazione e alla trasformazione condivisa.