Pare che la produzione di software tramite l'utilizzo di modelli linguistici sia in grande sviluppo, no, in tumultuosa crescita; anzi, sia ormai divenuta inarrestabile e indispensabile. Definita inizialmente come Vibe Coding, è stata dapprima presentata come lasciapassare per chiunque volesse sviluppare software senza avere competenze di informatica e programmazione. Poi, quando la cosa ha iniziato a sembrare l'idiozia che è, si sono invece osannati i vantaggi economici che l'impiego di questi metodi da parte di veri programmatori avrebbe consentito alle aziende, aumentando la produttività dei programmatori esistenti; non è chiaro se dei senior che potevano fare a meno di una squadra di junior, oppure degli junior, che potevano scrivere software a livello di quello scritto dai senior. Comunque certamente consentendo di tagliare posti di lavoro, presenti e futuri, facendo quindi scattare quell'automatismo che fa salire subito la quotazione in borsa di qualsiasi azienda.

Alla fine, hanno iniziato a essere contrastanti i pareri di chi aveva provato davvero a usare i Grandi Modelli Linguistici (Large Language Models o LLM) in ambienti di produzione riguardo il risparmio di tempo e la qualità del codice prodotto; i primi dubbi hanno iniziato a essere presi sul serio. Lo sforzo di inserire a tutti i costi funzionalità guidate da LLM, comune a tutte le applicazioni commerciali, ha saturato di LLM anche tutti gli ambienti di sviluppo software. E quindi tutti i programmatori, che lo volessero o no, si sono trovati ad avere l'indice sul grilletto di una nuova arma. 

Alla vostra profetessa preferita non è dato sapere quanto l'utilizzo di questi ausili sia ufficialmente promosso, o addirittura richiesto, all'interno dei team di sviluppo aziendali. Nemmeno quanto sia il loro effettivo utilizzo, e se sia piuttosto iniziativa dei singoli programmatori pigri o in cerca di scorciatoie. E neanche quanto il suo uso nella scrittura di nuovo software sia percentualmente diffuso. Proprio dall'alto di questa piramide di ignoranza, la vostra profetessa preferita, il cui alter ego ha compiuto un lungo percorso proprio nello sviluppo reale di software nelle aziende, ritiene di poter esporre un parere informato, anzi di additare un vero pericolo che tuttavia pare non sia degno di discussione neppure tra gli addetti ai lavori... proprio come non lo fu un certo cavallo di legno. Il problema è: quanto debito tecnologico stiamo accumulando e accumuleremo nelle applicazioni e nelle infrastrutture che mandano avanti la civiltà su questo pianeta. 

"Debito tecnologico" è il termine elegante che viene usato quando non si può dire «la moltitudine di bug nascosti nel software di scarsissima qualità che viene normalmente prodotto dall'industria del software».  Si sarebbero potuti utilizzare anche termini scatologici, davvero inadatti a queste pagine. E poiché qui siamo tra signori, continueremo anche se con fatica a usare solo il termine debito tecnologico. Nel suo sempre più rapido affidarsi alle nuove tecnologie, ognuno di noi, che lo sappia o no, che ne sia cosciente o no, si affida continuamente a sistemi hardware/software che possono tradirlo. E non stiamo ancora parlando delle parole e delle istruzioni messe in fila a caso da un LLM, ma di normali programmi, sviluppati da esseri umani con metodologie più o meno adeguate e che, contenendo errori dovuti a uno sviluppo software inadeguato, malfunzionano senza preavviso.

Consigliamo la lettura di:

Cowork rivoluziona il desktop: la IA di Anthropic legge, crea e modifica i tuoi ...

Google Antigravity cancella un intero drive: la IA si scusa, ma i dati sono pers...

Anthropic: il mestiere del programmatore è al tramonto. La IA ormai sa scri...

Therac-25, 40 anni dopo. Il bug software causò tre morti e cambiò per ...

Dal cellulare che si pianta fino alla catastrofe planetaria per un collasso sistemico di reti informatiche e di distribuzione. Dall'azienda che fallisce per una procedura di backup errata fino al paziente oncologico a cui la macchina per radioterapia fa un buco nella testa o nel petto. Tutte storie vere e già viste, accadute senza bisogno di ricorrere agli LLM per scrivere codice. Solo alla catastrofe planetaria ancora non siamo mai arrivati, ma eventi come l'affaire Maersk dovrebbero ricordarci quanto ci si può andar vicino, ed essere l'esempio pratico di quello che potrebbe succedere su scala molto più grande. Ma terminiamo questa geremiade che, per i bene informati, non contiene alcuna novità.

