Ho creato un prodotto con l’AI: come migliorarlo senza rompere ciò che funziona

Scopri di più su come lavorare con i modelli nella documentazione di Ailoot.

Perché il lavoro più costoso inizia dopo il lancio?#

Hai creato un’app in una sera, hai pubblicato un link e l’hai mandato agli amici. Funziona. Poi, una settimana dopo, arriva la prima persona che la usa davvero, clicca qualcosa nel modo sbagliato e metà delle funzioni smette di funzionare. Chiedi a Claude di sistemare il problema: ne risolve uno e ne crea un altro. Ti suona familiare?

Ed è qui che sorge la domanda principale: cosa si fa dopo aver lanciato un prodotto, quando è passata l’euforia del primo prototipo funzionante e bisogna comunque mantenerlo in qualche modo? Potremmo chiamarlo vibe coding per adulti. Creare significa entusiasmo e velocità. La manutenzione richiede sangue freddo: devi capire cosa stai cambiando e tenerlo sotto controllo. La maggior parte delle persone fallisce in questa seconda fase perché nessuno la prepara.

Uno studio di settore ha analizzato più di un milione di modifiche al codice provenienti da 2.444 team e ha calcolato dove finiscono davvero i soldi spesi per lo sviluppo con l’AI. Ecco il quadro:

La guida “Il costo nascosto del vibe coding” spiega queste cifre più nel dettaglio. Lì la domanda era per cosa stai pagando. Qui la domanda è diversa: 44 centesimi di ogni dollaro vanno alla correzione dei bug, e questo articolo parla proprio di come impedire che quella quota aumenti. Il lavoro per tenerla sotto controllo si chiama manutenzione.

La differenza tra chi fa vibe coding da adulto e chi fa solo da babysitter a una rete neurale si vede dopo il lancio. Il codice del primo cresce, lui apporta miglioramenti e niente si rompe. Dopo un mese, il prodotto del secondo è diventato un trabiccolo che perde da tutte le parti e che ha paura di toccare. Vediamo come finire nel primo gruppo.

Cosa si rompe davvero: 5 disastri dopo il lancio#

Questi sono post mortem pubblici di prodotti reali creati con l’AI, con cifre e date. Pensali come una mappa di un campo minato: ogni mina è già esplosa per qualcuno e si sa come evitarla.

Tutti e cinque i casi hanno la stessa causa principale. Per impostazione predefinita, l’AI fa funzionare le cose subito, non in modo sicuro un mese dopo sotto carico. Non puoi vedere la differenza mentre sviluppi sul tuo computer. Diventa evidente quando si presenta il primo sconosciuto con cattive intenzioni.

Il problema non è non scrivere il codice a mano: molte persone lavorano così. Il problema è non chiedersi: «Il database è protetto?». Ora ti mostrerò un prompt che pone questa domanda al posto tuo.

La prima rete di sicurezza è git e la possibilità di tornare a “com’era ieri”#

Quando Claude rompe qualcosa, ti serve un pulsante «rimettilo com’era ieri». Tecnicamente, quel pulsante si chiama git ed è più semplice di quanto sembri.

Tre termini che chi non programma deve conoscere:

1. Repository — la cartella del progetto salvata nel cloud, di solito su GitHub. Una copia di tutto il codice che non si trova solo sul tuo computer.
2. Commit — un punto di ripristino. In pratica, dici al codice: «salva in questo stato». Ogni commit è un segnalibro a cui puoi tornare.
3. Deploy — un trasferimento. Il codice era in locale, sul tuo computer, e funzionava solo per te. Il deploy lo invia a un server esterno, così funziona per tutti.

Se hai punti di ripristino recenti, puoi annullare qualsiasi danno con una sola frase. Letteralmente.

Ho rotto qualcosa: ieri funzionava tutto, oggi no. Trova l’ultimo commit in cui funzionava tutto, mostrami cosa è cambiato da allora e riporta il progetto a quello stato.

Due regole da applicare subito, prima che altre persone vedano il prodotto:

• Il repository deve essere privato. Non pubblico. Altrimenti chiunque può leggere il codice e tutto ciò che contiene.
• Inserisci il file dei segreti nell’elenco di esclusione. Chiavi, password e credenziali di accesso al database vanno in un file separato, di solito .env, che non deve mai entrare nel repository. Aggiungi una riga per .env a .gitignore e i segreti resteranno con te.

C’è una guida specifica su come annullare le modifiche in sicurezza in Claude Code: Come annullare le modifiche in Claude Code. Senza punti di ripristino, cammini sul filo senza rete di sicurezza e prima o poi cadrai.

Cosa annulla /rewind e cosa invece non annulla?#

