Benvenuto benvenuto, io sono Filippo Starozzi e stai ascoltando Avvocati Bank Compendium.

Compenium è un podcast in cui parlo delle mie esperienze quotidiane con la tecnologia, in particolare con quella Apple.

Compendium fa parte del network Runtime Radio la Radio Geek, questa è la puntata 83, nella quale ti parlerò delle mie tecniche di sviluppo di applicazioni con l'ausilio di intelligenza artificiale.

Ma prima sigla, alcune comunicazioni di servizio.

Allora, siamo sempre senza registrazione su YouTube.

Dubito che nel periodo estivo sarà possibile, anche perché adesso se riesco, cercherò di mettermi avanti appunto per non trovarmi in difficoltà, ma comunque, sì, difficilmente riuscirò a farlo con dirette su YouTube.

Quindi probabilmente se ne parla a settembre luglio caldo permettendo, e quindi tutta la gestione, diciamo, delle stanze dell'area condizionata, ho intenzione di fare delle nuove office hour, probabilmente la parte audio di questa office hour verrà inserito poi nel palinsesto di compendium.

Sempre su argomento office hour, sostanzialmente.

Non mi ricordo la settimana scorsa, comunque, mentre registro, sto registrando il 24 giugno, ho registrato un intero office hour, ero anche molto soddisfatto.

Peccato che avendo cambiato il microfono, non ho in OBS, non ho cambiato il microfono, e quindi sostanzialmente non ho registrato l'audio.

Non avendo guardato neanche i commenti, me ne sono accorto solo a finire la registrazione.

Complimenti a me stesso.

Se tutto va bene, cercherò di rifare per la terza volta questo office hour perché ci tenevo a completare diciamo il ciclo, e soprattutto effettivamente a poter avere poi come riferimento queste cose.

Comunque, vabbè, capita, ti segnalo inoltre.

Che a luglio, se tutto va come dovrebbe andare, inizieremo la registrazione delle nuove puntate del podcast 2 che faccio con l'amico Roberto Marin.

Quindi ti suggerisco di iscriverti al canale YouTube di A2 se vuoi vederli in anteprima in diretto perché altrimenti le puntate verranno poi pubblicate da settembre invece in versione audio, le dirette su YouTube comunque saranno solo audio perché tendenzialmente Roberto dei problemi di linea quindi il video diventa complicato.

Per quanto riguarda poi invece alcune ultime comunicazioni di servizio che ti lascio così, ne parlerò probabilmente più in dettaglio in articoli: sto facendo tutta una serie di beta test sulle nuove versioni di Mac e così via, ma ti segnalo che recentemente, grazie sempre all'ausilio di intelligenza artificiale, grazie al fatto che sostanzialmente mi hanno dato il codice sorgente di SLPCT, sono riuscito a generare la versione di SLPCT per Arma.

Attualmente SLPCT è solo per Intel e utilizza Rosetta 2 nel caso specifico per funzionare su Mac Arm.

Posto che da MECOS 2028, cioè settembre 2027 per intenderci, le app Intel non saranno più compatibili e non ci sarà neanche più Rosetta 2, era necessario fare questo.

Uno dei passaggi, diciamo, era questo.

Poi, ovviamente, diciamo cosa succederà da qui a un anno, non si sa.

Io ho dato tutte le informazioni che mi ha dato poi l'intelligenza artificiale agli sviluppatori di SLPCT.

Vedremo se ci sono novità, diciamo, te le darò.

Tuttavia, in generale, sappi che attualmente esiste una versione di SLPCT per AR, quindi ci sono buone speranze che non ci siano problemi appunto a settembre 2027.

A fronte di tutto questo, ovviamente l'appetito viene mangiando come al solito, e siccome sono ancora, sto finendo a dire la verità, il mese di abbonamento pro credo che sia, di Cia GPT, che è la versione Max sostanzialmente di quella di Antropic.

Mi sono divertito per pura curiosità e probabilmente non ne nascerà nulla di concreto, anche perché effettivamente come applicazione è un'applicazione decisamente complicata e che richiede comunque uno sviluppatore più che altro che la mantenga.

Ma insomma, ci sto giocando, ho sviluppato sostanzialmente un'app in Swift, quindi per Mac sostanzialmente tipo SLPCT, l'ho chiamata provvisoriamente MACT, ma il nome è un programma.

La cosa interessante di questo sistema è che questa applicazione nasce come applicazione nativa di Nime Cos, quindi lo stack è relativamente complesso.

Ma la cosa carina, secondo me e appunto, se avrò modo, ne parlerò più avanti, è che appunto avendo la sviluppata io e sapendo come funziona un po' tutto, diciamo, sono riuscito a credo spero: creare una interfaccia utente molto molto carina, soprattutto adesso la parte iniziale di verifica dell'installazione di tutti i software che servono.

E tra l'altro, siccome poi anche qui c'è una versione nuova di SLPCT che risolve il problema di dover sempre installare anche la versione Java, anche qui ho usato questo sistema per cui teoricamente l'applicazione, una volta che si è installato, sostanzialmente OpenSC e il middleware di Bit 4D, funziona senza problemi e fa un check del fatto che sia stata installata questa roba e quindi con i link per andare a scaricare tutto.

Insomma, diciamo che il mio approccio a questa applicazione, a prescindere che è nativa Mac e così via, era quella anche di renderla sostanzialmente un esercizio di stile per renderla, diciamo, il più user friendly possibile della vicenda.

Bene, fatte tutte queste premesse, passiamo invece all'argomento di questa puntata.

Questa puntata sostanzialmente nasce, diciamo, quella precedente: l'82 dove ho spiegato bene o male come funziona questo sistema Anoni MCP, che è un Model Context Protocol per diciamo permettere la comunicazione da cartelle, diciamo quindi da documenti, ai large language model e così via.

Non ti sto a ripetere tutto oggi.

Lo scopo diciamo di questa puntata che mi sembrava abbastanza utile, perché poi appunto in questo periodo ci sto giocando molto proprio perché questo abbonamento mensile ha avanzato e quindi sto facendo cose, probabilmente troppe cose, ma questo è un altro discorso.

Sarà oggetto eventualmente una puntata anche qui a parte sul fatto di cosa ti permette di fare l'intelligenza artificiale e quante opzioni ti dà, e quindi la complessità anche di quello che sto facendo.

Perché ovviamente, come avrei capito, ho sostanzialmente interrotto lo sviluppo di Anoni MCP per fare altre cose.

Mi sto perdendo i mille rivoli e questo non è un bene, ma farò degli approfondimenti del caso.

