L’AI potrebbe ridurre il numero di sviluppatori necessari nelle grandi organizzazioni, ma allo stesso tempo creare una nuova domanda di competenze tecniche proprio nelle aziende che fino a oggi non hanno mai potuto avere un vero reparto software.
Quando si parla dell’impatto dell’intelligenza artificiale sul lavoro degli sviluppatori, la discussione tende quasi sempre a seguire la stessa direzione. Se un programmatore, grazie a strumenti come Codex, Claude Code o GitHub Copilot, riesce a produrre in poche ore ciò che prima avrebbe richiesto giorni, la conclusione sembra abbastanza immediata: in futuro serviranno meno sviluppatori.
Probabilmente, almeno in parte, sarà così.
Una software company che oggi impiega cento persone potrebbe scoprire di poter mantenere lo stesso livello di produzione con un team molto più piccolo, soprattutto perché una parte crescente del lavoro che prima richiedeva sviluppatori junior può essere eseguita, o quantomeno accelerata, da sistemi di AI. Gli sviluppatori più esperti, a loro volta, possono gestire una quantità di lavoro molto maggiore, coordinando agenti, generando codice, verificando implementazioni e muovendosi contemporaneamente su parti diverse di un progetto.
Se guardiamo soltanto a questa parte dell’equazione, quindi, è facile arrivare alla conclusione che l’AI porterà inevitabilmente a una riduzione dei posti di lavoro nel software.
Ma credo che ci sia un’altra parte della storia che stiamo osservando molto meno e, per capirla bene, bisogna prima considerare come è organizzata oggi gran parte del mercato del software.
La maggioranza delle aziende non sviluppa il proprio software. Lo compra (o lo “affitta”).
Un ristorante utilizza un sistema per le prenotazioni, un’azienda di logistica acquista un gestionale, uno studio professionale utilizza un CRM, una piccola impresa adotta un sistema per la contabilità, un’altra paga una serie di abbonamenti SaaS per gestire vendite, personale, documenti, comunicazione e processi interni.
È un modello che esiste per una ragione molto semplice: sviluppare software è sempre stato costoso.
Per creare anche un’applicazione relativamente ordinaria servivano analisti, sviluppatori, database administrator, persone che si occupassero dell’infrastruttura, del testing, della sicurezza e successivamente della manutenzione. Per una grande organizzazione poteva avere senso sostenere questo costo. Per una piccola o media impresa, nella maggior parte dei casi, no.
Il risultato è stato una forte concentrazione delle competenze software.
Da una parte abbiamo aziende il cui prodotto è il software e che impiegano centinaia o migliaia di persone per costruirlo. Dall’altra abbiamo milioni di aziende che utilizzano quel software e che, salvo qualche eccezione, non avrebbero mai avuto le risorse economiche o organizzative per costruire internamente qualcosa di equivalente.
Questa struttura ha inoltre prodotto un compromesso che conosciamo molto bene.
Quando un’azienda compra un software commerciale, raramente quel software è stato progettato esattamente per il suo modo di lavorare. È stato progettato per soddisfare un mercato abbastanza ampio da giustificare il costo del suo sviluppo.
Di conseguenza contiene decine, a volte centinaia, di funzionalità delle quali ogni singolo cliente utilizza solamente una parte. Alcune si adattano bene ai processi aziendali, altre richiedono configurazioni, workaround o semplicemente un cambiamento nel modo in cui l’azienda lavora.
Per anni abbiamo accettato questo compromesso perché l’alternativa era economicamente poco sensata.
Costruire un software completamente personalizzato per una piccola azienda, soltanto per riprodurre quel venti o trenta per cento delle funzionalità che utilizza realmente, sarebbe costato molto più che acquistare una licenza SaaS.
L’intelligenza artificiale potrebbe cambiare proprio questa equazione.
Non perché il proprietario di una piccola azienda diventerà improvvisamente uno sviluppatore software e inizierà a costruire il proprio ERP durante il fine settimana. Questa, secondo me, è una delle interpretazioni più ingenue dell’attuale entusiasmo intorno al cosiddetto vibe coding.
Costruire software che deve essere utilizzato realmente da un’azienda rimane un’attività ingegneristica. Bisogna capire come modellare i dati, come gestire autenticazione e autorizzazioni, come progettare l’architettura, come integrare servizi esterni, come proteggere informazioni sensibili, come testare il sistema e soprattutto come mantenerlo quando inevitabilmente qualcosa cambia.
Il fatto che un modello possa generare rapidamente diecimila righe di codice non elimina nessuno di questi problemi ma cambia radicalmente la quantità di lavoro necessaria per risolverli.
Ed è qui che secondo me potrebbe iniziare una trasformazione molto più interessante del semplice dibattito sul numero di programmatori che perderanno il lavoro: una piccola azienda che fino a ieri non avrebbe mai potuto permettersi un team di cinque o dieci sviluppatori potrebbe scoprire che una singola persona con una buona esperienza tecnica, supportata da sistemi di AI sufficientemente avanzati, è in grado di costruire e mantenere una parte significativa del software di cui quell’azienda ha realmente bisogno.
L’azienda, tra l’altro, possiede già una delle componenti più difficili da acquisire: la conoscenza del proprio lavoro.
Il titolare di un’azienda di logistica conosce i problemi della logistica molto meglio di uno sviluppatore appena assunto. Le persone che lavorano quotidianamente nell’azienda conoscono le eccezioni, i passaggi manuali, gli Excel che nessuno osa toccare, le informazioni che vengono copiate da un sistema all’altro e tutte quelle piccole inefficienze che dall’esterno spesso non sono nemmeno visibili.
Quello che normalmente manca non è il domain knowledge: manca, invece, la capacità di trasformare quella conoscenza in un sistema software affidabile. Ed è proprio qui che potrebbe nascere una nuova categoria di professionisti.
Non necessariamente persone che conoscono già il settore nel quale entreranno a lavorare, perché quella conoscenza può essere trasferita dall’azienda stessa, ma persone capaci di prendere un processo reale, comprenderlo insieme a chi lo utilizza ogni giorno e trasformarlo in requisiti, architettura, dati, integrazioni e infine software funzionante, usando l’intelligenza artificiale come moltiplicatore della propria capacità produttiva.
Questo cambia anche il modo in cui dovremmo pensare alla possibile perdita di posti di lavoro nelle grandi organizzazioni tecnologiche.
Se una software company riesce a fare con cinquanta sviluppatori il lavoro che prima ne richiedeva cento, cinquanta posizioni potrebbero effettivamente scomparire da quella particolare azienda.
Ma questo non significa necessariamente che la domanda complessiva di competenze software debba diminuire nella stessa misura.
Se contemporaneamente migliaia di aziende che prima acquistavano esclusivamente software standard iniziano a sviluppare internamente piccole applicazioni, automazioni, sistemi verticali e integrazioni personalizzate, una parte di quella domanda potrebbe semplicemente spostarsi dalle aziende che costruiscono software per tutti verso aziende che costruiscono software per se stesse.
Ed è per questo che penso che parlare soltanto di distruzione dei software jobs rischi di farci perdere la trasformazione più interessante.
Potremmo essere all’inizio di una redistribuzione del lavoro.
Per decenni la capacità di produrre software è rimasta concentrata in un numero relativamente limitato di organizzazioni perché il costo per costruirlo era elevato. Se l’AI riduce drasticamente quel costo, la conseguenza non è necessariamente soltanto che serviranno meno persone per produrre la stessa quantità di software.
Potrebbe succedere anche il contrario: potremmo iniziare a produrre molto più software, in molti più posti, per problemi che fino a ieri non valeva economicamente la pena risolvere con una soluzione personalizzata.
E se questo accadrà, uno dei cambiamenti più importanti non riguarderà semplicemente quanti sviluppatori avremo bisogno in futuro.
Riguarderà dove lavoreranno, per chi lavoreranno e soprattutto che tipo di lavoro saranno chiamati a fare.
Dal programmatore al solution engineer
Questa possibile redistribuzione pone però un problema importante per chi oggi lavora nello sviluppo software, soprattutto per le figure che svolgono attività relativamente standardizzate e che quindi sono maggiormente esposte all’automazione.
La risposta più comune è che queste persone dovrebbero semplicemente “imparare l’AI”. Non credo sia sufficiente.
Sapere utilizzare un coding agent sarà presto una competenza di base, nello stesso modo in cui oggi non consideriamo particolarmente distintivo il fatto che uno sviluppatore sappia utilizzare Git o un IDE.
Il vero salto professionale consiste nel passare dall’essere una persona che riceve un task e produce codice all’essere una persona capace di prendere un problema poco definito e trasformarlo in una soluzione tecnica completa.
Questo significa parlare con le persone che svolgono realmente il lavoro, capire cosa stanno cercando di ottenere, distinguere un requisito reale da una preferenza, individuare le eccezioni, modellare correttamente i dati, decidere quali parti costruire e quali acquistare, progettare integrazioni, verificare il comportamento del sistema e assicurarsi che ciò che è stato prodotto continui a funzionare dopo sei mesi.
L’AI può scrivere una quantità enorme del codice necessario per fare tutto questo ma qualcuno deve ancora sapere quale codice dovrebbe esistere ed è probabilmente in questa direzione che una parte degli sviluppatori di oggi dovrà evolversi.
Non necessariamente verso un ruolo più astratto o manageriale, ma verso una forma di ingegneria più completa, nella quale la capacità di programmare rimane importante ma diventa soltanto una componente di un lavoro molto più ampio.
Paradossalmente, quindi, l’AI potrebbe ridurre il valore economico della semplice produzione di codice e aumentare quello della capacità di trasformare problemi reali in sistemi funzionanti.
Per un developer junior questa può sembrare una prospettiva poco rassicurante, perché una parte del lavoro che tradizionalmente rappresentava il punto di ingresso nella professione è esattamente quella che gli strumenti di AI stanno imparando ad automatizzare più rapidamente.
Ma potrebbe, invece, essere anche un’indicazione piuttosto chiara su dove investire il proprio tempo: non limitarsi a diventare più veloci nel produrre codice con l’AI, ma imparare a gestire l’intero processo che porta da un’esigenza aziendale a una soluzione in produzione.
Se davvero il software diventerà più facile ed economico da costruire, questa capacità potrebbe diventare utile in moltissimi più posti di quanto non lo sia oggi.
Ed è qui che la storia sull’AI e i software jobs potrebbe prendere una direzione molto diversa da quella che normalmente immaginiamo.
Forse non stiamo semplicemente entrando in un mondo nel quale serviranno meno sviluppatori.
Forse stiamo entrando in un mondo nel quale molte più aziende potranno permettersi di averne uno.