La prima cosa utile che l’AI ha fatto per me come programmatore è stata rispondere alle domande alla velocità del pensiero. Non alla velocità di un motore di ricerca, dove si digita una query, si scorrono tre thread su Stack Overflow, si legge una man page e si torna all’editor avendo perso il filo di ciò che si stava facendo. Intendo: ho una domanda, ricevo una risposta, continuo a scrivere codice. Il ciclo si chiude in secondi invece che in minuti.

È un miglioramento reale. È anche, credo, un quadro parziale di ciò che sta accadendo davvero. E la parte che viene omessa dalla maggior parte delle conversazioni sull’AI e sull’apprendimento merita di essere esaminata con attenzione.

Il problema del ciclo di feedback

Anders Ericsson ha trascorso la maggior parte della sua carriera a studiare come gli esperti diventano tali, e la scoperta costante era che la pratica deliberata richiede un feedback rapido e accurato. Si pratica, si riceve un segnale correttivo, ci si aggiusta. Più il ciclo è breve, più velocemente il modello nella propria testa converge su qualcosa di reale. È per questo che un musicista che studia le scale con un insegnante presente in sala migliora più rapidamente di uno che studia da solo, e che gli studenti di medicina nei reparti clinici imparano di più per settimana che in un’aula: il feedback è più stretto, più rapido, più specifico.

L’apprendimento classico incorpora un feedback ad alta latenza. Si scrive codice, si aspetta il compilatore, si eseguono i test, si legge il messaggio di errore, si cercano i documenti, si prova qualcosa, si aspetta di nuovo. Per un principiante, la latenza non è la parte fastidiosa: è il tutto. Non si aspetta soltanto una risposta. Si aspetta, si legge, si formulano ipotesi, le si mettono alla prova, falliscono, si rivede. Ogni ciclo deposita qualcosa nel modello mentale che si sta costruendo.

L’AI comprime quel ciclo a secondi. Per la sintassi, per la superficie delle API, per i pattern che ancora non si conoscono, questo è genuinamente trasformativo. Il tempo per arrivare alla prima cosa funzionante si riduce drasticamente. Il principiante che avrebbe trascorso due ore a combattere con un errore di tipo ora ne impiega dieci minuti. Il programmatore senior che avrebbe dedicato un pomeriggio a leggere la documentazione di una libreria sconosciuta ora impiega venti minuti per orientarsi e un pomeriggio a fare il lavoro vero.

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

Il test è il fallimento inedito

Ecco cosa osservo negli ingegneri junior che hanno imparato principalmente tramite prompt.

Sono più veloci. Consegnano qualcosa di funzionante molto prima rispetto ai loro omologhi di cinque anni fa. Quando il compito rientra nella distribuzione delle cose che hanno già fatto, o che l’AI ha già fatto, sono genuinamente competenti.

Mettiamoli davanti a qualcosa fuori da quella distribuzione e il divario si apre immediatamente.

Una race condition in Go che l’AI non ha mai incontrato in quella forma. Un nil pointer dereference sepolto tre livelli in profondità dentro una catena di interfacce. Una query di database che funziona bene a mille righe e crolla a un milione. Un memory leak che si manifesta solo sotto specifici pattern di concorrenza. Non sono fallimenti esotici. Sono i fallimenti normali del software a scala non banale. Quello che richiedono non è il pattern-matching ma il ragionamento: bisogna tenere nella testa un modello mentale del sistema, tracciare una catena di causalità, formulare un’ipotesi, trovare un modo per metterla alla prova.

Quel modello mentale è esattamente ciò che viene saltato quando si impara principalmente portando il prompt a produrre codice funzionante. Il codice funziona. Non si capisce perché. Questo sembra apprendimento. Non lo è.

Cosa produce davvero la fatica

Geoff Colvin, in Talent Is Overrated, fa un’osservazione che suona controintuitiva fino a quando non la si prende sul serio: il prodotto della pratica non è il punto della pratica. La fatica è il meccanismo. Quando si combatte per risolvere un problema mai visto prima, la risoluzione di quella lotta codifica qualcosa. I vicoli ciechi esplorati, le ipotesi sbagliate messe alla prova, il momento in cui la spiegazione corretta ha fatto scatto: tutto ciò lascia una traccia nel modello mentale che rende il prossimo problema sconosciuto più veloce da diagnosticare.

L’AI rimuove la fatica. Il che significa che rimuove il meccanismo.

Si ottiene il risultato senza la codifica. Il codice compila, i test passano, si va avanti. Nulla è stato depositato. La prossima volta che si incontra un problema strutturalmente simile senza il supporto dell’AI, si ricomincia da zero. Il codice consegnato era reale. L’apprendimento no.

Da questo deriva una specifica modalità di fallimento che ritengo sottovalutata. Chi diventa fluente nel fare prompt in un dominio che non comprende in profondità sviluppa quella che definirei incompetenza sicura di sé. Riesce a portare a termine le cose in una vasta gamma di casi normali. Si muove velocemente, consegna cose, appare produttivo. Fino a quando qualcosa va storto e non è in grado di diagnosticarlo. A quel punto il divario tra ciò che sembra sapere e ciò che sa davvero diventa visibile tutto in una volta. Ed è spesso più grande del previsto, perché il prompting è stato così efficace nel mascherarlo.

Dove l’AI aiuta davvero

La descrizione qui sopra sembra un argomento contro l’uso dell’AI nell’apprendimento. Non lo è. È un argomento sulla sequenza.

