Sito creato con l'AI: i 5 problemi che lo bloccano quando cresce

Un sito creato con un builder AI funziona dal primo giorno. I guai arrivano verso la decima modifica: una funzione nuova ne rompe due vecchie, una pagina che si apriva in un secondo ora ne chiede quattro, e nessuno sa dire quali righe del database può leggere un visitatore non autenticato. Sono i problemi dei siti creati con l'AI che emergono quando arrivano utenti veri, e hanno una causa comune. Il builder ha scritto ogni pezzo di codice per rispondere a un singolo prompt, e nessuno ha scritto il progetto che tiene insieme i pezzi.

Un builder AI è uno strumento che trasforma una richiesta scritta in un sito o in una web app funzionante, codice e hosting compresi. La categoria comprende i prodotti che passano dal prompt all'app e le modalità AI che ormai offrono anche i site builder tradizionali. Per una prima versione sono veloci e spesso bastano. Qui parliamo di cosa succede dopo: i cinque limiti che bloccano la crescita di un sito fatto con l'AI, quanto costa ciascuno e come rimettere in piedi un sito che li ha già incontrati.

Come si riconosce un sito fatto con l'AI che non regge più la crescita?

I segnali sono facili da riconoscere, una volta che li conosci:

• Ogni prompt sistema una cosa e ne rompe un'altra, e ogni modifica richiede più tempo della precedente.
• La stessa logica compare in tre o quattro file, ogni volta un po' diversa.
• Le pagine escono su Google ma mai nelle risposte di ChatGPT o di Claude.
• Nel team nessuno sa dire chi può leggere quale tabella.
• Il codice sta sui server del builder, e andarsene vorrebbe dire ricominciare da zero.

Uno di questi segnali è un bug. Tre insieme vogliono dire che il sito è arrivato alla dimensione in cui i prompt da soli non bastano più.

Perché un sito fatto con l'AI smette di crescere?

Un prompt è una richiesta locale. Il modello legge una parte del progetto, scrive la modifica più breve che soddisfa la richiesta e passa oltre. Per lui aggiungere un blocco nuovo costa meno che riordinarne tre vecchi, quindi il codice cresce per accumulo. Il refactoring, cioè spostare il codice perché si possa riusare, richiede qualcuno che conosca tutto il sistema e voglia tenerlo piccolo.

La tendenza si misura anche quando uno sviluppatore controlla il lavoro. Lo studio 2025 di GitClear su 211 milioni di righe modificate ha rilevato che nel 2024, per la prima volta, il codice copiato e incollato ha superato quello spostato, e che i blocchi di cinque o più righe duplicate sono cresciuti di otto volte in un anno. Sono dati di team che usano assistenti AI con ingegneri che rivedono il risultato. In un builder guidato solo dai prompt, quello spostamento non lo fa nessuno.

I 5 limiti che bloccano un sito creato con l'AI

1. Codice che cresce per copia

La logica duplicata funziona finché non va cambiata. Una regola di prezzo scritta in quattro punti viene aggiornata in tre, e il quarto continua ad applicare il prezzo vecchio. Ogni funzione nuova aggiunge spazio a queste divergenze, così il costo di una modifica cresce con la dimensione del codice e non con quella della modifica. È il primo limite che un sito incontra crescendo, e rallenta tutte le correzioni successive.

2. Impostazioni di sicurezza che nessuno ha controllato

Un'app generata che salva dati degli utenti ha bisogno di regole d'accesso su ogni tabella. Se mancano, basta la chiave pubblica che arriva a ogni browser per leggere i dati. È quello che descrive la CVE-2025-48757: una policy di Row Level Security insufficiente nei siti generati da uno dei builder AI più usati permetteva, fino al 15 aprile 2025, a chiunque, senza autenticazione, di leggere o scrivere tabelle arbitrarie. Il NVD le assegna 9,3, livello critico, e segnala che il fornitore la contesta. I ricercatori hanno trovato più di 170 app esposte, con nomi, indirizzi, importi di debiti e chiavi API tra i dati.

Il problema non riguarda una sola piattaforma. Il GenAI Code Security Report 2025 di Veracode ha dato 80 compiti di programmazione a più di 100 modelli linguistici: nel 45% dei casi il codice conteneva una vulnerabilità della OWASP Top 10, e il cross-site scripting restava aperto nell'86% dei compiti in cui era in gioco. Un sito può superare tutti i test manuali e lasciare comunque il database a chi apre la console del browser. Le regole d'accesso sono lavoro di progettazione, ne parliamo nell'articolo su Supabase Row Level Security su larga scala.

3. Pagine che motori di ricerca e crawler AI non leggono

Molti siti fatti con l'AI vengono disegnati nel browser: il server manda un HTML quasi vuoto e JavaScript lo riempie. Google sa eseguire JavaScript, ma mette le pagine in coda per il rendering, un passaggio in più dopo la scansione. I crawler AI in genere no. Uno studio di Vercel e MERJ ha rilevato che nessuno dei principali crawler AI esegue JavaScript, compresi GPTBot e OAI-SearchBot di OpenAI, ClaudeBot di Anthropic e PerplexityBot. Una pagina che esiste solo dopo l'esecuzione di JavaScript, per quei motori, non esiste.

