Un crash è il miglior bug che ti possa capitare. Succede davanti a te, blocca l’app, e lo risolvi quel pomeriggio stesso. Chiunque costruisca con generatori IA ha una storia su un deploy rotto o una schermata bianca, ed è quasi sempre una storia con un lieto fine: trovato, risolto, pubblicato.
La corruzione dei dati non funziona così. Non va in crash. Non genera un errore. Scrive un numero sbagliato in una colonna del database e prosegue, e l’app continua a funzionare esattamente come prima. Il bug di cui dovresti davvero preoccuparti è quello che non ti dice mai che è successo.
Perché il crash è il risultato fortunato
Quando qualcosa si rompe in modo visibile, ottieni 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 così di continuo, ed è fastidioso ma gestibile, perché l’errore fa rumore.
La corruzione silenziosa rovescia completamente il problema. Il bug e la sua scoperta possono essere separati da mesi, e in quell’intervallo i dati corrotti continuano ad accumularsi: vengono copiati nei report, somati nei totali, usati per calcolare una fattura. Quando qualcuno si accorge che i numeri non quadrano, non stai più correggendo un singolo errore. Stai cercando di capire quali, tra le migliaia di record creati da quando il bug è stato pubblicato, sono attendibili e quali no, senza alcun log che segnali la differenza.
I casi limite che nessuno descrive in un prompt
I modelli di IA costruiscono per lo scenario che hai descritto. Un prompt come “lascia che gli utenti aggiornino la quantità del loro ordine” ti dà un pulsante di aggiornamento funzionante, testato per esattamente una cosa: un singolo utente, su una connessione stabile, che clicca una volta. L’uso reale non resta dentro quello schema, e le falle emergono in una manciata di pattern ricorrenti:
- Modifiche simultanee. Due persone aprono lo stesso record e salvano le modifiche a pochi secondi di distanza. Senza una strategia di blocco o risoluzione dei conflitti, chi salva per ultimo sovrascrive silenziosamente le modifiche dell’altro, senza alcun avviso per nessuno dei due.
- Una connessione che salta a metà di un modulo. Un invio parte, la connessione ha un’interruzione, e il client non riesce a confermare se il server l’ha ricevuto. L’utente vede un indicatore di caricamento, pensa che sia andato storto, e rinvia. Senza deduplicazione, ora ci sono due record dove ce ne dovrebbe essere uno.
- Il pulsante di invio cliccato due volte. 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 successivo.
- Input inaspettati. Un campo quantità che accetta un numero negativo, un campo data che accetta un valore nel passato, un campo sconto che accetta più del 100%. Nessuno di questi fa andare in crash l’app. Producono solo un record matematicamente insensato nel momento in cui qualcuno lo confronta con la realtà.
Nessuno di questi è un modo di fallire esotico. Sono l’attrito ordinario di persone reali che usano un’app su reti reali, e un singolo prompt quasi non chiede mai all’IA di difendersi da essi, perché difendersene non aggiunge nessun progresso visibile a una demo.
Quando il calcolo è sbagliato su ogni singola transazione
La seconda variante di questo problema è ancora più silenziosa: un errore di arrotondamento o di calcolo che sbaglia di una frazione di centesimo, ogni volta, su ogni transazione. Funziona senza intoppi. Non genera mai un’eccezione. Il test unitario, se ne esiste uno, verifica che il calcolo restituisca un numero, non che quel numero sia corretto fino all’ultimo decimale su diecimila esecuzioni.
È qui che il test “funziona”, su cui il vibe coding ti allena a fare affidamento, diventa davvero pericoloso. Un calcolo dei prezzi sbagliato dello 0,3% non fallisce nella demo. Fallisce nella riunione di riconciliazione sei mesi dopo, quando il reparto finanziario fa notare che la somma di tutte le transazioni singole non corrisponde alla cifra totale del fatturato, e nessuno riesce a spiegare perché senza controllare record per record.
Quel divario tra “la funzione funziona” e “la funzione è corretta” è esattamente ciò che i test automatizzati dovrebbero individuare nello sviluppo software professionale, ed esattamente ciò che manca quando un creatore non tecnico è l’unico a controllare l’output dell’IA. Puoi confermare visivamente che una pagina si carica. Non puoi confermare visivamente che un calcolo cumulativo sia esatto al centesimo su un anno di transazioni.
Perché “sembra a posto” è il test sbagliato per l’integrità dei dati
| Cosa puoi testare manualmente | Cosa causa davvero la corruzione |
|---|---|
| Il modulo si invia correttamente? | Si invia esattamente una volta, anche su 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? |
| La calcolatrice restituisce un numero? | Quel numero è il numero giusto, verificato rispetto a una fonte indipendente? |
La colonna di sinistra è ciò che una demo, e la maggior parte dei test manuali, controlla davvero. La colonna di destra è ciò che determina se la tua fatturazione, le tue prenotazioni o i tuoi report saranno attendibili al sesto mese. Il vibe coding si 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 lo scenario ideale, non solo confermare che funziona.
Ciò che rende questo peggio di un bug: non puoi sapere quali record sono sbagliati
Un crash ha un raggio d’impatto che puoi vedere. I dati corrotti hanno un raggio d’impatto che puoi solo intuire. Quando un bug di invio duplicato o un errore di arrotondamento è in produzione da mesi, non c’è alcun contrassegno sulle righe interessate. O ti fidi dell’intero set di dati, che ora sai essere poco attendibile, oppure lo verifichi record per record, cosa che, oltre poche centinaia di righe, non è realistica per un piccolo team senza tempo di ingegneria dedicato.
Questo è il vero costo del “divario di fiducia” che accompagna il codice generato: non sei mai stato nella posizione di verificare che la logica fosse a tenuta stagna fin dall’inizio, quindi quando si scopre che non lo era, non hai alcun punto di partenza per la pulizia. Scoprire il bug non è la fine del problema. È l’inizio di uno molto più difficile: capire fino a dove risale il danno.
Costruire in modo che il danno non si accumuli
Non puoi eliminare ogni caso limite scrivendo prompt più accurati. Quello che puoi fare è scegliere dove girano davvero le parti della tua app che gestiscono denaro, quantità o prenotazioni.
Per progetti personali, prototipi interni, o qualunque cosa in cui un numero sbagliato sia un fastidio e non un rischio concreto, il codice generato e i test manuali sono un compromesso ragionevole per la velocità. Il calcolo cambia nel momento in cui i numeri alimentano una fattura per un cliente, un calendario di prenotazioni o un report che qualcuno approva formalmente. A quel punto, la domanda non è più “sembrava corretto quando l’ho testato”, ma “chi controlla che sia ancora corretto dopo diecimila transazioni”.
Per quella categoria di app aziendali, struttura il percorso di scrittura in modo che non dipenda dal fatto che l’IA gestisca correttamente la concorrenza e l’arrotondamento al primo (o al quinto) tentativo:
- Sposta le scritture principali su un’infrastruttura testata, non su codice appena generato. 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, invece che tramite logica generata dall’IA specifica per ogni app. Un rollup che somma le righe di una fattura esegue lo stesso calcolo testato ogni volta, invece di una funzione su misura che un’IA ha scritto una volta e non ha mai sottoposto a stress test per verificare derive di arrotondamento.
- Usa permessi visuali invece di logica di concorrenza scritta a mano. Gli User Groups e le Data Restrictions a livello di record di Softr regolano chi può modificare cosa, il che riduce (senza eliminarlo) il problema delle modifiche simultanee controllando l’accesso a livello di piattaforma, invece di dipendere da un blocco codificato su misura che un’IA potrebbe o non potrebbe aver pensato di aggiungere.
- Riconcilia in modo indipendente, con una cadenza fissa. 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 fornitore di pagamenti, un conteggio manuale. Questo vale sia che tu abbia costruito su codice generato dall’IA sia che non l’abbia fatto, ed è l’unico modo per individuare un errore cumulativo prima che raggiunga un anno di profondità.
- Se resti nel codice, riserva tempo reale per test avversariali. 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 “compila” non dice nulla sul fatto che sia corretto sotto carico.
Niente di tutto questo fa scomparire il problema di fondo. Un software che riguarda denaro o prenotazioni avrà sempre bisogno di qualcuno che verifichi i calcoli rispetto alla realtà. Ma c’è una vera differenza tra un’app in cui la logica di scrittura è stata generata su misura per ogni progetto e non è mai stata sottoposta a stress test, e un’altra in cui le operazioni di database principali seguono lo stesso percorso di codice testato su cui si affida ogni azienda della piattaforma. La prima ti offre una nuova occasione di sbagliare la concorrenza e l’arrotondamento a ogni singola funzionalità. La seconda non ti solleva dalla responsabilità di riconciliare, ma elimina la lotteria quotidiana su se questa particolare funzione di scrittura generata dall’IA gestisca correttamente un doppio clic.
La conclusione onesta è che i crash sono fastidiosi ma indulgenti. La corruzione silenziosa è paziente. Aspetta che il volume di dati sia sufficientemente alto, e il tempo trascorso sufficientemente lungo, perché correggerla costi molto più di quanto sarebbe costato prevenirla.