Tag: sviluppo applicazioni AI

AI & GENAI, TECH & BUSINESS

Lovable: la guida completa al builder AI che trasforma un prompt in un’app

A dicembre 2025 Lovable ha chiuso un round da 330 milioni di dollari a una valutazione di 6,6 miliardi. Diciotto mesi prima era l’app commerciale di un progetto open source che Anton Osika aveva chiamato GPT Engineer. In mezzo ci stanno otto milioni di utenti, più di centomila progetti creati ogni giorno, e oltre metà delle aziende Fortune 500 che la usano in qualche forma. La corsa è vera, e i numeri raccontano una corsa. A me interessa soprattutto il suo rovescio: oggi milioni di persone costruiscono software descrivendolo a parole, e quasi nessuna di loro saprebbe leggere il codice che ne esce.

Questa guida prova a dire cosa fa davvero Lovable, quanto costa, dove regge e dove si rompe, e quando vale la pena affidargli un progetto invece che a una persona. È la prima di tre, perché subito dopo arrivano Bolt e Replit, gli altri due nomi che chiunque incontri quando entra in questo territorio.

Da GPT Engineer a una valutazione da sei miliardi

Nel 2023, a Stoccolma, Osika rilascia GPT Engineer: software open source che usa un modello linguistico per scrivere intere applicazioni da una descrizione. Con Fabian Hedin ne fa una versione commerciale, la GPT Engineer App, e a dicembre 2024 la ribattezza Lovable aprendo l’accesso pubblico. Da lì la traiettoria diventa difficile da raccontare senza sembrare iperbolici.

A luglio 2025 il primo round serio, 200 milioni di Series A guidata da Accel, valutazione 1,8 miliardi. A novembre, sul palco di Slush a Helsinki, Osika annuncia 200 milioni di ricavi ricorrenti annui, il doppio rispetto a quattro mesi prima, quando l’azienda aveva passato i 100 milioni di ARR. Lui stesso lo descrive come la crescita più rapida nella storia del software, più veloce di OpenAI e di Cursor. A dicembre arriva la Series B da 330 milioni guidata da CapitalG e Menlo Ventures, con dentro anche Khosla, Salesforce Ventures e Databricks Ventures, a quei 6,6 miliardi che triplicano la valutazione in cinque mesi.

C’è un dettaglio che dice molto sul personaggio. Osika ha resistito alla pressione di trasferire l’azienda nella Silicon Valley, e attribuisce a quella scelta buona parte del risultato. Lovable resta svedese, con un organico piccolo rispetto ai ricavi, al punto che a marzo 2026 TechCrunch raccontava di 100 milioni di ricavi aggiunti in un solo mese con poco più di centoquaranta persone a libro paga. Tra i clienti compaiono Klarna, Uber, Zendesk. Non tutto è stato lineare: a novembre 2025 l’azienda è finita sotto accusa per non aver versato l’IVA dovuta in Svezia, un episodio che vale la pena tenere a mente quando si valuta la solidità di un fornitore così giovane e così veloce.

Per chi guida la tecnologia in azienda, il punto da registrare è semplice. Lovable ha smesso di essere un giocattolo per smanettoni ed è diventata a tutti gli effetti un fornitore enterprise, con tutto quello che questo comporta in termini di dipendenza, sicurezza e continuità.

Cosa succede quando descrivi l’app che vuoi

Scrivi cosa vuoi costruire, in linguaggio naturale, e Lovable genera un’applicazione full-stack completa. Il frontend esce in React con TypeScript e Tailwind CSS, il backend si appoggia a Supabase per database Postgres e autenticazione, e il tutto viene messo online su un URL pubblico con un clic. Da quel momento iteri conversando: chiedi una modifica, l’app cambia, ti accorgi di un errore, lo segnali, riprovi.

La parte che fa la differenza rispetto ai vecchi strumenti no-code è la portabilità del codice. Lovable mantiene una sincronizzazione bidirezionale con GitHub, quindi il progetto vive in un repository Git reale, e quel codice è tuo. Lo puoi esportare, estendere, far leggere a uno sviluppatore, oppure portarlo via del tutto. Non resti chiuso dentro un ecosistema visuale proprietario, che è esattamente la trappola in cui finivano le generazioni precedenti di costruttori senza codice.

