Quel 30% che fa la differenza: cosa studiare oggi per lavorare nell'informatica

Una riflessione su cosa è cambiato, cosa resta, e cosa consiglierei a chi parte oggi.

Il mio posto felice

Sono nato nel 1982. Il mio primo computer l’ho ricevuto a 5 anni: un Amstrad CPC 464, con quel monitor verde fosforescente e il registratore a cassette integrato. A 3 anni sapevo già leggere e scrivere, e ci misi poco a prendere in mano il manuale del Locomotive BASIC e cominciare a scrivere le mie prime righe di codice.

Non avevo idea di cosa fosse una “carriera informatica”. Non sapevo che esistesse un’industria del software, non pensavo ai soldi, non pensavo al futuro. Pensavo solo che quello schermo era un posto dove potevo creare qualsiasi cosa. Scrivevi delle parole, premevi RUN, e succedeva qualcosa. Era magia. Era la mia magia.

Non c’erano molti soldi in casa, e ringrazio ancora tanto i miei genitori per quel regalo. Ero un bambino estremamente curioso, di quelli che smontano tutto, che fanno mille domande, che non stanno mai fermi. L’Amstrad fu l’unica cosa capace di placarmi. Mi sedevo davanti a quello schermo e il mondo spariva.

Poi un giorno ho scoperto che potevo generare suoni. E che suoni. Il CPC 464 aveva un chip sonoro, l’AY-3-8912, tre canali audio, e io ho iniziato a spremerlo in ogni modo possibile. Frequenze, inviluppi, modulazioni. Passavo ore a creare melodie e effetti sonori con poche righe di BASIC, e poi a cercare di capire come i giochi producevano quei suoni impossibili. La chiptune mi ha affascinato da allora e continua ad affascinarmi ancora oggi: fare musica con un computer resta una delle cose più belle che conosca.

Nel frattempo gli anni passavano. I miei amici cominciavano a giocare con l’Amiga, con la sua grafica a 4096 colori e quel suono stereo campionato che sembrava venire da un altro pianeta. Io restavo con il mio CPC 464. Ma quella limitazione mi ha spinto a scavare più in profondità. Quando il BASIC non bastava più, sono passato allo Z80 assembly, col MAXAM come assembler. LD A,&FF. CALL &BC77. PUSH HL, POP DE, JP NZ, loop. Istruzioni che manipolavano direttamente il processore, la memoria, il chip video. Roba che ti faceva sentire di avere il controllo totale della macchina, byte per byte.

È stato lo Z80 a farmi scoprire la demoscene. Quelle demo che giravano su hardware identico al mio ma producevano effetti che sembravano impossibili: scroller, rasterbar, plasma, sprite multiplexing. Gente che tirava fuori dal CPC cose che i progettisti stessi non avevano previsto. Per me era la forma più pura di hacking: prendere una macchina, capire ogni suo limite, e poi superarli.

Per me la programmazione pura è il mio posto felice. È libertà e controllo allo stesso tempo. È un posto dove non ho paura, perché descrivo e definisco le regole del mio mondo e tutto risponde alla logica. Se qualcosa non funziona, c’è sempre una ragione. Non ci sono ambiguità, non ci sono “dipende”, non ci sono interpretazioni. C’è un bug, lo trovi, lo risolvi. C’è una logica che vuoi esprimere, la scrivi, funziona.

Questo rapporto con la programmazione ha definito la mia vita. Mi ha dato un mestiere, certo, ma soprattutto mi ha dato un modo di pensare. Mi ha insegnato a scomporre i problemi, a cercare le cause prima degli effetti, a non accontentarmi della prima soluzione che funziona. Mi ha insegnato la pazienza e l’ostinazione.

E adesso, dopo quasi quarant’anni, quel rapporto si sta trasformando. Non finendo. Trasformando.

La domanda che mi fanno tutti

“Cosa dovrei studiare per lavorare nell’informatica?”

Me lo chiedono spesso. Studenti, persone che vogliono cambiare carriera, genitori che chiedono per i figli. E ogni volta faccio fatica a rispondere, per una ragione che probabilmente non si aspettano.

Il problema non è che non ho opinioni. Ne ho fin troppe. Il problema è che per me l’informatica non è mai stata una carriera. È stata una passione che è diventata un lavoro, e questo mi rende probabilmente la persona sbagliata a cui chiedere consigli di carriera. Non riesco a mettermi nei panni di chi guarda questo mondo e vede prima di tutto uno stipendio, una stabilità, un percorso professionale. Non c’è nulla di male in quello sguardo, è perfettamente legittimo, ma io non parto da lì, e quindi i miei consigli sono sempre stati un po’ storti.

