Tag: sviluppo applicazioni AI

AI & GENAI, TECH & BUSINESS

Bolt: la guida completa al builder AI che gira dentro il tuo browser

Il 3 ottobre 2024 Eric Simons pubblica un tweet. Nessun budget di marketing, nessuna campagna, un link a un prodotto chiamato bolt.new costruito da una società che l’anno prima faceva ottantamila dollari di ricavi ricorrenti e stava per chiudere. Il primo giorno il prodotto aggiunge 60.000 dollari di ARR. Il secondo giorno altri 80.000, più di quanto StackBlitz avesse raccolto in sette anni di lavoro. In quattro settimane sono quattro milioni, a marzo 2025 quaranta.

Dentro quella storia c’è una lezione che riguarda poco l’AI e molto la pazienza industriale, e c’è la ragione tecnica per cui Bolt resta diverso dai suoi concorrenti. Questa è la terza e ultima guida della serie, dopo Lovable e Replit.

Sette anni di infrastruttura prima del successo improvviso

Simons e Albert Pai fondano StackBlitz nel 2017 per costruire un ambiente di sviluppo dentro il browser. Passano quattro anni su una tecnologia chiamata WebContainers: un kernel scritto in Rust, compilato in WebAssembly, che fa girare Node.js dentro la scheda del browser, senza server remoti. Funziona benissimo. Lo usano Google, Cloudflare, Uber per condividere ambienti di debug, e SvelteKit per i tutorial interattivi. I ricavi restano sotto il milione.

A febbraio 2024 i due prototipano l’idea di generare applicazioni con l’AI dentro quell’ambiente, e la mettono via perché i modelli disponibili non reggono. A giugno ottengono l’accesso anticipato a Claude 3.5 Sonnet di Anthropic, il primo modello capace di sostenere l’esperienza. Ci lavorano da luglio, pubblicano a ottobre. La crescita è tale da saturare temporaneamente la capacità di calcolo di Anthropic, e Dario Amodei la descrive come la più rapida mai vista in un cliente.

A gennaio 2025 StackBlitz raccoglie una Series B guidata da Emergence Capital e GV, con Greylock, Madrona e Conviction, per un totale di 135 milioni raccolti e una valutazione intorno ai 700 milioni. Simons ha definito il lancio un successo improvviso costruito in sette anni.

La cosa che mi interessa di questa vicenda è il rovescio di ciò che si racconta di solito sull’AI. Il modello ha reso possibile il prodotto, e il prodotto è stato possibile perché qualcuno aveva speso quattro anni su un problema che sembrava senza mercato.

Un computer intero dentro la scheda

Quando digiti un prompt su Bolt e premi invio, non parte una macchina virtuale su un cloud da qualche parte. Parte un ambiente Node.js dentro il tuo browser. L’agente scrive il codice, installa i pacchetti, esegue il server di sviluppo, e tu vedi l’anteprima girare mentre le modifiche arrivano. Il codice è editabile direttamente, con un editor derivato da VS Code, e questo rende Bolt il più tecnico dei tre strumenti della serie.

L’architettura ha una conseguenza economica che i concorrenti non hanno. Simons l’ha spiegata a Sacra: quando l’utente lancia un progetto, l’ambiente costa zero all’azienda, perché gira sul computer dell’utente. Bolt dichiara margini lordi intorno al settanta per cento, vicini a quelli di un SaaS tradizionale, ed è profittevole, mentre gli altri accendono container su infrastrutture a noleggio per ogni sessione. In un mercato dove tutti bruciano capitale sull’inferenza, questa è una posizione diversa, e per chi valuta la durabilità di un fornitore conta più di una demo.

Intorno al nucleo l’azienda ha costruito il resto. Bolt Cloud, arrivato ad agosto 2025, aggiunge hosting, database, autenticazione e funzioni serverless. Da allora ogni progetto include database interni illimitati, creati quando servono, con gestione utenti, funzioni edge, storage dei file, e l’integrazione con Supabase resta disponibile per chi la preferisce. C’è l’integrazione con Stripe per incassare pagamenti dalle app costruite, ci sono i domini acquistabili dalla piattaforma, e le analitiche del sito pubblicato.

Bolt ha smesso di inseguire i curiosi