Comunque, anche qui trovi nella notte dell'episodio, se non sai cos'è Anonimo MCP e non hai ascoltato la puntata 82, troverai tutto.

Questa puntata, però, è centrata, mettiamola in questi termini, su come ho iniziato a imparare, tra virgolette, sviluppare con l'ausilio dell'intelligenza artificiale.

La premessa logica è sempre una sola, ovvero che appunto non sono uno sviluppatore, faccio l'avvocato, mi diletto in queste cose, ho un minimo di conoscenza diciamo come funzionano e come viene gestita sottofondo, diciamo un'applicazione, alcune cose le so, tantissime altre cose non le so, nella sostanza, utilizzo l'intelligenza artificiale per scrivere completamente tutto il codice, tendenzialmente io facciamo io mi ritengo il beta test dell'applicazione, diciamo, il product manager, si chiama, cioè quello che ha la visione del prodotto che cerca di sviluppare un prodotto, ha i programmatori che devono seguire le sue istruzioni.

Quindi, questo è il mio approccio alla vita.

Credo che questo possa diventare un approccio anche valido per ovviamente applicazioni a uso interno o comunque applicazioni semplici, anche non solo per l'avvocato smanettone, diciamo in generale per gli avvocati, per semplificarsi la vita e per creare piccoli utiliti, chiamiamoli in questi termini, per fare cose.

L'ho detto nella puntata scorsa, lo ripeto velocemente, uno dei motivi per cui poi mi sono messo a fare altro sostanzialmente è che Anoni MCP viola una delle regole che io ritengo siano fondamentali per fare queste cose in ambito chiamiamo così legale o paralegale e così via, ovvero lo sviluppo di applicazioni che non vanno mai online.

Perché?

Perché ovviamente se un'applicazione va online, fa cose, e in questo caso, sostanzialmente i dati, diciamo anonimizzati o pseudonimizzati e così via, comunque vengono poi traghettati su un large language mode, che, per forza di cose, se non è locale, appunto, ne ho accennato una puntata scorsa, sul fatto anche che questa sia, secondo me, la soluzione veramente corretta, sul fatto che prima o poi ci proverò a gestire tutto in locale, ma mi serve una macchina totalmente diversa.

Questa applicazione va online e viola sostanzialmente quella che è per me la regola d'oro: cioè non avendo idea di come funzionano le cose, è importante evitare di creare strumenti online, ma devono essere tutti strumenti locali, locali che non facciano chiamate all'esterno, di modo che posto tutti i problemi di riservatezza e così via, della professione e di molte altre professioni, oltre a quelle dell'avvocato, diciamo, il grosso dei problemi non si dovrebbe porre, mettiamole in questi termini.

Volendo, bisognerebbe anche sviluppare questa applicazione su un computer, diciamo chiamiamo così pulito, cioè dove non ci sono dati critici, dove l'intelligenza artificiale non può fare potenzialmente danni, lo do per scontato, ma lo ripeto per sicurezza.

Come ti dicevo nella scorsa puntata e come ti ho raccontato anche adesso.

Appunto, sono abbastanza installo e mi sono di fatto fermato allo stato attuale.

Probabilmente dico probabilmente, ma ancora qui è tutto da decidere, mettiamole in questi termini.

Ragionerò se nei mesi di luglio e agosto, dove dovrei avere più tempo.

Se prolungare almeno di un mese o due, l'abbonamento pro per fare tutta una serie di test di sperimentazioni con questi sistemi per vedere se riesco ad arrivare a un punto interessante della vicenda.

Perché comunque devo dire la verità, lo sviluppo di queste applicazioni, a prescindere che non lo faccio direttamente io è molto interessante, mi sta crescendo molto a livello di conoscenze e informazioni, sperimentazioni, conoscenza anche di altre persone che poi hanno approfondito questo problema e quindi che mi danno nuove idee così via.

Tuttavia, appunto, a Anonymo MCP è sicuramente un'applicazione molto complessa, è forse l'applicazione più complessa assieme appunto a Mac PCT PC che sto pensando di sviluppare, proprio perché ci sono tanti pezzi che si devono mettere in fila, mettiamole in questi termini.

E quindi anche qui è sicuramente uno di sconsiglio caldamente di partire con un sistema del genere, diciamo, non mi sarei mai azzardato a fare una roba del genere se progressivamente non avessi fatto tutta una serie di step, adesso iniziamo a parlare di questi step.

Innanzitutto, quello che ti voglio fare presente, diciamo, è che tutte queste applicazioni le ho sviluppate progressivamente nel tempo utilizzando, prendendo spunto da altre applicazioni e da altro così codice, non in senso tecnico, non ho fatto copiare il codice, ma diciamo l'architettura, le idee e così via, le ho sempre copiate, mettiamole in questi termini e quindi ho lavorato in maniera incrementale.

Giusto per farti per darti un'idea, appunto, la prima applicazione che ho sviluppato con l'intelligenza artificiale è stata Anonimator, è l'applicazione probabilmente più matura, assieme a CCT-Link che serve per fare i link ai PDF, il link agli allegati al PDF riorganizzare e ordinare i PDF per i depositi telematici sostanzialmente.

E appunto Anoniator nasce sulle spalle di un'applicazione sviluppata con l'intelligenza artificiale a sua volta in Python fatta dall'amico Roberto Alma che mi ha dato accesso al suo codice sostanzialmente, io diciamo ho deciso invece di andare su una strada diverso di utilizzare di creare un'applicazione Electron e sostanzialmente è un'applicazione web multipiattaforma, facile da installare e così via.

Quindi, ho fatto tutta una serie di cose, e nella sostanza Anonimator mi è servito molto perché, appunto, progressivamente, pur non avendo specificamente una conoscenza sugli aspetti di anonimizzazione e anonimizzazione dei documenti, ho creato tutta creare tutta una serie di algoritmi e così via, dove sostanzialmente avevo una base già più o meno strutturata e abbastanza ottimizzata di come strapolare l'entità e come poi eventualmente anonimizzarla, Anoni MCP quindi è diventato uno sviluppo, ulteriore successivo, quindi avevo già la base di Anoniator, per Anoni MCP ho dovuto ho copiato l'idea appunto, come ti raccontavo la scorsa puntata da Devonzing, ma di fatto la parte di anonimizzazione era già operativa.