Claude Code crea uno snapshot dello stato prima di ogni modifica. Il comando /rewind (o due pressioni di Esc) ripristina sia i file sia la conversazione fino al punto selezionato. È comodo: se hai rotto una funzione cinque minuti fa, puoi tornare indietro di cinque minuti.

Ma c’è una trappola che fa perdere dati ai principianti. /rewind non annulla tutto:

Anthropic lo dice chiaramente: gli snapshot sono un pulsante locale «annulla», mentre git è la cronologia permanente. Gli snapshot completano il controllo di versione, ma non lo sostituiscono.

La conclusione pratica per chi non programma è questa: /rewind ti salverà da «Claude ha appena rotto una funzione». Ma se ha eliminato una riga del database o caricato codice nel cloud, solo git e un backup del database possono ripristinarli. Quindi mantieni entrambi i livelli: gli snapshot per i ripristini rapidi e i commit per la cronologia permanente del progetto.

Come puoi migliorare il prodotto senza rompere ciò che già funziona?#

Una persona su due resta intrappolata in questo ciclo. Chiedi all’AI di correggere un piccolo bug. Propone una modifica ragionevole. Quella modifica rompe qualcos’altro. Le chiedi di correggere il nuovo problema e ne spuntano altri due. E così via.

Il ciclo si verifica perché il vibe coding è non deterministico. Lo stesso prompt produce codice diverso due volte. Perciò ogni modifica può spostare silenziosamente la logica circostante: la soglia dello sconto passa dal 10 al 12 percento oppure una regola di convalida cambia comportamento, senza che tu faccia controlli e senza un solo avviso. Si chiama deriva logica e danneggia in silenzio proprio le cose che generano entrate: prezzi, accessi e pagamenti.

C’è una regola per proteggersi dalla deriva, abbastanza semplice da appendere al muro: non fare commit di codice che non sapresti spiegare a un’altra persona parola per parola.

In pratica, si traduce in un testo pronto da usare prima di qualsiasi modifica al codice funzionante. Fa procedere l’AI a piccoli passi e le chiede di mostrarti esattamente cosa è cambiato.

Prima di modificare il codice, fai quanto segue:

Salva lo stato attuale funzionante come punto di ripristino separato (commit).

Descrivi a parole con precisione cosa intendi modificare e in quali file.

Apporta la modifica più piccola possibile: solo ciò che serve a risolvere il mio compito, niente di più.

Mostrami cosa è cambiato e spiegami ogni modifica in modo che possa spiegarla a un’altra persona.
Non toccare la logica dei prezzi, degli accessi o dei pagamenti a meno che non te l’abbia chiesto.

Un altro principio che fa risparmiare settimane è la disciplina nel rispettare i limiti del compito. Un problema alla volta, una modifica, un’implementazione rapida. Non chiedere all’AI di riscrivere metà del progetto in un solo prompt. A volte gli sviluppatori professionisti iniziano a costruire un Uber intero quando serviva solo un pulsante, e ci mettono mesi. Non ne hai bisogno.

Tutto ciò che descrivo si basa su una cosa: la gestione del contesto. Per evitare che l’AI rompa la logica vicina, deve ricordare le regole del tuo progetto.

Come controllare una modifica prima di pubblicarla?#

Tra «funziona sul mio computer» e «funziona per tutti» c’è un passaggio intermedio che i principianti saltano: una copia di test. È uno snapshot separato dell’ambiente di produzione in cui controlli una modifica prima che la vedano persone reali. Il ciclo di lavoro è questo:

1. Sviluppa e controlla tu stesso la modifica (development).
2. Distribuiscila in staging, una copia della produzione senza utenti reali.
3. Prova gli scenari chiave e verifica che nulla sia cambiato.
4. Solo a quel punto distribuiscila in produzione.

Perché conta dopo il lancio: ogni rilascio comporta un rischio. Una piccola modifica al codice può impedire l’accesso agli account. Una singola impostazione mancante può mandare in tilt l’intero prodotto. Lo staging intercetta questi problemi senza conseguenze; in produzione perdi clienti.

Per evitare di controllare tutto manualmente ogni volta, dai all’AI un prompt che confronti il comportamento della nuova versione con quello della precedente nelle aree critiche.

Sto per distribuire una modifica. Segui gli scenari chiave del prodotto nell’ordine e verifica che ciascuno funzioni ancora come prima:

Registrazione e accesso di un nuovo utente.

Pagamento e concessione dell’accesso dopo il pagamento.

Diritti di accesso: un utente normale non può vedere i dati altrui né l’area amministrativa.

I valori chiave della logica aziendale (prezzi, sconti, limiti) non sono cambiati.
Se qualcosa si comporta diversamente dalla versione precedente, fermati e mostrami esattamente cosa è cambiato.