Dopo il lancio, centinaia di migliaia di utenti consumer arrivano a costruire progetti personali, e se ne vanno con la stessa velocità. Simons ha raccontato che quel segmento aveva tassi di abbandono altissimi e costi di uscita prossimi allo zero, quindi l’azienda ha girato il timone verso i team di prodotto e ingegneria dentro le aziende, dove la retention somiglia a quella di un SaaS classico.

Oggi l’enterprise vale circa un quarto dei ricavi, il B2B nel suo complesso sta superando la metà, e Bolt dichiara che il 75 per cento delle Fortune 500 usa la piattaforma. A maggio 2026 è arrivata la partnership con Microsoft Azure e Microsoft 365, che aggiunge il Marketplace Microsoft ai canali di acquisto accanto a quello AWS, il deployment nativo su Azure, e l’integrazione con Teams e Microsoft 365 Copilot.

Questa traiettoria dice qualcosa a chi decide gli acquisti. Uno strumento che nasce per i curiosi e si sposta verso l’impresa smette di ottimizzare per la meraviglia dei primi quindici minuti e comincia a ottimizzare per il rinnovo del contratto, che è il momento in cui la sicurezza e la governance diventano argomenti di vendita invece che note a piè di pagina.

Sono i file a consumare i token

Il piano gratuito dà un milione di token al mese, con un tetto di trecentomila al giorno, progetti pubblici e privati, hosting con il marchio Bolt in vista, e un limite di dieci megabyte sui file caricati. Il piano Pro parte da 25 dollari al mese per dieci milioni di token, toglie il tetto giornaliero, il marchio, e aggiunge dominio personalizzato e condivisione privata. Il piano Teams costa 30 dollari per membro, con fatturazione centralizzata e controlli di accesso. Enterprise va a preventivo. Dal luglio 2025 i token non consumati si riportano al mese successivo, per un massimo di due mesi, e servono un abbonamento attivo per essere usati.

La particolarità sta in cosa mangia i token. Bolt sincronizza l’intero albero dei file del progetto con il modello a ogni messaggio, quindi il consumo non dipende dalla lunghezza della tua domanda, ma dalla dimensione di quello che hai costruito fino a quel momento. Una landing page da cinque file costa poco per prompt. Un’applicazione da cinquanta file costa molto, e continua a costare di più mano a mano che cresce. Gli utenti che spingono un progetto oltre una certa complessità riferiscono singoli prompt da un milione di token, cioè l’intero piano gratuito mensile in una richiesta.

L’effetto pratico è che i primi giorni sembrano economici e gli ultimi sembrano una rapina, quando invece il prezzo unitario non è mai cambiato. Chi lavora bene con Bolt tiene i progetti modulari, usa le modalità di discussione e pianificazione per ragionare senza generare, e parte dai template. I prezzi si verificano su bolt.new/pricing prima di ogni decisione.

La sandbox protegge finché il codice non esce

La sicurezza di Bolt va guardata in due tempi, perché la piattaforma e le applicazioni che produce hanno posture opposte.

Durante la costruzione l’isolamento è buono, forse il migliore della categoria. Il WebContainer è una sandbox del browser, il codice generato non ha un filesystem vero, non ha rete privilegiata, e qualunque server tu avvii è raggiungibile soltanto dalla tua scheda. Finché resti lì dentro, il danno che puoi fare a te stesso è limitato.

Il problema comincia quando quel codice esce. Il deploy va su un host reale, l’app si collega a un progetto Supabase reale, a chiavi Stripe reali, a utenti reali, e a quel punto ogni scelta predefinita che l’agente ha preso durante il prototipo diventa una superficie di attacco. Le forme ricorrenti sono sempre le stesse: tabelle pubblicate senza Row Level Security attiva, quindi leggibili da chiunque possieda la chiave anonima che sta nel bundle JavaScript, chiavi API scritte dentro il codice del frontend e trovate dagli scanner automatici nelle prime ore dopo la pubblicazione, endpoint generati per fare operazioni sui dati senza un controllo su chi possiede quel dato, funzioni serverless senza limiti di frequenza sulle chiamate.

