Quando imparare era più difficile (e per questo più prezioso)

In questi mesi mi è capitato spesso di fare colloqui a ragazzi molto giovani, coinvolti in una academy  che la mia azienda sta costruendo internamente.

È un’esperienza stimolante, ma ogni volta mi riporta inevitabilmente a riflettere su quanto sia cambiato il modo di entrare nel mondo dell’IT.

Ripenso ai miei inizi universitari, quando per poter lavorare su una macchina Linux bisognava letteralmente fare la fila in laboratorio. Le macchine erano poche, spesso un Pentium II condiviso, e il tempo a disposizione era limitato. Quel tempo “morto”, in attesa di un terminale, non era davvero morto: si prendeva un foglio di carta e si iniziava a pensare.

Si scriveva il programma a mano, si ragionava sulle procedure, sugli input, sull’uso della memoria. Si arrivava al laboratorio con il codice già "ragionato", a volte già completamente scritto su carta, altre volte preparato su un editor di testo e copiato su un floppy, e solo allora lo si traduceva in C usando vi, malloc, realloc, gestione della memoria.

Allocazioni che sembravano perfette sulla carta e che poi esplodevano in un segmentation fault.

E come si affrontava quel problema?

Non c’era un tool a cui chiedere subito cosa fare: si tornava ai libri, si rileggeva Kernighan & Ritchie, si ridisegnava più volte il flusso del programma, ci si confrontava con amici e colleghi, cercando di capire davvero cosa stesse succedendo.

Col senno di poi, nessuna palestra è stata più formativa di quella.

Non avere tutta l’informazione a portata di mano, averne poca, ci costringeva a sviluppare pensiero critico, a comprendere in profondità i sistemi, i linguaggi e le architetture prima ancora di scrivere la prima riga di codice.

Ricordo perfettamente che il primo esame di Java prevedeva una prova scritta: tutto il codice su carta. All’epoca lo odiavo. A quell’età vuoi scrivere il codice migliore del mondo, ti immagini con le cuffie alle orecchie a scrivere alla velocità della luce.

Ma senza quel processo non avrei mai interiorizzato i concetti fondamentali dell’object-oriented. Senza accorgermene, stavo imparando a guidare lo strumento, non a farmi guidare da esso.

Ho passato giornate intere su ricorsioni complesse, problemi di ottimizzazione, programmazione dinamica, alberi red-black, strutture dati bilanciate, cercando di capire i trade-off, le scelte, i perché. Prima pensare, poi eseguire.

Ho avuto anche la fortuna di incontrare docenti straordinari (in quegli anni la Federico II di Napoli ne aveva molti), che non insegnavano l’hype — anche allora ce n’era tanta — ma insegnavano la comprensione profonda dei sistemi. Ripensandoci oggi, mi sento fortunato.

Ed è inevitabile, a questo punto, interrogarsi su chi si affaccia ora al mondo dell’IT, in un’epoca in cui la generative AI guida molte scelte e in cui tutto sembra immediatamente disponibile.

Forse le competenze vere non si acquisiscono solo nel risultato finale, ma nel percorso che porta a realizzarlo. Se perdi quel percorso, cosa ti porti davvero a casa? Solo il software prodotto?

È vero: oggi chi vuole approfondire un argomento non deve più spulciare manuali per giorni, può usare ChatGPT, Claude, Copilot, può scrivere codice più velocemente, ottenere esempi immediati, esplorare soluzioni in pochi minuti.

Ma questo spesso spinge verso la strada più semplice: ottenere il risultato, saltando il ragionamento che dovrebbe precederlo.

Ed è qui che sta il rischio.

Questi strumenti sono straordinari e vanno usati, migliorano la produttività e aprono possibilità enormi, ma devono essere utilizzati per imparare, non solo per deliverare più in fretta.

Esattamente come quando all’università leggevamo il codice di un collega più bravo, o cercavamo di “rubare” da un professore un pattern architetturale da provare a incastrare nei nostri sistemi.

Imparare, sempre.