Intorno al nucleo si sono accumulate funzioni che riducono i passaggi. La generazione di immagini è integrata nel builder, da marzo 2026 anche con sfondo trasparente, comoda per icone e illustrazioni di servizio senza uscire verso un altro strumento. C’è una modalità vocale per descrivere le modifiche parlando. E a marzo 2026 Lovable ha allargato il perimetro oltre le app, verso analisi dati, business intelligence, presentazioni e flussi di marketing, segno di un’ambizione che va ben oltre il prototipo.

Quello che cambia, sotto la superficie del prodotto, è chi può costruire. Quando l’interfaccia tra un’intenzione e un software diventa una frase scritta o detta, la barriera tecnica si abbassa di colpo e si sposta altrove. In Pelle Digitale ho provato a descrivere proprio questo, la mediazione tra la mente e gli strumenti che la estendono, e Lovable è uno degli esempi più nitidi di quella mediazione spostata sul linguaggio.

Come si pilota la generazione

Non c’è un solo modo di lavorare a un progetto, ce ne sono diversi, ognuno adatto a un momento. Agent Mode è la modalità autonoma: l’AI esplora il codice da sola, individua e corregge errori in modo proattivo, cerca informazioni sul web e ragiona su più passaggi prima di agire. Plan Mode, che prima si chiamava Chat Mode, è il suo opposto controllato: ragiona, pianifica, risponde a domande e aiuta a fare debug, ma non tocca il codice, ed è il posto giusto dove pensare un progetto prima di lasciarlo costruire.

Poi c’è la mano diretta. Visual Edits permette di cliccare su un elemento dell’interfaccia e cambiarne lo stile senza scrivere un prompt, utile a chi pensa per immagini più che per istruzioni. Dev Mode apre il codice e lo lascia modificare dentro Lovable, per i tecnici che vogliono mettere le mani dove l’AI non arriva. Le modifiche di solo testo e contenuto non consumano crediti, dettaglio che conta più di quanto sembri quando si guarda il conto a fine mese.

Quasi tutto questo è arrivato con Lovable 2.0, la versione che nella primavera del 2025 ha introdotto il lavoro in multiplayer, con workspace condivisi e fino a venti collaboratori, la scansione di sicurezza nel momento della pubblicazione, e la modalità di editing del codice. Da allora il prodotto ha continuato a crescere, ma è quella la base su cui si regge oggi l’esperienza d’uso.

Quanto costa, e quanto costa davvero

Il piano gratuito esiste e si usa, senza carta di credito. Dà cinque crediti al giorno con un tetto mensile intorno ai trenta, progetti pubblici ospitati su dominio lovable.app, branding di Lovable in vista, e nessuna possibilità di acquistare crediti extra o di aprire il codice. Basta per validare un’idea, non per costruirci sopra sul serio.

Il piano Pro parte da 25 dollari al mese, circa 21 con fatturazione annuale, e porta cento crediti mensili, progetti privati, dominio personalizzato, rimozione del branding, accesso al codice e crediti che si accumulano da un mese all’altro se non li usi. Il piano Business sale a 50 dollari al mese e aggiunge quello che serve a un team: SSO, controlli di accesso, fatturazione centralizzata, limiti di credito per singolo utente. Il piano Enterprise va a preventivo e mette sul tavolo SCIM, log di audit, attestazione SOC 2 e supporto dedicato.

Il meccanismo a crediti è semplice nella forma. Ogni interazione con l’AI ne consuma, le operazioni più complesse e quelle in Agent Mode ne consumano di più, le modifiche manuali non ne consumano affatto. Il problema arriva quando si traduce in conto reale. Chi ha spedito davvero un’applicazione lo racconta sempre allo stesso modo: i crediti bruciano più in fretta di quanto il piano lasci immaginare, e la spesa effettiva tende a essere due o tre volte quella nominale. A questo si aggiunge il backend, perché Supabase ha i suoi costi oltre il piano gratuito, a partire da circa 25 dollari al mese quando l’app supera i limiti di database, autenticazione o storage, e si aggiunge il dominio. Un piano da venti diventa facilmente un conto da sessanta o ottanta.