L’AI è più utile dopo che si ha il modello mentale, non prima. Una volta che si conosce il territorio, l’AI è un moltiplicatore di forza. Una volta che si sa cos’è una race condition, cosa la produce, come ragionare sullo stato mutabile condiviso, l’AI diventa un modo veloce per scrivere primitive di sincronizzazione corrette che già si comprendono ma che altrimenti si dovrebbero digitare. Una volta che si conosce un’API abbastanza in profondità da avere aspettative sul suo comportamento, l’AI aiuta a muoversi attraverso di essa dieci volte più velocemente.

Per un esperto, l’AI è uno degli strumenti più utili apparsi da molto tempo. Gestisce il lavoro di traduzione che non richiede giudizio, liberando tempo e attenzione per il lavoro che lo richiede. Questo è genuinamente prezioso.

Per un principiante, lo stesso strumento è una scorciatoia che rischia di bypassare l’infrastruttura necessaria per usarlo bene in seguito. Il principiante non sa ancora cosa non sa. La fatica di cui viene risparmiato è il processo che glielo avrebbe detto.

Usate l’AI come rubber duck, non come oracolo. Parlateci, spingetela, mettete in discussione ciò che produce. Se non si riesce a spiegare perché il codice che ha prodotto funziona, non lo si capisce ancora. La comprensione è l’obiettivo. Il codice funzionante è la prova che ci si sta avvicinando, non un suo sostituto.

Una nuova competenza che nessuno nomina

C’è una competenza che è diventata silenziosamente essenziale, e non l’ho vista discussa in modo chiaro da nessuna parte.

Prima degli LLM, il ciclo di feedback nell’apprendimento era abbastanza lento e onesto da far sì che si sapesse, grossomodo, quanto si capiva qualcosa. Se non si capiva qualcosa, tendeva a fallire. Il fallimento era il segnale. Era fastidioso, ma era accurato.

Ora il ciclo di feedback può chiudersi senza di noi. Si fa un prompt, l’AI produce, le cose funzionano. Il segnale che avrebbe detto se si capiva davvero qualcosa è stato sostituito da un segnale che dice solo se l’AI capisce qualcosa. Non è la stessa cosa, ma si sente uguale.

La nuova competenza è la metacognizione: sapere se si capisce qualcosa versus sapere se si è in grado di fare prompt su qualcosa. Questa distinzione non aveva molta importanza prima, perché le conseguenze di confonderle apparivano rapidamente. Ora le conseguenze possono essere rinviate quasi indefinitamente, fino a quando non si è abbastanza in profondità nella produzione, o in un progetto, o in un lavoro, che il divario diventa costoso.

Coltivarla richiede uno sforzo deliberato. Dopo aver ottenuto una risposta dall’AI, bisogna chiedersi: riesco a spiegarlo senza l’aiuto dell’AI? Riesco a tracciare il perché funziona? Riesco a prevedere cosa lo farebbe rompere? Se la risposta è no, si ha il risultato ma non la conoscenza. Vale la pena saperlo.

Come imparerei qualcosa di nuovo oggi

Ho imparato a programmare prima che esistessero gli LLM. La resistenza che provo nei confronti delle scorciatoie dell’AI nelle fasi iniziali dell’apprendimento non è nostalgia. Viene dall’aver sperimentato cosa produce la fatica e dall’osservare cosa succede agli ingegneri che l’hanno saltata.

Se dovessi imparare un nuovo dominio tecnico oggi, la sequenza che userei è questa.

Prima di tutto, i principi fondamentali. Leggere la specifica. Leggere il sorgente quando possibile. Costruire l’implementazione giocattolo, quella che fa solo una cosa e la fa male. Capire i messaggi di errore come se fossero una lingua. Trascorrere del tempo nel fallimento, perché è lì che si costruisce il modello.

Questa fase è più lenta. Deve esserlo. Il punto non è produrre codice funzionante il più rapidamente possibile. Il punto è costruire la struttura mentale che fa sì che il lavoro veloce abbia senso in seguito.

Una volta che il modello è al suo posto, una volta che si riesce a ragionare sul perché le cose falliscono e a prevedere come si comporterà il sistema, allora si usa l’AI. La si usa per scrivere il boilerplate che già si comprende. La si usa per esplorare la superficie delle API che si è in grado di valutare criticamente. La si usa per muoversi dieci volte più velocemente in un territorio già mappato.

L’ordine conta. Prima i principi fondamentali, poi il moltiplicatore di forza. Non il contrario.

L’implicazione scomoda

La storia che il settore racconta sull’AI e sull’apprendimento tende a fermarsi all’argomento dell’accesso: l’AI dà a tutti accesso a una guida esperta istantanea, il che democratizza l’acquisizione delle competenze. Questo è vero nei limiti in cui vale.

Ciò che omette è che democratizzare l’accesso alle risposte non è la stessa cosa che democratizzare l’acquisizione della comprensione. La comprensione richiede la fatica. La fatica è ciò che l’AI rimuove più efficientemente.

Gli ingegneri che beneficeranno di più dell’AI nel prossimo decennio non sono quelli che imparano più velocemente tramite prompt. Sono quelli che hanno i modelli mentali abbastanza profondi da usare il risultato dell’AI in modo critico, da sapere quando è giusto e quando è plausibile ma sbagliato, da diagnosticare i fallimenti che non riesce a vedere e da costruire le cose su cui non riesce a ragionare.

Quei modelli mentali si costruiscono nel modo antico. Lentamente, sotto attrito, fallendo ripetutamente su cose che sono appena fuori dalla propria portata attuale. L’AI non cambia ciò che li costruisce. Cambia quanto sia allettante saltare il processo che lo fa.