AI generativa e sviluppo software: l’esperienza e i consigli di DXC

Non c’è sviluppatore o azienda di software che non stia facendo i conti con la IA generativa e la sua fenomenale capacità di scrivere, correggere, documentare codice o tradurre software da un linguaggio all’altro. Oltre agli indubbi benefici, ciascuno sta però valutando anche i rischi e pianificando un’adozione che sia efficiente ma anche sicura e conforme con i requisiti di governance della proprietà intellettuale.

Per capire come le grandi aziende di tecnologia stanno affrontando l’argomento, e ricavarne indicazioni utili per tutte le aziende software, abbiamo intervistato a riguardo Remo Dentato, Applications Service Line Manager di DXC Technology.

Laureato in ingegneria elettronica e informatica, Dentato ha alternato negli ultimi decenni l’esperienza nello sviluppo software enterprise e la partecipazione alla comunità open source ed è oggi responsabile dello sviluppo applicativo in una divisione che conta circa 900 persone tra Milano, Roma e Bari, composta da Sviluppatori, Designer, Project Manager, Business Analyst e Software Architect.

Di questi temi ha parlato di recente insieme al collega Luka Kenno in una sessione della conferenza Codemotion a Milano.

La IA generativa nello sviluppo software

Remo Dentato, Applications Service Line Manager di DXC Technology

Andiamo con lui subito al sodo, chiedendogli se, nello sviluppo software, la IA generativa funziona davvero.

“La vicinanza con il linguaggio naturale permette di immaginare automazioni e accelerazioni fino a poco fa impossibili. La prima cosa che viene in mente è la generazione automatica del codice: puoi descrivere quel che ti interessa e lui genera codice nel linguaggio stabilito”, ci dice Dentato, che però poi specifica che nella realtà dei fatti, però, ci si trova di fronte a diversi limiti:

• il codice non è quasi mai immediatamente utilizzabile
• contiene dei bug
• fa uso di librerie obsolete
• è efficace con casi d’uso molto diffusi, ma non altrettanto con situazioni particolari e framework proprietari

L’ultimo punto è particolarmente importante per DXC, che si trova spesso a lavorare in aziende che hanno applicazioni proprietarie, anche molto vecchie, che devono essere aggiornate o integrate a nuovi sistemi.

“Sappiamo che un LLM funziona predicendo la parola successiva in un discorso, con una base statistica, e funziona quindi bene se ha visto numerosi esempi nello stesso contesto, ma non è altrettando efficace se deve adattarsi a un codice proprietario, che non compare nei suoi dati di addestramento, e rispondere a requisiti molto specifici”, spiega.

Il processo è più importante del risultato

Detto ciò, secondo Dentato, nel processo di successive interazioni, precisando, correggendo e aggiungendo contesto al modello linguistico in modo che produca un risultato utile, risiede gran parte del valore che la IA generativa può apportare a un team di sviluppo.

Nello sviluppo è nota la pratica del “rubber ducking”: lo spiegare un problema di programmazione a una paperella di gomma, o un altro pupazzetto inanimato che abita la scrivania degli sviluppatori, in modo da essere costretti a sviscerarne la logica e tradurla in istruzioni chiare.

I pupazzetti sulle scrivanie degli sviluppatori non sono solo decorativi: molti li usano per spiegare il problema da risolvere, in modo da inquadrarlo al meglio.

Secondo Dentato, la IA generativa permette di elevare questa pratica a un livello successivo, il “rubber grokking” (to grok nel gergo degli sviluppatori significa aver completamente sviscerato e compreso un problema).

“Le IA non si programmano, ma si guidano, con continue correzioni di rotta. Il vero valore non è nel contenuto, ma nel processo che ha portato a generare quel contenuto, che ti ha messo nelle condizioni di inquadrarlo e comprenderlo a fondo. A volte come risultato hai anche un codice utilizzabile, ma il vero valore è il processo che ti ha portato lì”, spiega.

Una risorsa per i compiti accessori allo sviluppo