Rispetto a strumenti che chiedono una quota fissa mensile senza contatore a prompt, come Cursor, v0 o Windsurf, il modello a crediti di Lovable è più generoso sul lavoro semplice e meno prevedibile su quello complesso, soprattutto quando il debug si allunga. Nella comunità è emerso un flusso di lavoro che dice molto: si costruisce il settanta o ottanta per cento del progetto in Lovable, dove prototipare è rapido ed economico, poi si esporta su GitHub e si finisce in Cursor. I prezzi cambiano spesso, quindi la pagina ufficiale resta l’unica fonte da verificare prima di decidere, e la trovi su lovable.dev/pricing.

La Row Level Security e i dati usciti da Lovable

A maggio 2025 il ricercatore Matt Palmer documenta una vulnerabilità che diventa CVE-2025-48757. Oltre 170 applicazioni costruite con Lovable avevano il database completamente esposto, senza Row Level Security attiva. I dati raggiungibili comprendevano email e indirizzi di casa, informazioni finanziarie, chiavi API e storici di pagamento. Una sola di quelle app esponeva i dati di tredicimila utenti. Per leggerli non servivano credenziali: bastava la chiave pubblica che sta nel codice del frontend.

La radice tecnica merita di essere capita, perché spiega un’intera categoria di problemi. Supabase espone tutte le tabelle tramite API per impostazione predefinita. La chiave anonima è pubblica, vive nel bundle JavaScript che ogni visitatore può ispezionare. L’unica cosa che impedisce a chiunque di leggere e scrivere il database sono le policy di Row Level Security, e se quelle policy non vengono attivate e configurate a mano, il database è di fatto un’API pubblica aperta a tutti. Il problema non è il codice che Lovable scrive, è quello che non scrive: i controlli di sicurezza che nessuno ha pensato a chiedergli. Un ricercatore l’ha sintetizzato così: l’AI fa quello che le chiedi, non pensa mai a quello che non le hai chiesto.

Non è un caso isolato e non riguarda solo Lovable. Scansioni indipendenti su oltre mille applicazioni costruite con strumenti di vibe coding e appoggiate a Supabase hanno trovato problemi di sicurezza in circa il 98 per cento dei casi, con il 16 per cento di falle critiche, e i campioni includevano anche v0, Bolt e Replit. È un problema di categoria, legato all’architettura client più al modello generativo che a un singolo prodotto. Va detta però anche la parte scomoda per Lovable: secondo un audit successivo, l’autorizzazione interna della stessa piattaforma è rimasta esposta per settimane dopo la segnalazione, il che indebolisce l’argomento secondo cui la responsabilità sarebbe tutta di chi configura male l’app.

Lovable ha risposto con un Security Scan integrato nel momento della pubblicazione per le app collegate a Supabase, e con un Security center che controlla chiavi API esposte, policy RLS, dipendenze datate. È un passo avanti che resta acerbo. Per chi porta la responsabilità della sicurezza in azienda, le regole pratiche sono poche e nette. Niente segreti di produzione dentro gli strumenti di coding AI, che vanno trattati come ambienti non fidati. RLS attiva su ogni progetto, verificata a mano e non chiedendo conferma all’AI che l’ha generata. E una valutazione del rischio fornitore identica a quella che si farebbe per qualunque altro responsabile del trattamento dei dati, con le implicazioni che questo porta su SOC 2 e ISO 27001. Se è il tipo di governance che serve impostare, è esattamente la conversazione che faccio con le aziende prima che un prototipo scivoli silenziosamente in produzione.

Dove si colloca rispetto a Bolt e Replit

Nessuno di questi strumenti è uguale agli altri, e la scelta dipende da chi sei e da cosa devi spedire. Lovable offre l’esperienza più completa appena aperta la scatola, con backend, editing visivo e modalità agente già pronti, ed è la più amica dei designer e di chi non scrive codice. Bolt, costruito sopra StackBlitz, dà più flessibilità tecnica, supporta più framework, lascia editare il codice in modo diretto e gira interamente nel browser, e tende a piacere di più agli sviluppatori. Replit, con il suo Agent, è un ambiente di sviluppo completo che arriva fino alle app mobili native via React Native, quindi quando serve il mobile vero è la risposta più solida. v0 di Vercel genera componenti di interfaccia eccellenti e pubblica in fretta, ma parla a chi conosce già React. Base44 toglie ogni decisione di configurazione ed è la via più rapida per un fondatore senza competenze tecniche.

Su questa mappa entro nel dettaglio nelle prossime due guide del blog, dedicate a Bolt e a Replit, che raccolgo insieme a questa nella sezione AI e GenAI. Qui basta la posizione: Lovable è il punto di riferimento per le app web full-stack con un flusso amichevole, e il confronto si gioca sul resto.

