Il software fa funzionare il mondo. La sua catena di produzione non se n’è ancora accorta

Due domande per l’ingegneria enterprise: il modo in cui realizziamo il software deve cambiare, e in cosa dovrebbe trasformarsi?

Negli ultimi 50 anni, una professione è rimasta sotto gli occhi di tutti: il programmatore. Ciò che questa professione produce è diventato silenziosamente ciò su cui gira tutto il resto.

È facile sottovalutare la portata del cambiamento. Nel 1980, gli Stati Uniti contavano circa 300.000 posti di lavoro nella programmazione informatica, secondo i dati del Bureau of Labor Statistics riportati da Fortune, 2025, e le macchine per cui queste persone scrivevano codice si trovavano in stanze che il pubblico non entrava quasi mai a vedere. Un’auto di quell’epoca disponeva di un chip a funzione singola per sincronizzare le candele.

Oggi circa 6 miliardi di persone, pari a circa il 74% dell’umanità, sono online, secondo l’ITU, 2025. La spesa IT mondiale è destinata a raggiungere i 6.370 miliardi di dollari quest’anno, di cui oltre 1.470 miliardi di dollari solo per il software, secondo Gartner, 2026. In tutto il mondo, circa 36,5 milioni di persone programmano professionalmente, mentre altri 10 milioni circa lo fanno come hobby, studenti o competenza secondaria, secondo SlashData, 2025. E oggi quell’auto viene consegnata con circa 100 milioni di righe di codice distribuite su più di cento centraline, una stima del 2021 che oggi è quasi certamente ancora più alta.

A un certo punto, il software ha smesso di essere una categoria di prodotto ed è diventato il mezzo attraverso cui le persone accedono al proprio denaro, alla propria assistenza sanitaria e al proprio governo. Nessuno può sottrarsi. E con l’AI, che è essa stessa software e un motore per produrne altro, la curva sta diventando più ripida, non più piatta.

Questo solleva due domande. La prima è ovvia. La seconda è quella che merita il vostro tempo.

Il modo in cui produciamo software deve cambiare?

Sì. Non perché gli strumenti siano diventati migliori, ma perché sono cambiate le responsabilità e perché collegare uno strumento veloce a un processo lento crea nuovi problemi.

Una donna ha presentato la propria dichiarazione dei redditi attraverso un nuovo portale governativo la scorsa primavera. È andato in crash due volte. Il messaggio di errore attribuiva la causa a un “traffico elevato”. Non era il traffico. L’agenzia aveva distribuito il codice più velocemente di quanto chiunque potesse testarlo o revisionarlo. Ha ripresentato la dichiarazione per posta. Nessuno ha definito questo un fallimento. Le pull request continuavano a essere conteggiate come progresso.

Quel fallimento è strutturale, non accidentale. I requisiti vengono scritti affinché gli esseri umani possano leggerli lentamente. I passaggi di revisione sono dimensionati sul volume prodotto da un team umano durante uno sprint. I piani di test presuppongono che una persona abbia scritto il codice e che un’altra lo legga attentamente prima della distribuzione. Aggiungendo un assistente di coding AI a questa pipeline non hai eliminato il vincolo, lo hai semplicemente spostato. Il codice ora arriva più velocemente di quanto revisione, test, approvazione della sicurezza e autorizzazione al deployment riescano ad assorbirlo. Il cittadino non vede nessuna di queste fasi. Vede il timeout.

I numeri dicono la stessa cosa. Secondo Gartner, 2025, le aziende che applicano l’AI solo alla generazione del codice stanno ottenendo circa il 10% di aumento della produttività a livello di sistema, mentre i team che applicano l’AI in modo coerente lungo l’intero ciclo di vita, dai requisiti alle operations, dovrebbero raggiungere il 25-30% entro il 2028. L’adozione non è mai stata la parte difficile: secondo Gartner, 2025, il 90% degli ingegneri enterprise dovrebbe utilizzare assistenti di coding AI entro il 2028, rispetto a meno del 14% nel 2024.

La produttività degli sviluppatori e l’esperienza del cittadino non sono la stessa misura. Una conta l’output per persona. L’altra conta se una persona reale ha ottenuto ciò per cui era venuta. Un team può migliorare il primo numero per un anno intero e vedere le lamentele cambiare a malapena.

