Un crash è il bug migliore che possa capitarti. Accade davanti ai tuoi occhi, blocca l’app e lo risolvi nel pomeriggio. Chiunque costruisca con i generatori AI ha una storia su un deploy fallito o uno schermo bianco, e quasi sempre è una storia con un lieto fine: l’hai trovato, l’hai risolto, l’hai rilasciato.
La corruzione dei dati non funziona così. Non crasha. Non restituisce un errore. Scrive un numero sbagliato in una colonna del database e prosegue, e l’app continua a girare esattamente come prima. Il bug di cui dovresti davvero aver paura è quello che non ti dice mai di essere accaduto.
Perché i crash sono l’esito fortunato
Quando qualcosa si rompe visibilmente, ricevi un feedback immediato e una breve lista di sospetti: l’ultimo prompt, l’ultimo deploy, l’ultima modifica al codice. Lovable, Bolt e generatori simili falliscono in questo modo costantemente, ed è fastidioso ma gestibile, perché il fallimento è rumoroso.
La corruzione silenziosa inverte completamente il problema. Il bug e la scoperta del bug possono distanziarsi di mesi, e in quell’intervallo i dati corrotti continuano ad accumularsi: vengono copiati nei report, sommati nei totali, usati per calcolare una fattura. Quando qualcuno nota che i numeri non tornano, non stai facendo il debugging di un singolo errore. Stai cercando di capire quali tra migliaia di record creati dopo il rilascio del bug siano affidabili e quali no, senza alcun log che ne indichi la differenza.
I casi limite per cui nessuno scrive prompt
I modelli AI costruiscono per lo scenario che hai descritto. Un prompt come “permetti agli utenti di aggiornare la quantità dell’ordine” ti fornisce un pulsante di aggiornamento funzionante, testato su un’unica cosa: un singolo utente, con una connessione stabile, che clicca una volta. L’uso reale non resta in quella scatola, e le lacune emergono in una manciata di pattern ripetibili:
- Modifiche concorrenti. Due persone aprono lo stesso record e salvano le modifiche a pochi secondi di distanza. Senza una strategia di locking o di risoluzione dei conflitti, chi salva per ultimo sovrascrive silenziosamente le modifiche dell’altra persona, senza alcun avviso per nessuno dei due utenti.
- Caduta della rete durante l’invio. Viene inviata una richiesta, la connessione ha un glitch e il client non può confermare se il server l’abbia ricevuta. L’utente vede un’icona di caricamento, presume che sia fallito e invia di nuovo. Senza deduplicazione, ora ci sono due record dove dovrebbe essercene uno solo.
- Il doppio clic sul pulsante di invio. La versione più banale dello stesso problema. Una risposta lenta più un clic impaziente e hai creato un pagamento duplicato, una prenotazione duplicata o una riga duplicata che gonfia ogni conteggio a valle.
- Input imprevisti. Un campo quantità che accetta numeri negativi, un campo data che accetta un valore passato, un campo sconto che accetta più del 100%. Nessuno di questi crasha l’app. Producono semplicemente un record matematicamente assurdo nel momento in cui qualcuno lo confronta con la realtà.
Nessuno di questi è un modo di fallire esotico. Sono le normali frizioni di persone reali che usano un’app su reti reali, e un singolo prompt quasi mai chiede all’AI di difendersi da essi, perché difendersi non aggiunge progressi visibili a una demo.
Quando i calcoli sono sbagliati su ogni singola transazione
La seconda variante di questo problema è ancora più silenziosa: un errore di arrotondamento o di calcolo sbagliato di una frazione di centesimo, ogni volta, su ogni transazione. Gira senza problemi. Non restituisce mai un’eccezione. Il test unitario, se ne esiste uno, verifica che il calcolo restituisca un numero, non che il numero sia corretto fino all’ultimo decimale su diecimila esecuzioni.
È qui che il test “funziona”, su cui il vibe coding ti abitua a fare affidamento, diventa attivamente pericoloso. Un calcolo del prezzo errato dello 0,3% non fallisce nella demo. Fallisce nella riunione di riconciliazione sei mesi dopo, quando l’amministrazione nota che la somma di tutte le transazioni individuali non corrisponde alla cifra del fatturato totale, e nessuno sa spiegare perché senza controllare record per record.
Quel divario tra “la funzionalità funziona” e “la funzionalità è corretta” è esattamente ciò che i test automatizzati dovrebbero intercettare nello sviluppo software professionale, ed è esattamente ciò che manca quando un costruttore non tecnico è l’unico a controllare l’output dell’AI. Puoi confermare visivamente che una pagina si carichi. Non puoi confermare visivamente che un calcolo composto sia accurato al centesimo su un anno di transazioni.
Perché “sembra tutto a posto” è il test sbagliato per l’integrità dei dati
| Cosa puoi testare manualmente | Cosa causa effettivamente la corruzione |
|---|---|
| Il modulo viene inviato correttamente? | Viene inviato esattamente una volta, anche con una connessione instabile? |
| La dashboard mostra un totale? | Quel totale è ancora corretto dopo 10.000 righe, o un errore di arrotondamento si accumula? |
| Un utente può modificare un record? | Cosa succede quando due utenti lo modificano contemporaneamente? |
| Il calcolatore restituisce un numero? | Quel numero è quello giusto, verificato rispetto a una fonte indipendente? |
La colonna di sinistra è ciò che una demo, e la maggior parte della QA manuale, controlla effettivamente. La colonna di destra è ciò che determina se la tua fatturazione, le tue prenotazioni o i tuoi report siano affidabili al sesto mese. Il vibe coding ottimizza fortemente per la colonna di sinistra e non ha alcun meccanismo naturale per quella di destra, perché la colonna di destra richiede di provare deliberatamente a rompere il percorso ideale, non solo di confermare che funzioni.
La parte che rende tutto questo peggio di un bug: non puoi capire quali record siano errati
Un crash ha un raggio d’azione visibile. I dati corrotti hanno un raggio d’azione che puoi solo ipotizzare. Una volta che un bug di invio duplicato o un errore di arrotondamento è rimasto attivo per mesi, non c’è alcun flag sulle righe interessate. O ti fidi dell’intero set di dati, che ora sai essere inaffidabile, o lo analizzi record per record, il che per qualsiasi cosa oltre poche centinaia di righe non è realistico per un piccolo team senza tempo di ingegneria dedicato.
Questo è il costo reale del “divario di fiducia” che accompagna il codice generato: non sei mai stato in grado di verificare che la logica fosse a prova di bomba fin dall’inizio, quindi quando si scopre che non lo era, non hai un punto di partenza per la pulizia. Scoprire il bug non è la fine del problema. È l’inizio di uno molto più difficile: capire quanto indietro arrivano i danni.
Costruire in modo che il danno non possa accumularsi
Non puoi eliminare ogni caso limite essendo più accurato con i prompt. Quello che puoi fare è scegliere dove girano effettivamente le parti della tua app che gestiscono denaro, quantità o prenotazioni.
Per i progetti amatoriali, i prototipi interni o qualsiasi cosa in cui un numero errato sia un inconveniente piuttosto che una responsabilità legale, il codice generato e i test manuali sono uno scambio ragionevole per la velocità. Il calcolo cambia nel momento in cui i numeri alimentano una fattura cliente, un calendario di prenotazioni o un report che qualcuno deve approvare. A quel punto, la domanda non è “sembrava corretto quando l’ho testato”, ma “chi sta controllando che sia ancora corretto dopo diecimila transazioni”.
Per quella categoria di app aziendali, struttura il percorso di scrittura in modo che non dipenda dall’IA che gestisca correttamente concorrenza e arrotondamenti al primo (o quinto) tentativo:
- Sposta le scritture core su infrastrutture testate, non su codice generato fresco. Softr gestisce la creazione di record, gli aggiornamenti e i calcoli di rollup (somme, medie, conteggi tra record collegati) tramite il proprio motore di database piuttosto che attraverso una logica generata dall’IA per ogni app. Un rollup che somma le voci di una fattura esegue lo stesso calcolo testato ogni volta, invece di una funzione su misura scritta una volta da un’IA e mai sottoposta a stress test per l’errore di arrotondamento.
- Usa i permessi visivi invece della logica di concorrenza scritta a mano. I Gruppi Utenti di Softr e le Restrizioni dei Dati a livello di record governano chi può modificare cosa, riducendo (anche se non eliminando) il problema delle modifiche simultanee controllando l’accesso a livello di piattaforma, invece di dipendere da un blocco codificato personalmente che un’IA potrebbe o meno aver pensato di aggiungere.
- Riconcilia in modo indipendente, secondo un programma. Nessuna piattaforma, no-code o meno, sostituisce l’abitudine di controllare periodicamente i totali rispetto a una fonte esterna: un estratto conto bancario, la dashboard di un processore di pagamenti, un conteggio manuale. Questo vale sia che tu abbia costruito su codice generato dall’IA sia che non lo abbia fatto, ed è l’unico modo per intercettare un errore cumulativo prima che sia passato un anno.
- Se rimani nel codice, prevedi tempo reale per i test avversari. Se sei uno sviluppatore che usa Cursor o Replit per costruire o estendere un’app personalizzata, scrivi esplicitamente test per scritture simultanee, invii duplicati e valori limite (numeri negativi, zero, date estreme), perché l’IA non li genererà a meno che tu non lo chieda, e il fatto che “sia compilato” non ti dice nulla sulla sua correttezza sotto carico.
Nulla di tutto ciò fa scomparire il problema di fondo. Il software che tocca denaro o prenotazioni avrà sempre bisogno di qualcuno che verifichi i calcoli rispetto alla realtà. Ma c’è una differenza reale tra un’app in cui la logica di scrittura è stata generata su misura per progetto e mai testata sotto stress, e una in cui le operazioni core del database sono lo stesso percorso di codice testato su cui si affida ogni azienda sulla piattaforma. La prima ti offre una nuova occasione di sbagliare concorrenza e arrotondamenti per ogni singola funzionalità. La seconda non rimuove la tua responsabilità di riconciliare, ma rimuove il lancio quotidiano della moneta per capire se questa specifica funzione di scrittura generata dall’IA gestisca correttamente un doppio clic.
La conclusione onesta è che i crash sono fastidiosi ma perdonabili. La corruzione silenziosa è paziente. Aspetta che il volume dei dati sia sufficientemente alto e il tempo trascorso sufficientemente lungo, affinché risolverla costi molto più di quanto sarebbe costato prevenirla.