Dove sono i tuoi segreti? La falla più grande per i principianti#

Spiego nel dettaglio la falla più grande perché mette fuori gioco più prodotti di qualsiasi altra. Quando l’AI scrive codice, la cosa più facile è mettere una chiave dove funziona subito: direttamente nel codice della pagina che si apre nel browser. In fase di sviluppo non noterai la differenza. Ma chiunque può leggere tutto ciò che arriva al browser aprendo gli strumenti per sviluppatori.

Il fondatore ai cui clienti erano stati addebitati 87.500 $ ha detto in seguito che un solo prompt avrebbe potuto impedirlo. Gli addebiti sono stati poi stornati, ma le commissioni non rimborsabili e la tranquillità perduta sono rimaste. Ecco quel prompt.

Controlla l’intero progetto e assicurati che nessuna chiave segreta finisca nel browser:

Trova tutte le chiavi del database, del sistema di pagamento e dei servizi esterni.

Assicurati che ciascuna sia conservata solo sul server, nelle variabili d’ambiente, e non nel codice della pagina.

Controlla la cronologia del progetto: qualche chiave ci è finita per sbaglio in passato?
Mostrami un elenco di ogni punto in cui hai trovato segreti e cosa bisogna fare per ciascuno.

Un’altra falla vicina riguarda il controllo dei diritti di accesso solo sul browser. Se il prodotto decide nel codice della pagina se «mostrare l’area amministrativa», chiunque può aggirare quella decisione. I diritti di accesso vanno sempre controllati sul server. Il database deve restituire dati solo a chi ne ha diritto: è questo lo scopo della sicurezza a livello di riga (RLS), che va attivata su ogni tabella.

Prima di vendere l’accesso o consentire ad altre persone di entrare, esegui un audit di sicurezza generale del prodotto.

Esamina il progetto come farebbe un aggressore e cerca falle di sicurezza:

Ci sono chiavi segrete conservate nel codice inviato al browser o nella cronologia del progetto?

La sicurezza a livello di riga (RLS) è attivata su ogni tabella del database e i diritti di accesso vengono controllati sul server anziché solo nel browser?

È configurato un backup automatico del database e ho mai verificato di poterlo ripristinare?

Il database di produzione è isolato dall’ambiente in cui viene eseguito l’agente AI?
Per ogni punto, dimmi se è tutto a posto oppure esattamente cosa va corretto.

C’è una guida completa specifica sulla sicurezza nel vibe coding: Come proteggere un’app creata con il vibe coding. La regola è semplice: considera non sicuro tutto ciò che l’AI ha fatto per impostazione predefinita, finché non hai verificato il contrario.

Dove ospitare il prodotto: la scala dell’hosting#

Non serve affittare subito un server tuo e configurarlo manualmente: all’inizio è un compito complicato e ti porterà via tempo. C’è una scala da salire man mano che il prodotto cresce:

1. Hosting gratuito (per esempio Vercel): per te, per i test e per piccoli progetti. Va bene se la piattaforma è disponibile al tuo pubblico e non conservi dati personali delle persone.
2. Una piattaforma con distribuzione tramite un solo comando (Railway): quando hai un backend e un database. Distribuisci con un comando e non devi configurare un server. La soglia d’ingresso è minima.
3. Un server dedicato tuo: quando il carico è elevato e ti serve il pieno controllo. Passa a questa soluzione più avanti, quando avrai raggiunto il limite della piattaforma.

Per chi non programma e ha appena lanciato un prodotto, l’opzione più semplice è una piattaforma con distribuzione tramite un solo comando, senza configurare manualmente il server. Passa a un server tuo più avanti. Se vuoi seguire questo percorso con un esempio concreto, consulta la guida a come distribuire un progetto creato con il vibe coding sul tuo server con Coolify.

Quando separare app, database e backup?#

Ci sono tre cose che non dovrebbero stare nello stesso paniere: l’app, il database e i backup. Finché gli utenti sono pochi, tutto vive insieme e va bene così. Ma c’è un segnale chiaro che indica quando è ora di separarli.

• Metti app e database su macchine diverse. Il segnale: al picco di carico, CPU e memoria restano sopra il 70–80 percento, le richieste rallentano e app e database competono per le stesse risorse. Dopo averli separati, puoi potenziare il database senza toccare l’app, e viceversa.
• Segui la regola di backup 3-2-1. Tre copie dei dati, su due tipi diversi di supporto, di cui una fuori sede. Protegge dai guasti hardware e dai ransomware. La cosa fondamentale è che i backup siano automatici.

