Github ha recentemente annunciato Github Spark, un nuovo servizio per generare delle “micro app” con l’ausilio dell’intelligenza artificiale. L’annuncio colpisce non solo perché promette l’automazione della generazione del codice, ma soprattutto perché supporta più modelli di AI generativa anche da parte di più vendor come OpenAI e Anthropic.
Questa capacità colpisce per almeno due ragioni: da una parte il software deve adattarsi a più intelligenze artificiali per funzionare, dall’altra Microsoft introduce in uno dei suoi servizi modelli AI che non sono di OpenAI.
Cerchiamo di capire le sfide da affrontare nello sviluppo di software capace di sfruttare più modelli di AI e le implicazioni che può avere per il futuro. La scelta di Microsoft di differenziare il supporto per i modelli AI può suggerire che quella sia la via da seguire.
GitHub Spark in breve
Il servizio sembra istituzionalizzare l’idea che sia possibile generare codice automaticamente che realizzi semplici funzioni applicative usando modelli AI, un po’ come succede per gli artifact realizzati con Claude, tenendo però conto che GitHub vive di sviluppo e sviluppatori e promette quindi la generazione di veri e propri programmi usando l’AI.
Il servizio è per ora in technical preview ed è quindi presto per potersi formare delle opinioni proprie, ma dalle informazioni che si trovano sembra che se si ha bisogno di un’applicazione che svolga una funzione specifica, o di generare un semplice videogame arcade, il risultato sia decisamente buono e più curato di quanto possano essere gli artifacts di Anthropic.
Un altro aspetto che colpisce dell’annuncio è la possibilità di sviluppare direttamente dallo smartphone aprendo una nuova pagina per attività creative come prototyping e anche di realizzazione di app da scambiare con gli amici. GitHub si candida ovviamente ad ospitare le eventuali connessioni server, c’è quindi da aspettarsi che con un abbonamento si possa anche avere un servizio premium.
La capacità di creare app interattive che facciano anche uso del 3D potrebbe aprire scenari interessanti, ad esempio usando software che effettuano lo scanner 3D dallo smartphone come Polycam si potrebbero acquisire modelli 3D della propria casa e poi animarli con l’aiuto dell’AI per promuovere la vendita o realizzare un gioco.
Microsoft – OpenAI, se scoppia la coppia perfetta
Microsoft ha già da tempo iniziato a ridurre la sua dipendenza da OpenAI. Come del resto OpenAI si sta sganciando da Microsoft.
Dopo la breve fuori uscita di Sam Altman da OpenAI, Microsoft ha ridotto la propria esposizione, aggiungendo ad Azure Mistral, un’azienda francese di IA, e altri modelli, e assumendo quasi tutto il personale di Inflection, un rivale di OpenAI, compreso il suo capo, Mustafa Suleyman.
Microsoft e OpenAI sono in procinto di rinegoziare i termini del loro rapporto, in quanto il creatore di modelli cambia la sua struttura aziendale da ente no-profit a ente a scopo di lucro.
Potrebbe anche esserci una clausola di decadenza incombente. Si ritiene che OpenAI abbia il diritto di sciogliere i suoi legami commerciali con Microsoft se i suoi modelli raggiungono un livello di capacità sovrumana chiamato intelligenza artificiale generale.
Ultimo tassello, OpenAI ha lanciato giovedì scorso Search ChatGPT, posizionando l’azienda per competere meglio con motori di ricerca come Google, Bing di Microsoft – appunto – e Perplexity.
Scrivere sistemi multi-modello
L’integrazione del software è studiata dal software engineering e richiede che i software rispettino numerose convenzioni nello sviluppo affinché sia possibile che due software sviluppati da programmatori differenti possano interagire correttamente.
Da un punto di vista del software engineering interagire con più modelli di AI sviluppati da entità differenti pone sfide analoghe alla realizzazione di altri software ma con un distinguo molto importante: le API, dei contratti che consentono ad un programma di invocare i servizi di un altro, sono normalmente complesse nell’integrazione e il programmatore deve seguire numerose convenzioni nella loro invocazione per assicurare il corretto funzionamento, mentre nell’AI generativa l’API dominante segue il modello della ChatCompletion di OpenAI (supportato anche da molti software Open Source come Ollama) che sostanzialmente offre un’interfaccia molto semplice:
ChatComplete (Messages)
Sostanzialmente si passa una sequenza di messaggi scritti in linguaggio naturale corrispondenti all’interazione della Chat e si ottiene la risposta dell’assistente come nuovo messaggio.
Dal punto di vista del software engineering non è quindi troppo difficile sviluppare sistemi che supportino più modelli di intelligenza artificiale (prova ne è Ollama che consente di eseguire migliaia di modelli AI senza dover essere programmato), quello che è invece molto difficile è adattare il comportamento del proprio software a risposte di modelli differenti.
Il software open source Oraculum che ho sviluppato supporta più modelli AI sfruttando il fatto che molti software li espongono mediante le API di OpenAI, ma quando ho cambiato il modello ho dovuto adattare numerosi aspetti affinché il comportamento del mio software rimanesse invariato.
Per provare a capire le differenze ho proposto a Claude e a ChatGPT il seguente prompt:
Scrivi una funzione javascript chiamata Mandelbrot che calcola date le coordinate di un punto nello spazio complesso la velocità del punto in accordo alla regola del popolare insieme
Il risultato riportato nelle seguenti immagini (sopra l’output di ChatGPT 4o e sotto quello di Claude) è sostanzialmente analogo, e la segnatura della funzione (nomi e parametri) sono stati generati nello stesso modo in entrambi gli output. Però la funzione generata da ChatGPT restituisce un numero intero tra 1 e maxIterations mentre quella generata da Claude un numero decimale tra 0 e 1.
Come si può osservare a parità di prompt nella generazione del software si possono ottenere risultati apparentemente compatibili ma con un significato diversissimo per chi volesse usare la funzione generata in modo automatico.
Ovviamente è possibile integrare il prompt in modo che l’output sia quello atteso, ma anche in questo semplice esempio emerge chiaramente le sfide che deve affrontare chi pensa di realizzare sistemi, soprattutto che generano programmi come GitHub Spark, utilizzando modelli diversi.
L’importanza strategica di sviluppare software multi-modello
Sviluppare software che usa più modelli di AI generativa per funzionare ha inevitabilmente un costo, e sicuramente il cambio di modello può condizionare significativamente il comportamento di un programma (anche se si limita a mostrare all’utente il risultato di un particolare prompt), ma si tratta di una scelta strategica molto importante volta a preservare gli investimenti fatti nella realizzazione del software stesso.
Supportare modelli AI realizzati da entità differenti, come Anthropic e OpenAI nel caso di GitHub Spark, è ancora più difficile, siamo infatti tutti abituati al fatto che classi differenti di modelli esibiscono comportamenti significativamente differenti rispetto a modelli che appartengono alla stessa classe (e tipicamente sviluppatore).
Per Microsoft la scelta di aprire a più modelli anche diversi da quelli di OpenAI, seppur in un servizio minore, rappresenta un’interessante palestra per imparare ad adattare il software a comportamenti differenti preservandone il comportamento, sicuramente un passo che consentirà potenzialmente al colosso di Redmond di avere alternative per il futuro qualora la relazione con OpenAI si dovesse guastare col tempo.
Conclusioni
Per troppo tempo si è parlato solo dei modelli LLM, della loro conoscenza, dei loro pregi e difetti, il software che li usa è però altrettanto importante e rappresenta un investimento sempre più rilevante per chi sviluppa. È importante assicurarsi che questo investimento possa durare nel tempo e supportare più modelli sembra un modo ragionevole di farlo.