Per anni, il consiglio più sincero che ho dato è stato: insegui una passione. Sii curioso. Sii hacker nel senso vero del termine. Non quello dei film, ma quello di chi smonta le cose per capire come funzionano, di chi non si accontenta di usare uno strumento ma vuole sapere cosa c’è sotto. Leggi il codice degli altri, rompi le cose, ricostruiscile meglio.

Era un buon consiglio? Forse sì, forse no. Funzionava per gente come me, gente che avrebbe programmato comunque, anche senza stipendio. Ma per gli altri? Per quelli che volevano semplicemente un buon lavoro in un settore in crescita? Non lo so.

Quello che so è che oggi la risposta a quella domanda è cambiata radicalmente. E per la prima volta, sento di poter dare un consiglio che vale per tutti: appassionati e pragmatici.

L’elefante nella stanza

Parliamo dell’AI. Anzi, parliamone seriamente, senza i toni apocalittici e senza l’entusiasmo da comunicato stampa.

Forse qualcuno si aspetta che io veda l’intelligenza artificiale come una minaccia. Uno che programma da quando aveva 5 anni, che ha fatto della scrittura del codice il suo posto felice: come può non sentirsi minacciato da una macchina che scrive codice?

La verità è che l’ho inseguita fin dal primo momento. Quando sono arrivati i primi modelli linguistici capaci di generare codice, non ho avuto paura. Ho avuto curiosità. La stessa curiosità del bambino davanti all’Amstrad. Cosa può fare questo? Fin dove può arrivare? Come posso usarlo?

E adesso, dopo mesi di utilizzo intensivo, quotidiano, integrato in ogni aspetto del mio lavoro, sento di avere dei super poteri. Non è un’esagerazione. Cose che prima richiedevano ore ora richiedono minuti. Prototipi che prima richiedevano giorni ora li vedo prendere forma in tempo reale. Ho un collaboratore instancabile che conosce praticamente ogni linguaggio, ogni framework, ogni pattern. Non si lamenta, non ha giornate storte, non si offende se gli chiedo di rifare tutto da capo.

Ma, e questo è un “ma” grosso come una casa, non per tutti è così.

Vedo colleghi che la odiano. Che la vivono come un affronto personale, come se qualcuno stesse sminuendo il loro lavoro. Vedo persone che la usano male, che copiano e incollano output senza capirli e poi si stupiscono quando le cose si rompono in produzione. E vedo, e questo è il più pericoloso, persone che pensano che ormai non abbia più senso imparare a programmare.

Tutte e tre queste reazioni sono sbagliate. Ma la terza è quella che mi preoccupa di più.

Il problema del 70%

C’è un concetto che Addy Osmani, ingegnere di Google e autore di testi fondamentali sullo sviluppo web, ha formulato e che secondo me centra perfettamente il punto. Lo chiama “il problema del 70%”.

L’idea è questa: l’AI oggi è in grado di generare circa il 70% di una soluzione software. Lo scaffolding, il boilerplate, i pattern comuni, le implementazioni standard, la documentazione di base, i test meccanici. Tutto quello che è prevedibile, ripetitivo, già visto. L’AI lo fa, e lo fa velocemente.

Il restante 30% è un’altra storia.

Quel 30% è fatto di architettura di sistema: decidere come i pezzi si incastrano, non scrivere i singoli pezzi. È fatto di edge case, quei casi limite che nessun modello prevede perché richiedono una comprensione profonda del dominio. È fatto di sicurezza, non la sicurezza da checklist, ma quella che nasce dall’esperienza di aver visto sistemi compromessi e dal sapere dove guardare. È fatto di decisioni che richiedono contesto, intuizione, giudizio.

Ed ecco il paradosso che Osmani evidenzia: per gli sviluppatori junior, quel 70% generato dall’AI sembra un miracolo. “Guarda, ho fatto un’applicazione completa in dieci minuti!” Per gli sviluppatori senior, quel 70% è la parte facile. Il vero lavoro è sempre stato nel 30%. E a volte, sistemare il 70% generato dall’AI richiede più tempo che scriverlo da zero.

Questo è il punto cruciale che chi vuole entrare nel mondo dell’informatica deve capire: l’AI non ha eliminato la necessità di competenza. L’ha resa più importante che mai.

Il paradosso della conoscenza

Questa è forse la cosa più controintuitiva dell’intera faccenda, e quella che dovreste tatuarvi sulla fronte se state pensando di intraprendere una carriera informatica.

Più sai, più l’AI ti è utile. Meno sai, più l’AI è pericolosa.

