Lorenzo, 50 anni, è laureato in informatica e si occupa di software e intelligenza artificiale fin dai suoi studi universitari. Ha lavorato per molti anni nell’ambito delle startup tecnologiche e oggi opera anche come libero professionista con partita IVA, affiancando aziende e team nell’adozione dell’AI nei processi di lavoro e nello sviluppo di prodotti digitali.

1. Come stai affrontando l’impatto dell’IA?

1. È una trasformazione profonda. Ho fatto software tutta la vita e oggi mi trovo a governare questa trasformazione e a beneficiarne moltissimo. Nell’ultimo periodo sono riuscito a produrre prototipi, componenti e parti funzionanti di software con una velocità che, fino a poco tempo fa, sarebbe stata impensabile. In questo momento, mentre stiamo parlando, più coding agent stanno lavorando in parallelo su piattaforme software di cui seguo progettazione, direzione e responsabilità tecnica. Questo però non significa che il lavoro sia finito quando il codice viene generato: resta fondamentale verificare, integrare, correggere, rendere coerente e mantenibile ciò che viene prodotto.
2. 
   E non ti sembra di poter essere sostituito?

L No.

D: Quindi comunque ritieni che il vostro lavoro avrà sempre un ruolo fondamentale nel gestire I processi?

L  Sì, ma cambia profondamente. È come se una parte del nostro lavoro si spostasse dal fare direttamente al diventare manager di una schiera di automazioni che dobbiamo governare. Il valore si sposta sulla capacità di definire cosa costruire, governare gli strumenti che producono codice, valutare la qualità del risultato e assumersi la responsabilità tecnica di ciò che viene messo in produzione.

D Complessivamente però pensi che questo comporterà una riduzione del lavoro oppure no?

L No, non credo che oggi si possa parlare di una riduzione immediata del lavoro. Nel mio settore, anzi, vedo il contrario: la domanda è aumentata, perché le aziende stanno cercando di capire che cosa diventa possibile fare adesso e come devono cambiare i processi.

Detto questo, alcune aree professionali diventeranno più fragili. Penso soprattutto ai lavori più esecutivi e a chi, per ragioni anche comprensibili, sta facendo resistenza. È normale: un cambiamento così rapido mette in discussione abitudini, competenze e anche identità professionali. Però non credo che questa resistenza sia sostenibile a lungo.

Nel software, chi nei prossimi uno o due anni non impara a usare bene questi strumenti rischia di diventare molto meno efficace. Non dico automaticamente senza lavoro: il mercato italiano è eterogeneo, con organizzazioni che adottano l’innovazione a velocità molto diverse. Ma meno competitivo sì, perché la differenza in termini di costi, tempi e delivery sarà sempre più difficile da ignorare.

D Ci sono persone che fanno lavori molto semplici che non avranno più lavoro secondo te?

Oppure, usando un altro approccio, è possibile individuare le mansioni che potranno essere potenziate e sostituite e quelle che invece non sono sostituibili e che quindi rimarranno il vostro vero ambito di lavoro e di professionalità.

L

La domanda sulle mansioni è quella giusta. Non credo sia utile chiedersi se una professione sparirà in blocco. È più corretto scomporre ogni lavoro nei compiti che lo compongono. Alcuni task possono essere automatizzati, altri possono essere accelerati, altri ancora diventano più importanti proprio perché richiedono giudizio, responsabilità, conoscenza del contesto e capacità di valutazione.

Nel mio settore, la parte più direttamente esposta è quella esecutiva: scrivere codice, produrre documentazione tecnica di base, generare test, fare refactoring, sistemare bug circoscritti. Tutte attività che fino a poco tempo fa richiedevano molto tempo umano e che oggi possono essere svolte, almeno in parte, con il supporto di strumenti molto potenti.

Questo però non significa che il lavoro dell’ingegnere software sparisca. Si sposta. Diventa più importante saper formulare bene il problema, progettare l’architettura, decidere cosa costruire e cosa non costruire, dare istruzioni precise agli strumenti, verificare che il risultato sia corretto, mantenibile e coerente con il sistema complessivo.

Chi oggi rifiuta questi strumenti perché li ha provati superficialmente e non ne ha visto subito il valore rischia di perdere un’occasione. È un po’ come dire: “ho aperto Excel, ho riempito due celle, non mi è servito, torno a fare i conti a mano”. Può succedere, è comprensibile, ma non è il modo migliore per capire se uno strumento può esserti di aiuto.

Credo che questa resistenza, in parte, passerà da sola: gli strumenti diventeranno più semplici, più integrati negli ambienti di lavoro, meno faticosi da usare. Però nel frattempo chi impara a usarli bene accumula un vantaggio concreto. Chi nei prossimi anni resta legato solo alla parte esecutiva rischia di avere uno spazio più ristretto sul mercato.

