Il debito tecnologico storico e l’arrivo dei LLM
Fin dagli anni ’70 il software è cresciuto in quantità e complessità, accumulando un debito tecnologico enorme. Errori di programmazione, spesso invisibili durante l’uso quotidiano, hanno causato incidenti, perdite economiche e, in alcuni casi, danni alla sicurezza delle persone. Per decenni questi difetti sono rimasti latenti, poiché le metodologie di testing erano insufficienti e le risorse limitate.
Tre anni fa, con l’avvento dei grandi modelli linguistici (LLM), è stato scoperto che è possibile analizzare i codici sorgente e identificare rapidamente probabili vulnerabilità. Il processo è semplice: si sottopone il codice a un LLM, il modello suggerisce punti di possibile errore, e un esperto umano verifica e corregge. Questa combinazione ha permesso di “pagare” parte del debito tecnologico accumulato.
Chi ha beneficiato di questa scoperta?
- I “buoni”: hanno iniziato a correggere alcuni software, migliorandone la qualità.
- I “cattivi”: hanno sfruttato gli stessi bug per creare exploit e attacchi informatici.
- Gli “cybersoldati”: hanno trasformato le vulnerabilità individuate in armi informatiche per future guerre ibride.
Il risultato è una frase sintetica: stiamo pagando oggi il debito tecnologico generato da decenni di programmazione scadente. Tuttavia, la questione è ben più complessa di quanto appaia a prima vista.
Il nuovo debito tecnologico: architettura, interfacce e “vibe coding”
Le LLM hanno introdotto una nuova moda, il vibe coding: programmare affidandosi quasi esclusivamente ai modelli linguistici, con verifiche limitate a test funzionali e quasi nessun controllo umano sul codice generato. Questo ha democratizzato la programmazione, permettendo a persone senza formazione approfondita di produrre software.
Parallelamente, i programmatori tradizionali hanno adottato lo stesso approccio, ottenendo guadagni di produttività misurati in linee di codice per programmatore per settimana. Tuttavia, la qualità del software è peggiorata sotto una luce diversa: gli errori non sono più semplici bug di singole istruzioni, ma scelte errate di architettura e di interfaccia, soprattutto dal punto di vista della sicurezza.
Esempi di nuovi tipi di debito
- Design di microservizi con dipendenze non documentate, difficili da tracciare.
- API pubbliche esposte senza adeguati controlli di autorizzazione.
- Modelli di dati flessibili ma non validati, che generano incoerenze a livello di database.
- Uso di librerie di terze parti non monitorate, vulnerabili a supply‑chain attacks.
Questi errori sono radicati nella struttura stessa del software, non più localizzabili in una singola riga di codice. Di conseguenza, anche i LLM faticano a individuarli, poiché richiedono una comprensione più ampia del contesto architetturale.
Conseguenze di un debito non individuabile
Se questi nuovi difetti non verranno risolti, si aprono scenari preoccupanti:
- Perdite economiche dovute a downtime prolungati di servizi critici.
- Violazioni della sicurezza che possono compromettere dati sensibili.
- Eventi catastrofici come il collasso di infrastrutture energetiche o di trasporto, con migliaia di vittime.
- Armi informatiche pronte all’uso in conflitti ibridi, costruite su vulnerabilità note ma non corrette.
Cassandra avverte che il nuovo debito tecnologico potrebbe essere più difficile da “pagare” perché richiede interventi a livello di redesign completo, non semplici patch. Inoltre, chi dovrà sostenere i costi? Le imprese, i contribuenti o gli utenti finali? La risposta resta incerta, ma la tendenza è una pressione crescente sui bilanci aziendali.
Riflessioni finali e raccomandazioni
Le LLM rappresentano uno strumento potente, ma non una panacea. Per mitigare il nuovo debito tecnologico è necessario:
- Introdurre revisioni architetturali periodiche, coinvolgendo esperti di sicurezza.
- Adottare policy di code review
- Limitare l’uso indiscriminato del vibe coding, garantendo che ogni generazione di codice sia supervisionata da sviluppatori esperti.
- Implementare monitoraggio continuo delle dipendenze e dei supply‑chain software.
Solo combinando l’intelligenza artificiale con pratiche tradizionali di ingegneria del software si potrà sperare di ridurre sia il debito storico sia quello emergente, evitando così scenari di crisi che potrebbero avere ripercussioni a livello globale.