← Torna a tutti gli articoli
Sfide

«Il software è morto» è un'esagerazione (e come il mercato l'ha letto tutto al contrario)

Di Marc Molas·4 giugno 2026·8 min di lettura

Quest'anno il mercato ha deciso che il software sta morendo.

I titoli parlano di una specie di apocalisse del SaaS: decine di società di software quotate hanno visto svanire una fetta enorme della loro capitalizzazione — migliaia di miliardi di dollari, messe tutte insieme — sotto una tesi tanto semplice quanto tagliente. Se un agente IA può fare il lavoro che prima faceva il tuo prodotto, perché qualcuno dovrebbe continuare a pagare per il tuo prodotto? L'argomento è pulito, sta in un tweet e ha mosso un mare di soldi.

E, come quasi tutte le tesi pulite che muovono un mare di soldi, è leggere al contrario quello che sta davvero succedendo.

Non lo scrivo dalla sedia dell'investitore, ma da quella di chi costruisce. Rilascio software in produzione da abbastanza anni da aver assistito al funerale di questa industria parecchie volte, e sempre con lo stesso copione: una tecnologia nuova rende ovvia una fetta del valore, il mercato scambia quella fetta per l'intero, e mentre tutti sono al funerale il lavoro vero si sposta in sordina verso un altro strato dello stack. Stavolta non fa eccezione. Quello che è diventato economico non è il software. È il modello.

Il mercato non ha ucciso il software; ha riprezzato il modello

L'equivoco di fondo è trattare «modello» e «software» come se fossero la stessa cosa. Non lo sono, e in quella differenza c'è tutta la storia.

Un modello di linguaggio è un motore statistico impressionante e, trimestre dopo trimestre, sempre più economico e più intercambiabile. Oggi ne hai mezza dozzina di frontiera che fanno, a fini pratici, un lavoro equivalente, e ne sostituisci uno con un altro cambiando una riga di configurazione. Questa è, letteralmente, la definizione di merce (commodity): un input potente, certo, ma senza fossato difensivo, perché il tuo concorrente dispone dello stesso input allo stesso prezzo.

Quello che il mercato ha punito non è la morte del software, ma la scoperta — improvvisa e digerita male — che il modello non è un fossato. E faceva bene a punire le aziende che avevano convinto tutti del contrario. Dove sbaglia è il passo successivo: dare per scontato che, se il motore è economico, l'auto intera valga zero.

Chiunque abbia costruito sistemi sul serio sa che il motore è sempre stato la parte facile.

Questo film l'abbiamo già visto

All'inizio degli anni 2000, quando il SaaS ha cominciato a mangiarsi il software in scatola, la paura era identica: il cloud trasformerà il software in una commodity, i margini evaporeranno, i giganti sono fuori tempo massimo. Le licenze perpetue, i CD di installazione, i server a casa del cliente: tutto quello stava morendo. Ed è morto davvero.

E l'industria del software, nel frattempo, si è moltiplicata. Quello che era un mercato di un paio di centinaia di miliardi di dollari l'anno è arrivato a muoverne intorno ai millecinquecento in poco più di un decennio. I presunti cadaveri — Microsoft, Adobe, Oracle — non solo sono sopravvissuti: sono diventati parecchie volte più grandi di com'erano prima della disruption che doveva ucciderli.

La lezione non è «andrà tutto bene». Alcune aziende sono morte sul serio, e tanti posti di lavoro concreti sono spariti davvero. La lezione è più precisa: disruption non è sinonimo di morte. Quello che è successo con il cloud non è stata una contrazione del software, ma un cambio di forma — e, lungo la strada, un'espansione enorme di quanto c'era da costruire. Chi ha confuso «il mio modello di business di dieci anni fa sta morendo» con «il software sta morendo» ha venduto nel peggior momento della storia per farlo.

«L'IA non sostituirà il software: lo userà»

Ecco la frase che ribalta l'intera tesi pessimista, e conviene leggerla piano: l'agente IA non è un sostituto del software. È il suo nuovo utente, e il più esigente.

Pensa a cosa serve davvero a un agente per fare lavoro utile sui tuoi sistemi. Gli serve un'API pulita e versionata da chiamare. Gli servono permessi granulari, perché non gli darai le chiavi di tutto. Gli serve l'idempotenza, perché un agente ritenta. Gli servono i rate limit, perché un agente finito in un loop può martellare un endpoint mille volte al secondo. Gli servono tracciabilità e audit, perché quando un'azione automatica toccherà la contabilità di un cliente qualcuno dovrà poter ricostruire chi l'ha decisa e perché. Gli servono guardrails, sandboxing e una superficie di strumenti pensata perché un attore non deterministico non combini un disastro.

