La prima cosa davvero utile che l’intelligenza artificiale ha fatto per me, come programmatore, è stata rispondere alle mie domande alla velocità del pensiero. Non alla velocità di un motore di ricerca, dove si digita una query, si scorrono tre discussioni su Stack Overflow, si legge una pagina di manuale e si torna all’editor avendo perso il filo del discorso. Intendo dire: mi sorge un dubbio, ottengo una risposta, continuo a scrivere codice. Il cerchio si chiude in pochi secondi, anziché in minuti.

Si tratta di un miglioramento concreto. Credo tuttavia che sia anche una visione parziale di ciò che sta realmente accadendo. Vale la pena soffermarsi su quell’aspetto che viene sistematicamente escluso dalla maggior parte delle conversazioni sull’IA e sull’apprendimento.

Il problema del ciclo di feedback

Anders Ericsson ha trascorso gran parte della sua carriera studiando come gli esperti diventino tali, e la sua scoperta più costante è stata che la pratica deliberata richiede un feedback rapido e preciso. Ci si esercita, si riceve un segnale correttivo, ci si adatta. Più breve è questo ciclo, più velocemente il modello mentale si avvicina alla realtà. È per questo motivo che un musicista che prova le scale con un insegnante nella stanza migliora più in fretta di uno che si esercita da solo, ed è sempre per questo che gli studenti di medicina imparano di più in una settimana di tirocinio in corsia che in un’aula universitaria: il riscontro è più serrato, più veloce e più specifico.

L’apprendimento classico porta con sé, per sua stessa natura, un riscontro ad alta latenza. Si scrive il codice, si aspetta il compilatore, si eseguono i test, si legge il messaggio d’errore, si consulta la documentazione, si fa un tentativo, si aspetta di nuovo. Per un principiante, questa latenza non è semplicemente un fastidio, ma l’essenza stessa del processo. Non ci si limita ad attendere le risposte. Si aspetta, si legge, si formulano ipotesi, le si mette alla prova, si fallisce e si corregge il tiro. Ogni ciclo deposita un tassello nel modello mentale che si sta costruendo.

L’IA comprime questo ciclo in pochi secondi. Quando si tratta di sintassi, di interfacce API o di pattern ancora sconosciuti, l’effetto è un’autentica trasformazione. Il tempo necessario per ottenere il primo risultato funzionante crolla drasticamente. Il principiante che avrebbe speso due ore a combattere con un errore di tipo, ora ci mette dieci minuti. L’ingegnere esperto che avrebbe impiegato un intero pomeriggio a leggere la documentazione di una libreria sconosciuta, ora trascorre venti minuti per orientarsi e il resto del pomeriggio a lavorare davvero.

Questa è la parte utile, e merita tutta l’attenzione che riceve.

Il vero banco di prova è il fallimento inedito

C’è un aspetto che noto spesso negli ingegneri alle prime armi che hanno imparato a programmare principalmente scrivendo prompt.

Sono più veloci. Riescono a consegnare un prodotto funzionante molto prima rispetto ai loro colleghi di cinque anni fa. Quando il compito rientra nello spettro delle cose che hanno già fatto, o che l’IA ha già affrontato, si dimostrano genuinamente competenti.

Se però li si mette di fronte a qualcosa che esce da quel tracciato, la voragine si apre immediatamente.

Una race condition in Go di cui l’IA non ha mai visto la struttura. La dereferenziazione di un nil pointer sepolta tre livelli più in basso in una catena di interfacce. Una query di database che funziona perfettamente con mille righe e collassa quando diventano un milione. Un memory leak che si manifesta solo in specifiche configurazioni di concorrenza. Non si tratta di guasti esotici. Sono i normali fallimenti di un software che opera su una scala non banale. Risolverli non richiede di riconoscere uno schema ricorrente, ma di ragionare: è necessario mantenere nella propria testa un modello mentale del sistema, tracciare una catena di cause ed effetti, formulare un’ipotesi e trovare il modo di verificarla.

Quel modello mentale è esattamente ciò che viene saltato a piè pari quando si impara producendo codice funzionante a colpi di prompt. Il codice funziona, ma non si capisce il perché. Si ha l’illusione di imparare, ma non è così.