Per un libero professionista il punto è ancora più delicato. Se il suo valore è percepito solo come capacità di eseguire pezzi di codice su richiesta, quella posizione diventa fragile. Se invece porta capacità di capire il problema, trasformarlo in soluzione, governare gli strumenti e garantire il risultato, allora l’AI può diventare un moltiplicatore enorme.

D Quindi, se non ho capito male, non è che cambino le competenze, ma vengono più sfruttate quelle che erano le competenze più alte, mentre quelle più esecutive vengono in gran parte sostituite.

L Esatto.

D Ma nella formazione di chi sta entrando la parte esecutiva ha comunque un ruolo oppure a questo punto è superata?

L Se si guarda ai percorsi di studio più professionalizzati, universitari, la parte di coding è relativamente marginale nel curriculum accademico.

Nei percorsi universitari di informatica il centro non è mai stato “imparare a scrivere codice”. Certo, si programma, ed è importante farlo. Ma la formazione più importante riguarda i principi: algoritmi, architetture, sistemi operativi, basi di dati, compilatori, metodi di progettazione, qualità del software.

La parte esecutiva serve perché ti fa attraversare concretamente i problemi. Ti dà sensibilità tecnica: capisci cosa vuol dire costruire qualcosa che funziona davvero, dove nascono gli errori, quali vincoli emergono, cosa rende un sistema fragile o mantenibile. Quindi non la eliminerei dalla formazione, anche se nella pratica professionale peserà meno.

Il valore professionale è sempre di più nella capacità di capire il problema, progettare una soluzione, usare bene gli strumenti, valutare ciò che producono e assumersi la responsabilità del risultato.

D Come si stima il valore dei servizi che produci con l’aiuto dell’IA?

L Ecco la cosa molto difficile ora da capire è come stimare il costo del software.
Il software, da sempre, lo stimiamo in tempo uomo: quanti giorni di analisi, quanti giorni di sviluppo, quanti giorni di test. Solo che questa unità di misura oggi comincia a non reggere più.

Se una parte del lavoro che prima richiedeva settimane ora la posso comprimere moltissimo, non posso continuare a ragionare esattamente come prima. Però non posso nemmeno dire che il valore di quello che produco coincida con il tempo materiale che ho impiegato a far uscire il primo prototipo.

Faccio un esempio reale. Una piccola realtà in fase di avvio, in un settore industriale verticale, aveva bisogno di un’applicazione interna per fare valutazioni tecniche e analisi dati sul proprio dominio. Li ho ascoltati, ho usato le meeting notes come base di lavoro e, con alcuni assistenti specializzati nel coding, dopo pochissimo avevo già un prototipo funzionante.

Però non posso dire che il lavoro sia finito lì. Questa prima versione devo dimostrarla, capire se corrisponde davvero al loro bisogno, verificare che i calcoli siano corretti, provarla su casi reali, correggerla, raffinarla. Quella prima iterazione è potentissima, perché mi permette di arrivare subito a qualcosa di concreto, ma non è tutto il lavoro.

Quindi non posso valorizzare solo il tempo che ho impiegato per arrivare al prototipo. Allo stesso tempo, non posso stimarlo come se avessi dovuto costruire la stessa cosa in tre mesi con un processo tradizionale: quella piccola impresa probabilmente non avrebbe potuto permetterselo.

Siamo in mezzo a un cambio di metrica. Il tempo uomo non basta più a spiegare il valore. Bisogna trovare un equilibrio: il cliente può accedere a soluzioni che prima sarebbero state troppo costose, mentre il professionista deve imparare a valorizzare il risultato, la competenza e la responsabilità, non solo il tempo impiegato.

D possiamo dire che c’è lo spazio per poter avere dei prezzi più bassi e accontentare di più la domanda, ma allo stesso tempo di remunerare in maniera corretta il lavoro.

L Beh sì, al momento è così. È tutto ancora molto instabile, quindi magari tra un anno il mercato si sarà già assestato in un altro modo. Però oggi chi sa usare bene questi strumenti può fare una cosa che prima era molto difficile: offrire al cliente un costo più accessibile e, allo stesso tempo, aumentare la propria capacità produttiva. Questo perché riesci a seguire più attività in parallelo, a comprimere una parte del lavoro esecutivo e ad arrivare molto prima a qualcosa di concreto. Per il cliente il costo può essere più basso rispetto a un progetto software tradizionale; per il professionista, se riesce a organizzarsi bene, il margine può anche aumentare.

Naturalmente non penso che questa situazione rimanga identica per sempre: man mano che gli strumenti diventeranno più diffusi, anche il mercato cambierà le proprie aspettative.

