Come sai davvero se la tua app vibe-coded funziona?

Hai costruito la cosa. L’hai testata cliccando dappertutto. Il pulsante ha funzionato, il record si è salvato, la dashboard si è aggiornata. Ti senti bene con questo.

Ma non hai scritto tu quel codice, e se sei onesto, probabilmente non l’hai nemmeno letto. Quindi quello che sai davvero è: ha funzionato una volta, per te, facendo l’unica cosa che hai provato. Tutto il resto su se “funziona” è fiducia.

Lo scenario ideale è l’unico percorso che la maggior parte delle persone testa

Ecco come di solito si presenta il test di un’app vibe-coded: carichi un file e viene elaborato. Invii un modulo e il record appare. Clicchi un pulsante e il workflow si attiva. Tutto qui. Questo è il test.

Non è pigrizia. È il limite naturale del test manuale fatto da qualcuno che non ha scritto la logica sottostante. Puoi pensare di testare solo ciò che immagini possa andare storto, e se non riesci a leggere il codice, stai testando la demo, non il sistema. Lo scenario ideale è l’unico percorso su cui l’IA ha sicuramente ottimizzato, dato che è lo scenario del prompt che ha prodotto l’app in primo luogo.

Il problema è che l’uso reale non resta sullo scenario ideale. Gli utenti reali cliccano due volte. Aprono due tab. Tornano indietro e reinviano. Niente di tutto ciò emerge quando tu, il creator, clicchi sulla tua stessa app una volta, con attenzione, nell’ordine in cui ti aspetti che venga usata.

La concorrenza è dove si rompe davvero

L’esempio più chiaro è la concorrenza, ed è genuinamente difficile testarla a mano anche se sai esattamente cosa cercare.

Immagina una funzionalità basata su crediti: un utente avvia un processo, questo costa crediti, e un controllo del saldo dovrebbe bloccarlo una volta che i crediti finiscono. Ora immagina quello stesso utente aprire cinque tab e avviare cinque processi nello stesso secondo, prima che il primo controllo di fatturazione abbia finito di essere eseguito. Se la logica “controlla e poi sottrai” non è costruita per gestire questa sovrapposizione, tutti e cinque i processi possono superare il controllo del saldo prima che uno solo registri una sottrazione. Il risultato è un utente che esegue processi che non può permettersi, un saldo crediti che va in negativo, e uno stato dell’account ormai sbagliato in un modo che nessuno aveva previsto.

Non lo scoprirai cliccando un pulsante una sola volta. Dovresti pensare ad aprire cinque tab, sincronizzare i clic in modo che cadano nella stessa frazione di secondo, e sapere che “controlla saldo” e “sottrai saldo” sono due passaggi separati che possono competere tra loro. Non è una svista nei test. È una categoria di bug che il clic manuale, uno alla volta, non può trovare per costruzione, perché il bug esiste solo quando più cose accadono contemporaneamente, e una singola persona che testa da sola non può facilmente creare quella condizione di proposito, tanto meno ripeterla.

Questo è esattamente il tipo di caso limite che la ricerca sulle app generate dall’IA segnala come la modalità di fallimento di cui nessuno tiene conto: l’IA costruisce percorsi per lo specifico scenario di successo che le è stato richiesto, non per modifiche concorrenti, clic duplicati o scarti temporali tra i passaggi. E poiché la corruzione risultante non genera un errore, resta lì in silenzio finché un report o un saldo non appaiono sbagliati settimane dopo.

Perché quasi nessuno scrive i test che lo individuerebbero

La soluzione onesta per questa categoria di bug è il test automatizzato: test unitari, test di integrazione, qualcosa capace di simulare cinque richieste simultanee e verificare il risultato in modo meccanico, invece di fare affidamento sull’immaginazione e la pazienza di una persona. I test automatizzati non si stancano, non dimenticano un caso limite, e possono essere rieseguiti dopo ogni modifica per assicurarsi che qualcosa che hai corretto lunedì non si sia rotto martedì.