A cosa serve davvero lo sforzo

Nel suo libro Talent Is Overrated, Geoff Colvin esprime un concetto che suona controintuitivo finché non lo si prende sul serio: il risultato della pratica non è lo scopo della pratica. Il meccanismo risiede nello sforzo. Quando si lotta per risolvere un problema mai visto prima, l’esito di quella battaglia codifica un’informazione. I vicoli ciechi esplorati, le ipotesi errate messe alla prova, l’istante in cui la spiegazione corretta si è palesata: tutto ciò lascia una traccia nel modello mentale, rendendo più rapida la diagnosi del prossimo problema sconosciuto.

L’IA elimina lo sforzo. Di conseguenza, elimina il meccanismo.

Si ottiene il risultato senza la codifica dell’informazione. Il codice viene compilato, i test vengono superati e si passa oltre. Non si è depositato nulla. La volta successiva in cui ci si imbatte in un problema strutturalmente simile senza l’assistenza dell’IA, si riparte da zero. Il codice consegnato era reale; l’apprendimento no.

Ne consegue una specifica modalità di fallimento che, a mio avviso, viene sottovalutata. Chi diventa abile nel generare prompt per un ambito che non comprende a fondo, sviluppa quella che definirei un’incompetenza fiduciosa. Queste persone riescono a portare a termine i compiti in un’ampia gamma di casi normali. Si muovono rapidamente, consegnano il lavoro, sembrano produttive. Finché non va storto qualcosa che non sono in grado di diagnosticare. A quel punto, il divario tra ciò che sembrano sapere e ciò che sanno realmente diventa visibile tutto in una volta. E spesso è più ampio del previsto, proprio perché l’uso dei prompt è stato così efficace nel mascherarlo.

Dove l’IA è davvero d’aiuto

La descrizione appena fatta potrebbe sembrare un’argomentazione contro l’uso dell’IA nell’apprendimento, ma non lo è. È un’argomentazione che riguarda la sequenza temporale.

L’IA dà il meglio di sé dopo aver costruito il modello mentale, non prima. Una volta compreso il territorio, diventa un moltiplicatore di forze. Quando si sa cos’è una race condition, cosa la genera e come ragionare su uno stato condiviso mutabile, l’IA diventa un modo rapido per scrivere primitive di sincronizzazione corrette che si comprendono già, ma che altrimenti si dovrebbero digitare a mano. Quando si conosce un’API abbastanza a fondo da avere delle aspettative sul suo comportamento, l’IA aiuta a muoversi al suo interno a una velocità dieci volte superiore.

Per un esperto, l’IA è uno degli strumenti più utili comparsi da molto tempo a questa parte. Si occupa del lavoro di traduzione che non richiede capacità di giudizio, liberando tempo e attenzione per le attività in cui tale capacità è indispensabile. Questo ha un valore inestimabile.

Per un principiante, lo stesso strumento è una scorciatoia che rischia di aggirare l’infrastruttura necessaria per usarlo bene in futuro. Chi è alle prime armi non sa ancora cosa ignora. Lo sforzo che gli viene risparmiato è l’esatto processo che glielo rivelerebbe.

Conviene usare l’IA come una paperella di gomma per il debugging, non come un oracolo. Bisogna parlarci, metterla alla prova, mettere in discussione ciò che restituisce. Se non si è in grado di spiegare perché il codice che ha prodotto funziona, significa che non lo si è ancora compreso. La comprensione è l’obiettivo finale. Il codice funzionante è la prova che ci si sta arrivando, non un suo surrogato.

Una nuova competenza a cui nessuno dà un nome

C’è una competenza che è diventata silenziosamente essenziale, eppure non l’ho ancora vista discutere con chiarezza da nessuna parte.

Prima dei modelli linguistici di grandi dimensioni (LLM), il ciclo di riscontro nell’apprendimento era abbastanza lento e onesto da far capire, a grandi linee, il proprio livello di comprensione. Se non si capiva qualcosa, in genere si falliva. Il fallimento era il segnale. Era frustrante, ma preciso.