Quindi, concludendo questa parte introduttiva, diciamo la cosa che ho notato è per esempio che andare a scala, cioè andare un passo dopo la volta diventa molto utile perché appunto ti permette poi di espandere sostanzialmente sviluppare progressivamente competenze da una parte e anche codice che a questo punto l'intelligenza artificiale riesce a riciclare o comunque da cui aprendere spunto per poi andare oltre e ottimizzare quindi non devi fare tutto da zero.

Altro piccolo esempio: quando ho creato PCT-Link, di fatto buona parte di tutto il lavoro che era stato fatto per l'interfaccia Electron per l'automatizzazione della creazione delle build per Windows, Mac e Linux, non l'ho dovuta l'ho fatta rifare, ma gli ho detto vai a copiare quello che è già stato fatto per l'anonimato ovviamente utilizzando utilizzando le conoscenze legate lì, ma trasportandole e modificandole, ovviamente in base alle esigenze per PCT Link.

Anche lì PCT-Link l'ho generata, l'ho fatta generare molto velocemente proprio perché alla fine il tempo più grosso che ho speso è stato quello di lavorare a martellate con l'intelligenza artificiale per ottimizzare cosiddetti UI, l'interfaccia grafica.

Tutte queste applicazioni, però, sono partite sostanzialmente da una prima fase che io chiamo di pianificazione.

Infatti, il modo migliore per fare sviluppare queste applicazioni è io consiglio di utilizzare strumenti come Cloud Code, Codecs e così via, cioè assistenti a riga di comando.

Ma a prescindere da questo anche in base poi agli abbonamenti e alle utilità che uno ha.

La prima cosa è di andare in plan mode, sostanzialmente si utilizza ShiftTub e si cambia la modalità.

La modalità base è quella di esecuzione, tu gli chiedi di fare una cosa, sostanzialmente all'assistente a riga di comando, ma funziona anche con quelli diciamo desktop e questo parte da fare.

Invece il consiglio soprattutto se l'applicazione, ma in generale, qualunque cosa che tu debba fare, è meglio prima far pianificare l'intelligenza artificiale.

Questo perché quando il piano viene visto e tu lo puoi vedere, perché alla fine la generazione di tutto questo piano ti viene sottoposto e ti dice: Ma vuoi vuoi farlo oppure no?

Vuoi fare delle modifiche oppure no?

Spoiler, ovviamente ti conviene sempre raffinare e esaminare tutti i problemi, èbbene a fronte di un piano ben strutturato, la realizzazione concreta, seppur sempre martellate sostanzialmente, perché il large language model di fatto seguono il piano, ma poi il piano non è mai preciso al millesimo di centimetro e quindi a quel punto lì devono iterare fare varie cose, soprattutto all'inizio il plan mode è fondamentale.

In questo caso, io tra le altre cose ti suggerisco perché l'ho imparato a mie spese, di utilizzare i modelli più grossi, possibilmente con contesti molto grossi, perché appunto in questo frangente sostanzialmente avere un grosso contesto, quindi potere inizialmente avere tutta una serie di informazioni aggiuntive può diventare molto utile.

Perché a questo punto si possono fare approfondimenti, si possono esaminare cose, si può cercare poi di far generare documentazione introduttiva proprio per queste cose diventa molto utile.

Altra cosa utile probabilmente pubblicherò appena faccio il passaggio a UGO la guida per utilizzare l'CP di Perplexity, ma nella sostanza è importante fare le ricerche, cioè far fare le ricerche large language model ovviamente ricerca online, ricerca sulla documentazione a questo punto, soprattutto documentazione legata allo sviluppo.

Quindi, non so, per applicazione di Apple, tutta la documentazione di sviluppo in Swift, casomai le bastice e così via, o appunto applicazioni Electro, anche qui si va su un altro frangente.

Io nell'ultimo periodo, da quando appunto ho implementato l'MCP di Perplexity cosa ho fatto?

Sostanzialmente dico ai vari assistenti a riga di comando di procedere a fare le ricerche approfondite su questo argomento, su quell'argomento, in modo che ovviamente abbiano tutta una serie di materiale aggiornato, soprattutto che è quello fondamentale, per vedere se i loro progetti sono effettivamente fattibili o se appunto lavorando solo con chiamiamola così la loro conoscenza di base non hanno allucinato perché è molto probabile o comunque casomai dal momento in cui hanno fatto il training al momento attuale in cui si chiede di fare qualcosa nella programmazione, è cambiato qualcosa, nelle risorse sono cambiate qualcosa.

Prima di tutto di questa integrazione con l'MCP di Perplexity, apri qui una parentesi perché non lo sapesse chi non avesse letto la newsletter, sostanzialmente c'è questo neanche sviluppatore, ma perché anche lui l'ha fatto tutto in vibe coding, ma c'è questa persona.

Se mi ricordo metterò il link al repository GitHub.

C'è questa persona che in pratica ha creato un MCP, quindi Model Contrast Protocol, che permette di far collegare Cloud Code, Codecs e così via direttamente a Perplexity quindi con l'abbonamento free e pro.

Io utilizzo il Pro perché ti permette anche poi di fare ricerche a ricerche approfondite e alla possibilità anche di utilizzare modelli differenti quindi lo uso in varie modalità, però, nella sostanza, ti permette di collegare Perplexity e le ricerche online di Perplexity al Cloud Code e Codec, io prima invece lo facevo così detto a mano, usavo le ricerche di Perplexity e generavo dei documenti Markdown da poi passare all'assistente IA riga di comando, quindi a questo punto, cosa facevo?

Mi facevo tutta una serie di ricerche e di approfondimenti e lo faccio anche tuttora, perché poi spesso volentieri all'inizio diciamo ragiono sulla fattibilità dell'idea, sulle possibilità che si riescono effettivamente a fare, quindi la prima cosa da, non avendo le informazioni che mi servono, spesso volentieri faccio una ricerca e inizio a creare sostanzialmente una chat di perplexity su un determinato argomento.

Addirittura se sviluppo una specifica applicazione.

Anche se adesso sto con fatto con l'MCP, tendo a fare tutto dentro, diciamo il repository dell'applicazione, per avere poi tutto lì e potermi spostare da un modello all'altro senza troppi problemi.

Ma comunque facevo proprio tutta una serie di ricerche, approfondimenti, e in questa maniera poi sostanzialmente andavo a comprendere meglio il problema da una parte, dall'altro comprendevo anche meglio quello che avevo a disposizione e quello che si poteva fare con determinate cose.

Per esempio, una determinata domanda a una determinata domanda mi davo una risposta, non capivo minimamente la risposta, allora richiede: ma spiegamela meglio, fammi capire, fammi degli esempi semplici.

