Premessa. Questo articolo non intende affrontare i problemi etici e morali legati all’utilizzo di LLM (Large Language Model), come vengono chiamati i sistemi di (presunta) intelligenza artificiale e altri strumenti legati a questi sistemi. Volenti o nolenti, questi strumenti sono già stati adottati da molte persone fisiche e aziende e sarà sempre più necessario saperli usare nel proprio lavoro.

Avevo già scritto qualche commento tempo fa riguardo alla corsa all’adozione di questi strumenti da alcuni dei maggiori motori di ricerca. Qui intendo solo raccontare la mia personale esperienza nello sviluppo di un’app che utilizza un sistema di questo tipo per effettuare elaborazioni che altrimenti sarebbero estremamente complesse da realizzare. Anche per questo motivo, ho utilizzato questo sistema anche come assistente allo sviluppo dato che era la mia prima esperienza in questo tipo di sviluppo software.

Avevo cominciato a testare l’utilizzo di qualche chatbot e a creare qualche immagine già nel 2024 e solo occasionalmente li avevo trovati utili. Nel corso del tempo ho visto i progressi di questi sistemi e ho cominciato a pensare a un utilizzo più professionale. L’idea di sviluppare app universali che potessero girare sia su PC, sotto Windows e anche sotto Linux, che su dispositivi Android, MacOS e ChromeOS con i linguaggi Flutter e Dart ha cominciato a intrigarmi.

Familiarizzarsi con la sintassi di questi linguaggi non è difficile ma la filosofia dietro lo sviluppo di un’interfaccia utente in Flutter è diversa da quelle di linguaggi che avevo usato in passato. Non conoscevo gli strumenti che permettono di compiere facilmente certe operazioni complesse e dovevo installare e configurare vari strumenti per lo sviluppo sul mio desktop Linux e sul mio miniPC Windows e configurare gli strumenti Flutter per i test sul mio tablet Android. Si è trattato di altri motivi per farmi assistere da un LLM e devo dire che è molto comodo poter avere risposte rapide e precise a domande specifiche invece di cercare in mezzo a documentazione assortita che a volte non è neppure chiara.

Google offre una quota gratuita di utilizzo delle API del suo sistema Gemini perciò è stata per me quasi una scelta obbligata per condurre i primi test e per offrire a chiunque la possibilità di utilizzare le app che sfruttano quelle API senza dover pagare. Altre aziende hanno scelto di offrire API solo a pagamento perciò il supporto nelle mie app potrà essere aggiunto più avanti per chi ha le proprie chiavi di accesso per utilizzarle ma è tutto da definire.

L’esperienza di utilizzo di Gemini è agrodolce. Sicuramente la prototipazione di un’app è rapida perché in realtà basta spiegargli cosa si vuol fare e Gemini comincia a sparare blocchi di codice. Il vero problema è nel passaggio dal prototipo all’app funzionante. Chi fa sviluppo software sa che ci sono parti di un software che rivelano complessità impreviste e servono valutazioni molto attente e riflessioni per ottenere ciò che si vuole. La complessità è il nemico degli LLM! Quando Gemini deve gestire blocchi di codice oltre una certa dimensione, comincia ad allucinare. Propone un blocco di codice e subito dopo comincia a menzionare variabili diverse da quelle che ha proposto.

Un’altra fase fondamentale dello sviluppo software è il debugging. Cercare gli errori a volte è frustrante perché il flusso di eventi può essere complesso e per altri motivi. Gemini è un ottimo assistente quando si tratta di trovare ad esempio un errore di sintassi nel codice ma per il resto è un disastro! Tira a indovinare dove può essere l’errore, senza una logica.

Ho imparato presto che in certi casi Gemini non è affidabile: una mattina, si stava ormai avvicinanzo mezzogiorno quando ho avuto un problema, ho chiesto assistenza a Gemini, ho ricevuto del codice che doveva correggere l’errore, il codice ha generato altri errori, Gemini mi ha proposto altro codice che ha generato altri errori e così via finché mi sono reso conto che mi ero fatto prendere dalla frenesia di chiudere la mattina di lavoro ma affidarmi a Gemini era la scelta sbagliata.

In altri casi, Gemini ha mostrato la tendenza a comportamenti in cui afferma di semplificare oppure ottimizzare il codice o di dare priorità a una certa fase del flusso di eventi. In ogni caso, il risultato è che “dimentica” pezzi di codice. Per questo motivo, è fondamentale prestare attenzione quando si inserisce nella propria app un pezzo di codice proposto da Gemini che ne sostituisce uno funzionante! In questi casi, bisogna subito tornare indietro alla precedente versione del codice, altrimenti diventa complicato ripristinare i pezzi “perduti”. Quando sviluppo software, salvo sempre una copia di backup alla fine di ogni sessione ma quando lavoro con Gemini mi capita di salvarne una ogni volta che completo un certo blocco di codice.

Un altro “trucco” che ho imparato durante quest’esperienza è che è utile confrontare diversi approcci e diverse soluzioni per un problema chiedendo l’opinione di altri LLM per poi scegliere la soluzione migliore o una ibrida. Sia coPilot che Claude mi hanno fornito suggerimenti che in certi casi sono stati utili e migliori di quelli di Gemini. Va detto che mi è capitato di chiedere a Gemini la sua opinione su soluzioni suggerite da coPilot e Claude e Gemini ne ha ammesso la validità e le ha integrate nei propri suggerimenti. In altri casi il percorso è stato opposto, nel senso che coPilot o Claude hanno fornito soluzioni che miglioravano suggerimenti di Gemini. Mi è anche capitato di usare e mescolare suggerimenti di due iterazioni separate di Gemini.

In sostanza, combinare l’uso di LLM diversi può migliorare la qualità dello sviluppo di un software. In tutti questi casi, ho notato che l’arma vincente consiste nel riuscire a porre ai vari LLM le domande giuste. Si tratta di provare diversi LLM, anche per capire quali siano i punti di forza e i punti deboli di ognuno di essi per poterli sfruttare al meglio. Non è facile, anche perché sono situazioni che cambiano nel corso del tempo con l’evoluzione dei vari modelli.

Ho completato la versione che ho chiamato 0.1 dell’app di analisi di copertine di libri ma non è ancora pronta per essere distribuita. Il problema principale è che a volte il titolo originale di un libro in edizione italiana non è corretto perciò serve una catena di verifica per ovviare a queste allucinazioni. Servono riflessioni che vanno oltre le capacità di un LLM e nel frattempo ho cominciato a sviluppare un’app di analisi di etichette alimentari. È un’avventura per certi versi stimolante e per altri versi frustrante e chissà come andrà avanti.