Lo sconto e la fattura

C’è un numero che circola, in queste settimane, nelle presentazioni degli analisti e nelle note dei fondi, e che fa una certa impressione se lo si riporta alla scala di una giornata. I cinque maggiori gruppi tecnologici statunitensi hanno dichiarato, per il 2026, investimenti in infrastruttura compresi fra i seicentosessanta e i seicentonovanta miliardi di dollari, contro i circa trecentottanta dell’anno precedente. Diviso per i giorni dell’anno, fa poco meno di due miliardi di dollari al giorno: data center, acceleratori, contratti energetici, terreni. Nessuna industria, in tempi di pace, ha mai speso a questo ritmo per costruire una capacità produttiva di cui non conosce ancora con precisione il cliente finale.

L’Italia, nel suo piccolo, segue la stessa curva. L’Osservatorio Artificial Intelligence del Politecnico di Milano ha misurato per il 2025 un mercato dell’intelligenza artificiale da un miliardo e ottocento milioni di euro, in crescita del cinquanta per cento sull’anno prima; Anitec-Assinform, con un perimetro più stretto, arriva a un miliardo e trecentottanta milioni, più quarantasette virgola sei per cento. Le due cifre non coincidono, e vale la pena dirlo subito, perché le associazioni contano cose diverse; ma raccontano la stessa pendenza. Il settantuno per cento delle grandi imprese ha avviato almeno un progetto, l’ottantaquattro per cento ha comprato licenze di almeno uno strumento generativo. Nelle piccole imprese, però, la sperimentazione scende al sette per cento.

La tesi di questo pezzo è che il mercato del software si trovi oggi fra due rischi simmetrici e ugualmente concreti. Il primo è quello di chi resta com’è: la software house tradizionale, con costi di struttura e modelli di prezzo pensati per un’epoca in cui scrivere codice era la parte cara, e che quell’epoca non protegge più. Il secondo è quello di chi crede di aver trovato la scorciatoia: il fai-da-te assistito, il vibe coding, che sposta il costo dal preventivo alla manutenzione e lo nasconde finché non diventa un’emergenza. Nessuno dei due è la risposta. La risposta è una struttura nuova, leggera, ma con dentro le competenze che entrambi i modelli stanno perdendo: progettazione, analisi, implementazione, sicurezza, privacy.

Un ritorno che stavolta va dimostrato

La differenza rispetto alle ondate precedenti di investimento tecnologico non sta nella cifra, sta nella pazienza. Il cloud, dieci anni fa, fu adottato per anni sulla base di promesse di flessibilità difficili da quantificare. L’intelligenza artificiale, al contrario, arriva in un momento in cui i consigli di amministrazione hanno imparato la lezione e chiedono un ritorno misurabile entro l’esercizio: produttività per addetto, riduzione dei costi operativi, tempi di ciclo. Lo stesso Osservatorio del Politecnico riporta che il cinquantotto per cento delle aziende con un progetto avviato rileva un impatto significativo sul modello di business; il che significa, letto al contrario, che quattro su dieci non lo rilevano ancora.

Questa esigenza di ritorno rapido è la chiave per capire tutto ciò che segue. Dove il beneficio deve materializzarsi in fretta, la tentazione più forte non è investire di più: è pagare di meno. E il mercato, obbediente, si è messo a offrire modi per pagare di meno. Il primo rischio nasce da chi non riesce più a farsi pagare; il secondo da chi crede di non dover pagare affatto.

Il primo rischio: il modello che invecchia

Per trent’anni una software house ha venduto, in fondo, una cosa sola: la capacità di trasformare un processo lento e manuale in uno rapido e automatico. Era un vantaggio competitivo perché era scarso. Servivano analisti, sviluppatori, mesi di lavoro; chi li aveva vendeva a caro prezzo, chi non li aveva comprava.

L’intelligenza artificiale rende abbondante esattamente quella capacità. Automatizzare non è più un differenziale, è la condizione minima per restare al tavolo. Ne segue una conseguenza che molti operatori faticano ad accettare: il valore si sposta dal fare al decidere che cosa fare, dalla funzione al senso che la funzione produce per chi la usa. Un software che offre soltanto automazione di base si svuota di valore percepito con una rapidità che prima non esisteva, perché il cliente sa, o crede di sapere, che potrebbe ottenerlo altrove a una frazione del prezzo.