La frequenza dei backup dipende da quanto costa perdere dati di qualche ora. Per un servizio di abbonamento online in cui perdere un’ora di registrazioni dei pagamenti è inaccettabile, l’intervallo dei backup deve essere inferiore a un’ora, oppure servono log delle transazioni verificati e ripristino a un punto nel tempo (PITR). Scegli l’intervallo in base alla perdita massima tollerabile e verifica separatamente il tempo necessario a ripristinare il servizio. Per un blog basta una volta al giorno. La logica è semplice: decidi quanti dati puoi permetterti di perdere e configura i backup di conseguenza.

Aiutami a decidere se è ora che il mio prodotto passi a un’infrastruttura più seria. Controlla ogni punto e fammi domande:

Quanto sono sotto carico CPU e memoria nei picchi: l’utilizzo resta sopra il 70–80 percento oppure no?

Il database e l’app si trovano sulla stessa macchina o su macchine diverse?

È configurato un backup automatico del database e ho provato a ripristinarlo?

C’è una copia separata dell’ambiente (staging) per fare verifiche prima della distribuzione?
In base ai risultati, dammi una raccomandazione chiara: cosa lasciare com’è, cosa separare per prima e perché.

C’è anche una questione a parte: database gestito o proprio. Per un piccolo team, quello gestito è quasi sempre meglio: il tuo costa meno in hardware, ma ti porta via ore di manutenzione. Se lavori da solo e il tuo prodotto non è l’infrastruttura, quelle ore costano più della differenza di prezzo del server.

Come mettere la manutenzione in autopilota?#

La manutenzione manuale è estenuante. Puoi delegarla in due modi: monitoraggio e agente di pattuglia.

Il monitoraggio usa due strumenti diversi per due compiti diversi:

1. «Il sito è online?»: un monitor di disponibilità, per esempio UptimeRobot. Interroga il prodotto ogni pochi minuti e invia un avviso se non è raggiungibile. Ha un piano gratuito.
2. «Cosa si è rotto esattamente?»: un sistema di tracciamento degli errori, per esempio Sentry. Raccoglie gli errori all’interno dell’app e mostra dove e perché si è verificato un problema.

Il primo rileva che il prodotto è andato giù. Il secondo mostra quale funzione si è guastata e perché. Insieme rispondono alla domanda: «Scoprirò un guasto prima che un cliente scriva all’assistenza?»

Il secondo livello di autopilota è un agente di pattuglia. Immagina un’agenzia immobiliare: alle sette del mattino, un agente AI legge le richieste sul sito, nota che il modulo di prenotazione è guasto, trova la causa nel codice e ti prepara una correzione con una spiegazione. La esamini e dici «sì»: viene distribuita. L’ordine conta: prima risolvi il problema dell’utente (concedi l’accesso, chiedi scusa), poi indaga sulla causa e sul denaro.

Un’altra regola per l’accesso dell’AI al database di produzione: assegnale un utente di sola lettura e nascondi i dati personali dietro uno strato intermedio, così l’agente vede «nome» invece del nome reale di una persona. In questo modo, anche se sbaglia, non potrà fisicamente eliminare o corrompere i dati di produzione. L’incidente della tabella qui sopra, in cui un agente ha cancellato il database di produzione, riguarda proprio l’assenza di questa limitazione. La guida Cosa fare se l’AI ha eliminato il tuo database spiega cosa fare se il disastro è già avvenuto.

Quando è il momento di chiudere un prodotto?#

La parte più sottovalutata della manutenzione è sapere quando smettere di mantenere un prodotto. Chi crea molto ha un cimitero di progetti: ne ha creato uno, ci ha smanettato e poi lo ha abbandonato. È normale e non è un fallimento. Il fallimento è trascinare per mesi qualcosa che nessuno usa, per rimpianto del tempo speso.

Ecco alcune soglie utili per decidere:

1. Due settimane: bastano per capire se un’idea funziona. Se i primi utenti reali tornano, continua. Il silenzio è una risposta.
2. Tre mesi: il limite massimo. Se non è decollata in tre mesi, chiudila. Con la velocità del vibe coding, sei mesi di test per una sola idea sono troppi.

Chiudere un progetto è difficile dal punto di vista psicologico, quindi trattalo come una decisione, non come un sentimento. Lasciar andare un progetto in cui hai investito è come licenziare un dipendente che non sa fare il suo lavoro: spiacevole, ma tenerlo costa più che lasciarlo andare.

La manutenzione è il lavoro che serve a mantenere un prodotto vivo e utile alle persone. Tutto il resto — git, backup, monitoraggio — è solo uno strumento per arrivare al punto in cui il prodotto inizia a lavorare per te ogni giorno.

Creare un prodotto con l’AI in una sera è solo metà del lavoro. Tenerlo vivo e sicuro mentre cresce: questo significa fare vibe coding da adulti.

Per il prossimo passo, Ailoot.