Il primo progetto

Si parte dal piano gratuito, senza carta. La descrizione iniziale conta più di tutto il resto, quindi vale la pena essere precisi su cosa fa l’app, chi la usa e quali sono le schermate principali, invece di affidarsi a una frase generica. Prima di lasciar costruire conviene passare da Plan Mode per ragionare sull’impianto, poi attivare Agent Mode per la generazione vera. Quando servono dati e login si collega Supabase, e a quel punto la regola è una sola: lanciare il Security Scan prima di pubblicare e verificare a mano che la Row Level Security sia attiva, senza fidarsi della conferma dell’AI. Infine si sincronizza il progetto con GitHub, così il codice resta portabile, e si collega un dominio personalizzato. La spesa la si lascia crescere quando si toccano i limiti, non prima.

Dove regge, dove rallenta

Lovable è straordinario per comprimere la distanza tra un’idea e qualcosa di vivo. MVP, prototipi di SaaS, landing page, strumenti interni, portali cliente e dashboard, demo da mettere in mano a qualcuno la settimana stessa: su tutto questo regge benissimo, e mette un fondatore non tecnico o un product manager nella condizione di spedire un prodotto reale senza un team di sviluppo. Dove rallenta è prevedibile. La logica custom complessa richiede più giri, i casi limite vanno chiariti uno per uno, e qualunque applicazione che maneggi dati sensibili o regolati non dovrebbe vedere la luce senza una revisione di sicurezza fatta da chi sa leggere il codice.

Questi strumenti generano un buon punto di partenza, non un sistema finito. Una produzione vera ha ancora bisogno di revisione del codice, di un’architettura pensata, di test e di manutenzione nel tempo, e nessuno di questi passaggi sparisce perché l’app è nata da un prompt. Per chi guida la tecnologia, Lovable è due cose insieme: un modo legittimo per accorciare il ciclo dall’idea al prototipo, e una responsabilità di governance nel momento in cui qualcuno prova a spingere quel prototipo in produzione senza che nessuno lo abbia controllato. Il mestiere di chi sa leggere il codice non scompare, si sposta verso la revisione, la sicurezza, i casi che l’AI non vede.

Senza dubbio questi strumenti diventeranno più sicuri e più capaci. La domanda che resta aperta è un’altra: quando descrivere un’applicazione diventa facile come dirla a parole, chi si prende la responsabilità di quello che quell’applicazione fa nel momento in cui nessuno la sta guardando?

Trasparenza: i link a Lovable nel corpo di questa pagina sono referral. Le valutazioni del pezzo, inclusa la parte sulla sicurezza, restano quelle che avrei scritto senza. I link qui sotto sono diretti.

Riferimenti.

Ufficiali: sito Lovable, documentazione, annuncio Lovable 2.0, piani e prezzi, FAQ sicurezza.

Azienda e finanziamenti: scheda Wikipedia; TechCrunch sulla Series B da 330 milioni a 6,6 miliardi e sui 200 milioni di ARR con la scelta di restare in Europa.

Analisi e recensioni indipendenti: UI Bakery, No Code MBA sui prezzi.

Sicurezza: Superblocks sulla CVE-2025-48757, studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

AI & GENAI

Il vero glitch dell’AI non è nel codice. È nel lessico del mercato.

Una soluzione che assomiglia a HubSpot, una che somiglia a YouTube ma fa video lezioni, una che è il clone di Instagram, e un’altra che replica un sistema di analytics tipo Google. Tutto nasce in poche ore con l’AI e, ormai, non stupisce più nessuno.

Questo, di per sé, è già un fatto enorme. Riduce i tempi, abbassa il costo iniziale, rende concreta un’idea quasi subito e cambia profondamente il modo in cui si passa dall’intuizione a qualcosa di tangibile. Per chi lavora su prodotto, innovazione, venture building o validazione, non è un miglioramento incrementale ma uno spostamento reale delle dinamiche iniziali. Cambiano le logiche con cui si esplora, si testa, si racconta un’idea, e allo stesso tempo si aprono opportunità che fino a poco tempo fa erano molto più costose, lente o semplicemente non accessibili.