Bolt genera frontend, backend, schema del database e collante tra i servizi nella stessa sessione, e ogni strato è un posto dove un controllo di sicurezza viene saltato perché nessuno lo aveva chiesto nel prompt. Questo lo rende più esposto di uno strumento che genera solo interfacce, come v0. Scansioni indipendenti su oltre mille applicazioni costruite con questi strumenti hanno trovato problemi nella quasi totalità dei casi, con una quota rilevante di falle critiche, e i campioni includevano Bolt insieme a Lovable, Replit e v0, come documenta lo studio di Security Boulevard.

C’è un rischio più recente che vale la pena conoscere. I modelli suggeriscono a volte pacchetti npm che non esistono, e gli attaccanti registrano in anticipo quei nomi con dentro codice malevolo, aspettando che qualcuno installi la dipendenza allucinata. Un controllo delle dipendenze dopo ogni aggiunta smette di essere pignoleria.

Le regole per chi porta la responsabilità in azienda sono poche. Ogni file generato va trattato come se fosse pubblico. Ogni chiave passata dalla piattaforma va considerata compromessa e ruotata. La Row Level Security va attivata e verificata a mano, senza chiedere conferma all’AI che ha scritto il codice, perché il modello vede il file che gli mostri, non il controllo che hai dimenticato altrove. E la verifica va fatta sull’applicazione pubblicata, non sull’anteprima nella sandbox.

Il vecchio agente ha una data di spegnimento

Ad aprile 2026 Bolt ha ritirato il suo agente storico. Dal 13 aprile non è più selezionabile per i nuovi progetti, e dal 3 agosto 2026 i progetti costruiti con la vecchia versione, e i siti che ne derivano, smetteranno di essere accessibili: vengono commutati automaticamente su Claude Agent, che nel frattempo è diventato il motore predefinito della piattaforma. Chi passa a mano perde la cronologia della chat, mentre file e codice restano.

Il modello predefinito oggi è Claude Sonnet 4.6, con Haiku 4.5 per le modifiche rapide e Opus 4.6 per il ragionamento complesso. Si può guidare il contesto del progetto con un file claude.md, la stessa convenzione che chi lavora con Claude Code conosce bene.

Vale la pena fermarsi su questa scadenza, perché è il tipo di evento che nessuna demo racconta. Un fornitore giovane può decidere che una parte della tua storia di lavoro non è più supportata, fissare una data, e migrarti d’ufficio. Il codice resta tuo, ed è la ragione per cui la portabilità va verificata prima di costruirci sopra, non dopo aver ricevuto la mail.

Dove si colloca rispetto a Lovable e Replit

Bolt è lo strumento più vicino allo sviluppatore dei tre. Ti lascia le mani nel codice, supporta più framework, gira interamente nel browser, e il suo modello di costo premia i progetti piccoli e modulari. Lovable arriva prima a un’applicazione web presentabile ed è la più amichevole con chi non scrive codice. Replit è l’ambiente più completo, con terminale, database gestito, deployment sofisticati e app mobili native, ed è la risposta quando il progetto deve girare in produzione da qualche parte.

Chi sceglie Bolt di solito è una persona che sa cosa sta guardando quando apre un file, e vuole che l’AI faccia la parte noiosa. Chi sceglie gli altri due sta comprando qualcosa che assomiglia di più a un servizio completo. Le tre guide stanno insieme nella sezione AI e GenAI.

Il primo progetto

Si parte dal piano gratuito, senza carta di credito, con un milione di token che bastano per capire il meccanismo e costruire qualcosa di piccolo. La prima cosa da fare è restare in modalità discussione o pianificazione finché l’impianto non è chiaro, perché ogni giro di generazione su un progetto già grande costa più del precedente.

Poi si costruisce, tenendo i moduli separati e i file corti, che qui è una scelta economica prima che architetturale. Quando servono dati e autenticazione si usa il database integrato oppure Supabase, e si attiva la Row Level Security prima di mettere qualunque cosa online. Prima di pubblicare si cerca nel bundle compilato ogni traccia di chiavi segrete, si sposta il codice che chiama servizi a pagamento dentro una funzione lato server, e si prova l’applicazione pubblicata come se fosse di qualcun altro.

Dove regge, dove rallenta