In pratica, i vibe coder quasi non hanno mai questo. Scrivere una suite di test è una competenza tecnica a sé stante, probabilmente più difficile della scrittura dell’app stessa, perché richiede di ragionare sui modi in cui qualcosa può fallire, non solo sul fatto che la funzionalità funzioni. Un agente IA può scrivere test se glielo chiedi, ma qualcuno deve comunque sapere di doverlo chiedere, capire cosa verificano davvero i test, e mantenerli aggiornati mentre l’app cambia sotto di loro. Per un creator non tecnico che lancia un portale clienti un martedì pomeriggio, è un ponte troppo lungo, e persino i creator tecnici che vibe-codano velocemente raramente si fermano a scrivere copertura di test per codice che comunque sostituiranno con il prossimo prompt.

Quindi lo stato realistico dei test sulla maggior parte delle app vibe-coded è: un solo passaggio sullo scenario ideale, fatto una volta, dalla persona meno equipaggiata per indovinare cosa potrebbe andare storto. Questo è il vuoto di fiducia. Non stai verificando che l’app funzioni. Stai sperando che funzioni, basandoti sull’unica cosa che hai provato.

Cosa significa davvero “certezza visiva”

Esiste una vera alternativa allo sperare, e non è “imparare a scrivere suite di test”. È costruire le parti rischiose su una base dove la logica non è nascosta fin dall’inizio.

Certezza visiva significa poter aprire un pannello impostazioni e vedere esattamente quale gruppo di utenti può visualizzare un record, esattamente quale filtro un blocco applica a una fonte di dati, e esattamente cosa fa un workflow passo dopo passo, in ordine, senza leggere una riga di codice generato. Non stai testando un comportamento per dedurne la regola. Stai leggendo la regola direttamente.

Questo conta soprattutto per le categorie in cui il vuoto di fiducia è più costoso: logica di fatturazione, permessi, e tutto ciò che coinvolge utenti concorrenti. Una piattaforma come Softr gestisce questo mantenendo permessi, restrizioni sui dati e passaggi del workflow come configurazione visiva e ispezionabile, invece di codice generato dall’IA che dovresti controllare riga per riga per fidartene. Se vuoi sapere se un cliente può vedere i record di un altro cliente, apri la regola di restrizione dati e la leggi. Non devi simulare cinque login simultanei e sperare che l’IA abbia gestito correttamente la race condition, perché è l’infrastruttura già testata della piattaforma a far rispettare la regola, non un controllo su misura che l’IA ha scritto per il tuo prompt specifico.

Questo non significa che ogni funzionalità personalizzata sparisca in un pannello impostazioni. Per un’interfaccia davvero personalizzata, un blocco vibe-coded limitato a un solo componente e collegato attraverso il livello esistente di permessi e dati della piattaforma è un rischio molto diverso rispetto a un’intera app di logica di business generata, perché il raggio d’impatto di “l’IA ha sbagliato questa parte” è un blocco, non il sistema di fatturazione.

Il bivio in cui ti trovi davvero

Se la tua app è un progetto da weekend o un prototipo per cui nessuno paga, pubblicala, percorri lo scenario ideale una volta, e vai avanti. La posta in gioco è esattamente quella del test manuale che hai fatto.

Se è un portale clienti, un sistema di prenotazioni, o qualcosa con crediti, saldi o ruoli, la domanda onesta non è “l’ho testato?”. È “posso davvero verificare le parti che farebbero male se fossero sbagliate, o mi sto fidando della parola di un’IA?”. Se la risposta è fiducia, è lo stesso bivio di cui abbiamo già scritto a proposito di il problema del Day Two, ed entrambi i rami sono legittimi a seconda di chi sei.

Se sai leggere il codice, o sei disposto a imparare, chiudi il divario con strumenti reali invece che con un altro builder. Cursor lavora dentro una codebase vera dove puoi chiedere test di concorrenza e poi leggere il risultato, e Replit ti offre un ambiente cloud dove eseguire una suite di test è una parte normale del ciclo, non un ripensamento. In entrambi i casi il divario non è la capacità dell’IA, è se sai di dover chiedere il test e sai valutare se è valido.

Se non puoi, e stai costruendo il tipo di app in cui un permesso sbagliato o un saldo negativo è un problema reale, sposta le parti rischiose su una base dove leggi la regola invece di indovinarla. Guarda la nostra classifica dei portali clienti se è questa l’app che stai davvero costruendo, perché è lì che una supposizione sbagliata costa più cara.