Come fare debug di un'app creata con l'AI: un metodo pratico

Per fare debug di un'app creata con l'AI, prima fai ricomparire il bug di proposito, poi raccogli le prove — i passaggi esatti, il messaggio di errore e ciò che mostrano la console del browser e la scheda di rete — e presentali all'AI come «ho fatto X, mi aspettavo Y, ho ottenuto Z». Se una correzione peggiora le cose, torna all'ultima versione funzionante invece di accumulare altre correzioni sopra. Non serve leggere il codice per fare tutto questo bene.

Questa guida copre l'intero ciclo, incluso un rapido giro negli strumenti per sviluppatori del browser pensato per chi non è un programmatore.

Il ciclo di debug

Ogni correzione di un bug, che la faccia una persona o un'AI, segue lo stesso ciclo:

1. Riproduci — fai accadere il bug in modo affidabile.
2. Osserva — raccogli il messaggio di errore e cosa stava facendo l'app.
3. Descrivi — dai all'AI passaggi precisi, risultato atteso e risultato effettivo.
4. Correggi — lascia che l'AI cambi una sola cosa.
5. Verifica — ripeti i passaggi esatti e conferma che sia risolto e che nulla vicino si sia rotto.
6. Fai rollback se serve — se è peggiorato, annulla e riprova con informazioni migliori.

Gran parte del tempo perso con le app create con l'AI deriva dal saltare i passaggi 1, 2 e 5: dire «è rotto», accettare una modifica senza provarla e poi chiedere un'altra correzione sopra una versione già rotta.

Passo 1: riproduci il bug

Un bug che puoi innescare a comando è già mezzo risolto. Cerca la sequenza di passaggi più breve che lo causa.

Chiediti:

• Succede ogni volta? Se succede solo a volte, cosa è diverso quando accade — un record particolare, una connessione lenta, l'essere disconnessi?
• Succede a tutti gli utenti? Accedi con un altro account. Molti bug compaiono solo per i nuovi utenti senza dati, o per un utente con un ruolo diverso.
• Succede su tutti i dispositivi? Prova uno schermo di larghezza da telefono e un altro browser.
• È iniziato dopo una modifica precisa? Se funzionava ieri, le ultime modifiche sono i sospetti principali.

Scrivi i passaggi come un breve elenco numerato. Lo incollerai nel prompt più tardi.

Passo 2: leggi il messaggio di errore

I messaggi di errore sembrano intimidatori, ma ti servono solo alcune parti.

Non serve capirlo; serve copiarlo esattamente. «Cannot read properties of undefined (reading 'name')» dice all'AI che il codice si aspettava dei dati (probabilmente una prenotazione o un utente) che non c'erano. Una parafrasi come «un errore undefined» perde quell'informazione.

Alcuni errori comuni, tradotti a grandi linee:

• Errori undefined / null — il codice si aspettava dati che non sono arrivati. Spesso uno stato di caricamento o una lista vuota che il codice non gestisce.
• 404 Not Found — la pagina o l'indirizzo API non esiste. Spesso un refuso in un percorso o un link a una pagina rinominata.
• 401 Unauthorized / 403 Forbidden — la richiesta non era autenticata, oppure l'utente non può fare quell'operazione.
• 500 Internal Server Error — il codice lato server è andato in crash. La ragione vera sta nei log del server, non nel browser.
• Errori CORS — il browser ha bloccato una richiesta verso un dominio diverso. Di solito è un problema di configurazione lato server.

Passo 3: usa gli strumenti per sviluppatori del browser

Ogni browser desktop ha strumenti per sviluppatori integrati («devtools»). Mostrano cosa fa la pagina dietro le quinte. In Chrome, Edge e Firefox, fai clic destro in un punto qualsiasi della pagina e scegli Ispeziona, oppure premi F12 (Cmd+Opzione+I su Mac). In Safari, attiva prima il menu Sviluppo nelle impostazioni di Safari.

Ti bastano tre schede.

Console

La scheda Console elenca errori e messaggi del codice della pagina. Gli errori sono mostrati in rosso. Se un pulsante non fa nulla quando lo clicchi, la console molto spesso mostra un errore rosso nel momento del clic. Copia il testo completo dell'errore (fai clic destro per l'opzione copia nella maggior parte dei browser).

Rete

La scheda Rete elenca ogni richiesta che la pagina fa — caricare dati, salvare un modulo, accedere. Aprila, poi ripeti i passaggi che causano il bug.

• Cerca le righe in rosso o con uno stato uguale o superiore a 400.
• Clicca su una riga fallita per vedere la sua Risposta. Un errore del server spesso include lì un messaggio più utile di qualsiasi cosa sullo schermo.
• Annota l'URL della richiesta e il codice di stato — «il POST a /api/bookings ha restituito 500» è una frase molto utile da dare all'AI.

Spunta Mantieni log se il bug coinvolge un ricaricamento della pagina o un reindirizzamento, così le richieste non scompaiono.

Elementi