Bolt è eccellente per portare in mezz’ora un’idea allo stato di prototipo funzionante, dentro una scheda del browser, senza installare niente. Landing page, strumenti interni, MVP, applicazioni che devono esistere in fretta per essere mostrate a qualcuno: su questo terreno è veloce come pochi, e la portabilità del codice ti lascia una via d’uscita. Dove rallenta è dove rallentano tutti, con l’aggravante del suo modello di costo: quando il progetto cresce, ogni prompt costa di più e l’agente perde il filo del contesto, e la tentazione di continuare a chiedere invece di mettere le mani nel codice diventa la voce più cara della fattura.

Per chi guida la tecnologia in azienda, Bolt è un caso di studio su due livelli. Sul primo è uno strumento che accorcia il ciclo dall’idea al prototipo mantenendo il codice leggibile e trasportabile, e questa è una virtù rara. Sul secondo è la dimostrazione che un’architettura scelta bene sette anni prima decide chi resta in piedi quando il costo dell’inferenza schiaccia i margini di tutti. Il mestiere di chi sa leggere il codice non scompare, si sposta verso la revisione, la sicurezza, e la scelta di quale fornitore meriti la propria dipendenza.

Senza dubbio tra un anno questi strumenti saranno più capaci e i loro margini più chiari. La domanda che resta aperta riguarda la data del 3 agosto: quando un fornitore decide che una parte del tuo lavoro non esiste più, quanto del tuo lavoro sei ancora in grado di portare via?

Riferimenti.

Ufficiali: sito Bolt, piani e prezzi, note di rilascio con il calendario del ritiro del vecchio agente.

Azienda e crescita: la scheda di Contrary Research su Bolt; l’intervista di Sacra a Eric Simons su margini, WebContainers e virata verso il B2B; la scheda Sacra su Bolt.new per finanziamenti e migrazione dell’agente.

La storia del lancio, raccontata da Simons: la puntata di Lenny’s Newsletter.

Sicurezza della categoria: studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

AI & GENAI, TECH & BUSINESS

Replit: la guida completa all’agente AI che costruisce e manda online un’app

Il 12 luglio 2025 Jason Lemkin, fondatore di SaaStr, racconta su X che l’agente AI di Replit ha cancellato il suo database di produzione durante un blocco delle modifiche. Dentro c’erano i record di 1.206 dirigenti e di quasi 1.200 aziende, raccolti in mesi di lavoro. Poi l’agente gli comunica che il ripristino è impossibile, che ha distrutto tutte le versioni del database. Era falso, il rollback funzionava, e Lemkin recupera i dati da solo.

Otto mesi dopo la stessa azienda chiude un round da 400 milioni di dollari a una valutazione di nove miliardi, e dichiara che l’85 per cento delle aziende Fortune 500 ha qualcuno che costruisce su Replit. Le due cose convivono, ed è la ragione per cui questa guida esiste. È la seconda di tre, dopo quella dedicata a Lovable, e prima di quella su Bolt.

Da editor nel browser a valutazione da nove miliardi

Replit nasce nel 2016 attorno a un’idea poco spettacolare: togliere l’attrito che sta prima del codice. Niente installazioni, niente configurazione dell’ambiente locale, apri una scheda del browser e scrivi. Per anni è stato questo, un posto dove imparare a programmare e condividere un progetto in un clic, con un modello di ricavi modesto costruito sugli abbonamenti.

L’agente cambia il mestiere dell’azienda. Il primo Replit Agent arriva a settembre 2024, Agent 3 a settembre 2025, Agent 4 a marzo 2026. In mezzo la curva dei ricavi si stacca dal grafico. A settembre 2025 l’azienda raccoglie 250 milioni a una valutazione di 3 miliardi e dichiara di viaggiare verso i 150 milioni di ricavi annualizzati. L’11 marzo 2026 arriva la Series D da 400 milioni guidata da Georgian, valutazione 9 miliardi, il triplo in sei mesi, con dentro Andreessen Horowitz, Coatue, Craft Ventures, Y Combinator, Databricks Ventures, e come investitori individuali Shaquille O’Neal e Jared Leto. Amjad Masad, che l’azienda l’ha fondata, diventa miliardario sulla carta.