Secondo Dentato, in un team di sviluppo la IA generativa è utile anche e soprattutto per svolgere una serie di compiti che vanno al di là della mera generazione di codice, “dal project management alla generazione di diagrammi e schemi che possono essere utili ai business analyst che devono dialogare con il cliente e rappresentare le informazioni in modo veloce, o per fare un’analisi delle note di un meeting da mandare in produzione, facendogliele prima analizzare alla ricerca di incongruenze o ambiguità nelle richieste”.

Ottimi risultati si sono avuti anche in altri compiti accessori, come la stesura della documentazione, il controllo della coerenza o la verifica della sicurezza del codice.

Un aspetto interessante è che, se nella documentazione emergono incongruenze rispetto a ciò che ci si aspetta, lo sviluppatore è costretto a capire dove stia l’errore: è sbagliata la documentazione o è sbagliato il codice? Ed è sbagliato perché le richieste non erano precise? “Interagendo in questa nuova forma con il modello alla ricerca dell’errore, uno sviluppatore anche junior può quindi imparare molte cose”, dice Dentato.

La questione della proprietà intellettuale

Nell’utilizzo professionale dei modelli linguistici ci sono due preoccupazioni opposte che riguardano la proprietà intellettuale: il rischio di utilizzare inconsapevolmente materiale protetto da copyright, e di doverne quindi subire conseguenze legali e di immagine, e il rischio che i nostri contenuti vengano usati per addestrare il modello e finiscano poi nell’output di qualche altro utente, che si ritroverebbe nel primo caso.

“In progetti enterprise come i nostri non vedo il rischio di incorporare codice proprietario, perché nella maggior parte dei casi partiamo da codice che è già del cliente, che il modello non può avere mai visto prima, per fare codice accessorio. Il modello d’uso è così lontano che il problema non si pone.

Detto ciò, il problema esiste. Prima di essere messo in produzione, il codice deve essere sottoposto a molti controlli e scrutini. Se una porzione di codice ha uno stile diverso e completamente avulso dal resto, dovrà essere scrutinato per bene”, avverte Dentato.

Per quanto riguarda la possibilità che la proprietà intellettuale dell’azienda venga fagocitata dal modello, DXC utilizza solo GPT4 erogato su una istanza proprietaria, con provider che offrono garanzie di privacy e governance dei dati. A tutti i dipendenti è vietato usare ChatGPT o altri modelli “consumer” per motivi di lavoro.

A meno di compiti molto specifici, secondo Dentato al momento non vale invece la pena di prendere in considerazione la possibilità di utilizzare un modello più limitato, come Llama2 o Mistral, sulla propria infrastruttura. Se è vero che, con le sue dimensioni, GPT4 appare sproporzionatamente grande per essere usato solo per lo sviluppo, e che è possibile addestrare un modello open source per affinarlo alle proprie esigenze specifiche, la possibilità che alcuni compiti richiedano un contesto più ampio che solo un modello davvero “large” può fornire, non è affatto remota. Inoltre, è necessario farsi carico del training e fine tuning del modello.

Generative AI: i consigli per le aziende software

Come dovrebbero quindi orientarsi le aziende che operano nello sviluppo software? Visto il ritmo con cui arrivano le novità in questo campo, conviene saltare subito a bordo, investendo tempo e denaro, o attendere che venga rilasciata una soluzione che risponde alle proprie esigenze?

Dentato suggerisce di dividere nettamente due fasi:

Un momento esplorativo, in cui si fanno test per “prendere le misure” e fare esperimenti

Un momento operativo, in cui si utilizza la IA per risolvere un problema concreto e specifico

“C’è il rischio che gli LLM diventino soluzioni in cerca di un problema. Bisogna invece partire dall’esigenza specifica che si ha e dal valore che si vuole ottenere. Questo non è un compito banale, perché come dicevo il valore potrebbe non risiedere nella generazione del codice. I modelli possono scrivere efficacemente codice generico e che si usa in software ad ampia diffusione, o per casi ben noti. CodeWhisperer va benissimo per scrivere codice per la infrastruttura AWS, ma che chiunque potrebbe scrivere. Non saranno questi strumenti l’elemento differenziante, ma la capacità di analizzare problemi specifici e complessi e tradurre questa analisi in istruzioni per la IA. Continueremo a scrivere codice, ma non sarà lo stesso tipo di codice”.