Vibe coding vs produzione: i 13 livelli che nessuno ti mostra
Generare un'app con l'intelligenza artificiale è facile. Farla sopravvivere online, con utenti veri, dati veri e qualcuno che prova a entrarci, è un altro mestiere. Ecco cosa c'è in mezzo, livello per livello.
Il vibe coding è il modo di programmare che è esploso con gli assistenti di intelligenza artificiale: descrivi a parole quello che vuoi, l'IA scrive il codice, tu guardi se funziona e chiedi di correggere. In un pomeriggio hai un'app che si apre, salva dati e sembra pronta.
Lo uso anche io, ogni giorno. È uno strumento formidabile per provare un'idea, mostrare un prototipo a un cliente, togliere di mezzo il lavoro ripetitivo. Il problema non è il vibe coding. Il problema è scambiare il prototipo per il prodotto.
Un software in produzione deve reggere cose che nel prototipo non esistono: utenti che sbagliano, attacchi automatici, server che si riavviano, dati che non si possono perdere, una legge sulla privacy da rispettare, e qualcuno che dovrà metterci le mani fra tre anni. Ho messo in fila i 13 livelli che separano "funziona sul mio computer" da "regge il mondo reale".
01 Il prototipo
È il punto di partenza, e va benissimo così: l'app gira sul tuo computer, con dati di prova, e fa vedere l'idea. Qui il vibe coding dà il meglio.
Segnale d'allarme: il prototipo è già online, con clienti veri, "tanto per ora va".
02 Codice versionato e rivisto
Di solito: file copiati in cartelle chiamate "finale", "finale2", "finale-davvero". Ogni nuova richiesta all'IA riscrive pezzi interi, e non si sa più cosa è cambiato.
Serve: un repository Git, modifiche piccole e descritte, e qualcuno che le legga prima di andare online. Il codice scritto dall'IA va revisionato come quello di un collega appena arrivato: spesso è buono, a volte è sicuro di sé e sbagliato.
Segnale d'allarme: nessuno sa dire cosa è cambiato nell'ultima settimana.
03 Segreti fuori dal codice
Di solito: password del database, chiavi dei servizi di pagamento o delle API dell'IA scritte direttamente nel codice, perché "così funziona subito".
Serve: i segreti stanno nella configurazione del server o in un archivio cifrato, mai nel codice e mai nella storia di Git. E se una chiave è finita lì anche una volta sola, si considera bruciata: si revoca e se ne crea una nuova, cancellarla dal file non basta.
Segnale d'allarme: cercando "password" o "key" nel codice trovi valori veri.
04 Accessi e permessi
Di solito: un login che controlla la password, e poi tutti vedono tutto. Spesso basta cambiare un numero nell'indirizzo della pagina per vedere i dati di un altro utente.
Serve: password salvate con algoritmi adatti, sessioni che scadono, limite ai tentativi, doppio fattore per gli amministratori, e soprattutto un controllo dei permessi su ogni richiesta, lato server: non basta nascondere un pulsante nell'interfaccia.
Segnale d'allarme: i permessi esistono solo come voci di menu nascoste.
05 Input non fidati
Di solito: i moduli accettano qualunque cosa e la passano dritta al database o alla pagina.
Serve: ogni dato che arriva da fuori è sospetto. Va validato sul server, usato nel database solo con query parametrizzate (niente SQL composto a mano), mostrato nelle pagine con l'escape giusto. I moduli pubblici hanno bisogno di protezioni contro i bot e di un limite alle richieste.
Segnale d'allarme: scrivendo un apice in un campo di ricerca compare un errore del database.
06 Un database che si difende
Di solito: tabelle create al volo, nessun vincolo, il database "si adatta" al codice.
Serve: uno schema pensato, con chiavi, vincoli e indici; modifiche allo schema versionate e ripetibili; operazioni che devono avvenire insieme dentro una transazione. Il database è l'ultima linea di difesa dei tuoi dati: se il codice sbaglia, deve essere lui a dire di no.
Segnale d'allarme: trovi ordini senza cliente o importi negativi dove non dovrebbero esistere.
07 Test automatici
Di solito: "l'ho provato, funziona". Fino alla prossima modifica.
Serve: test automatici sui punti che contano (calcoli, permessi, pagamenti, le regole del tuo mestiere) che girano a ogni modifica. Con l'IA scriverli costa poco: non ci sono più scuse. Sono loro che ti permettono di chiedere una modifica all'IA senza paura di rompere tre cose altrove.
Segnale d'allarme: ogni correzione fa saltare fuori un problema nuovo.
08 Errori e log
Di solito: errori ignorati, oppure mostrati all'utente con tutti i dettagli tecnici del server.
Serve: errori gestiti con un messaggio comprensibile per chi usa l'app, e il dettaglio scritto nei log per chi la mantiene. Log utili, senza password né dati personali dentro, e conservati abbastanza a lungo da capire cosa è successo martedì scorso.
Segnale d'allarme: quando un cliente segnala un problema, l'unico modo per capirlo è chiedergli di rifarlo.
09 Rilascio ripetibile
Di solito: file caricati a mano sul server, comandi lanciati a memoria, il venerdì sera.
Serve: un processo automatico che costruisce l'app, fa girare i test e la mette online sempre allo stesso modo, con la possibilità di tornare alla versione precedente in pochi minuti. Ambienti di prova separati da quello vero.
Segnale d'allarme: solo una persona sa come si aggiorna il server.
10 Il perimetro
Di solito: il sito funziona in HTTPS e ci si ferma lì.
Serve: intestazioni di sicurezza configurate, porte del server chiuse se non servono, librerie aggiornate e controllate per vulnerabilità note, accesso al server con chiavi e non con password. Le app generate dall'IA tendono a usare molte dipendenze: ognuna è una porta da tenere chiusa.
Segnale d'allarme: le librerie del progetto non vengono aggiornate da mesi.
11 Backup provati
Di solito: "il provider fa i backup". Forse. Di cosa, e quanto indietro?
Serve: copie automatiche e cifrate, conservate fuori dal server principale, per un periodo definito. E soprattutto un ripristino provato: un backup che non hai mai ripristinato è una speranza, non un backup.
Segnale d'allarme: nessuno ha mai provato a rimettere in piedi l'app da zero.
12 Monitoraggio e allarmi
Di solito: ti accorgi che il sito è fermo quando un cliente ti chiama.
Serve: controlli automatici che verificano che l'app risponda, allarmi su errori, lentezze, spazio disco e certificati in scadenza, e qualcuno che li riceva. Anche le prestazioni vanno guardate: una pagina che con dieci utenti è veloce può fermarsi con mille.
Segnale d'allarme: scopri i problemi dai clienti.
13 Privacy e futuro
Di solito: dati personali raccolti "perché poi servono", senza informativa né modo di cancellarli. E un codice che solo l'IA, nella conversazione di quel giorno, sapeva spiegare.
Serve: raccogliere solo i dati necessari, proteggere quelli delicati, gestire consensi e richieste di cancellazione, sapere dove stanno i server. E un codice leggibile, documentato quanto basta, che un altro sviluppatore possa riprendere: il software vive anni, le conversazioni con l'IA no.
Segnale d'allarme: se un utente ti chiede di cancellare i suoi dati, non sai da dove cominciare.
E quindi, il vibe coding va evitato?
No. Va messo al suo posto. L'intelligenza artificiale ha abbassato drasticamente il costo di scrivere codice, e io la uso come un copilota in ogni progetto. Ma il costo di un software non è mai stato soprattutto scriverlo: è farlo durare, proteggerlo e cambiarlo senza romperlo.
La differenza fra un prototipo e un prodotto sta proprio in questi 13 livelli. L'IA ti porta velocemente al primo. Gli altri dodici richiedono metodo, esperienza e qualcuno che se ne prenda la responsabilità.