In questa maniera, sostanzialmente, pian pianino vedendo cos'era possibile fare, ovviamente mi venivano anche l'idea per fare le cose e per eseguire meglio il piano o per approfondire certi aspetti che invece erano necessari.

Fato tutta questa operazione iniziale, ok, a dire la verità te lo segnalo perché adesso non lo faccio più, ma originariamente, soprattutto all'inizio, quando ho avuto tutta una serie abbastanza grossi di problemi con Anonimator, avevo anche fatto generare una perplexity un prompt che permettesse di lavorare meglio a Cloud Code, di modo che sostanzialmente avevo già un prompt piuttosto importante per sviluppare le cose, poi mi sono spostato al sistema che ti ho raccontato.

Una volta che diciamo sei soddisfatto, ho premesso che ovviamente piano non il piano si infrangerà ovviamente sempre nella sua esecuzione, ma a questo punto, una volta che hai fatto il piano e ho utilizzato il modello a massima capacità diciamo di cui hai a disposizione, a questo punto puoi andare su modelli più leggeri che devono solo eseguire il piano.

E a questo punto, appunto, io spesso e volentieri, buona parte di quello che ho fatto l'ho fatto con Sonnet senza opus per intenderci, e alla fine nell'esecuzione materiale, diciamo, è fattibile hai una finestra di contesto minore, ma ci sono tutta una serie di trucchi, diciamo, per comunque ottimizzarla e così via.

E per esempio, se invece usi GPT si può andare tranquillamente con GPC 5.4.

Attualmente non lo sto facendo per semplice fatto che ho un piano molto generoso, quello da più di 103 euro al mese e quindi sostanzialmente non arrivo mai ai limiti e quindi vado a massima potenza tutto il tempo.

Tuttavia, se fossi in un piano da 20 euro non lavorerei in questa maniera e ti sconsiglio, soprattutto all'inizio se ci vuoi giocare.

Programmare consuma rapidamente tanti crediti e quindi anche qui fare piccole sessioni, piccole sessioni di sviluppo e di miglioramento del sistema cercando di ottimizzare ovviamente i crediti in base al periodo così via.

Altra cosa fondamentale che ho scoperto nel tempo è di impostare o dare comunque le indicazioni specifiche alla language mode dello scopo dello sviluppo dell'app, cioè non solo dire cosa deve fare, ma perché lo deve fare e quali sono le prerogative.

Questo perché ti faccio l'esempio concreto con Anonimator con i vari anonimo MCP e così via.

Ovviamente il sistema vuole anonimizzare i documenti per tutti i problemi legati alla problemi ideontologici e GDPR di questi documenti documenti legali, ma in documenti in generale.

Il problema è che, siccome, il large language model ha questa modalità, mettiamola in questi termini, va avanti a spada tratta e fa cose che diventano aumentano la complessità senza avere dei benefici.

Mi spiego meglio.

Per esempio, in Anone MCP a un certo punto voleva cifrare di tutto di più per rendere le cose più sicure e il ragionamento di fondo era corretto.

Peccato che ci farava tutta una serie di cose salvate all'interno della cartella dei documenti che erano in chiaro, ovviamente perché, se no, anonimo MCP non poteva ovviamente fare l'anonimizzazione, non poteva estrarre le informazioni, e che dal mio punto di vista era evidente che non necessitassero di cifratura per un motivo semplice, che sono sul mio computer.

Il mio computer ha già l'artisk cifrato, ma un ulteriore cifratura, diciamo, se per sé non garantisce maggior sicurezza.

La sicurezza, diciamo, è solo appunto, con il mezzo intermediario dell'anonimizzazione e dell'MCP che non fa passare, diciamo, non permette l'accesso a questi documenti ai large language model online.

Una volta che sono riuscito, gli ho spiegato bene cosa doveva fare e qual era lo scopo di tutto il sistema, quindi dove doveva stare attento, diciamo, e dove no, la situazione è risultata più semplice e più organizzata, anche perché se andava, tra virgolette a complicare inutilmente la vita, quando alla fine appunto non ha senso che il database dell'entità che sei salvato, appunto nella cartella dove ci sono anche i documenti si è cifrato, ma quando ci sono i documenti non cifrati, tra virgolette, che quindi bastava ovviamente basta accedere a quella cartella avendo le possibilità, a quel punto lì il problema non è minimamente risolto, il database non è cifrato, ma i documenti sono in chiaro, ovviamente perché se no, sarebbero leggibili e a questo punto non c'è niente da fare.

Ovvio che il ragionamento di fondo è importante avere l'articifrato e io lo consiglio sempre, dove si salvano i documenti, e ovviamente la sincronizzazione non deve essere in cloud, mettiamola così, o se in cloud utilizzare sistemi come Cryptometro e altre cose per avere la cifratura anche sul cloud, mettiamola in questi termini, ma questo è un discorso che non c'entra, non è collegato alle funzioni del programma di base, mettiamola così nel caso specifico di AMC e questo è importante.

Perché appunto l'IA non capisce bene i problemi grandi e spesso va per generalizzazioni, e quindi indicare in maniera chiara cosa fare, cosa non fare, cosa serve e cosa non serve e cosa non dare per scontato.

Diciamo, tu dai per scontato, ma l'intelligenza artificiale non dà per scontato, quindi spiegarglielo è fondamentale.

Diciamo che le regole anche qui sono le stesse.

Di fare un buon prompt sostanzialmente, più sei specifico, più sei chiaro, più indichiati.

Quindi anche qui tutta la parte di preparazione fondamentale.

Più che altro per capire tu, quali indicazioni e quanta precisione dare ai large language model e al loro sistema.

L'altra cosa fondamentale è quella di creare, appunto progressivamente dei Clode MD o degli agents MD, le regole a cui si deve adeguare i large language model.

Questi file, infatti, sono file che vengono letti ogni volta che viene fatta una query sostanzialmente assistenti a riga di comando, e di fatto sono comparabili a un sistema prompt ulteriore, cioè sono le indicazioni specifiche di lavoro in quella specifica cartella e possono essere anche in più sotto cartelle direttamente al large language model, anche qui l'importante, soprattutto all'inizio, è creare una serie di regole chiara, specifica, puntuale e molto dettagliata.

Molto dettagliata non vuol dire che deve esserci un Clude MD o un agence MD lungo migliaia di parole o migliaia di righe, anche perché anche qui bisogna utilizzare sempre la progressive disclosure.