In cosa dovrebbe trasformarsi?

Non in un altro assistente di coding. Il lavoro consiste nel governare ciò che gli agenti possono fare una volta che si trovano già all’interno della pipeline. Quattro mosse, in quest’ordine.

1. Definire il confine prima che l’agente tocchi il repository. Cosa è autorizzato a modificare, chi revisiona ciò che produce e come viene registrata quella decisione. La maggior parte delle aziende non ha preso nessuna di queste decisioni. Ha attivato gli strumenti e sperato che il processo si mettesse al passo.
2. Ordinare la revisione in base al rischio, non all’abitudine. Le modifiche di routine e a basso impatto ricevono una validazione automatizzata. Qualsiasi cosa riguardi i dati di una persona, un pagamento o un confine di compliance mantiene una convalida umana con una motivazione registrata. Questo non significa revisionare tutto manualmente né non revisionare nulla: significa riprogettare realmente il processo.
3. Mantenere una tracciabilità che sopravviva alla domanda difficile sei mesi dopo. Cosa ha modificato l’agente, perché e sotto quale autorità. La spiegabilità smette di essere un tema di ricerca nel momento in cui un’autorità di regolamentazione, un revisore o un cliente pone la domanda.
4. Misurare la persona dall’altra parte. Individuare dove il lavoro generato dall’AI rimane effettivamente bloccato, non dove procede più velocemente. La metrica che conta è se è riuscita a presentare la dichiarazione dei redditi.

“Richiede ai responsabili dell’ingegneria del software di ripensare le proprie strategie”, è così che Joachim Herschmann, VP Analyst di Gartner, ha descritto ciò che lo sviluppo basato sugli LLM richiede oggi alle organizzazioni di engineering.

È questo il livello attorno al quale è costruita la pratica di Calsoft per l’ingegneria di sistemi intelligenti su larga scala: sviluppo di AI agentica con autonomia controllata, non agenti che operano sui sistemi di produzione senza un confine definito. La governance non è la parte che le aziende aggiungono dopo che l’SDLC AI-native funziona. È la parte che protegge la persona dall’altra parte della transazione.

Nel 1980, l’output di un programmatore era un prodotto. Oggi è un’infrastruttura dalla quale 6 miliardi di persone non possono prescindere. Una suite di test più veloce non conta se il cittadino continua a incontrare un modulo non funzionante. Una pipeline più veloce non conta se nessuno può spiegare perché la sua dichiarazione ha fallito due volte.

Le aziende che riusciranno a farlo non saranno quelle con più codice generato dall’AI entro dicembre. Saranno quelle i cui cittadini e clienti smetteranno di notare il software, semplicemente perché funzionerà.

FAQs

Perché la produzione del software deve essere ristrutturata ora?
Perché è cambiata la dipendenza. Il software è passato dall’essere una categoria di prodotto a essere il mezzo attraverso cui miliardi di persone accedono al denaro, all’assistenza sanitaria e al governo. L’AI ora genera codice più velocemente di quanto revisione, test, approvazione della sicurezza e autorizzazione al deployment possano assorbirlo, mentre tutti questi processi sono ancora dimensionati per i volumi precedenti all’AI. Il vincolo si è spostato a valle; il processo non è cambiato.

Cos’è un SDLC AI-native?
Un ciclo di vita dello sviluppo software ricostruito attorno ad agenti AI che lavorano in ogni fase, dai requisiti alle operations, anziché un assistente aggiunto a un processo precedente all’AI. Sostituisce i workflow sequenziali e basati sul ritmo umano con revisioni basate sul rischio e validazione continua, in modo che la persona che utilizza il software incontri meno errori invece di ricevere semplicemente codice più velocemente.

Come dovrebbero ristrutturare le aziende l’SDLC per l’AI?
Definire i confini degli agenti prima che tocchino il repository. Classificare le revisioni in base al rischio: validazione automatizzata per le modifiche di routine, approvazione umana con audit trail per qualsiasi cosa riguardi dati, pagamenti o compliance. Mantenere una tracciabilità che regga anche dopo mesi e misurare i risultati per il cliente, non l’output degli sviluppatori.