Io auspico anche un effetto più democratico. Per me il coding deve uscire dal silos dell’ingegneria. Come c’è stata l’epoca del personal computer, immagino una fase di personal software, in cui molte persone potranno costruire strumenti su misura per i propri bisogni, senza essere ingegneri.

Diversamente, il software a servizio dei processi aziendali avrà sempre bisogno di competenze specialistiche: qualcuno deve garantire che il sistema funzioni, sia corretto, sia manutenibile e sia affidabile nel contesto in cui viene usato.

D , però dal momento che è più semplice fare le cose, non pensi che questa diventerà una scusa per i committenti, per pagare di meno, per dire vabbè, tanto lo fai in mezz’ora, quindi ti do poco. Come sempre, quando le cose diventano più facili sembra che sia anche giusto pagarle poco.

L È un fenomeno emergente, ancora non pienamente visibile. Io lo sto sperimentando in prima persona: avendo questa capacità di produzione potenziata, ho meno bisogno di chiedere una mano ai colleghi freelance con cui talvolta collaboro. E dureante le collaborazioni stesse ci troviamo a rivedere insieme le pianificazioni alla luce dell’efficienza che questi strumenti portano. Anzi, mi auguro che i professionisti con cui lavoro siano sempre più esperti nell’usarli al meglio, perché è lì che si crea valore comune: si riduce quella coda lunga di piccoli interventi e manutenzioni che nel software ha sempre reso il lavoro inefficiente.

Però il punto resta: l’ora di lavoro è ancora l’unità di misura del valore economico ma non funziona più come misura adeguata. Bisogna trovare un equilibrio tra quello che viene consegnato e il contributo effettivo della persona che lo ha reso possibile. E questo equilibrio, oggi, non c’è ancora.

D Ci hai parlato molto dei vantaggi, che sono sicuramente enormi. Vedi anche dei rischi o degli svantaggi nel modo di lavorare con l’uso dell’intelligenza artificiale ? Aumentano lo stress, le possibilità di errori, di allucinazioni.
O invece sei in grado di gestire anche tutto questo in maniera ormai organizzata?

L Il nodo vero è quello organizzativo: come strutturare i propri strumenti, il modo in cui li si usa e quali passaggi di controllo introduci. A parità di strumenti, due persone possono ottenere risultati molto diversi, perché contano le competenze, l’esperienza, il metodo di lavoro. È lì che il contributo umano continua a fare la differenza. Io non li vedo come svantaggi, li vedo come elementi da perfezionare, non ancora totalmente efficaci, su cui c’è ancora bisogno di un apporto individuale per progredire.

Per essere sincero, non mi fido di chi dice “l’ho fatto con l’IA” senza saper spiegare cosa ha fatto. È una dinamica che sto osservando in diversi contesti di sviluppo: colleghi molto bravi, brillanti e velocissimi, che usano questi strumenti per produrre funzionalità a una velocità impressionante. Quando però si passa alla revisione, talvolta emerge una difficoltà a spiegare alcune scelte architetturali. Questo mi fa pensare che non sempre sia stata fatta fino in fondo quella fase di valutazione critica che, per me, è una parte essenziale della competenza ingegneristica.

Il rischio, altrimenti, è costruire un Frankenstein: tante funzionalità cucite una all’altra, magari funzionanti prese singolarmente, ma che si duplicano, si contraddicono, introducono fragilità e rendono difficile mantenere ed evolvere il prodotto.

Per questo, nei processi che coordino, ho introdotto un cambiamento: non valutiamo più solo la funzionalità finale. Prima di costruirla chiediamo un piccolo documento di progetto che spieghi come verrà realizzata, quali scelte sono state fatte e quali punti critici vanno controllati.

Una volta che quel documento è condiviso e approvato, la produzione può anche essere molto automatizzata, perché ci sono test, checkpoint e revisioni che aiutano a garantire la qualità. Il baricentro si sta spostando: diventa centrale la qualità della specifica e del processo con cui arrivi al codice. In questo senso, quando qualcuno dice che “la specifica è il prodotto”, secondo me coglie qualcosa di reale.

D Con questo uso intensivo dell’IA, aumenta o diminuisce l’interazione tra colleghi? La relazione con la macchina tende a sostituire quella tra persone?

L Nel nostro settore c’è sempre stata una certa tendenza a stare meglio davanti alla macchina che nelle riunioni con altre persone. Siamo sempre stati un po’ degli orsi, diciamolo. Quindi sì, il rischio che qualcuno si chiuda ancora di più nel rapporto con lo strumento esiste.