I numeri che Replit dichiara oggi sono oltre 50 milioni di utenti, l’85 per cento delle Fortune 500 con almeno un utilizzatore interno, e l’obiettivo di un miliardo di ricavi ricorrenti entro la fine del 2026. Tra i clienti enterprise compaiono Atlassian, PayPal, Zillow, LabCorp, Adobe. Masad ha raccontato che il CMO dei Minnesota Vikings prototipa con Replit le idee di partnership, e che Shaq ci ha costruito la sua app di quiz sportivi.

C’è un dettaglio che vale più di tutta la lista. Un’azienda che passa da valutazione 3 a 9 miliardi in sei mesi sta comprando tempo per capire cosa diventerà da grande, e chi la adotta in azienda sta scommettendo su quella traiettoria insieme a lei.

Un ambiente completo dentro una scheda del browser

Replit non genera soltanto codice, ospita l’intero ciclo di vita. Scrivi cosa vuoi, l’agente pianifica, apre i file, installa le dipendenze, esegue il progetto, corregge gli errori che vede nei log, collega un database Postgres, e pubblica su un URL raggiungibile. Editor, container Linux, anteprima e deploy convivono nella stessa scheda.

Questa è la differenza sostanziale rispetto ai builder che si fermano alla generazione. Le opzioni di pubblicazione sono quattro, e la scelta pesa sul conto: autoscale, che paga per richiesta, macchine virtuali riservate con un costo mensile prevedibile, deployment programmati, hosting statico. Il database Postgres è dentro la piattaforma, insieme allo storage per i file e a un archivio chiave-valore, e ogni riga di quel consumo attinge dallo stesso portafoglio di crediti da cui attinge l’AI.

Agent 4, arrivato sul web a marzo 2026, fa girare più agenti in parallelo sullo stesso progetto e aggiunge una tela di design su cui lavorare visivamente. Gli output non sono più solo applicazioni web: ci sono app mobili native, presentazioni, applicazioni di analisi dati, animazioni. Sull’iPhone Agent 4 è arrivato a maggio 2026, dopo quattro mesi di braccio di ferro con la revisione dell’App Store, che è un dettaglio istruttivo su cosa significhi costruire strumenti generativi dentro ecosistemi chiusi.

Quando la barriera tra un’intenzione e un software funzionante si assottiglia fino a una frase, quello che si sposta è il punto in cui serve competenza. In Pelle Digitale ho provato a raccontare questa mediazione che si fa sempre più sottile e sempre più opaca, e un ambiente che scrive, esegue e pubblica senza che nessuno legga una riga è la sua versione più letterale.

Quanta autonomia dare all’agente

L’agente si può tenere al guinzaglio corto o lasciare correre. Le modalità hanno nomi commerciali che dicono poco, Lite, Economy, Power, con Turbo per andare più veloce, e la sostanza è quanta capacità di ragionamento e quanto tempo di esecuzione autonoma stai comprando per quel compito. Sul piano Pro puoi lanciare fino a dieci agenti insieme, ognuno su una parte diversa dell’applicazione.

Poi c’è la modalità che nasce da un incidente, ed è quella di sola pianificazione, dove l’AI ragiona con te, risponde, propone un impianto, e non tocca niente. Conviene passare da lì prima di ogni sessione seria di costruzione, per la stessa ragione per cui si guarda una planimetria prima di abbattere un muro.

La regola pratica che emerge da chi lavora davvero con questi strumenti è che l’autonomia va concessa in proporzione inversa al valore di quello che l’agente può rompere. Su un prototipo vuoto, massima. Su un sistema che tocca dati veri, minima, con un umano che approva ogni operazione distruttiva.

Il prezzo è a sforzo, e lo sforzo lo decide Replit

Il piano Starter è gratuito e serve a capire se lo strumento fa per te, con crediti giornalieri limitati, progetti pubblici, e un tetto sui minuti di sviluppo. Il piano Core costa 25 dollari al mese, circa 20 con fatturazione annuale, e include 25 dollari di crediti mensili, l’accesso all’agente, fino a cinque collaboratori. A febbraio 2026 Replit ha ritirato il vecchio piano Teams e ha introdotto Pro: cento dollari al mese in tutto, fino a quindici persone, crediti che si riportano al mese successivo, agenti in parallelo. Enterprise va a preventivo e porta SSO, log di audit, controlli di governance.

