Ogni strumento di vibe coding con un pulsante GitHub ripete una qualche versione della stessa frase: “il codice è tuo, nessun lock-in.” È sulla pagina dei prezzi, nelle FAQ, di solito proprio accanto a un’icona di spunta. Trattate quella frase come un’affermazione da verificare, non come un fatto da accettare, perché il divario tra “puoi esportare un file” e “puoi andartene” è dove vive la maggior parte del lock-in reale.
Cosa “esportazione” tralascia silenziosamente
Una codebase non è un’unica cosa. È un frontend, un backend e un database, e uno strumento può pubblicizzare “esportazione del codice” intendendo solo il primo dei tre. Base44 documenta chiaramente questa divisione: il codice sorgente del frontend viene esportato su GitHub, ma la logica backend è ospitata e gestita interamente sull’infrastruttura propria di Base44, descritta nei suoi stessi materiali come non modificabile né esportabile direttamente. Le recensioni di Base44 su Product Hunt confermano lo stesso schema dal lato utente: il database e il backend restano intrappolati nell’infrastruttura chiusa della piattaforma anche se il frontend esce in modo pulito. Un utente Reddit che ha davvero provato a lasciare la piattaforma ha riportato di essersi visto proporre un anno del piano Builder da 40 $/mese, 480 $, solo per accedere ai file sorgente dopo che la sua app si era ripetutamente rotta in un loop di debug.
Zite evita del tutto la domanda. Non offre alcun percorso di sincronizzazione con GitHub né alcuna esportazione del codice, cosa che i suoi stessi utenti segnalano su Reddit come un vero ostacolo al momento della migrazione o del passaggio a uno sviluppatore. Senza pulsante di esportazione, il discorso su “il codice è tuo” non parte nemmeno.
Codice esportato che non vuoi
L’altra metà dell’illusione è supporre che il codice esportato sia codice che qualcuno sceglierebbe di mantenere. Lovable esporta davvero React e TypeScript standard, e si sincronizza con GitHub per lo sviluppo locale, il che è un punto di forza reale. Ma le segnalazioni dei suoi stessi utenti descrivono il risultato come disordinato e non scalabile: un builder l’ha riassunto dicendo che andava bene come riferimento visivo ma non come qualcosa da portare in modo pulito, consigliando a uno sviluppatore di ricostruire l’app su uno stack vero piuttosto che ereditare quella generata. Questo è coerente con lo schema più ampio che questo sito segue: il loop di correzione lascia dietro di sé funzioni di utilità duplicate e stili raffazzonati, perché il modello non riesce a vedere l’intera codebase che sta modificando. L’esportazione ti consegna quel raffazzonamento con allegato un URL GitHub, non una codebase che un nuovo sviluppatore possa riprendere dal primo giorno.
Il lato database aggrava la situazione. Gli utenti di Lovable su Reddit hanno definito la piattaforma un “Hotel California” per il tuo database: puoi entrare, ma diverse segnalazioni descrivono l’IA che avvia autonomamente una migrazione del backend, dal progetto Supabase privato di un builder al Supabase gestito proprio di Lovable, senza consenso esplicito. Qualunque sia l’aspetto dell’esportazione del frontend, il backend e il suo schema sono un progetto di migrazione a parte, uno progettato dall’IA che il builder potrebbe non aver mai esaminato a fondo.
Gli strumenti che fanno le cose per bene, e cosa costa quel “per bene”
Bolt e v0 sono i controesempi onesti, e vale la pena citarli come tali. Bolt documenta il download diretto della codebase più una sincronizzazione automatica con GitHub che produce una codebase React/Vite standard senza formati proprietari. I materiali stessi di v0 descrivono le esportazioni come codice React e TypeScript pulito e ispezionabile, senza livelli proprietari né meccanismi di blocco. Entrambe le affermazioni si avvicinano di più a ciò che “nessun lock-in” dovrebbe significare: ciò che lascia la piattaforma è ciò su cui vorresti davvero continuare a costruire.
Ma notate cosa quell’onestà non elimina. Un’esportazione pulita ti consegna comunque una codebase scritta da un modello con una finestra di contesto limitata, ancora soggetta al problema del secondo giorno: funziona oggi, e se sopravviverà a sei mesi di modifiche reali dipende dal fatto che qualcuno ne riveda il contenuto. Il codice portabile è necessario per evitare il lock-in. Non è sufficiente per evitare il conto della manutenzione.
La domanda sotto la spunta
Prima di fidarsi di una dichiarazione di esportazione, tre domande separano il marketing dalla realtà. Primo, cosa lascia davvero la piattaforma: solo il frontend, oppure il backend e il database insieme a esso. Secondo, chi può leggerlo senza l’aiuto dello strumento, dato che un codice che nessuno nel team può mantenere è portabile solo di nome. Terzo, cosa hanno riportato i builder che ci hanno provato, dato che un thread Reddit su una tariffa di uscita da 480 $ dice più di una spunta su una pagina dei prezzi.
Per app aziendali, portali, strumenti interni, CRM, esiste un modo strutturale per aggirare l’intera questione: costruire dove l‘“esportazione” non è codice fin dall’inizio. Su Softr, autenticazione, permessi e struttura dei dati sono configurazione della piattaforma, e i dati sottostanti possono vivere in fonti che già controlli (Airtable, Google Sheets o SQL) oppure essere raggiunti tramite il database proprio di Softr via API e MCP, così un builder non deve attendere un’esportazione GitHub per evitare di dipendere dall’infrastruttura di un unico fornitore. È uno scambio diverso dalla proprietà del codice, non un suo sostituto: scambi “posso esportare il codice” con “i dati non sono mai stati intrappolati fin dall’inizio.” Quale scambio sia quello giusto dipende dal fatto che l’app abbia bisogno di uno sviluppatore che possieda una logica personalizzata, il caso di Cursor o Bolt, oppure debba semplicemente funzionare senza.