Sembra un paradosso, ma provate a pensarci. Quando io chiedo all’AI di generare una funzione di autenticazione, non scrivo “crea una funzione di login”. Scrivo qualcosa come: “Implementa un sistema di autenticazione con JWT, refresh token rotation, rate limiting sui tentativi falliti, hashing con bcrypt, logging strutturato per l’audit trail.” So cosa chiedere perché so cosa serve. So valutare l’output perché conosco i pattern corretti. So dove l’AI taglierà angoli perché li ho tagliati io stesso in passato e ne ho pagato le conseguenze.

Un junior che chiede “crea una funzione di login” otterrà qualcosa che funziona. Tecnicamente. In un ambiente di test. Su un progetto giocattolo. Ma in produzione, con utenti veri, con attaccanti veri, con dati veri? Quello che ottiene è una bomba a orologeria.

Non è colpa dell’AI. L’AI ha fatto esattamente quello che gli è stato chiesto. Il problema è che chi ha chiesto non sapeva cosa chiedere. E non sapeva di non saperlo, che è infinitamente peggio.

Quindi il primo consiglio, quello fondamentale, quello che viene prima di tutto il resto: imparate le basi. Veramente. Non le basi “ho fatto un tutorial su YouTube e ho deployato un’app su Vercel.” Le basi vere. Come funziona la memoria. Come funziona una rete. Cos’è un processo, cos’è un thread, cos’è una race condition. Come funziona un database sotto il cofano, non solo come si scrive una query.

L’AI non rende queste conoscenze obsolete. Le rende il moltiplicatore di forza più potente che abbiate mai avuto.

L’evoluzione delle competenze

Se dovessi disegnare una mappa delle competenze che contano oggi, quel famoso 30%, la dividerei in due grandi famiglie.

La prima è quella delle competenze che c’erano già ma che ora contano di più.

Software Architecture. Progettare sistemi complessi e scalabili. Non sto parlando di scegliere tra microservizi e monolite perché l’ha detto il blog che avete letto stamattina. Sto parlando di capire i trade-off, di sapere perché una scelta architetturale che funziona per Netflix non funziona per la vostra startup con tre utenti, di saper pensare in termini di sistemi distribuiti, di consistenza, di disponibilità.

System Design. Definire componenti e le loro interazioni. Saper disegnare su una lavagna come i pezzi si parlano. Saper individuare i colli di bottiglia prima che si manifestino. Saper progettare per il fallimento, perché i sistemi falliranno, e la differenza la fa quanto siete preparati.

Performance Tuning. Ottimizzare basandosi su una comprensione profonda di quello che succede realmente, non su superstizioni. Sapere leggere un profiler, capire dove finisce il tempo, distinguere tra un problema di CPU e un problema di I/O. L’AI può suggerire ottimizzazioni, ma non sa cosa conta nel vostro specifico contesto.

Security Analysis. E qui si apre un capitolo enorme. L’AI non introduce solo soluzioni: introduce anche vulnerabilità. Codice generato dall’AI che nessuno ha veramente letto e compreso è codice potenzialmente vulnerabile. Sapere dove guardare, conoscere i pattern di attacco, capire i rischi. Questa competenza non è solo rimasta importante, è diventata critica.

La seconda famiglia è quella delle competenze nuove, nate dall’interazione con l’AI stessa.

Context Engineering. Questa è forse la skill più sottovalutata. È la capacità di fornire all’AI il contesto giusto per ottenere output utili. Non è banale. Significa capire come ragiona il modello, cosa gli serve per funzionare bene, come strutturare le informazioni perché le processi nel modo più efficace. È un po’ come saper scrivere un buon brief per un designer o una buona specifica per un team di sviluppo, ma con le sue particolarità.

Prompt Design. Collegato al punto precedente, ma distinto. Formulare richieste precise ed efficaci. Non è “parlare con ChatGPT.” È capire che la qualità dell’input determina la qualità dell’output in modo diretto e spesso spietato. È sapere quando essere specifici e quando essere aperti, quando vincolare e quando lasciare libertà. È un’abilità che si sviluppa con la pratica e con la comprensione di come funzionano questi sistemi.

Critical Thinking. Valutazione critica dell’output AI. Questa è forse la competenza più importante in assoluto. L’AI genera testo e codice con una sicurezza totale, anche quando sbaglia. Produce output che sembra corretto, che suona corretto, che ha la forma di qualcosa di corretto, ma che può essere completamente sbagliato. Saper distinguere, saper dubitare, saper verificare: questa è la meta-competenza che separa chi usa l’AI da chi ne è usato.