La progressive disclosure è un sistema per cui questi file MD vengono letti progressivamente, ovvero l'agent o Clude MD danno le regole di base, cosa fa questo repository, i comandi principali dove trovare le informazioni che servono, le informazioni specifiche che servono, e poi appunto le informazioni specifiche che servono devono essere in sottofile.

Anche qui, per esempio, non so, lo vedremo dopo, per tutto il discorso della gestione del repository, per esempio, i commit come gestire i commit, come fare le modifiche.

È importante dare le indicazioni di base proprio perché lavori in maniera corretta e faccia le cose secondo le tecniche di sviluppo correnti e efficaci proprio per ridurre problemi di vario genere.

Altra cosa fondamentale: i test, questa è una cosa tipicamente a programmatori ed è un principio che ho rubato, diciamo, da Salvatore San Filippo, ogni cosa che fa l'LM deve essere testato e deve poterlo verificare.

Questo vuol dire che appunto, l'LLM può verificare il risultato e di tirare in modo efficace ed efficiente.

Quindi, gli LM, siccome codificano di fatto a forza brutta, io lo chiamo: nel senso se non funziona, fanno delle modifiche, verificano la modifica, se funziona, passa alla fase successiva.

Se non funziona, reitera di nuovo.

Quindi cerca di fare una modifica, cerca di capire dove è il problema e continua a fare modifiche fino a che lo chiama martellata e non funziona.

Dare la possibilità: innanzitutto, di fare tutta una serie di test, proprio per evitare che poi le modifiche vengano fatte, ma inutilmente, perché poi non funziona niente, perché non sono stati fatti i test.

Quindi, comunque, chiedali sempre sviluppa, di fare dei test per verificare che lo sviluppo sia efficace e concreto, dall'altra, ancora più importante, soprattutto per l'interfaccia grafica e così via, e dare accesso all'interfaccia grafica.

Per esempio, Electron esiste un MCP Electron che permette addirittura al Large Language Model di fare fotografie, diciamo, fare screenshot dell'applicazione, di farla partire, ovviamente, di vedere tutta la struttura dell'applicazione, vedere i log e quindi vedere se ci sono degli errori e anche se a livello grafico ci sono delle problematiche e così via.

Stesso discorso, ho scoperto vale per esempio per l'applicazione Swift c'è con la versione 26.5, credo di Xcode, la possibilità di far aprire le applicazioni all'assistente a riga di comando e farle lavorare, quindi anche di risolvere tutta una serie di problemi che sono importanti.

Il test, comunque risulta utilissimo per tutto.

Altra cosa fondamentale da tenere presente è quello che io chiamo sviluppare in modo atomico, cioè chiedere all'intelligenza artificiale innanzitutto di usare Git, che è un sistema di version control.

Se ovviamente si vuole utilizzare, diciamo GitHub o comunque i sistemi per rendere pubblico il codice, usare il comando GH che è facilmente installabile o poi chiedere di farlo installare se è in ombriu sul tuo Mac, e in questa maniera utilizzando Git, ogni modifica deve essere versionata, cioè deve essere ogni volta che io vado a fare una modifica, deve essere fatto quello che in gioco tecnico viene detto commit, e a questo punto, siccome le varie modifiche sono salvati in commit differenti appunto, io, o meglio, il Large Language Model può fatto un grave errore o se ha fatto una modifica che tu non volevi che facesse, puoi dire di tornare indietro la versione precedente e quindi non perdere tutto il lavoro fatto perché casomai poi ti cancella il file che invece funzionava correttamente.

Lo sviluppo atomico è abbastanza importante.

E tra l'altro l'utilizzo di Git che io per esempio utilizzo da tempo per gli articoli di avvocati Mac, di modo che appunto progressivamente mentre faccio le modifiche, queste sono incrementali e vengono salvate progressivamente, è anche un ottimo modo di imparare il sistema.

E anche qui, per esempio, io, pur conoscendo come funziona Git, non ho voglia di fare tutto io, e quindi spesso e volentieri.

Anche qui, siccome Large Lage Bond invece sanno programmare molto bene.

Gli dico di utilizzamente lui Git e quindi fa tutte le sue cose.

Io non mi ci devo particolarmente.

Per cui anche qui per un avvocato, diciamo che non sa programmare, ma che ha questi concetti di base, diciamo, puoi demandare poi tutta l'attività, diciamo noiosa, comunque più da programmatore direttamente, anche per questa fase di sviluppo della parte di sviluppo, direttamente all'intelligenza artificiale.

Lo sviluppo atomico ha anche un altro grosso vantaggio che sostanzialmente ti permette di distinguere bene le cose.

Altra cosa fondamentale legata a Git sono i branch, ovvero le ramificazioni dello sviluppo, di fatto una nuova funzione è un ramo diverso dello sviluppo, e quindi hai chiamiamo così un branch che si chiama main, cioè principale, e abitualmente io ti consiglio di dire all'intelligenza artificiale per ogni nuova funzione, ogni nuova caratteristica che vai a chiedere di fare sviluppare, di appunto creare un ramo di sviluppo specifico con un nome specifico, quindi sai anche cosa è stato fatto.

Se diciamo rompe il programma, non è un problema, o se ti rendi conto che per esempio quella parte di sviluppo non è corretta o comunque crea più problemi di quelli che risolve, puoi diciamo, mollare quel ramo e ripartire con un ramo nuovo, eventualmente appunto imparando dagli errori.

Se poi invece quel ramo funziona, quindi anche qui il mio consiglio è sempre dopo aver fatto tutti i test e così via, fare dei test reali, quindi far andare l'applicazione e testarla manualmente, diciamo, puoi fare il cosiddetto merge, cioè l'unione del ramo laterale, diciamo con il ramo principale: il main, a questo punto progredire nello sviluppo.

Anche qui sono tutti concetti, diciamo di base degli sviluppatori, non sono concetti particolarmente complicati una volta che si comprende il sistema, ma non sono neanche una volta compresi questi concetti, sostanzialmente basta specificare verbalmente l'intelligenza artificiale di fare queste cose, di seguire in questa maniera questi sistemi.

Quindi, anche qui la cosa interessante è proprio questa: cioè che l'avvocato, il professionista, che vuole vuole fare questa attività, non si deve preoccupare più di tanto di ottimizzare o di avere tutta una serie di informazioni, ma può lavorare in maniera abbastanza trasparente.

Ovviamente progressivamente è importante anche capire meglio i vari funzionamenti e tutto il resto.

Altro punto fondamentale, avendo migliorato la mia tecnica di creare codice a quelli A, c'è sempre il più grosso problema: cioè capire quando li aprono una via sbagliata e quando no.

