Come controllare un sito creato con l'IA prima di pubblicarlo

Un'IA può creare in pochi minuti una landing page o un modulo che sembra finito. Quella velocità è il vantaggio del vibe coding, ma rende anche facile confondere una bella anteprima con un prodotto pronto. Un sito può apparire impeccabile e avere collegamenti sbagliati, dati che spariscono, errori senza spiegazione o un'azione server che si fida di valori modificabili.

Questo controllo di pubblicazione usa come esempio l'iscrizione a un workshop. La persona sceglie una sessione, scrive nome ed e-mail e riceve una conferma. Sette controlli separano la bozza generata da una versione che puoi pubblicare con responsabilità. Ognuno richiede una prova osservabile, non la frase «dovrebbe funzionare».

1. Fissa il risultato e il perimetro prima di provare

Scrivi una frase con il risultato obbligatorio: «Su mobile e desktop, una persona interessata può scegliere un workshop disponibile, inviare dati di contatto validi e ricevere una conferma inequivocabile». Aggiungi ciò che non fa parte di questa versione, per esempio pagamenti, account utente o sincronizzazione con il calendario.

Questo limite evita che l'IA aggiunga funzioni durante la revisione e alteri ciò che già funzionava. Un prompt ben delimitato indica anche la zona interessata, ciò che deve restare uguale e i criteri di accettazione. Salva lo stato iniziale nel controllo di versione o come anteprima con un nome per identificare esattamente ciò che hai provato.

2. Percorri il cammino principale in un browser reale

Apri il sito come visitatore, non solo come chi legge il codice. Parti dall'ingresso pubblico, arriva all'iscrizione, scegli una sessione, compila il modulo e osserva il risultato. Ripeti dopo un ricaricamento e con uno schermo stretto. Collegamenti, focus, attesa e conferma fanno parte del percorso.

Playwright consiglia di provare il comportamento visibile per la persona. Individua un pulsante dal ruolo e dal nome accessibile e verifica il messaggio di successo visibile. Una classe CSS interna non dimostra che qualcuno possa trovare o capire l'azione.

Il caso corretto non basta. Prova almeno uno stato vuoto, un ingresso non valido e un guasto tecnico:

• Nessuna sessione: la pagina spiega la situazione e offre un passo utile.
• E-mail errata: il campo riceve una spiegazione comprensibile e mantiene il focus.
• Doppio clic o rete lenta: l'iscrizione non viene salvata due volte.
• Il server non risponde: i dati non spariscono in silenzio e il successo non viene simulato.

3. Proteggi entrambi i lati del modulo

I tipi di campo HTML, required, limiti ragionevoli e una risposta immediata aiutano a correggere gli errori. MDN ricorda che la validazione lato client non è una misura di sicurezza completa, perché una richiesta può aggirare l'interfaccia. Il server deve imporre separatamente gli stessi limiti di business.

Nell'iscrizione, il server accetta solo identificatori di sessioni reali, limita la lunghezza dei campi, normalizza l'e-mail in modo consapevole e rifiuta dati inattesi. Conferma anche che resti un posto libero. Un valore nascosto nel modulo non è un'autorizzazione.

Disegna il percorso dei dati: che cosa esce dal browser, dove viene salvato, chi può leggerlo e quando viene cancellato. Se l'IA non riesce a ricavare una risposta chiara da codice e configurazione, resta un rischio aperto.

4. Verifica tastiera, semantica e messaggi

WCAG offre uno standard condiviso per contenuti web più accessibili. Non serve memorizzarlo tutto per una piccola pubblicazione, ma il percorso principale deve restare comprensibile e usabile senza mouse. Naviga con Tab, Maiusc+Tab, Invio e Spazio. Il focus non deve sparire né restare dietro una finestra di dialogo.

Controlla etichette visibili, ordine dei titoli, contrasto, alternative delle immagini e messaggi di stato. Ingrandisci al 200 per cento e usa uno schermo stretto. Un audit automatico trova molti problemi di base, ma non sostituisce la prova da tastiera né una breve revisione con uno screen reader o con persone.

5. Ispeziona i limiti di sicurezza

OWASP raggruppa rischi web ricorrenti come controllo di accesso difettoso, configurazione errata, difetti nella catena di fornitura e injection. Trasforma quelle categorie in domande concrete. Una persona può leggere le iscrizioni altrui? C'è un segreto dentro il pacchetto del browser? Il server si fida di un ruolo inviato dal modulo? Pacchetti esterni e variabili d'ambiente sono sotto controllo?

Chiedi all'IA di indicare prima prove e posizioni, prima di cambiare qualsiasi cosa. Autenticazione, pagamenti, informazioni sanitarie o altri dati sensibili meritano una revisione esperta. Il codice generato non è insicuro per definizione, ma il suo aspetto convincente può nascondere assunzioni non verificate.

6. Misura le prestazioni sui dispositivi rilevanti

web.dev presenta LCP, INP e CLS come Core Web Vitals stabili per caricamento, risposta e stabilità visiva. Sono segnali utili, non un pulsante universale di approvazione. Misura la pagina reale con immagini, font, script e servizi esterni di produzione.

Prova almeno un telefono rappresentativo, una connessione limitata e un browser desktop usato dal tuo pubblico. Osserva l'immagine principale, gli script che bloccano, i controlli lenti e i salti durante il caricamento. Definisci un piccolo budget, come dimensioni massime delle immagini e nessuna dipendenza esterna bloccante senza motivo.

7. Prepara approvazione, osservazione e ripristino

Prima di pubblicare rispondi a tre domande: chi approva? quali segnali mostreranno un guasto? come si recupera la versione precedente? Un'anteprima controllata, come quella dell'articolo su ChatGPT Sites, serve per l'ultima revisione quando pubblico e dati del modulo sono scelti consapevolmente.

Pubblica una versione precisa e provata, non un vago «stato attuale». Poi controlla l'URL pubblico, il percorso principale, gli errori del server e gli invii reali. Il ritorno indietro è affidabile solo quando versione di destinazione, persona responsabile e procedura sono noti.

Elenco compatto per pubblicare

• Obiettivo, esclusioni e versione provata sono registrati.
• Caso corretto, stato vuoto, ingresso non valido e guasto del server sono stati provati nel browser.
• Client e server validano; diritti e percorso dei dati sono comprensibili.
• Il percorso funziona da tastiera, con ingrandimento e su un telefono rilevante.
• Segreti, variabili d'ambiente, dipendenze e punti pubblici sono stati rivisti.
• Le prestazioni sono state misurate con risorse reali e le regressioni critiche corrette.
• Approvazione, osservazione e ripristino hanno una persona responsabile.

Questi controlli non vogliono togliere velocità al lavoro assistito dall'IA. Proteggono il suo vantaggio reale: passare in fretta da un'idea a un prodotto utile di cui puoi spiegare e assumere il comportamento. Quando manca una prova, trasforma quell'assenza nel compito successivo, ben delimitato. L'iterazione resterà rapida senza trasformare la pubblicazione in una scommessa.