Verification. Processi di validazione sistematica. Non fidarti, verifica. O meglio, come dicevano durante la Guerra Fredda: “trust, but verify.” Fìdati dell’AI per il 70% del lavoro meccanico, ma metti in piedi processi sistematici per verificare che quel 70% sia corretto. Test automatizzati, code review, security scanning, monitoring. Più l’AI produce, più hai bisogno di verificare.

Da artigiano a direttore d’orchestra

C’è una metafora che è perfetta per spiegare questo cambiamento: il passaggio da artigiano del codice a direttore d’orchestra.

L’artigiano del codice, il mestiere che ho amato per tutta la vita, è quello che prende un problema, apre l’editor, e riga dopo riga costruisce la soluzione. Conosce ogni carattere che ha scritto, ogni decisione che ha preso, ogni compromesso che ha fatto. È un lavoro intimo, preciso, totale.

Il direttore d’orchestra non suona nessuno strumento durante il concerto. Ma conosce ogni strumento, sa come dovrebbe suonare ogni sezione, sa quando qualcosa è fuori tempo o fuori tono. Senza di lui, l’orchestra produce rumore. Con lui, produce musica.

Il futuro dello sviluppatore è lì. Non scrivi più ogni riga di codice, ma devi sapere come dovrebbe suonare ogni riga. Non implementi più ogni pattern, ma devi riconoscere quando un pattern è sbagliato. Non fai più debug riga per riga, ma devi sapere dove guardare quando qualcosa non funziona.

E attenzione: questo non significa “meno lavoro.” Significa lavoro diverso. In un certo senso, significa più responsabilità. Perché quando scrivevi tutto tu, il raggio d’azione era limitato dalla tua velocità. Ora che l’AI moltiplica la tua capacità produttiva, il raggio d’azione esplode, e con esso la quantità di cose che possono andare storte se non sai quello che fai.

Ogni ingegnere oggi è, in un certo senso, un manager. Non di persone, ma di sistemi AI. E come ogni buon manager, deve saper delegare, saper controllare, saper dare direzione, saper riconoscere quando il lavoro è fatto bene e quando no.

Quello che non è cambiato (e non cambierà)

Fin qui ho parlato di competenze tecniche. Ma c’è un livello più profondo che vorrei toccare, perché è quello che fa davvero la differenza, e che nessun curriculum universitario e nessun bootcamp vi insegnerà.

La curiosità. Quella del bambino di 5 anni davanti all’Amstrad. Quella che ti fa smontare le cose non perché devi, ma perché vuoi sapere. L’AI non la sostituisce. Se non siete curiosi, l’AI è solo un generatore di codice che non capite. Se siete curiosi, l’AI è un portale verso una quantità infinita di cose da esplorare.

La capacità di comprendere oltre i bit. Il software non esiste nel vuoto. Esiste per risolvere problemi di persone reali. Il codice più elegante del mondo è inutile se risolve il problema sbagliato. Capire il dominio, parlare con gli utenti, comprendere le esigenze: queste sono competenze profondamente umane che l’AI non può e non potrà sostituire.

L’empatia. Sì, l’empatia. Nel software serve. Serve per progettare interfacce che le persone riescano a usare. Serve per scrivere messaggi di errore che aiutino invece di frustrare. Serve per capire che il collega che ha scritto quel codice orribile non è stupido: aveva fretta, aveva vincoli, aveva informazioni diverse dalle tue.

L’intuizione. Quella sensazione che qualcosa non va, anche se non sai ancora spiegare cosa. Quell’istinto che ti dice “questa architettura non reggerà” prima di aver fatto i conti. Quell’esperienza accumulata che si manifesta come un sesto senso. L’AI ha la statistica. Noi abbiamo l’intuizione. E spesso, quando la statistica e l’intuizione dicono cose diverse, è l’intuizione che ha ragione.

Lo spirito hacker. Intendo quello vero: la voglia di capire come funzionano le cose, di trovarsi davanti a un sistema e pensare “e se facessi così?” Non per rompere, anche se a volte rompere è il modo migliore per capire, ma per esplorare, per trovare i limiti, per andare oltre quello che il manuale ti dice che puoi fare.

Queste qualità non si studiano su un libro. Si coltivano con la pratica, con l’esperienza, con la volontà di mettersi in gioco. E sono, oggi più che mai, il vero vantaggio competitivo.

Allora, cosa studiare concretamente?

Ok, dopo tutta questa filosofia, proviamo a essere pratici. Se oggi avessi 20 anni e volessi costruire una carriera nell’informatica, cosa farei?

