Secondo di tre approfondimenti nati dalla tavola rotonda organizzata da Bitrock con nove professionisti dello sviluppo mobile e dell’intelligenza artificiale.
Basta un piccolo esperimento per scoprire una tendenza curiosa. Samantha Giro, Mobile Manager di Bitrock, ha provato a chiedere all’AI di generare un’app senza indicare l’architettura da usare, ripetendo la prova su più piattaforme. Il risultato l’ha lasciata perplessa: per il cross-platform, l’agente proponeva quasi sempre React Native. Non Flutter, non Kotlin Multiplatform. Perché?
Questa domanda ha aperto uno dei filoni più interessanti della tavola rotonda organizzata da Bitrock, dedicata al rapporto tra AI e sviluppo mobile. In questo secondo articolo, entriamo nel merito delle scelte tecnologiche: come si comporta l’AI con i diversi framework e cosa cambia, di conseguenza, per chi progetta app.
Una questione di numeri (e di dati di addestramento)
La spiegazione più condivisa è tanto semplice quanto rivelatrice: l’AI conosce meglio ciò di cui esiste più codice. Lo mette a fuoco Stefano Mondino, sviluppatore iOS in Synesthesia: «È una questione di numeri. React Native attinge a un bacino di sviluppatori JavaScript enormemente più grande rispetto, per esempio, a quello di Flutter, che parte da un linguaggio meno conosciuto come Dart».
Marco Riva, AI engineer in Fortitude Group, conferma dal lato di chi i modelli li sviluppa: in assenza di indicazioni precise e senza una ricerca online preliminare, il modello «va dritto» dove il suo training set è più ricco, e cioè su JavaScript e React Native.
Carlo Lucera, Flutter Team Lead in Pivotal Technologies, aggiunge una lettura originale legata alle origini di questi strumenti: molti sono nati sul web, dove l’anteprima immediata di un’app richiedeva tecnologie eseguibili nel browser. «Da lì è nata una preferenza che poi si è propagata ed è rimasta un caposaldo della programmazione agentica».
Ogni framework ha le sue insidie
Il comportamento dell’AI cambia sensibilmente da tecnologia a tecnologia, e conoscerne i limiti è parte del mestiere.
Su Flutter, Carlo Lucera segnala non tanto errori clamorosi quanto pratiche un po’ datate: «Ogni tanto usa convenzioni superate, tipo dichiarare il tipo di una costante quando non serve più. Non sono bug, è più codice sporco da ripulire. A livello di affidabilità però siamo quasi al 90% dei casi corretti».
Su Kotlin Multiplatform, Marco Gomiero riconosce che il training set è più limitato, «ma con qualche indicazione giusta e qualche skill o guardrail, tutto sommato va abbastanza bene: l’importante è dargli istruzioni precise».
Su iOS, Federico Nessi ha osservato una differenza netta tra progetti: su un’implementazione confusa l’AI tendeva a perdersi nei flussi, mentre su un’architettura pulita e diffusa come la TCA era «estremamente puntuale». La sua interpretazione: i pattern implementati in modo uniforme da tutta la community generano skill precise, e questo si sposa benissimo con il modo di ragionare di un’AI.
Su Android, Federico Monti racconta di refactoring resi complicati dal riferimento a librerie vecchie: «Per arrivare alla versione finale ci sono stati tanti prompt e tante ricerche online». E avverte, con Jetpack Compose, di un rischio concreto: l’AI attinge anche a montagne di codice datato basato su XML o su vecchie versioni di Compose, con il pericolo di debito tecnico «fin dal giorno uno» per chi non ha le competenze per accorgersene.
Il fattore che fa la differenza: la struttura del progetto
Su un punto tutti concordano: più il progetto è organizzato, migliore è il risultato. Stefano Mondino lo sintetizza con un dettaglio pratico spesso sottovalutato — l'”incartellamento”. «Con una struttura molto solida e cartelle ben organizzate, il nome della cartella diventa direttamente contesto per l’AI. Claude funziona da Dio». Stessa logica per Federico Monti: nomi di file e cartelle sensati, documentazione interna e commenti riducono drasticamente la manutenzione finale.
Nativo o ibrido? La domanda cambia
Provocazione inevitabile: se con gli agenti posso generare buon codice nativo, ha ancora senso lo sviluppo ibrido? Le risposte convergono su un cambio di prospettiva più che su una tecnologia vincente.
Marco Gomiero invita a non irrigidirsi: «Lo shift da fare è non fossilizzarsi su nativo o multipiattaforma, ma usare ciò su cui l’agente lavora meglio. È anche un cambio di mentalità». Stefano Mondino riporta l’attenzione sulle persone: «Se ho un team iOS e uno Android molto skillati, lavoro per farli collaborare meglio e resto nativo, senza portarmi in casa i rischi di cambiamenti drastici di architettura». La scelta, insomma, dipende da tempo, budget, qualità richiesta e dalla squadra disponibile.
E il futuro? Mondino scommette su una divisione di ruoli piuttosto stabile: il nativo manterrà la sua fetta per le app premium ad alte prestazioni e forte integrazione con l’hardware, mentre i framework cross-platform come React Native e Flutter, sempre più assistiti dagli agenti, domineranno le app di servizio.
In sintesi
L’AI non è neutrale rispetto ai framework: riflette ciò che ha imparato, e ciò che ha imparato dipende da quanto codice esiste in circolazione. Sapere questo permette di scegliere con consapevolezza, dare le istruzioni giuste e strutturare i progetti in modo che l’agente lavori al meglio.
Nel terzo e ultimo articolo, affronteremo il tema più delicato: cosa resta insostituibilmente umano, dalla crescita dei junior alle aspettative dei clienti.
Serie in tre parti — Rivedi la Roundtable
Speaker: Federico Monti (MOLO17), Stefano Mondino (Synesthesia), Carlo Lucera (Pivotal Technologies), Marco Gomiero (Airalo / Google Developer Expert), Federico Nessi (Bitrock), Emanuele Maso (Bitrock), Alberto Dallaporta (Novalab), Mauro Marinello (Fortitude Group), Marco Riva (Fortitude Group).
Moderazione: Samantha Giro, Mobile Manager at Bitrock.