Questo l'ho già detto prima: è importante sia nella fase di pianificazione, anzi, ancora più importante nella fase di pianificazione, perché una buona pianificazione vuol dire poi un'esecuzione più spedita, con meno errori quindi con minor consumo di token.

Ma ovviamente la pianificazione non vuol dire che ha già fatto tutto, perché, se no, non avremo il problema.

Quindi, a volte nel corso dello sviluppo bisogna ovviamente tenere monitorato cosa fa, espresso e volentieri, appunto, leggere passaggi, i cosiddetti pensieri dell'intelligenza artificiale, esaminare attentamente le domande che ti pone e le autorizzazioni che ti chiede di fare proprio per capire se sta andando in una direzione sbagliata o in una direzione corretta, fare domande, sempre fare domande anche di chiarimento, se non si capisce qualcosa è sempre meglio fare una domanda in più che una domanda in meno, cercando ovviamente di piegare e di comprendere il miglior modo possibile.

I trucchi che io utilizzo abitualmente, quando chiedo le spiegazioni è specificare di essere tecnici e informatici o comunque di avere conoscenze informatici.

Quindi chiedere per esempio esempi o metafore per le spiegazioni.

In questa maniera, soprattutto negli aspetti diciamo più tecnici, dove effettivamente anche io faccio abbastanza fatica a capire.

In questa maniera vedo che, pur ovviamente non comprendendo tutto al 100%, riesco a afferrare quantomeno i macro concetti e quindi anche qui svolgere uno sviluppo più sensato e più lineare tutto.

Spesso e volentieri, tra l'altro, una delle cose che mi sono trovato a notare è che li ha a molte meno intuizioni dell'umano.

Quindi anch'io, casomai pongo delle domande, gli dico: non sarebbe meglio fare così, oppure mi è venuta questa idea, perché non facciamo così, secondo te va bene o non va bene?

Ed effettivamente, spesso e volentieri questa unione tra suggerimenti umani e capacità, ovviamente informatiche delle intelligenze artificiali, ti permettono di ottimizzare di soprattutto non far andare per la tangente l'intelligenza artificiale, perché sostanzialmente sono l'intelligenza artificiale e gli assistenti a riga di comando sono degli ottimi esecutori, mettiamoli in questi termini, messi ovviamente i vincoli che ti ho raccontato all'inizio di questa puntata, ma spesso e volentieri, la programmazione e la progettazione li casca l'asino abbastanza spesso, soprattutto se non vuoi consumare una quantità enorme di token, perché una delle tecniche che adesso va di moda, diciamo nello sviluppo con l'intelligenza artificiale, è per esempio quella di creare questi loop: cioè consumare un'infinità di token, nella speranza che prima o poi a martellate sostanzialmente l'intelligenza artificiale riesca a fare quello che tu gli hai chiesto e che la cosa funzioni, diciamo che esamine sostanzialmente tutte le strade possibili e a un certo punto sviluppi qualcosa di sensato e così via.

Io ritengo che sia uno spreco di token di energia, di risorse e così via, ma due, soprattutto a fronte di limitazioni, diciamo di quello che è possibile fare o che io ho intenzione di spendere per queste cose, sia effettivamente controproducente, abbastanza inutile mettiamola in questi termini.

Altra cosa fondamentale di cui ti voglio parlare, sempre per migliorare le tecniche di sviluppo, è chiedere all'intelligenza artificiale di fare red teaming.

È una tecnica tipica del mondo della cyber security, sostanzialmente il red teaming è simulare appunto il team rosso, quindi simulare attacchi per migliorare il piano di difesa, è un concetto che i large model conoscono bene proprio perché il grosso della loro istruzione, diciamo, delle informazioni che ha, sono di tipo informatico e quindi, appunto, dire semplicemente fai red teaming, consumi pochi token, ma il concetto che trasmetti alla genguine model è chiaro e specifico e così via.

Poi spesso volentieri è sempre meglio dire fai il red teaming su questa cosa su questo aspetto e così via.

Per cui c'è un risparmio notevole di token.

Apro chiudo una parentesi, il red teaming ne ho parlato nell'Office Hour che non è stata registrata, ma sostanzialmente è una tecnica utile non solo nel mondo diciamo del coding, ma io lo utilizzo tantissimo anche in ambito legale, ma non solo.

Spesso e volentieri, appunto cosa si fa non è un modo per evitare l'allucinazione, ma il red teaming comunque è un modo per spostare, diciamo l'osservazione e l'analisi, diciamo dell'intelligenza artificiale in modo avversoriale, cioè cerca di simulare appunto un attacco avversario e facendo questo può criticare il proprio lavoro precedente.

Considerato anche che tendenzialmente l'intelligenza artificiale, appunto, ha questo difetto di risponderti sempre quindi di cercare di darti una risposta anche se non conosci la risposta, la risposta non è quella corretta e di darti sempre ragione, fare il red teaming diventa molto comodo e farò anche spesso.

Io spesso e volentieri sia nella fase di progettazione sia nella fase di esecuzione, a volte faccio varie iterazioni proprio per cercare di tirare fuori più problemi.

A volte anche qui il red teaming è controproducente, perché poi si fa si fa dei pipponi che la metà bastano.

Tuttavia, tendenzialmente quantomeno fare un meno un red teaming in fase di progettazione e qualche red teaming nella fase di esecuzione è fondamentale e utile, quant'altro.

Per chi poi utilizzasse Cloud Code, ti segnalo che c'è un'opzione che ovviamente consuma più token, ma che si chiama Ultra Sync esiste anche l'Ultra Plan sostanzialmente che ti permette, da una parte: l'ultra sync, ovviamente: slash Ultra Think proprio, quindi pensa di più, gli permette di ragionare di più, e quindi teoricamente dovrebbe ottenere dei risultati migliori, invece, l'UltraPlan è appunto, anche lì pensa di più, ma nella fase di pianificazione, quindi dovrebbe e dico dovrebbe migliorare, mettiamola in questi termini, il piano e quindi poi l'esecuzione stessa.

Argomento tangenziale, ma credo utile, mentre appunto facevo tutte queste esperimenti, diciamo, io prevalentemente, negli ultimi mesi ho utilizzato molto Cloud Code, con il quale ho preso abbastanza familiarità.

Ho perché ero curioso, appunto, preso maggior confidenza in quest'ultimo mese perché sostanzialmente è un poco meno di un mese che sto utilizzando Codex, devo dire la verità è abbastanza utile.