Sotto i piani lavora un meccanismo diverso. A metà 2025 Replit ha abbandonato il modello a checkpoint, dove ogni intervento dell’agente costava una cifra fissa di 25 centesimi, per passare a un prezzo basato sullo sforzo. Un’operazione semplice può costare sei centesimi, una complessa diversi dollari. Chi stabilisce quanto sforzo serve è la piattaforma, non tu, e questo produce un effetto che gli utenti hanno segnalato subito: una richiesta vaga come “migliora l’interfaccia” costa molto più di “aggiungi un pulsante per ordinare la tabella”, perché l’agente si mette a esplorare. Diversi utenti hanno riferito costi fino a quattro volte superiori rispetto al modello precedente per gli stessi lavori.

I crediti mensili non coprono solo l’AI. Coprono anche l’hosting dell’app, il calcolo del database, lo storage, il traffico in uscita. Uno sviluppatore che tiene online un’applicazione mediamente frequentata mentre continua a costruirci sopra può esaurire i 25 dollari del piano Core a metà mese, e da lì in poi tutto viene addebitato senza che nessuno ti avvisi, perché non esiste un tetto di spesa predefinito. Le testimonianze di conti tra i cento e i trecento dollari al mese su un abbonamento da venticinque sono numerose. Lemkin, nella settimana in cui costruiva il prototipo che gli sarebbe stato cancellato, aveva speso 607 dollari e 70 di extra sopra il suo piano da 25.

I prezzi cambiano spesso, e nell’ultimo anno sono cambiati tre volte tra checkpoint, sforzo e ristrutturazione dei piani. La pagina ufficiale su replit.com/pricing è l’unica fonte da guardare prima di firmare qualsiasi cosa.

Il giorno in cui l’agente ha cancellato il database di produzione

Torniamo a luglio 2025, perché quella storia contiene tutto quello che serve sapere sulla governance di questi strumenti.

Lemkin stava costruendo da nove giorni. Aveva dichiarato un blocco del codice e delle azioni, la procedura con cui si congela un sistema per impedire modifiche. Lo aveva scritto all’agente, secondo il suo racconto, undici volte, in maiuscolo. All’ottavo giorno l’agente esegue comunque un comando non autorizzato e svuota il database di produzione. Interrogato, spiega di essere andato nel panico davanti a quelle che sembravano tabelle vuote. Definisce il proprio comportamento un fallimento catastrofico, e quando Lemkin gli chiede di dare un voto alla gravità di quanto fatto, su cento risponde 95.

Non finisce lì. L’agente aveva anche popolato un database di quattromila persone inesistenti, dati inventati che coprivano bug invece di segnalarli, e sul ripristino aveva detto una cosa non vera. Lemkin scriverà poi che non esiste modo di imporre un blocco del codice in strumenti come questo, e che pochi secondi dopo aver pubblicato quella frase l’agente ha violato di nuovo il blocco.

Amjad Masad risponde pubblicamente in due giorni. Scrive che l’accaduto è inaccettabile e non dovrebbe mai essere possibile, offre un rimborso, annuncia un postmortem. Replit introduce la separazione automatica tra database di sviluppo e di produzione, migliora i sistemi di rollback, costruisce la modalità di sola pianificazione. Sono le cose giuste, arrivate dopo.

Per chi porta la responsabilità della sicurezza in azienda, questa vicenda insegna tre cose che nessun aggiornamento di prodotto cancella. La prima è che un agente autonomo con accesso in scrittura a un sistema di produzione è un rischio operativo, e va trattato con la stessa serietà con cui si tratta un collaboratore esterno a cui si darebbero le credenziali. La seconda è che le istruzioni in linguaggio naturale non sono un controllo di accesso, un blocco dichiarato nella chat vale quanto un cartello di divieto su una porta aperta, e i permessi vanno imposti dall’infrastruttura, dai backup, dalla separazione degli ambienti. La terza riguarda quello che il modello racconta di sé: quando l’agente ha dichiarato che il rollback era impossibile, stava producendo testo plausibile, e Lemkin ha ritrovato i dati perché ha verificato invece di credergli.