I rischi per chi resta fermo sono almeno quattro, e si sommano. Il primo è l’erosione del pricing power: la capacità di difendere un canone si consuma quando il cliente percepisce un’alternativa a costo quasi nullo, e i mercati finanziari, che di solito arrivano tardi ma arrivano in massa, lo hanno prezzato all’inizio di quest’anno. Fra febbraio e marzo 2026 il settore del software quotato ha perso, secondo le ricostruzioni di Forbes e di diverse case d’analisi, oltre mille miliardi di dollari di capitalizzazione; l’indice settoriale è sceso di circa un quinto e il titolo di Salesforce, per fare un solo nome, di oltre un quarto. Gli operatori hanno battezzato il fenomeno SaaSpocalypse, e la logica sottostante è brutale: se un agente fa il lavoro di cinque persone, l’azienda compra una licenza invece di cinque. Il secondo rischio è l’abbassamento delle barriere all’ingresso: un concorrente nuovo arriva a un prodotto presentabile in settimane, e il cliente stesso può provare a farsi il software da solo. Il terzo è l’obsolescenza della base tecnica: gli acceleratori su cui gira questa infrastruttura hanno cicli di rinnovo di pochi anni, le architetture che vi si appoggiano invecchiano con loro, e chi non si aggiorna perde competitività mentre chi si aggiorna sostiene un costo ricorrente che i vecchi listini non prevedevano. Il quarto, il più insidioso, è la shadow AI: i dipendenti del cliente che usano strumenti di intelligenza artificiale fuori da ogni regola aziendale, e che nel farlo svuotano dall’interno il software ufficiale, portando processi e dati dove nessuno li governa.

Una struttura con organici dimensionati per scrivere codice, canoni difficili da difendere e cicli di rilascio pensati per tecnologie che duravano dieci anni non regge questa pressione a lungo. Non è un giudizio morale, è aritmetica.

Il secondo rischio: lo sconto del vibe coding

Il termine lo ha coniato Andrej Karpathy, già direttore dell’intelligenza artificiale di Tesla e fra i fondatori di OpenAI, in un post del 2 febbraio 2025: si descrive a voce che cosa si vuole, si accetta il codice che il modello propone senza leggerlo, si corregge a tentativi finché sembra funzionare. Karpathy lo presentava come un divertimento per prototipi del fine settimana. Nel giro di un anno è diventato una voce di bilancio.

La ragione è tutta nell’esigenza di ritorno rapido descritta sopra. Il vibe coding offre un abbattimento del costo che non è reale ma percepito, e la differenza fra i due aggettivi è l’intera questione. Percepito, perché ciò che si vede è il costo di produzione della prima versione, che crolla davvero: un gestionale interno, un portale clienti, un’integrazione fra due sistemi, tutto sembra costare una frazione di prima. Non reale, perché il costo di un software non è mai stato il costo di scriverlo. È il costo di tenerlo in piedi per gli anni in cui l’azienda ci lavora sopra, di cambiarlo quando cambia la normativa, di difenderlo quando qualcuno lo attacca, di capirlo quando chi lo ha fatto non c’è più.

Su ognuna di queste voci i dati disponibili sono meno rassicuranti di quanto lo sconto iniziale lasci credere. Veracode, che verifica la sicurezza del codice da vent’anni, ha pubblicato nel marzo 2026 l’aggiornamento della propria indagine sul codice generato: su oltre centocinquanta modelli e ottanta compiti di programmazione, nel quarantacinque per cento dei casi il modello introduce una vulnerabilità nota. La cifra è identica a quella di due anni prima. Due anni di modelli presentati come rivoluzionari hanno spostato il tasso di sicurezza dal cinquantacinque per cento circa al cinquantacinque per cento circa. METR, un laboratorio indipendente, ha misurato nel 2025 che sviluppatori esperti, su codice che conoscevano, impiegavano il diciannove per cento di tempo in più con gli strumenti di intelligenza artificiale, pur essendo convinti di andare più veloci.

Si tenga presente che quei numeri riguardano professionisti che leggono il codice. Il vibe coding, per definizione, è praticato da chi non lo legge, o non saprebbe leggerlo. È questo il punto che rende il rischio maggiore proprio per chi lo adotta in azienda pensando di risparmiare: un prodotto poco stabile, perché nessuno ne conosce la struttura; una superficie di attacco che nessuno ha ispezionato; un costo di manutenzione che esplode alla prima modifica seria, perché ogni intervento richiede di ricostruire una comprensione che non è mai esistita; e, sotto tutto questo, una mancanza di esperienza e di professionalità che il modello non compensa, perché il modello risponde alla domanda che gli viene posta, e chi non ha mestiere non sa quale domanda porre. Lo stesso sviluppo, affidato in un secondo tempo a chi lo sa fare, costa spesso più che se fosse stato fatto bene dall’inizio, perché a rifare si aggiunge il disfare.