Il punto, però, non è stabilire se questa accelerazione esista, perché è evidente che esista. Il punto è capire dove stia realmente avvenendo e, soprattutto, dove invece crediamo che stia avvenendo senza che sia così. In altre parole, la domanda non è “quanto siamo diventati veloci”, ma “che cosa abbiamo davvero reso più veloce”.

Il glitch più interessante, infatti, non è tecnico. È nel modo in cui il mercato interpreta quello che vede. Sempre più spesso una demo interattiva, ben costruita e coerente, viene letta come prodotto, oppure un prototipo credibile viene promosso a MVP senza aver attraversato quel passaggio che trasforma qualcosa di funzionante in qualcosa di utilizzabile, affidabile e sostenibile nel tempo. Non si tratta di un errore ingenuo, ma di una distorsione percettiva: la qualità della rappresentazione è talmente alta da anticipare la percezione di maturità.

Da qui iniziano a generarsi effetti concreti. Si costruiscono aspettative su basi non ancora solide, si prendono decisioni operative partendo da un livello di maturità che è solo apparente, si impostano conversazioni con investitori, clienti e team come se alcune fasi fossero già state superate. In realtà, molto spesso, devono ancora iniziare.

Se torniamo al significato originario di MVP nel contesto Lean, la distanza diventa evidente. MVP non è mai stato “il minimo software funzionante”, né la prima versione che riesce a girare. È il minimo investimento necessario per verificare un’ipotesi rilevante con utenti reali, producendo apprendimento reale. Il focus non è sulla costruzione, ma sulla validazione. Non sull’impressionare, ma sul capire.

È qui che oggi si crea una frattura. La presenza di un’interfaccia funzionante, spesso molto convincente, tende a essere letta come evidenza di validazione, quando in realtà è soltanto evidenza di fattibilità. Ma fattibilità e validazione sono due piani completamente diversi. Un MVP può anche non essere software: può essere una landing page, un concierge test, un prototipo assistito, un processo manuale. Ciò che lo definisce non è la quantità di codice deployato, ma la qualità dell’apprendimento che genera.

Il fatto che oggi si riesca a costruire rapidamente qualcosa che “sembra un prodotto” non significa che si sia più vicini al mercato, ma che si è diventati molto più efficienti nel rappresentarlo. E questa distinzione è tutt’altro che semantica, perché ha impatti diretti su come si leggono i progressi, si allocano risorse e si prendono decisioni.

Una demo, in questo senso, è una promessa interattiva. Può essere estremamente utile per chiarire un’idea, per allineare persone, per esplorare possibilità. Personalmente ne faccio molte, proprio perché consentono di accelerare il confronto e rendere visibile qualcosa che altrimenti resterebbe astratto. In alcuni casi possono anche essere strumenti validi per testare specifiche ipotesi. Ma nella maggior parte delle situazioni restano rappresentazioni, non ancora sistemi pronti per essere esposti a un uso reale e continuativo.

Quello che si osserva spesso è che si rimane nella zona dell’Idea MVP, a volte si entra in quella dell’esperimento, ma solo raramente si arriva a un vero Product MVP. E la differenza non è una questione di etichette, ma di implicazioni operative. Trattare un’idea resa visibile come se fosse già un prodotto porta inevitabilmente a una lettura distorta del lavoro che resta da fare, con una tendenza sistematica a sottostimarlo.

Detto questo, liquidare tutto come hype sarebbe una semplificazione sbagliata. La componente positiva è concreta e rilevante. L’AI ha ridotto drasticamente il costo della prototipazione, ha accelerato la possibilità di esplorare alternative, ha reso più rapido il passaggio da intuizione a primo riscontro. Questo incide direttamente sul modo in cui si lavora: si possono fare più tentativi, iterare più velocemente, eliminare prima le ipotesi deboli e concentrare energie su quelle che mostrano segnali migliori.

Anche il processo di validazione può beneficiarne, non perché venga automatizzato, ma perché diventa più efficiente. Il giudizio resta umano, ma il percorso che porta a esercitarlo è meno costoso e più rapido. Inoltre, si abbassa la barriera di accesso: più persone riescono a dare forma a un’idea e a portarla a un livello minimo di tangibilità.

Il problema emerge quando questa accelerazione viene interpretata come se riguardasse l’intero ciclo di vita del prodotto. In realtà riguarda soprattutto la fase iniziale, quella in cui qualcosa diventa visibile, comprensibile, dimostrabile. È la fase in cui si costruisce una rappresentazione credibile, non quella in cui si costruisce un sistema robusto.

