Come leggere i messaggi di errore:ogni errore in 30 secondi
Come leggere i messaggi di errore quando la tua app costruita con l'AI si rompe: apri la console, decifra la prima riga e il file, risolvi in 30 secondi.
Come leggere i messaggi di errore: non sei bloccato — semplicemente non vedi l'errore. Ogni volta che la tua app costruita con l'AI si rompe "misteriosamente", scrive nella console del browser una spiegazione esatta di cosa è andato storto. Apri la console con una scorciatoia da tastiera, leggi la prima riga e il nome del file, e puoi decifrare quasi qualsiasi errore in 30 secondi — senza una laurea in ingegneria.
Questa è la competenza con la leva più alta per un founder non tecnico che costruisce con l'AI. Non perché risolverai da solo ogni errore, ma perché la differenza tra "si è rotto, aiuto" e incollare a Claude l'errore esatto è la differenza tra un'ora di tentativi alla cieca e una correzione in 30 secondi.
Come aprire la console del browser
La console è il backstage del tuo sito. Se la tua app è uno spettacolo teatrale, la console è dove vedi i macchinisti, i segnali e il momento esatto in cui qualcosa cade. Per aprirla:
- Chrome: Cmd + Option + J su Mac, Ctrl + Shift + J su Windows — oppure clic destro ovunque, scegli Ispeziona, poi clicca sulla scheda Console
- Firefox: Cmd + Option + K su Mac, Ctrl + Shift + K su Windows
- Safari: attiva prima il menu Sviluppo (Impostazioni, Avanzate, "Mostra menu Sviluppo"), poi Cmd + Option + C
Due schede contano. Console mostra errori e log — parti da qui ogni volta che qualcosa non funziona. Network mostra ogni richiesta che la tua app fa ai server — usala quando il login fallisce o i dati non si caricano: aggiorna la pagina, cerca le righe rosse, cliccane una per vedere i dettagli. E no, guardando non puoi rompere niente. La console è di sola lettura per impostazione predefinita.
Come leggere i messaggi di errore: l'anatomia di un errore
I messaggi di errore sembrano intimidatori perché sono scritti per sviluppatori che conoscono il gergo. Ma hanno una struttura fissa, come una diagnosi medica — termini tecnici, una posizione esatta e informazioni sufficienti per risolvere il problema. Quattro parti, sempre nello stesso ordine:
- Il tipo di errore. La categoria: un TypeError significa che stai usando qualcosa nel modo sbagliato, un ReferenceError che stai usando qualcosa che non esiste, un SyntaxError che il codice ha un refuso, un NetworkError che l'app non riesce a raggiungere un server.
- La descrizione. Il problema specifico in una riga — "Cannot read property of undefined" significa che il codice ha provato a usare dati che non ci sono ancora.
- La posizione. Un nome di file, un numero di riga e una posizione del carattere. È la parte più utile: ti dice esattamente dove guardare.
- Lo stack di chiamate. La catena di chiamate di funzione che ha portato all'errore. Di solito ti interessano solo le prime righe che citano file che riconosci — il resto è codice interno delle librerie che puoi ignorare.
Il metodo dei 30 secondi: leggi la prima riga per capire cosa è andato storto, trova il primo nome di file che riconosci per capire dove, e ignora tutto ciò che cita gli interni delle librerie.
Rosso, giallo, grigio: cosa significano i colori
La console codifica tutto con i colori in base alla gravità, e questo ti dice cosa merita la tua attenzione:
- Rosso = errore. Qualcosa si è rotto adesso e l'app non può continuare. Fermati e correggilo.
- Giallo = avviso. Oggi funziona ma potrebbe rompersi dopo o andare lenta. Correggilo quando puoi — gli avvisi non fermeranno la tua app.
- Bianco o grigio = informazione. Log normali. Alcune librerie sono semplicemente chiacchierone. Ignorali.
Una console piena di messaggi non è automaticamente un male. Concentrati sui rossi, annota i gialli e ignora il resto.
Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →I sei errori che vedrai davvero (decifrati)
Costruendo un SaaS con strumenti di AI come Claude e Supabase, lo stesso pugno di errori spiega quasi tutto. Ecco la traduzione in parole semplici:
| L'errore | In parole semplici | La prima cosa da provare |
|---|---|---|
| Cannot read property of undefined | Il codice usa dati che non sono ancora stati caricati | Aggiungi un controllo di caricamento prima di usare i dati |
| 401 Unauthorized | Non hai effettuato l'accesso, o la sessione è scaduta | Esci, rientra e riprova |
| 403 Forbidden | Hai effettuato l'accesso ma non hai il permesso | Controlla il tuo ruolo e le policy di sicurezza del database |
| 404 Not Found | La pagina o l'endpoint non esiste | Controlla l'ortografia dell'URL; verifica che la route esista |
| Network request failed | L'app non riesce a comunicare con il server | Verifica che il dev server sia attivo e che le impostazioni dell'URL siano corrette |
| Row violates security policy | Il livello di sicurezza del database blocca l'operazione | Controlla di essere autenticato e che la policy consenta questa azione |
I codici di stato seguono una sola regola: tutto ciò che sta nei 200 significa successo, i 400 significano che hai sbagliato qualcosa (dati errati, non hai effettuato l'accesso, nessun permesso, indirizzo sbagliato) e i 500 significano che si è rotto il server stesso. Questa sola regola decifra l'intera scheda Network.
Cosa incollare quando chiedi aiuto all'AI
Qui saper leggere gli errori ripaga. Quando passi un errore a Claude, la qualità della risposta la decide ciò che incolli. Tre cose, ogni volta:
- Il messaggio di errore completo — compresi nome del file e numero di riga, copiato direttamente dalla console (clic destro sul messaggio, Copia)
- Il codice intorno all'errore — circa cinque righe prima e dopo la riga a cui punta l'errore
- Cosa stavi facendo — una frase: "Stavo cercando di caricare la pagina del profilo dopo il login"
Con queste tre cose, l'AI risolve la maggior parte degli errori al primo tentativo. Senza, tira a indovinare — ed è così che finisci nel pasticcio descritto in i segnali che l'AI sbaglia con sicurezza. Se lo stesso errore continua a tornare, o ti sei bloccato in uno scenario più che in un singolo errore, il post successivo passa in rassegna i dieci problemi più comuni nel costruire con l'AI e le loro soluzioni.
Gli errori non sono il nemico. Sono l'app che ti dice esattamente di cosa ha bisogno. I founder che rilasciano non sono quelli che non vedono mai testo rosso — sono quelli che hanno smesso di averne paura.
12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →Domande frequenti
Devo capire il codice per leggere i messaggi di errore?
No. Devi riconoscere le quattro parti — tipo, descrizione, posizione, stack di chiamate — e copiarle con precisione. Tipo e descrizione dell'errore sono quasi italiano semplice una volta che hai visto quelli comuni, e la posizione è solo un nome di file e un numero di riga. Il resto lo fa l'AI.
Posso rompere la mia app usando la console del browser?
No. Gli strumenti per sviluppatori sono di sola lettura per impostazione predefinita — guardi dietro le quinte, non sposti la scenografia. Puoi aprire la console, scorrere le schede e copiare i messaggi senza alcun rischio per la tua app o i tuoi dati.
Quali errori devo correggere per primi?
Gli errori rossi che bloccano i flussi principali: errori di rete, errori di autenticazione, errori del database e tutto ciò che produce una schermata bianca. Gli avvisi gialli possono aspettare. I log informativi grigi non richiedono alcuna azione — sono solo l'app che racconta la sua giornata.
E se la console non mostra errori ma l'app continua a comportarsi male?
Controlla la scheda Network per righe rosse — una richiesta fallita non genera sempre un errore visibile in console. Se anche la rete è pulita, i dati probabilmente vengono filtrati invece di fallire: account sbagliato, record inattivi o un flag di bozza. Questo scenario e altri nove sono decifrati in la guida ai problemi più comuni nel costruire con l'AI.
Quanto sei intrappolato, davvero?
Fai l'Indice di Soffocamento Aziendale, la valutazione gratuita per capire se sei pronto a diventare solopreneur.