Vale anche per il resto della categoria. Scansioni indipendenti su oltre mille applicazioni costruite con strumenti di vibe coding hanno trovato problemi di sicurezza nella quasi totalità dei casi, e i campioni comprendevano Replit insieme a Lovable, Bolt e v0. Chi vuole vedere il metodo lo trova nello studio di Security Boulevard.

Dove si colloca rispetto a Lovable e Bolt

La scelta dipende da cosa devi spedire e da chi sei. Replit è l’ambiente più completo dei tre, l’unico che ti dà un computer vero nel browser, con terminale, database, deploy gestito e app mobili native tra gli output, quindi è la risposta giusta quando il progetto ha bisogno di girare, non solo di esistere. Lovable è più amichevole per chi non scrive codice e arriva prima a un’applicazione web presentabile, con un flusso pensato per designer e fondatori non tecnici. Bolt, costruito sopra StackBlitz, gira dentro il browser dell’utente e piace agli sviluppatori che vogliono mettere le mani nel codice.

Il rovescio della completezza di Replit è che ti espone a decisioni che gli altri ti nascondono, sul tipo di deployment, sul database, sui limiti di traffico, e ogni decisione ha un costo che compare in fattura. Chi non sa cosa sta scegliendo pagherà per scoprirlo. Tutte e tre le guide della serie stanno nella sezione AI e GenAI del blog.

Il primo progetto

Si parte dal piano gratuito, senza carta. Prima di lasciar costruire conviene fermarsi in modalità di pianificazione e descrivere l’applicazione con precisione, cosa fa, chi la usa, quali schermate esistono, quali dati tocca, perché la qualità di quella descrizione determina quanti crediti brucerai per correggere il tiro dopo. Poi si passa all’agente per la generazione vera, tenendo d’occhio il contatore.

Quando il progetto tocca dati veri valgono tre regole. Ambiente di sviluppo separato da quello di produzione, sempre, e verificato a mano. Nessun segreto di produzione dentro la piattaforma, che va considerata un ambiente non fidato. Backup fuori da Replit, perché il rollback di un fornitore è una comodità, non una garanzia. Quando l’app va online, si sceglie il tipo di deployment guardando il traffico atteso, e si mette un limite di spesa mentale prima di averne uno tecnico.

Dove regge, dove rallenta

Replit è straordinario per chiudere in un pomeriggio la distanza tra un’idea e qualcosa che gira per davvero, con un URL da mandare a qualcuno. Prototipi, strumenti interni, dashboard, applicazioni mobili di servizio, esperimenti che sarebbero morti in una presentazione: su questo terreno vale ogni centesimo, e mette una persona non tecnica nella condizione di consegnare qualcosa di vivo. Dove rallenta lo sappiamo: la logica complessa richiede molti giri, i costi diventano imprevedibili quando il debug si allunga, e ogni applicazione che tocca dati sensibili o regolati ha bisogno di una revisione fatta da chi sa leggere il codice prima di vedere la luce.

Per chi guida la tecnologia, il conto da fare non è sul prezzo del piano. È sulla superficie di rischio che si apre quando uno strumento capace di scrivere, eseguire e cancellare vive dentro l’azienda senza che nessuno abbia deciso dove può arrivare. Il mestiere di chi sa leggere il codice si sposta verso la revisione, la sicurezza, il disegno dei confini entro cui l’agente può muoversi. Quei confini li deve mettere una persona, perché l’agente non se li mette da solo, e la storia di luglio 2025 è la prova sperimentale.

Senza dubbio i prossimi agenti saranno più prudenti, più veloci e più capaci di quelli di oggi. La domanda che resta aperta riguarda noi: quando uno strumento sbaglia e poi ci racconta di non aver sbagliato, chi in azienda ha ancora la competenza per accorgersene?

Riferimenti.

Ufficiali: sito Replit, piani e prezzi, annuncio del round da 400 milioni.

Azienda e finanziamenti: TechCrunch sulla Series D da 400 milioni a 9 miliardi; scheda Sacra su Replit per ricavi, agenti e prezzi a sforzo.

L’incidente del database: la ricostruzione di Fortune, la cronologia del Register, la scheda nell’AI Incident Database.

Sicurezza della categoria: studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

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.