I due si differenziano su vari fronti, la cosa più grossa a livello di sviluppo è che Cloud Code di fatto ha accesso a tutto il computer a meno che non utilizzi la modalità, diciamo con il sandbox, mentre Cloud Codex invece parte di base in sandbox e da un certo punto di vista ti dà maggiore tranquillità nel dare i comandi, mettiamola così, perché lavora diciamo in un sandbox, quindi non può fare danni sul tuo computer sostanzialmente.

Ma richiede poi molti più comandi perché spesso e volentieri, certi comandi non funzionano nel sandbox di base e quindi tu devi sempre autorizzare.

Fallo fuori, fallo fuori, fallo fuori.

Personalmente trovo tendenzialmente Cloud Code più performante, soprattutto adesso hanno messo una volta che hai fatto il piano e se hai definito bene il tuo piano, c'è la possibilità di autoeseguire il piano e quindi non ti chiede in continuo autorizzazione.

Anche qui è un trade-off, nel senso che non chiedendo autorizzazioni, può fare più danni potenzialmente.

Ma se appunto hai dedicato molto tempo alla pianificazione, diciamo tendenzialmente il sistema funziona bene.

Siccome avevo a disposizione GPT, sostanzialmente, perché ormai Cloud con Open Code, che è un altro sistema simile a Codex e a Cloud Code, ma open source, quindi io tendenzialmente lo utilizzo, apprezzo questi sistemi.

Diciamo, Open Code, che è appunto un sistema di ARNES open source per gli LLM.

L'ARNES è sostanzialmente sono quei programmi, quella strutturazione, quindi anche lo stesso Cloud Code molto simile, ma appunto aperto e sviluppato da programmatori per programmatori.

La caso più interessante di Open Code è l'LSP.

L'LSP è il larger il language server protocol.

È un protocollo che permette a un editor di dialogare con il language server che forniscono funzionalità come completamento, refactoring, go definition e in modo standardizzato e indipendente dall'editor.

Nella sostanza, appunto l'LSP permette a questi sistemi di scrivere codice migliore e più corretto.

Per cui è come avere il dizionario della grammatica per intenderci di un linguaggio specifico di sviluppo.

Per cui avere anche questo LSP all'interno di Open Code permette di evitare di avere meno errori di creazione del codice e appunto, siccome l'LLM è non deterministico e quindi può sempre inventare sostanzialmente anche formati di codice sbagliato.

Diciamo come le allucinazioni possono esserci sia nella creazione di codice come nella creazione di testo, l'LSP sostanzialmente aggiunge un guardraid deterministico perché di fatto è un programma, è un algoritmo specifico che evita errori di formattazione del codice e quant'altro.

Dalla mia esperienza la particolarità di Open Code è che è diverso da Cloud Code e tende ad essere più autonomo.

Quindi andare per i fatti suoi molto facilmente.

Da quello che ho visto, Cloud Code e Codec tendono a seguire di più gli ordini umani, mettiamoli in questi termini.

Concludo alcune piccole chicche che, però, ho trovato molto comode.

Sono il consiglio degli LLM, io questo l'ho fatto attraverso appunto l'MCP di Perplexity, nella sostanza.

Cosa fa?

Perplexity nella versione Pro, però ti dà la possibilità di accedere a differenti modelli di differenti provider.

Quindi mentre quando sviluppi con Cloud Code, con Codex e così via, abitualmente hai solo una classe di modelli, quindi tutti i modelli di Antropic per Claude, tutti i modelli di OpenAI per Codex, se utilizzi, per esempio Open Code, diciamo già hai la possibilità di utilizzare modelli diversi volendo, ma pagando separatamente, ma con Perplexity e con l'MCP che collega a Perplexity, sostanzialmente se l'abbonamento Pro, hai la possibilità di appunto utilizzare sostanzialmente GPT, la versione meno potente, diciamo, Sonnet e Gemini, oltre che altri modelli adesso attualmente c'è Chimi 2.6, credo e Nemotron.

Quindi c'è la possibilità di far generare per la stessa domanda più risposte da differenti large language model e utilizzare questo in modo da appunto avere una risposta migliore, diciamo, a fronte del fatto che difficilmente gli stessi differenti large model ti danno una risposta uguale, visto che hanno istruzioni e hanno sostanzialmente training differenti, per cui utilizzando il consiglio degli LLM, le risposte che ti danno dovrebbero diciamo essere meno a rischio di allucinazioni e estrapolare informazioni migliori.

La cosa interessante è che appunto, l'MCP di Perplexity, che però è un plugin, cioè un MCP non ufficiale, anzi, presumo che quando Perplex ne si ne accorgerà, cercheranno di bloccarlo, mettiamolo in questi termini, però, finché va, funziona, questo mi ha dato molte possibilità, soprattutto per le cose abbastanza complicate, cioè nelle decisioni complesse chiedevo sempre di far partire, ovviamente consumando molti più token attendo a precisare, ma per fortuna Perplexity è flat, tra virgolette, quindi ho tot ricerche tot utilizzi dei vari differenti mode, diventa molto comodo, soprattutto tra le altre cose, se utilizzi un abbonamento base di Perplexic intorno ai 20 euro al mese, un abbonamento base di Clodo GPT che anche lì hai 20 euro al mese, ovviamente addirittura si può utilizzare il modello di picco: quindi Opus per Claude e GPT 5.5 X-ite come giudice sui giudici, il Large Language Model il consiglio dà tre risposte differenti.

Poi, dopo il modello più potente, giudica qual è la risposta migliore o quale delle risposte è il pezzo migliore da prenda, sempre nello sviluppo, poi ti segnalo che diventa molto utile soprattutto nella fase di progettazione, diciamo, per avere una prima visualizzazione dell'interfaccia geografica, di chiedere di fare l'interfaccia ASCII ASCII, sostanzialmente è una modalità che anche qui funziona bene con l'arge model perché lavoro anche col testo, di visualizzazione appunto con lettere e altro dell'interfaccia grafica, in modo che già nella fase di progettazione, mettiamola così, puoi avere un'idea di base, ovviamente, perché difficilmente l'interfaccia grafica riesce a visualizzare un'interfaccia molto complesso, ma comunque ti dà un modo di visualizzare o addirittura i flussi, i flow chart e così via, diventa molto comodo nello sviluppo.

Un'altra cosa di cui ormai abuso, mettiamola così, è quella di creare dei file MD di chiama architettura o comunque di spiegazione di come funziona il progetto.