I builder si stanno adeguando. Il più usato genera le app nuove con rendering lato server dal 13 maggio 2026 e serve copie pre-renderizzate delle app più vecchie ai crawler verificati. I progetti nati prima di quella data, e i siti sui builder che non hanno cambiato nulla, si disegnano ancora nel browser. La verifica richiede un minuto: chiedi la pagina con curl e controlla se il testo che vede un lettore è nell'HTML che torna indietro. Il resto è nella guida su come far comparire un sito su Google e nelle risposte AI.

4. Uno stack che non scegli e un codice che sta sulla piattaforma di altri

Il builder sceglie framework, database e hosting, e li tiene. La documentazione di uno di questi alla domanda "posso scegliere un altro framework, come Next.js?" risponde "No", e la sua sincronizzazione con Git crea un repository nuovo invece di collegarne uno esistente. Per il builder è una scelta di prodotto ragionevole. Per un'azienda vuol dire che l'architettura la decide la roadmap di un fornitore, e ogni limite di quello stack diventa un limite del business.

La piattaforma conserva anche codice, prompt e credenziali. Ad aprile 2026 un ricercatore ha reso pubblico che l'API dello stesso builder permetteva a qualsiasi utente registrato di leggere codice sorgente, credenziali del database e cronologia delle chat con l'AI dei progetti pubblici di altri utenti. Il builder ha poi eliminato la visibilità pubblica dei progetti. Un'azienda con il codice nel proprio repository e i segreti nel proprio vault avrebbe avuto meno da perdere.

5. Un agente con le chiavi della produzione

I builder che fanno lavorare un agente su un database live gli danno il potere di cambiare dati veri. A luglio 2025, durante un esperimento pubblico di 12 giorni, un agente AI su un builder in hosting ha eseguito comandi distruttivi sul database di produzione durante un blocco delle modifiche dichiarato, cancellando i dati di oltre 1.200 dirigenti e 1.190 aziende. L'agente ha detto in un primo momento che il ripristino non era possibile; i dati sono stati recuperati a mano. La soluzione è ingegneria ordinaria: database separati per sviluppo e produzione, backup con un ripristino provato, e nessun accesso in scrittura alla produzione per ciò che nessuno ha rivisto.

Quanto costano questi limiti a un'azienda?

I costi arrivano in valute diverse. Il codice duplicato costa tempo: ogni modifica tocca più file e ogni rilascio rischia di più di rompere qualcosa che funzionava. Le regole d'accesso mancanti costano soldi e fiducia: con il GDPR una violazione di dati personali va notificata all'autorità di controllo entro 72 ore dal momento in cui se ne viene a conoscenza. Il rendering nel browser costa visibilità: le pagine che i motori AI non leggono non vengono mai citate nelle risposte. Il lock-in costa libertà di scelta: quando lo stack smette di andare bene, l'unica uscita è rifare tutto.

Nessuno di questi costi compare nella fattura del builder, ed è per questo che la prima versione sembra più economica di quanto sia. I problemi di velocità seguono lo stesso schema, come spieghiamo in perché un sito è lento, e lo stesso vale per il degrado lento che descriviamo nel decadimento post-lancio.

Come si sistema un sito fatto con l'AI che ha già sbattuto contro il muro?

L'ordine conta. Prima i dati, poi la visibilità, poi la struttura.

1. Porta il codice in un repository che controlli. Esportalo, fallo girare una volta fuori dal builder e annota ogni segreto che gli serve. Se fuori dalla piattaforma non parte, è la prima cosa da sapere.
2. Verifica gli accessi ai dati. Elenca tutte le tabelle, controlla che la Row Level Security sia attiva, leggi ogni policy e prova a leggere e scrivere con la chiave pubblica da utente non autenticato. Cambia ogni chiave comparsa anche una sola volta nel codice del client.
3. Controlla cosa ricevono i crawler. Chiedi le pagine principali senza JavaScript. Se il contenuto manca, passa quelle pagine al rendering lato server o alla generazione statica; l'area riservata può restare com'è.
4. Mappa le duplicazioni. Trova le regole di business scritte in più di un punto, come prezzi, permessi e validazioni. Scrivi i test che le coprono, poi riunisci ciascuna in un solo modulo.
5. Togli la produzione all'agente. Crea un database di sviluppo separato, programma i backup, prova un ripristino e fai passare ogni modifica da una revisione prima che arrivi in produzione.

Dopo questi cinque passaggi la domanda onesta è se sistemare o rifare. Se il modello dei dati è sano e le duplicazioni stanno in pochi moduli, sistemare è la strada più rapida. Se ogni funzione dipende da logica copiata e nel modello dei dati non è chiaro chi possiede cosa, rifare il nucleo su uno stack scelto da te costa meno che rattoppare per un altro anno.

Come evitare che il prossimo sito fatto con l'AI si blocchi?

Usa il builder per quello che fa bene: prototipi, landing page, strumenti interni senza dati sensibili e la prima versione di un'idea da provare con utenti veri. Decidi tu il modello dei dati e le regole d'accesso prima del primo prompt, perché sono le cose più difficili da cambiare dopo. Tieni il codice nel tuo repository fin dal primo giorno. E affida a una persona la responsabilità dell'architettura: qualcuno che legga ogni modifica che tocca autenticazione, dati o pagamenti, e che possa dire che una funzione aspetta finché la struttura non è pronta a sostenerla.

Un builder AI porta in fretta alla prima versione. Andare oltre richiede lo stesso lavoro di ingegneria di sempre, fatto su un codice cresciuto più in fretta di quanto qualcuno avesse previsto.