Prima di tutto, le fondamenta. Computer science vera. Algoritmi e strutture dati, non per superare i colloqui di Google, ma per avere un modello mentale di come i computer risolvono problemi. Sistemi operativi, per capire cosa succede sotto il vostro codice. Reti, perché ormai tutto è distribuito e se non capite TCP/IP, HTTP, e le basi della comunicazione tra sistemi, state costruendo su sabbia. Database, non solo SQL, ma i principi: normalizzazione, indici, transazioni, consistenza.

Sì, lo so, sembra il programma di un corso universitario degli anni ‘90. Ed è esattamente il punto. Queste cose non invecchiano. Sono le fondamenta su cui tutto il resto si appoggia, e sono esattamente le conoscenze che vi permetteranno di usare l’AI come un superpotere invece che come una stampella.

Poi, imparate a pensare in termini di sistemi. Non singole funzioni, non singoli endpoint, ma sistemi. Come si progetta qualcosa che deve servire mille utenti? E centomila? E dieci milioni? Dove metti la cache? Come gestisci i fallimenti? Come fai monitoring? Come fai deploy senza downtime? Queste sono le domande del 30%, e sono le domande che l’AI non sa fare da sola.

Imparate almeno un linguaggio bene. Veramente bene. Non cinque linguaggi a livello superficiale: uno, a fondo. Capite come gestisce la memoria, come funziona il suo sistema di tipi, quali sono i suoi punti di forza e i suoi limiti. Quando conoscete veramente un linguaggio, imparare gli altri diventa naturale. E quando chiedete all’AI di scrivere codice in quel linguaggio, saprete immediatamente se sta scrivendo roba buona o roba che “funziona ma non è il modo giusto.”

Studiate sicurezza. Non come specializzazione, come competenza di base. OWASP Top 10, principi di autenticazione e autorizzazione, come funziona la crittografia (non come si implementa, quello lo fa l’AI, ma perché funziona e quando usarla). Ogni riga di codice generata dall’AI che non avete verificato dal punto di vista della sicurezza è un rischio. E i rischi in produzione diventano incidenti, e gli incidenti costano.

Imparate a lavorare con l’AI. E intendo veramente lavorare, non “chiedere a ChatGPT di scrivermi il compito.” Imparate il context engineering: come strutturare le informazioni perché il modello vi dia output utili. Imparate il prompt design: come formulare richieste che producano risultati di qualità. Imparate soprattutto il critical thinking applicato all’AI: come valutare, verificare, integrare quello che l’AI produce.

E infine, ma non per ultimo, coltivate il lato umano. Imparate a comunicare. Imparate a scrivere (non codice: testo). Imparate a spiegare cose complesse a persone che non sono tecniche. Imparate a lavorare in team, a gestire conflitti, a dare e ricevere feedback. Queste sono le competenze che l’AI non toccherà mai, e sono quelle che faranno la differenza quando sarete al colloquio, in ufficio, o a decidere l’architettura di un sistema con il vostro team.

Il mio consiglio più onesto

Torno al punto da cui sono partito. Ho sempre fatto fatica a dare consigli di carriera perché per me questo mestiere non è una carriera. È una parte di chi sono.

Ma oggi, per la prima volta, ho un consiglio che vale per tutti. Appassionati e pragmatici. Sognatori e calcolatori.

Non competete con l’AI. Diventate la persona che la sa usare.

Il 70% del lavoro meccanico, il codice boilerplate, i CRUD, le configurazioni, la documentazione standard, sta diventando commodity. È roba che l’AI fa bene e farà sempre meglio. Investire il vostro tempo per diventare i più veloci a scrivere quel tipo di codice è come allenarsi per correre più veloce di un’automobile. Potete farlo, ma perché?

Il 30%, l’architettura, il design, la sicurezza, il pensiero critico, la verifica, la comprensione del dominio, la capacità di fare le domande giuste, quello è il vostro territorio. È lì che il vostro valore cresce, non diminuisce, con l’arrivo dell’AI. È lì che l’esperienza conta. È lì che la curiosità, l’empatia, l’intuizione fanno la differenza.

Quel bambino di 5 anni davanti all’Amstrad non sapeva nulla di carriere, di mercato del lavoro, di prospettive economiche. Sapeva solo che voleva capire come funzionava quella macchina e cosa poteva farci.

Quarant’anni dopo, con un’intelligenza artificiale come collaboratore quotidiano, la sensazione è la stessa. La curiosità è la stessa. La voglia di esplorare è la stessa. Gli strumenti sono cambiati, enormemente, ma lo spirito no.

E quello spirito, alla fine, è l’unica cosa che non potete delegare a nessuna macchina.