Ed è proprio qui che si crea la distorsione più rilevante: la qualità della rappresentazione anticipa la percezione di completezza. Si ha l’impressione di essere molto più avanti di quanto si sia realmente, perché ciò che si vede è già molto vicino alla forma finale. Ma ciò che non si vede, e che determina la reale capacità di stare sul mercato, non è stato ancora affrontato.

Basta spostarsi su un caso concreto per rendersene conto. Una chat che funziona in demo non ha ancora incontrato gran parte delle condizioni reali in cui dovrà operare: gestione dei ruoli, permessi incoerenti, utenti duplicati, allegati pesanti, notifiche errate, carichi concorrenti, gestione degli errori, audit log, retention dei dati, backup, moderazione, abuso, dispositivi non performanti, connessioni instabili, recupero degli account. E questo ancora prima di entrare in temi come privacy, compliance, accessibilità, localizzazione o sostenibilità dei costi infrastrutturali.

Non si tratta di “il dopo”. È parte integrante del prodotto.

È in questo passaggio che qualcosa smette di essere credibile e inizia a essere affidabile, e il salto tra le due condizioni è esattamente quello che oggi rischia di essere sottovalutato. Il lavoro più impegnativo non è stato eliminato, ma semplicemente spostato fuori dal primo campo visivo, quello che oggi viene compresso e accelerato.

Nella pratica, è questo il punto che vedo più spesso frainteso. La prodottizzazione non coincide con la costruzione di feature, ma con la capacità di farle vivere in un contesto reale, nel tempo, senza frizioni sistemiche e senza richiedere interventi continui. Quando questo passaggio viene sottovalutato, nelle startup si generano errori di pianificazione e di aspettativa, mentre nelle aziende più strutturate si rischia di abbassare la soglia di qualità e controllo, perché la rappresentazione iniziale è già sufficientemente convincente da sembrare “abbastanza”.

Questa dinamica non è nuova. Si è già vista in altre fasi del digitale, anche se con velocità diverse. Quando i CMS hanno reso semplice pubblicare contenuti, per un periodo si è confuso il fatto di avere un sito con l’avere una strategia digitale. Quando il cloud ha reso accessibile l’infrastruttura, l’accesso è stato scambiato per capacità di gestione. Quando i social hanno abbassato la barriera di pubblicazione, la produzione di contenuti è stata confusa con la comunicazione. In tutti questi casi è cambiato il livello di astrazione, ma non la natura del lavoro sottostante.

La differenza oggi è la rapidità con cui questa compressione avviene. E quando le fasi iniziali si comprimono così tanto, il mercato tende a riscrivere il significato delle parole. Prototipo diventa prodotto, esperimento diventa MVP, una prima forma convincente viene interpretata come maturità. In realtà, spesso, si tratta di una rappresentazione molto più efficace di quanto fosse possibile in passato, non di una reale evoluzione dello stato del sistema.

Questo non è un motivo per prendere le distanze dall’AI, anzi. Sarebbe una lettura miope. È uno strumento estremamente potente e destinato a incidere profondamente sul modo in cui costruiamo. Ma proprio per questo va compreso con lucidità. Non è una scorciatoia universale, è un acceleratore selettivo. Aumenta la produttività in alcune fasi, ma non elimina la complessità complessiva, che tende piuttosto a redistribuirsi.

Siamo in una fase fisiologica, in cui stiamo imparando a usare qualcosa mentre ne stiamo ancora esplorando i confini. Il potenziale è evidente, i limiti molto meno. È una dinamica ricorrente: quando il livello di astrazione cambia rapidamente, l’entusiasmo anticipa il metodo e la disciplina arriva solo in un secondo momento.

Col tempo, il mercato torna a distinguere. Tra ciò che è dimostrabile e ciò che è sostenibile, tra ciò che appare funzionante e ciò che regge nel tempo, tra ciò che convince in una demo e ciò che può essere davvero utilizzato su scala.

L’AI ha reso molto più veloce l’inizio. Non ha reso automaticamente più semplice tutto ciò che viene dopo. Un’idea può diventare visibile in poche ore; trasformarla in qualcosa di utile, affidabile e difendibile resta un percorso che richiede ancora metodo, competenze e capacità di lettura molto più profonde.