Ora il ciclo di riscontro può chiudersi senza alcun intervento umano. Si scrive un prompt, l’IA produce il risultato, le cose funzionano. Il segnale che avrebbe indicato l’effettiva comprensione di un concetto è stato sostituito da un segnale che indica soltanto se l’IA ha capito qualcosa. Non sono la stessa cosa, ma la sensazione è identica.

La nuova competenza è la metacognizione: saper distinguere tra l’aver compreso qualcosa e il saper semplicemente scrivere un prompt per ottenerla. In passato questa distinzione non aveva molta importanza, poiché le conseguenze di una simile confusione emergevano rapidamente. Oggi, invece, possono essere rimandate quasi all’infinito, finché non ci si trova così addentrati nella produzione, in un progetto o in un lavoro, che colmare quel divario diventa estremamente costoso.

Coltivare questa capacità richiede uno sforzo deliberato. Dopo aver ottenuto una risposta da un’IA, bisognerebbe chiedersi: sarei in grado di spiegarlo senza il suo aiuto? Riesco a tracciare i motivi per cui funziona? Posso prevedere cosa lo farebbe smettere di funzionare? Se la risposta è no, si possiede il risultato ma non la conoscenza. Ed è un’informazione preziosa da avere.

Come imparerei qualcosa di nuovo oggi

Ho imparato a programmare prima che esistessero gli LLM. La resistenza che provo nei confronti delle scorciatoie offerte dall’IA nelle fasi iniziali dell’apprendimento non è dettata dalla nostalgia. Nasce dall’aver sperimentato in prima persona i frutti di quello sforzo e dall’aver osservato cosa succede agli ingegneri che lo hanno saltato.

Se oggi dovessi imparare un nuovo ambito tecnico, la sequenza che adotterei sarebbe questa.

Prima di tutto, i principi fondamentali. Leggere le specifiche. Leggere il codice sorgente quando possibile. Costruire un’implementazione di prova, quel progetto rudimentale che fa una sola cosa e la fa male. Comprendere i messaggi di errore come se fossero una lingua a sé. Trascorrere del tempo nel fallimento, perché è lì che si costruisce il modello.

Questa fase è più lenta. Ed è giusto che lo sia. L’obiettivo non è produrre codice funzionante nel minor tempo possibile. L’obiettivo è costruire la struttura mentale che darà un senso al lavoro veloce che verrà dopo.

Una volta che il modello è consolidato, quando si è in grado di ragionare sui motivi per cui le cose falliscono e di prevedere come si comporterà il sistema, allora si può usare l’IA. La si può usare per scrivere il codice standard che si comprende già alla perfezione. La si può usare per esplorare le interfacce API in modo critico. La si può usare per muoversi dieci volte più velocemente in un territorio che è già stato mappato.

L’ordine è fondamentale. Prima i principi fondamentali, poi il moltiplicatore di forze. Non il contrario.

La scomoda implicazione

La narrazione che l’industria fa dell’IA e dell’apprendimento tende a fermarsi all’argomento dell’accesso: l’IA offre a chiunque una guida esperta istantanea, democratizzando l’acquisizione delle competenze. Questo è vero, fino a un certo punto.

Ciò che viene omesso è che democratizzare l’accesso alle risposte non equivale a democratizzare l’acquisizione della comprensione. La comprensione richiede fatica. E la fatica è l’elemento che l’IA rimuove con maggiore efficienza.

Gli ingegneri che trarranno i maggiori benefici dall’IA nel prossimo decennio non saranno quelli che imparano più in fretta scrivendo prompt. Saranno quelli dotati di modelli mentali abbastanza profondi da usare i risultati dell’IA in modo critico, da sapere quando ha ragione e quando è plausibile ma in errore, da diagnosticare i fallimenti che la macchina non riesce a vedere e da costruire le cose su cui non è in grado di ragionare.

Quei modelli mentali si costruiscono alla vecchia maniera. Lentamente, con l’attrito, fallendo ripetutamente in compiti che sono appena al di fuori della propria portata attuale. L’IA non cambia gli elementi necessari per costruirli. Cambia solo quanto sia allettante saltare il processo che li genera.