La scheda Elementi (o Ispettore) mostra la struttura e gli stili della pagina. È più utile per i bug di layout: passando sopra un elemento ne vedi dimensioni e spaziature evidenziate. Non serve modificare nulla qui; basta dire «il piè di pagina è largo 2.000 pixel su mobile e spinge la pagina di lato».

Passo 4: controlla i log del server

Alcuni bug accadono sul server, dove il browser non li vede. Un errore 500 nella scheda di rete è il segno classico. I log del server — l'output testuale del tuo backend mentre gira — di solito contengono l'errore reale con uno stack trace (l'elenco delle funzioni in esecuzione quando è fallito).

Dove trovarli dipende dallo strumento. Nella maggior parte degli app builder basati sull'AI puoi aprire un terminale o una vista dei log del progetto, oppure chiedere semplicemente all'AI: «Controlla i log del server per gli errori dall'ultima richiesta e dimmi cosa è fallito».

Passo 5: descrivi il bug all'AI

Metti insieme ciò che hai raccolto in questa forma:

Nella pagina Prenotazioni, con accesso come membro: ho cliccato Annulla sulla lezione di domani alle 9:00. Atteso: la prenotazione scompare e la lezione mostra un posto libero in più. Effettivo: sullo schermo non cambia nulla. La console mostra TypeError: Cannot read properties of undefined (reading 'id') in BookingCard.tsx:31, e la scheda di rete mostra che DELETE /api/bookings/123 ha restituito 500. Trova la causa, correggila e verifica che l'annullamento funzioni per un membro con una prenotazione e per uno con più prenotazioni.

Perché ogni parte conta:

• Dove e come chi restringe il problema a una schermata e a un ruolo.
• I passaggi esatti permettono all'AI di riprodurlo.
• Atteso vs effettivo definisce cosa significa «risolto».
• Il testo dell'errore e la richiesta fallita indicano direttamente la causa.
• «Verifica che…» chiede all'AI di controllare, non solo di modificare.

Se l'AI ha tentato due correzioni senza successo, chiedile di spiegare prima di cambiare qualsiasi cosa:

Non cambiare ancora il codice. Cosa pensi causi questo problema, e quali prove lo sostengono?

Una teoria sbagliata è facile da individuare quando viene scritta, ed è molto più economica da correggere di una correzione sbagliata.

Passo 6: verifica, poi controlla ciò che sta vicino

Quando l'AI dice che è risolto, ripeti i passaggi esatti del Passo 1. Poi controlla ciò che gli sta intorno:

• La stessa azione per un ruolo utente diverso
• La stessa azione senza dati e con molti dati
• Le pagine che condividono componenti con quella che hai corretto
• Uno schermo di larghezza da telefono, se la correzione ha toccato il layout

Le modifiche dell'AI a volte correggono un percorso e rompono in silenzio un altro. Un controllo di due minuti adesso ti risparmia un'ora di confusione dopo.

Passo 7: fai rollback invece di accumulare

Se una correzione ha peggiorato le cose, o se sei al terzo giro senza progressi, torna indietro. Tornare all'ultima versione funzionante e riformulare con prove migliori quasi sempre batte chiedere una quarta correzione sopra tre sbagliate. Ogni tentativo fallito lascia codice che confonde il tentativo successivo.

Buone abitudini che rendono facile il rollback:

• Testa dopo ogni modifica, così sai quale cambiamento ha rotto le cose.
• Mantieni le modifiche piccole — una funzione o una correzione per messaggio.
• Annota l'ultima versione buona prima di iniziare qualcosa di rischioso.
• Se il codice è in Git, fai commit delle versioni funzionanti così puoi tornarci.

Schemi comuni di bug nelle app create con l'AI

Quando il problema non è un bug

Alcuni «bug» sono l'AI che costruisce esattamente ciò che le è stato chiesto, e la descrizione era ambigua. Se la correzione che chiedi è davvero un cambio di comportamento, dillo chiaramente: «Cambia in modo che…». Se non sei sicuro di quale sia il comportamento corretto, decidilo prima. La nostra guida su come scrivere prompt per gli app builder AI spiega come specificare le regole in modo chiaro. E se stai preparando un'app per utenti reali, come portare un prototipo AI in produzione illustra i controlli da fare prima del lancio.

Il debug in Mythex

Mythex ha strumenti per ogni passaggio del ciclo:

• Anteprima per riprodurre il bug, incluso un riquadro di dimensione telefono.
• /test fa cliccare all'agente la tua anteprima dal vivo come un utente e riporta i flussi rotti.
• /fix indirizza l'agente specificamente sui problemi.
• La modalità Piano permette all'agente di indagare e spiegare prima di modificare qualsiasi cosa.
• Codice → terminale mostra i log del server della tua app.
• Ripristina a questo punto su qualsiasi risposta riporta il progetto al checkpoint.

Se una pubblicazione fallisce, la finestra di pubblicazione di solito offre Correggi con l'AI, che legge l'output della build o i log dell'app. Vedi Fai debug della tua app e Risoluzione dei problemi di pubblicazione nella documentazione.

Domande