Questo per un doppio motivo: da una parte diventa comodo, poi vedere nell'architettura come funziona la tua applicazione a livello teorico, diciamo di funzionamento, di implementazione e così via, quindi puoi vedere se la large language model ha avuto dei problemi o se per esempio fa delle cose che non deve fare o fa delle cose come non gli hai detto di fare, quindi l'architettura MD diventa utile anche per uno soggetto esterno per capire velocemente come funziona il tuo sistema, dall'altra è un ottimo strumento per creare dei vincoli al large language model, cioè non parte a inventarsi i funzionamenti dell'architettura, ma sa che quella è l'architettura che deve seguire, eventualmente quando fa delle modifiche grosse va a modificare il file di architettura, glielo devi dire, ovviamente sempre di modificare il file di architettura, ma in questa maniera diciamo, lo sviluppo segue anche una linea maestra, un progetto, appunto che diventa molto comodo.

Ti ho già parlato nel caso dello sviluppo di applicazioni Electron e quindi anche di Anony MCP, che è di fatto la parte, diciamo di animizzazione è un'applicazione Electron dell'MCP Electron che effettivamente, soprattutto su Andone MCP mi ha dato una marcia in più perché permettendo a sostanzialmente il Large Language Mode di vedere l'interfaccia, addirittura gli ho fatto fare una guida passo passo del funzionamento.

Anche qui, se me lo ricordo, te la linco nelle note dell'episodio, non è perfetta, diciamo, ma non ho dovuto fare io tutti gli screenshot, ma me li ha fatti direttamente dal large language mode alla fronte degli screenshot.

Poi ha spiegato pian pianino come funziona tutta l'applicazione, anche perché appunto su applicazioni relativamente complesse, l'interfaccia è da una parte complessa, ma deve essere il più semplice possibile per fare azioni relativamente complesse.

Quindi anche qui quello che ho notato io, una volta che il sistema sotto funziona, mettiamola in questi termini, è molto utile.

La parte più complicata, diciamo, è quella di rendere semplice il complesso e quindi rendere semplice, solitamente un'interfaccia grafica per l'utente che casomai non sa come l'intelligenza artificiale, e tu hai sviluppato una determinata applicazione.

Bene, tiriamo velocemente le somme.

Come hai visto, iniziare a sviluppare anche l'ausilio dell'intelligenza artificiale non è una cosa semplice, è una cosa che richiede comunque delle competenze che progressivamente comunque si sviluppano, perché è normale che sia così, e conviene partire dai dei semplici.

Diciamo, strumenti molto basilari.

Altra cosa che non ho detto nel corso alla puntata è che spesso e volentieri è meglio far fare, diciamo, prima di dedicarsi all'interfaccia grafica ai fronzoli, diciamo di un'applicazione, cercare di far sviluppare un'applicazione base che casomai funziona solo col terminale o che comunque funziona solo con dei comandi.

Termine dove tra l'altro l'intelligenza artificiale ti può aiutare tantissimo.

I vari cloud code e così via, riescono a fare tantissime cose quindi non ti deve preoccupare.

Diciamo, la questione del terminale, perché per esempio, a Ronali MCP l'ho fatta partire, l'ho sviluppata secondo me in due ore velocemente fatta sviluppare, partendo da un'interfaccia terminale.

E poi, perché sono un po' malato di mente, gli ho fatto creare la TUI, cioè terminal user interface quindi un'interfaccia terminale che almeno mi dava un minimo di funzionamento, ma questo ti permette appunto di vedere se l'idea funziona e se riesci a sviluppare la base in poco tempo.

Effettivamente, io ho generato tutto il sistema in poco tempo, poi la parte veramente complessa andare a limare tutte le problematiche, tutti i casi.

I casi particolari che casomai, tra l'altro ti accorge solo quando gli utenti iniziano ad utilizzare l'applicazione o quando appunto l'appetito viene mangiando, quando inizia a fare una cosa, diciamo, sarebbe bello fare anche questo, vorrei anche questa funzione e quindi alla fine si impilano milioni di cose, ma abitualmente una volta che hai un'architettura ben strutturata, ben funzionante è importante.

Ecco anche qui un'ulteriore cosa che non ho detto.

Ma diciamo che va anche in una fase un po' elevata di sviluppo, è quella poi di non leggendo il codice che viene fatto, anche cercare di far fare un qualche tipo di ottimizzazione del codice e soprattutto farli fare molti commenti.

Non perché io tendenzialmente quasi non guardo il codice generato dell'intelligenza artificiale, ma da una parte i commenti diventano utili anche per i futuri sviluppi del large language model perché può andare a vedere esattamente.

Dall'altra, se effettivamente invece un programmatore poi necessità, se qualcuno che sa di cosa come funziona un programma, necessitassi di esaminare l'istato del programma, sostanzialmente avrebbe quantomeno un modo per capire e quindi anche tu poi, volendo andando uno step oltre a avere poi in un futuro la possibilità poi di eventualmente fare modifiche manuali e così via.

Io non è mia intenzione, ma però a livello generale, diciamo, inserire commenti e tutto il resto, come appunto l'architettura diventa molto utile per lo sviluppo futuro e soprattutto incrementale dell'applicazione in modo che tutto il codice sia quantomeno organizzata in maniera che un umano possa capirci qualcosa, mettiamole in questi termini.

Chiudo dicendo una cosa fondamentale che non ho detto, e poiché apre alle prossime puntate, tutte queste tecniche ho scoperto comunque sono molto utili anche nello sviluppo delle skill dei plugin, perché nella sostanza, pur essendo lo vedremo poi in prossime puntate dove ti anticipo appunto che ho intenzione di fare degli approfondimenti, skill plugin sono di fatto dei documenti testuali dove spiegano come cosa fare a un large language model in determinate situazioni, sono io le chiamo le ricette per fare cose, ma possono essere sviluppati, secondo me si ottengono risultati migliori utilizzando comunque le tecniche di sviluppo che ti ho raccontato in questa puntata.

Per cui anche qui se non ti interessa niente sviluppare applicazioni specifiche, già per sviluppare skill e così via, quello che ti ho raccontato oggi è molto utile e anzi ti dà delle condizioni in più per lavorare meglio e quant'altro.

Bene, siamo arrivati alla fine.

Come al solito se ti è piaciuto quel che hai ascoltato, ti propongo di iscriverti alla mia newsletter.

Ogni mese e invio link ad articoli che ho trovato interessanti, avviso per nuovi podcast e nuovi articoli.

Trovi le note all'episodio all'indirizzo hdps, due punti slash slash www.avvocati mac.it slash podcast slash 83 che è il numero di questa puntata.

Come sempre ci sentiamo alla prossima.