Perché alla fine l’unica cosa che conta davvero è la competenza.

E la competenza non si misura nel numero di righe di codice scritte, ma nella comprensione dei sistemi, nella capacità di individuare un problema, di collegare i puntini (come dicono adesso quelli bravi)

Ma dietro quel “saper unire i puntini” deve esserci una conoscenza profonda di linguaggi, architetture e sistemi.

Chi inizia oggi dovrebbe sfruttare la generative AI proprio per questo: costruire un percorso di crescita più profondo, non più superficiale.

Usarla per capire, per esplorare, per mettere in discussione le proprie soluzioni. Non solo per ottenere un output.

Il codice sarà del cliente, diventerà obsoleto, con il tempo verrà dismesso, ma quello non è l’unico deliverable.

Il vero deliverable è il percorso che ci porta a realizzare qualcosa, è il bagaglio di competenze che resta e che ci portiamo dietro per tutta la carriera.

In un’epoca come questa, la competenza non perde valore: diventa fondamentale.

Non perché la generative AI sia inutile, ma perché non tutto può essere generato, non tutto può essere delegato, e soprattutto non tutto può essere compreso automaticamente.

Oggi l’accesso a questi strumenti sembra economico, immediato, quasi illimitato. Ma già ora, se si osservano con attenzione le sfumature, emergono segnali diversi: modelli di pricing complessi, costi difficili da stimare ex ante, metriche poco intuitive, bundle che nascondono il consumo reale.

Non è sempre chiaro quanto stiamo pagando, per cosa e in quali condizioni quel costo rimarrà stabile nel tempo. Questa opacità non è casuale: è una dinamica già vista ogni volta che una tecnologia diventa infrastruttura critica.

È quindi lecito chiedersi se questa fase di apparente accessibilità non serva anche a rendere la generative AI pervasiva e indispensabile, creando una dipendenza difficile da sciogliere in futuro.

La storia del cloud ci ha insegnato che il lock-in raramente arriva come una scelta esplicita: spesso è il risultato di molte decisioni piccole, prese quando il costo sembra trascurabile e la comodità troppo alta per rinunciarvi.

Proprio per questo diventa essenziale non perdere autonomia. Saper usare la generative AI è ormai una competenza necessaria, ma non sufficiente. La vera differenza la farà chi saprà decidere quando usarla, dove usarla e quando invece rinunciarvi, mantenendo la capacità di costruire, modificare e comprendere i sistemi anche senza di essa.

L’AI può suggerire una soluzione, accelerare un’implementazione, aiutare nell’esplorazione di un problema. Ma non può assumersi la responsabilità dei trade-off, dei costi reali, delle conseguenze architetturali, né può garantire che una scelta resti valida nel tempo.

Quando l’efficienza diventerà una necessità e non un’opzione, quando i costi inizieranno a pesare davvero e non solo a essere contabilizzati a posteriori, servirà qualcuno che sappia capire cosa spegnere, cosa semplificare, cosa rifare.

Il codice potrà essere generato, riscritto, ottimizzato e infine dismesso. Ma la comprensione dei sistemi, delle architetture, dei costi e dei failure mode non è generabile. È il risultato di un percorso, di scelte consapevoli, di errori affrontati e compresi. Ed è proprio questo bagaglio che permette di evitare lock-in non necessari, di mantenere libertà tecnologica e di adattarsi quando il contesto cambia.

Per chi oggi si affaccia a questo mondo, il messaggio non è “non usare la generative AI”, ma usarla nel modo giusto, non per banalizzare un task, non per saltare il ragionamento, ma per ampliare le proprie competenze.

Gli strumenti vanno dominati, studiati, sfruttati fino in fondo, ma allo stesso tempo bisogna costruire le basi per non esserne dominati.

Perché il vero rischio non è usare l’AI, ma smettere di saper fare senza di essa.

Chi pensa che l’AI risolva tutto, faccia tutto e sostituisca il pensiero vive di hype, noi no, noi siamo tecnici ed i tecnici non vendono fumo.