Niente di tutto questo nasce da sé. Tutto questo è software, e a costruirlo sono gli ingegneri. Quando il tuo utente più vorace smette di essere una persona che clicca un pulsante e diventa un agente che spara mille azioni al minuto, la superficie di software che devi costruire e gestire non si restringe: esplode. Ogni capacità che prima nascondevi dietro un'interfaccia umana ora la devi esporre, mettere in sicurezza, limitare e monitorare come uno strumento di prima classe. Questo è più ingegneria, non meno.

Il call center che risponde alle domande con un copione, sì, quello l'agente lo sostituisce eccome, e fingere il contrario non aiuta nessuno. Ma il sistema che l'agente usa per risolvere il caso sul serio — consultare l'ordine, validare la policy, emettere il rimborso senza rompere niente — qualcuno lo deve costruire, e non si costruisce da solo.

Il valore sale lungo lo stack, non sparisce

Se il modello è il motore economico e intercambiabile, dove finisce il valore? Sale. Verso lo strato che il modello non può darti: i tuoi dati e, soprattutto, i tuoi workflow di fiducia.

Un modello di frontiera non sa come la tua azienda gestisce un reso, quali sono le tue regole di compliance, cosa significa «cliente a rischio» nel tuo settore, né quale dei sei passaggi di quel processo è quello che non si salta mai. Tutta questa conoscenza — codificata, verificata, integrata con i tuoi sistemi reali — è esattamente ciò che non si scarica da un fornitore di modelli. È il fossato. Ed è, guarda caso, la parte più difficile e più costosa da costruire: l'integrazione, la qualità dei dati, la verifica, i guardrails, il giudizio per capire quando passare la palla a una persona.

Ho già spiegato più nel dettaglio perché questo strato — l'harness che avvolge il modello — è dove vive davvero l'ingegneria, e perché la sua complessità crescente indica più lavoro per gli ingegneri, non meno, in Agentic-as-a-Service e il ritorno dell'ingegnere. Il riassunto, per chi ha fretta: il modello rende commodity l'80% facile, e la differenziazione si sposta per intero nel sistema che lo avvolge. E quel sistema non si genera da sé.

Il prezzo cambia forma; non sparisce

L'altra metà del panico è il modello di business. Se smetti di vendere «postazioni» perché non ci sono più umani seduti davanti allo schermo, come incassi?

Beh, cambi asse. Invece di fatturare per utente, fatturi per lavoro svolto: per azione dell'agente, per caso risolto, per risultato. E questo cambio, lungi dall'essere una minaccia, è il sogno di chiunque venda software che davvero fa cose: smetti di incassare in base a quanta gente apre l'app e passi a incassare in base a quanto valore genera. Le aziende già in questa transizione raccontano che una fetta sostanziale del fatturato nuovo non si vende più a postazioni. Non è la fine della monetizzazione del software. È un modo più onesto di monetizzarlo.

Un modello di business che evolve non è un'industria che muore. È un'industria che cresce abbastanza in fretta da fare paura a chi la guarda da fuori.

Cosa farei io se fossi il tuo CTO questo trimestre

Tre scommesse concrete, perché una diagnosi senza azione non è che una bella opinione:

  1. Non puntare il fossato sul modello. Se la tua differenziazione dipende da quale LLM usi, una differenziazione non ce l'hai — il tuo concorrente può noleggiare lo stesso domani. Metti il fossato dove non si noleggia: i tuoi dati, i tuoi workflow, la tua verifica, la tua integrazione.
  2. Tratta ogni agente come un utente di prima classe. Progetta le API, i permessi, l'audit e i guardrails dando per scontato che il cliente principale sarà non deterministico e instancabile. Quello che costruisci qui è proprio la parte che agli altri costerà di più copiare.
  3. Conta gli ingegneri al rialzo, non al ribasso. La tentazione del titolo è tagliare perché «tanto lo fa l'IA». La scommessa di chi ha già visto il film è l'opposta: l'esplosione della superficie di software chiede più persone capaci di ragionare su sistemi probabilistici sotto carico, non meno. Chi taglia oggi passerà il 2027 a riassumere personale, come è già successo a chi si è portato avanti con la moda dei licenziamenti.

La linea che difendo è quella di sempre, e ora il mercato me la illustra con un funerale salato: l'IA non sostituisce il software, lo usa; e non sostituisce l'ingegnere, lo potenzia. Quello che è morto è l'idea comoda che il motore fosse il fossato. Tutto il resto — l'auto intera — è ancora da costruire, e non c'è mai stato così tanto da costruire.

La morte del software, come quella di quel famoso scrittore, è stata molto esagerata. E chi saprà leggerla nel verso giusto sarà chi rilascerà i sistemi che contano davvero in questo decennio.


Stai costruendo lo strato che fa davvero la differenza — workflow, integrazione, verifica — e ti servono ingegneri senior che sappiano dove l'IA aumenta e dove no? Parla con un CTO di come schierare uno squad nearshore che costruisca il fossato, non che si limiti a collegare il modello.

Pronto a costruire il tuo team di ingegneria?

Parla con un partner tecnico e distribuisci sviluppatori validati da CTO in 72 ore.