Il debito tecnologico rappresentato dalla massa di bug presenti nel software attuale esiste davvero; alcuni di questi bug causeranno, domani come ieri, il solito numero di danni e vittime. Cosa potrebbe succedere se in pochi anni la maggior parte del codice nuovo o modificato fosse scritto da o tramite gli LLM? Da dei programmi che non hanno nessun vincolo di realtà, ma solo di verosimiglianza. Da macchine apparentemente molto brave a scrivere sorgenti in maniera bella e credibile, grazie al fatto che i linguaggi di programmazione non sono complessi linguaggi naturali, ma linguaggi formali, dotati di grammatiche forti, chiuse e complete, e anche al fatto che possono copiare a man bassa da Github e dagli altri repository di codice con cui sono state addestrate. Che errori possono essere generati da questo nuovo modo di sviluppare il software? È banale chiedersi se saranno di più o di meno di quelli che sarebbero stati prodotti dalle modalità di sviluppo attuali. 

Ma prevedere la quantità di errori è materia che interessa prevalentemente i consigli di amministrazione, che devono valutare l'ammontare dei danni che saranno chiamati a risarcire, e il costo delle relative polizze di assicurazione. La maggiore o minore dimensione finanziaria del debito tecnologico che verrà così accumulato non è il vero problema, secondo Cassandra. La domanda che preoccupa Cassandra, e che a suo parere dovrebbe essere fatta per prima, è non quanto sbaglieranno i programmi generati usando gli LLM, ma come. Che tipo di errori saranno contenuti nel codice da loro generato, o generato con il loro ausilio. Saranno errori simili a quelli prodotti dagli umani, quasi sempre derivanti da un uso malaccorto delle primitive dei linguaggi di programmazione, o piuttosto errori del tutto diversi, derivanti dalla non comprensione da parte degli LLM delle specifiche tecniche, del codice esistente e dei prompt?

Ti raccomandiamo anche:

Possiamo vivere con computer che sbagliano?

Il BASIC 6502 di Microsoft diventa open source: un'eredità che ha plasm...

Le IA vendute come oracoli sono solo fuffa: ecco perché

La bolla finanziaria degli LLM

Sembrerebbe ragionevole che il codice generato tramite LLM possa contenere più facilmente errori insidiosi di concetto piuttosto che di programmazione malaccorta, visto che il codice viene scritto in totale mancanza di comprensione, e senza nessun vincolo di realtà. Questo potrebbe cambiare completamente la tipologia di debito tecnologico che accumuliamo, passando da errori che conosciamo e con cui abbiamo imparato a convivere ad altri che sono ignoti all'attuale sistema immunitario dell'industria del software. Non avremmo software che contiengono normali errori che portano a malfunzionamenti e a deviazioni dal comportamento atteso, ma software i cui stessi algoritmi possono essere errati in un modo sottile, che non sarebbe evidenziabile con gli odierni strumenti di programmazione. 

Un software i cui algoritmi non siano affidabili ma sottilmente difformi dalle specifiche potrebbe malfunzionare in maniera inusuale, non semplicemente fallendo nel suo compito ma facendo cose diverse e impreviste. Per questo motivo, in fondo al lungo elenco di problemi tecnici e sociali che l'utilizzo forzato di LLM senz'altro causerà o potrebbe causare, Cassandra suggerisce di aggiungere anche questo.

Non perderti anche:

Gli LLM e la Legge Zero dell'Informatica

Uomo contro macchina: programmatore batte IA in una sfida lunga 10 ore

Tutti sono entusiasti. Cosa mai potrebbe andare storto?

Se ci sono errori o vulnerabilità, sono guai seri

Non perderti anche:

Si riducono tempi e costi, e tutto sembra funzionare

Abbandonarsi alle vibrazioni e programmare senza toccare la tastiera

Vibe coding: creare programmi senza saper programmare

Il giorno che la IA si rifiutò di eseguire un comando