Però potrebbe succedere anche il contrario. Se la parte più esecutiva, il coding, assorbe meno tempo, si può liberare più spazio per il confronto sulle cose che contano davvero: cosa stiamo costruendo, perché lo stiamo costruendo, quali scelte facciamo, quali rischi ci prendiamo, come facciamo a garantire qualità. In teoria, quindi, l’AI potrebbe rendere più preziosa l’interazione tra colleghi, non meno.

Poi c’è anche il rischio della tana del coniglio, e lì parlo per esperienza personale. Quando ti accorgi che puoi costruire cose a una velocità enorme, puoi finire dentro un tunnel produttivo molto forte. A me è successo: a gennaio, in circa venti giorni, lavorando su side project nel tempo libero ho prodotto una quantità di codice funzionante che con metodi tradizionali avrebbe richiesto anni. Questa esperienza mi è servita moltissimo, perché mi ha fatto capire direttamente la potenza reale e i limiti di questi strumenti. Però mi ha anche tolto tempo libero e relazioni umane. Quindi non la racconterei solo come una storia di efficienza: è anche una cosa da imparare a governare.

D Tu dici che è importante che le persone abbiano la consapevolezza di quello che fanno, conoscano la struttura che sta dietro quello che vanno a produrre. Se consideri le persone giovani che iniziano adesso, che partono lavorando sin da subito con l’intelligenza artificiale nella produzione di software, come è possibile che abbiano questa consapevolezza?  C’è il rischio concreto di codice costruito senza capire davvero come funziona?

Sì, il rischio c’è. Ed è giusto porsi il problema, soprattutto per chi entra adesso nella professione.

Continuo a vedere enormi vantaggi in questi strumenti, quindi non parlo da una posizione difensiva. I più giovani devono usarli, anzi probabilmente devono imparare a usarli meglio di noi. Però il fatto che una parte del coding venga automatizzata non significa che si possa saltare la disciplina.

Nel software esistono competenze che non sono semplicemente “scrivere codice”. Sono competenze che servono per capire che cosa stai costruendo e perché una soluzione è corretta oppure fragile. Se uno non attraversa almeno in parte quel tipo di complessità, rischia di produrre cose funzionanti in superficie, ma senza capire davvero come stanno in piedi.

In futuro si scriverà molto meno codice a mano e diventa ancora più importante sapere come farlo generare, come assemblarlo, come controllarlo, come integrarlo in un sistema più grande. È una competenza diversa, e richiede comunque studio ed esperienza.

C’è poi un secondo punto: costruire sistemi software complessi non è qualcosa che impari solo da solo, davanti a un modello. Lo impari anche dentro organizzazioni strutturate, lavorando con persone più esperte, vedendo progetti grandi, vincoli reali, errori veri, tempi, responsabilità, specializzazioni diverse. È lì che le competenze si mescolano e maturano.

Quindi no, non credo che la soluzione sia tornare a lavorare come prima. Ma non credo neanche che basti dare a una persona giovane un modello di AI e lasciarla costruire software da sola. Le eccezioni ci saranno sempre, persone con grandissima autonomia. Ma per la maggior parte dei professionisti servono studio, contesto, confronto e la possibilità di assumersi responsabilità vere nel tempo.

I giovani devono usare l’AI con grande sicurezza, ma devono avere alle spalle una disciplina. Senza quella disciplina possono costruire prototipi, strumenti, prodotti anche brillanti ma difficilmente potranno progettare e costruire software che reggono processi importanti, infrastrutture critiche o prodotti complessi.

D Se non ho capito male vedi il futuro della professione all’interno di strutture, cioè non per il singolo freelance isolato, ma per uno che lavora dentro un’organizzazione che poi ci lavori con un rapporto di collaborazione esterna o come dipendente forse non è rilevante, ma comunque dentro un’organizzazione.

L  Sì, almeno per il software che conta davvero. È chiaro che con questi nuovi strumenti singoli professionisti o piccoli gruppi potranno produrre molto più di prima, e questo apre spazi nuovi anche per i freelance qualificati. Però la maggior parte del software che entra nei processi reali delle organizzazioni, che deve durare, integrarsi con altri sistemi, essere mantenuto e assumersi responsabilità, difficilmente nasce nel vuoto.

Non è solo una questione di scrivere codice. È una questione di capire per chi lo stai costruendo, dentro quale contesto, con quali vincoli e con quali conseguenze. Da questo punto di vista il team resta centrale, anche se magari sarà un team diverso da quello tradizionale.

Quindi non direi che il futuro è solo dentro l’azienda o solo fuori. Direi che il futuro è per chi sa lavorare dentro un sistema: come dipendente, consulente, freelance o partner cambia relativamente. Quello che conta è non essere solo un esecutore isolato, ma qualcuno che porta competenza dentro un processo collettivo di costruzione.