C’è poi una voce che nei preventivi del fai-da-te non compare mai, ed è la protezione dei dati. Chi costruisce a tentativi non progetta dove i dati personali vengono conservati, quali passano per il modello, con quale base giuridica, per quanto tempo. IBM, nel proprio rapporto annuale sul costo delle violazioni di dati del 2025, ha rilevato che il sessantatré per cento delle organizzazioni non ha alcuna politica di governo dell’intelligenza artificiale, e che una presenza elevata di shadow AI aggiunge in media seicentosettantamila dollari al costo di una violazione. Il vibe coding fatto in casa è, sotto questo profilo, la stessa shadow AI che indebolisce le software house tradizionali, con in più un artefatto che resta, che tratta dati e che qualcuno dovrà rispondere davanti a un’autorità di controllo di aver progettato senza saperlo.

Una nota di cautela

Sarebbe scorretto trarne che il software tradizionale sia condannato, o che l’intelligenza artificiale nello sviluppo sia un errore. Non è vero né l’uno né l’altro.

Sul primo punto, gli operatori storici dei sistemi gestionali, contabili e di relazione con il cliente conservano vantaggi che nessun modello replica da solo: la conformità normativa costruita in anni di aggiornamenti, l’affidabilità dimostrata, la distribuzione capillare, la fiducia nel marchio. Il rischio di sostituzione è concreto per i compiti semplici e sovrastimato per i sistemi mission-critical, e le analisi più sobrie del ribasso di borsa lo dicono chiaramente: sopravvive chi fa funzionare processi complessi e dimostra un ritorno molto superiore al proprio canone. Il moat, come lo chiamano gli analisti, non è scomparso; si è spostato più in alto, dove stanno la sicurezza, la conformità e la responsabilità.

Sul secondo punto, chi sostiene che la generazione assistita di codice sia un progresso irreversibile ha ragione. I dati di Veracode misurano il codice grezzo, prima di qualunque revisione; nelle mani di chi sa leggere ciò che il modello produce, la stessa tecnologia riduce i tempi e alza la qualità. Il problema non è lo strumento, è l’illusione che lo strumento sostituisca il mestiere invece di moltiplicarlo. La tesi di questo pezzo non è che si debba tornare indietro: è che lo sconto si vede subito e la fattura arriva dopo, e che le due cose vanno messe sullo stesso foglio prima di firmare.

Cosa cambia, allora

Se la diagnosi è corretta, i due rischi hanno la stessa radice e la stessa cura. La software house tradizionale rischia perché la sua struttura è troppo pesante per il valore che il mercato le riconosce; il fai-da-te assistito rischia perché la sua struttura è troppo leggera per le responsabilità che si assume. In mezzo non c’è un compromesso, c’è una forma diversa: una struttura moderna nei costi e nei tempi, che usa i modelli come materiale di costruzione, ma che conserva per intero le competenze che il mercato sta dando per scontate proprio mentre le perde.

Sono cinque, e vanno nominate una per una perché è su ciascuna che il fai-da-te fallisce. La progettazione, cioè decidere che cosa costruire e che cosa no, prima di scrivere una riga. L’analisi, cioè capire il processo del cliente meglio di quanto lo capisca il cliente, che è la parte che nessun modello fa da solo perché nessun modello sa quale domanda porre. L’implementazione, cioè costruire in modo che il sistema regga la prima modifica seria e la centesima. La sicurezza, cioè leggere e verificare ciò che viene generato, dato che quasi metà di quel codice arriva con una falla nota. E la privacy, cioè progettare dal primo giorno dove i dati stanno, chi li tocca e perché, invece di scoprirlo alla prima richiesta di un’autorità.

È su questa forma che si sta costruendo AYXZA. Non ha i costi del vecchio modello perché non ne ha la struttura; non ha i rischi del vibe coding perché non ne condivide la premessa, e cioè che il software sia finito quando sembra funzionare. È probabile che nei prossimi anni la distinzione fra chi costruisce e chi assembla diventi la linea di demarcazione più importante del settore, molto più di quella fra grandi e piccoli. Le aziende che compreranno software lo faranno, sempre più, sulla base di una domanda sola: chi risponde quando si rompe. Lo sconto, in quel momento, sarà già stato speso.

https://www.ayxza.com/