Perché con l'AI gli sviluppatori non spariranno

«Tra cinque anni gli sviluppatori non serviranno più.» È la frase che si sente ripetere a ogni nuova release di un modello AI. La logica sembra inattaccabile: se una macchina scrive codice, perché pagare qualcuno che lo scriva?

Il problema è che questa logica l'abbiamo già vista. Esattamente la stessa, parola per parola, formulata circa duecentocinquanta anni fa nei confronti di un altro mestiere: il tessitore. La macchina sapeva tessere. Quindi i tessitori, dicevano, sarebbero spariti.

Non sparirono. Diventarono qualcos'altro — e produssero cento volte di più. Ma soprattutto: la rivoluzione che li trasformò seguì una logica precisa, e quella logica oggi sta agendo di nuovo, sugli sviluppatori, in direzione opposta.

Quando nel 1764 James Hargreaves brevetta la Spinning Jenny, e poi nel 1785 Edmund Cartwright costruisce il primo telaio meccanico funzionante, l'industria tessile inglese cambia in modo che oggi facciamo fatica a capire. Nei settant'anni che seguono, il consumo di cotone grezzo in Gran Bretagna passa da 6 a 663 milioni di libbre. Più di cento volte tanto.

La narrazione popolare dice che le macchine "rubarono il lavoro" ai tessitori. La realtà storica è più interessante. Il numero di persone occupate nel settore tessile aumentò in quei decenni, non diminuì. Quello che cambiò fu il tipo di lavoro che facevano.

Il tessitore artigiano che produceva due metri di tessuto al giorno con il telaio a mano sparì, è vero. Ma al suo posto comparvero figure nuove: l'operatore di telaio meccanico (che ne supervisionava cinque o dieci alla volta), il manutentore, l'ingegnere tessile, il progettista di trame industriali, il responsabile di produzione, il commerciante di larga scala. Mestieri che prima non esistevano, perché non poteva esistere il problema che risolvono.

La macchina non ha sostituito il tessitore. Ha sostituito l'azione fisica del tessere. Il sapere del tessitore — capire i filati, leggere la trama, controllare la qualità, intervenire quando qualcosa va storto — è stato amplificato, non eliminato.

Oggi succede una cosa molto simile, ma con il software. Un assistente AI può scrivere centinaia di righe di codice di routine in pochi secondi: form, endpoint REST, schemi di database, componenti UI standard, integrazioni tra API, test unitari di base.

Tutta quella parte di lavoro che gli sviluppatori chiamano "boilerplate" — il codice ripetitivo, prevedibile, che bisogna scrivere ma che non è dove si trova il valore — è esattamente l'equivalente del gesto fisico del tessere. È il lavoro che la macchina può amplificare di un fattore 10, 50, 100.

Ma scrivere codice non è mai stato il vero lavoro dello sviluppatore. Il vero lavoro è capire cosa va costruito, perché, per chi, con quali vincoli, quali trade-off accettare, come integrarlo con il resto, come renderlo manutenibile, come farlo evolvere. Tutto questo l'AI non lo fa — non perché non sia "abbastanza intelligente", ma perché richiede contesto, conversazioni con persone reali, conoscenza implicita del business, intuizione sui rischi.

Quello che cambia, e cambia in fretta, è la distribuzione del tempo dello sviluppatore. Meno ore a scrivere codice di routine. Più ore a parlare con chi userà il prodotto, a disegnare l'architettura, a valutare alternative, a guidare l'AI verso la soluzione giusta — perché, esattamente come un telaio, anche un assistente AI ha bisogno di qualcuno che sappia cosa fargli fare.

Qui è dove le due rivoluzioni si separano. E la differenza non è marginale: è strutturale, e definisce il tipo di valore che l'AI nella programmazione sta sbloccando.

La meccanizzazione del tessile aveva un obiettivo chiarissimo: produrre lo stesso tessuto in serie, a costo radicalmente più basso. Standardizzazione totale. Mille metri di calicò identici a mille altri metri di calicò. Milioni di camicie tutte uguali. Il valore economico era nell'omogeneità: stesso prodotto, scala enorme, costo unitario crollato.

L'AI nella programmazione fa l'esatto opposto. Non riduce il costo di produrre lo stesso software — riduce il costo di produrre software diverso ogni volta, su misura per un problema specifico.

È una differenza enorme, e per capirla serve guardare al mercato del software degli ultimi vent'anni. L'industria SaaS è nata proprio perché costruire software custom era costoso, lento e rischioso. La soluzione: un solo prodotto venduto a migliaia di aziende, ognuna delle quali si adatta come può. È stato il nostro modello tessile: produzione in serie applicata al codice.

Con l'AI, quel calcolo cambia. Costruire un'applicazione su misura per un singolo processo aziendale, prima impensabile sotto i 50.000 euro, oggi può essere realizzato in tempi e costi che la rendono competitiva con un abbonamento SaaS pluriennale. Non per tutti i casi — ma per molti più di quanti la maggior parte delle aziende immagini.

Se la rivoluzione fosse di tipo "tessile", lo sviluppatore avrebbe ragione a preoccuparsi: il valore si sposterebbe verso pochi grandi player capaci di gestire la scala, e la maggior parte del lavoro tecnico sarebbe commodity.

Ma siccome la direzione è opposta — verso la personalizzazione di massa, non verso la standardizzazione di massa — succede il contrario. Il valore si sposta verso chi sa capire un problema specifico e tradurlo in un sistema che lo risolve. E questa capacità, a oggi, è ancora profondamente umana.

Tre cose, in concreto, stanno cambiando per chi sviluppa software professionalmente.

Primo: la soglia di accesso al "custom" si abbassa. Progetti che prima erano economicamente impraticabili diventano sostenibili. Aziende che si rassegnavano a un SaaS approssimativo iniziano a chiedersi se possono permettersi qualcosa di pensato apposta per loro. La domanda di software su misura, lungi dal diminuire, sta crescendo.

Secondo: il mestiere si sposta a monte. La parte di lavoro che vale di più non è scrivere il codice — è capire il dominio del cliente, identificare i processi che meritano un'applicazione dedicata, progettare l'architettura, prendere decisioni di trade-off. Lo sviluppatore puro che scriveva codice come "esecutore" è la versione moderna del tessitore artigiano. Lo sviluppatore che progetta sistemi è la versione moderna dell'ingegnere tessile.

Terzo: la qualità del giudizio diventa l'asset principale. Quando l'AI può produrre tre soluzioni plausibili in trenta secondi, il valore si sposta su chi sa scegliere quella giusta. Saper riconoscere un'architettura che non scalerà, un'API mal disegnata, un trade-off che ti costerà caro tra due anni — questo non lo fa nessun modello, e probabilmente non lo farà a breve.

La domanda «l'AI farà sparire i programmatori?» è la stessa domanda — sbagliata — che ci si poneva sui tessitori nel 1790. La risposta è la stessa: no, ne farà nascere di tipo diverso, e probabilmente di più. Ma di un tipo diverso.

La domanda giusta, sia se sei uno sviluppatore sia se sei un'azienda che sta valutando come muoversi, è un'altra: se costruire software su misura sta diventando dieci volte più veloce ed economico, quali processi del mio business meritano davvero un'applicazione pensata apposta per loro — invece di un altro abbonamento mensile?

Perché è esattamente lì, in quello spazio nuovo che si è appena aperto, che si sta giocando la partita. E come duecentocinquanta anni fa, vincerà non chi avrà paura della macchina — ma chi capirà, prima degli altri, cosa farsene.