La maggior parte delle aziende pensa di costruire una software factory. In realtà, stanno solo spedendo bug più velocemente

Le factory industriali hanno cambiato radicalmente la produzione fisica: maggiore output, costi ridotti, velocità senza precedenti. Ora, un cambiamento simile sta avvenendo nel software. I Large Language Models (LLM) hanno abbassato la soglia per scrivere codice, incrementato l’output individuale e spinto le organizzazioni a considerare lo sviluppo del software come un sistema produttivo. La standardizzazione del ciclo di vita dello sviluppo software e le pratiche CI/CD consolidate non sono in grado di sostenere questa pressione. Ecco dove entra in gioco l’idea di una "software factory", un concetto che, come per le factory fisiche, richiede molto di più della semplice velocità per funzionare veramente.

Come si è concretizzata l’idea della software factory

Oltre l’anno scorso, il discorso ha preso forma con testi come "The Era of the Software Factory" di Luca Rossi, che ha sostenuto con forza l’idea che l’intelligenza artificiale non sta solo accelerando la scrittura del codice, ma sta completamente ridefinendo il sistema produttivo del software. Il concetto può assumere diverse interpretazioni: un insieme di agenti di codifica e file di competenze; una maggiore velocità in CI/CD; una revisione migliorata; maggiore automazione nel delivery del software. Tuttavia, non è un mero insieme di strumenti o di modelli; la software factory richiede una piattaforma che definisce come il lavoro fluisce, come il codice viene prodotto, revisionato, testato, tracciato, distribuito e corretto in caso di problemi.

Perché questo sta succedendo oggi?

Ci sono diversi fattori interagenti. Da sempre, le aziende desiderano più software di quanto i programmatori possano produrre. Strumenti come Excel esistono per colmare questa lacuna. Inoltre, l’AI ha abbassato drasticamente la soglia per generare codice, e questo è il punto su cui concentrarsi principalmente. La creazione di codice è più facile oggi, anche se non sempre è più economica o migliore, come rivelano numerose aziende preoccupate per i costi di utilizzo di grandi modelli linguistici. Inoltre, un singolo sviluppatore può oggi produrre molto di più di quanto potesse fare alcuni anni fa, cambiando il collo di bottiglia: da “A che velocità qualcuno può scriverlo?” a “Dovrebbe essere scritto?”.

La domanda più rilevante è oggi, però: Possiamo creare prodotti digitali sostenibili e affidabili o stiamo solo producendo più tecnologia inutile e piena di bug, più velocemente che mai? Ecco dove risiede il rischio.

I pericoli della software factory moderna

Sebbene sembri positivo — dopo tutto, le factory industriali hanno reso i processi di produzione più veloci, economici, accessibili e scalabili — esistono sempre compromessi. Maggiore è la velocità di produzione, maggiore è il potenziale per errori. Il ritmo attuale di generazione di codice è industriale: perfino piccole organizzazioni possono improvvisamente accumulare codice simile a quello delle grandi aziende tecnologiche di un decennio fa. La realtà mostra problemi crescenti. Secondo Faros AI, i tassi di incidenti per pull request sono aumentati del 242,7% e i bug per sviluppatore salgono dell’54%. La ricerca DORA di Google ha rivelato che un maggiore utilizzo di AI è associato a una peggior stabilità nel deployment.

Il rischio di evoluzione caotica

Da un punto di vista operativo, le aziende si trovano spesso a dover gestire problemi che si accumulano con l’evoluzione rapida dei progetti. Ho lavorato ultimamente in due progetti in cui l’infrastructure generata dagli agenti AI stava mutando progressivamente in modo incontrollabile. Non ci sono state praticamente standard, il che ha portato, tra diversi sviluppatori, a generare stili di codice diversi quasi all’istante. Gli LLM, in risposta, iniziavano a creare varianti che non solo erano incoerenti, ma che diventavano incomprensibili nel giro di pochi mesi. A quel punto i team smettevano di capire esattamente cosa stesse succedendo nel codice.

This pattern è molto simile a quanto successo nel passato con gli strumenti “self-service”: guadagni iniziali di produttività che nascondono complessità downstream. Ecco perché la software factory non può basarsi solo sulla velocità.

I principi che rendono una software factory sostenibile

Piattaforma, non solo strumenti

Molti team introducono l’AI nei cicli di sviluppo solo perifericamente — aggiungendo un agente di revisione o file di competenza nei loro repository. Ma costruire una vera factory software richiede una piattaforma, non raccolte di strumenti. Una piattaforma fornisce un fondamento unificato dove gli strumenti condividono dati, interagiscono l’uno con l’altro e operano in un sistema coerente — standard, processi e lavoro sono connessi in maniera strutturata. Gli strumenti “a macchia d’olio” non sostituiscono una piattaforma integrata.

Riproducibilità e tracciabilità

Una piattaforma reale deve permettere di riseguire ogni esecuzione, individuare dove qualcosa è andato, e di rieseguirla. Questo è il motivo per cui gli agenti one-off non costituiscono una factory software. Il sistema deve permettere di tracciare un ID esecuzione, esaminarlo e risalire passo per passo al risultato. I macchinari a stato finito sono una scelta migliore rispetto alle semplici iterazioni cicliche per i flussi di lavoro AI: rendono molto più facile riprodurre un processo complessivo e capire cosa è accaduto in ogni fase.

Sicurezza e barriere protettive

Una factory software, come una factory fisica, non è sicura di default. Con sempre più utenti che lavorano su queste piattaforme, le misure di sicurezza e le barriere protettive sono fondamentali. Il testing e il controllo qualità devono essere integrati in modo anticipato nel processo. Cogliere i bug alle fasi iniziali riduce il costo della riparazione e limita il rischio sistemico.

Standardizzazione

A livello di azienda, ogni codice ha il suo stile. Sovrapporre strumenti AI senza standard produce un caos di stili e di modelli. La standardizzazione deve essere integrata fin dall’inizio del processo produttivo. Senza di essa, il sistema non riesce a produrre in maniera unificata e scalabile.

Qualità integrata in ogni fase

Il modello tradizionale di controllo qualità (QC) era spesso posizionato alla fine del processo produttivo: il prodotto era assemblato, testato, e corretto in seconda istanza. Toyota ha invertito questo modello inserendo il controllo qualità direttamente nel processo, educando i dipendenti a interrompere la catena di montaggio davanti a un'anomalia. Lo stesso principio deve essere applicato alla software factory: il QC deve essere integrato in ogni fase, a partire dal momento in cui si definiscono le specifiche di progetto.

Questo