Ogni generazione di sviluppatori senior ha pensato che quella dopo avesse la vita troppo facile. Chi ha imparato senza Stack Overflow ha guardato con sospetto chi ci è cresciuto dentro, e chi è cresciuto con Stack Overflow ha detto le stesse cose sui framework che nascondono tutto. Quasi sempre si sbagliavano: gli strumenti alzavano il livello del punto di partenza e la competenza si ricostruiva un po’ più in alto.
Prima di scrivere il resto di questo articolo mi sono chiesto se non stia facendo esattamente lo stesso errore. Non ne sono del tutto sicuro. Però credo che questa volta ci sia una differenza che vale la pena guardare da vicino, e non riguarda quanto è potente lo strumento: riguarda in quale punto del percorso toglie attrito.
Lo stesso strumento fa due cose opposte
Quando io uso l’intelligenza artificiale per generare un modulo, sto delegando qualcosa che so fare. Leggo il risultato e vedo subito se la gestione degli errori è messa dove serve, se quella query diventerà un problema con dieci volte i dati, se quella scelta mi vincola su una cosa che tra sei mesi dovrò cambiare. Non lo vedo perché sono più intelligente: lo vedo perché quelle tre cose le ho già sbagliate, e le ho pagate.
Quando un junior usa lo stesso strumento, sta delegando qualcosa che non ha mai fatto. Il risultato è identico. Quello che manca è tutto quello che succedeva prima che il risultato arrivasse.
È lì che si formava la competenza. Non nel codice finito, che era anzi la parte meno interessante, ma nelle quattro ore passate a capire perché non partiva, nel dead end preso e abbandonato, nell’errore letto tre volte prima di accorgersi che diceva esattamente cosa fare. Quelle ore sembravano tempo perso, e in senso stretto lo erano: producevano poco. Producevano però un modello mentale di come le cose si rompono, che è l’unica cosa che poi permette di guardare del codice e sentire che qualcosa non torna prima di sapere perché.
Quell’attrito non era un difetto del processo. Era il processo.
Il plateau invisibile
C’è un effetto collaterale meno ovvio e secondo me più insidioso.
Prima, il livello di un junior si vedeva dal suo output. Il codice diceva dov’era: cosa aveva capito, cosa stava ancora imitando, cosa non aveva mai incontrato. Era un segnale rumoroso ma leggibile, e serviva a due persone — a chi lo seguiva, per calibrare il lavoro da assegnargli, e a lui, per sapere dove si trovava.
Oggi quel segnale è quasi sparito. L’output di un junior con un buon assistente è spesso indistinguibile da quello di una persona con cinque anni di esperienza. Sembra una buona notizia, e in parte lo è. Ma significa anche che nessuno dei due — né chi guida né chi impara — ha più un modo semplice di sapere a che punto è la crescita. La differenza salta fuori tutta insieme, e sempre nel momento peggiore: il primo problema che non assomiglia a niente di già visto, il primo incidente in produzione, la prima volta che lo strumento propone una soluzione plausibile e sbagliata.
Il rischio non è avere junior meno capaci. È avere junior che sembrano competenti, si sentono competenti, e scoprono di non esserlo in una situazione dove quella scoperta costa cara a tutti.
E poi c’è il problema economico
Qui la faccenda smette di essere pedagogica.
I compiti che davamo ai junior avevano tutti le stesse caratteristiche: ben delimitati, a basso rischio, ripetitivi, con un risultato verificabile. Erano i gradini bassi della scala, e servivano esattamente a quello — far salire qualcuno.
Sono anche, con precisione quasi comica, i compiti che oggi l’intelligenza artificiale svolge meglio. Più veloce, a costo quasi nullo, senza bisogno di supervisione.
Quindi il problema non è solo “come faccio a insegnare”. È che il lavoro con cui si insegnava non ha più una ragione economica per esistere. Chi decide come allocare le persone su un progetto si trova davanti a una scelta che dieci anni fa non c’era: quel task lo do a una persona che deve imparare, sapendo che ci metterà tre giorni invece di venti minuti e che il risultato sarà peggiore, oppure lo chiudo stasera. La seconda opzione è sempre difendibile sul singolo progetto, e sistematicamente disastrosa sui tre anni.
Nessuno prende mai la decisione di smettere di formare le persone. Si arriva lì una consegna alla volta.
Cosa provo a fare, senza sapere se basta
Non ho una risposta pulita. Ho alcune cose che sto provando, con risultati diseguali.
Prima scrivi, poi confronta. Su un pezzo scelto — non su tutto, sarebbe insostenibile — chiedo che la prima stesura sia fatta a mano, e solo dopo generata. Il valore non è nella versione scritta a mano, che quasi sempre è peggiore. È nel confronto: perché lo ha risolto così, cosa non avevo considerato, cosa invece nel mio era meglio e va tenuto. Il confronto insegna moltissimo, ma funziona solo se hai qualcosa da confrontare.
La review si sposta dal codice al ragionamento. Non chiedo più solo se funziona. Chiedo perché quella scelta, cosa è stato scartato, cosa si rompe se il carico decuplica, cosa succede se quel servizio esterno risponde lento invece che dare errore. Se le risposte non ci sono, il codice non passa — anche quando funziona perfettamente. Non è pignoleria: è che il codice che nessuno sa spiegare è codice che nessuno potrà cambiare.
Il debug di roba scritta da altri, presto. Un incidente in produzione insegna in un pomeriggio quello che un task assegnato non insegna in un mese, e non è delegabile: l’assistente ti aiuta a leggere lo stack trace, non ti toglie la responsabilità di capire perché quel sistema è fatto così. È anche l’unico attrito rimasto che non si può comprimere.
Proprietà lunga su qualcosa di piccolo. Un componente vero, in produzione, seguito per mesi. Le conseguenze delle proprie scelte che tornano indietro dopo sei mesi sono il maestro più efficace che conosco, e sono l’esatto opposto della logica del task chiuso in venti minuti.
La cosa che non so
Resta aperta un’obiezione seria, che mi faccio da solo.
Forse la competenza che stiamo cercando di preservare non è più quella che serve. Forse il mestiere si sposta davvero verso il giudizio, la revisione, la capacità di decidere cosa vale la pena costruire — e forse quelle si possono allenare direttamente, senza passare dalle quattro ore sull’errore di compilazione. Se è così, quello che ho scritto qui sopra è nostalgia travestita da metodo, e tra dieci anni farà sorridere come le prediche su Stack Overflow.
Non riesco a escluderlo. So solo che il giudizio, per come l’ho visto formarsi nelle persone con cui ho lavorato, è sempre arrivato dopo aver sbagliato abbastanza volte da riconoscere le forme. E che non ho ancora visto nessuno svilupparlo guardando funzionare cose che non ha capito.
- Come si forma un junior quando la prima stesura è gratis - Settembre 24, 2026
- Il debito di comprensione - Settembre 21, 2026
- Margine: il tema del mio blog, progettato parlando con un’AI - Settembre 18, 2026