DevTools, log e network: verificare ciò che l’AI dichiara

L’AI può dire “ho gestito l’errore”, “la richiesta viene validata”, “il token non è esposto”, “il form invia i dati correttamente”. Sono frasi utili, ma non sono prove. La prova è ciò che osservi nel browser, nel terminale, nei log, nella tab Network, nel database o nei test. Questa lezione insegna a trasformare le affermazioni dell’AI in verifiche concrete.

Perché questa lezione conta

Nel vibe coding il rischio non è solo che il codice sia sbagliato. Il rischio è che sembri giusto abbastanza da non farti controllare. Una UI può mostrare “salvato” anche se la API ha risposto 500. Un form può validare nel browser ma mandare comunque payload sporchi al server. Un token può non apparire nello schermo ma finire in localStorage, in un log o in una query string.

DevTools e log sono il ponte tra “il modello sostiene” e “il sistema fa”. Se impari a usarli presto, smetti di discutere con l’AI in astratto e inizi a verificare con segnali osservabili.

Obiettivo operativo

Alla fine devi saper:

1. collegare ogni affermazione dell’AI a una prova osservabile;
2. usare Console, Network e log per verificare un flusso generato;
3. scrivere un mini report di verifica che dica cosa è confermato, cosa è falso e cosa resta non verificato.

Nucleo della lezione

1. Affermazione, prova, conclusione

Ogni controllo parte da una frase:

L'AI dice: "Il form gestisce errore di rete mostrando un messaggio all'utente."

Trasformala in prova:

Prova: apro DevTools, simulo offline nel tab Network, invio il form.
Segnali attesi: richiesta fallita, nessun crash console, messaggio visibile, pulsante riabilitato.
Conclusione: confermato / falso / parziale.

Questo schema evita una trappola frequente: controllare genericamente “se funziona”. Tu non vuoi un’impressione generale; vuoi sapere se una promessa specifica è vera.

2. Console: errori, warning e segnali runtime

La Console risponde a domande come:

• ci sono errori JavaScript durante il flusso?
• ci sono warning di framework che indicano stato incoerente?
• una promise fallisce senza gestione?
• un click produce l’evento previsto?
• i log contengono dati sensibili?

Non tutti i warning bloccano il rilascio. Ma ogni errore rosso durante il flusso principale va capito, non ignorato. Anche un errore “innocuo” può indicare che un branch non testato sta fallendo.

Pattern da cercare:

• Cannot read properties of undefined: dati mancanti non gestiti.
• Unhandled Promise Rejection: errore async non catturato.
• hydration mismatch: markup server/client incoerente.
• warning su key duplicate: lista renderizzata male.
• log con email, token, payload personali: problema privacy.

Quando trovi un errore, copia messaggio, stack e azione che lo produce. Non basta dire “c’è errore in console”.

3. Network: la realtà delle API

La tab Network è spesso più sincera della UI. Controlla:

Request:

• metodo corretto (GET, POST, PUT, DELETE);
• URL previsto, senza segreti in query string;
• payload coerente con la specifica;
• header necessari presenti;
• nessun dato personale superfluo.

Response:

• status code corretto (200, 201, 400, 401, 403, 500);
• corpo coerente;
• errori non troppo dettagliati;
• redirect non inattesi;
• caching compatibile con dati sensibili.

Sequenza:

• richieste duplicate dopo un click;
• fetch ripetuti a ogni render;
• chiamate fatte prima che l’utente autorizzi;
• dati caricati anche per utenti non autorizzati.

Esempio: la UI mostra “Accesso negato”, ma Network rivela che la risposta con i dati privati è arrivata 200 e solo dopo il client li ha nascosti. Questo non è access control: è cosmetica pericolosa.

4. Log applicativi e terminale

Se hai backend o dev server, guarda anche il terminale. Domande:

• il server riceve il payload che pensi?
• la validazione avviene lato server o solo lato client?
• gli errori sono loggati con contesto utile ma senza segreti?
• una richiesta fallita produce stack trace comprensibile?
• il server continua a funzionare dopo input ostile?

Log buono:

POST /api/newsletter 400 invalid_email requestId=req_123

Log cattivo:

Validation failed for email=mario@example.com token=sk_live_...

Il primo aiuta a capire. Il secondo espone dati.

5. Verifica guidata con tabella

Usa una tabella semplice:

Affermazione	Dove verifico	Segnale atteso	Risultato	Decisione
Validazione lato server	Network + log server	400 se payload invalido anche bypassando UI	Parziale: UI blocca, API accetta	Correggere
Nessun token esposto	Network + Storage + Console	token assente da URL/log/localStorage	Confermato	Accetto
Errore rete gestito	Network offline + Console	messaggio + nessun crash	Falso: spinner infinito	Blocca

Questa tabella trasforma la verifica in documento. È breve, ma evita discussioni vaghe.

Procedura pratica

Per verificare una feature generata:

1. Elenca 3-5 affermazioni che l’AI o il diff implicitamente fanno.
2. Apri Console e Network prima di interagire con la pagina.
3. Esegui il flusso normale e annota richieste, errori, redirect.
4. Esegui un caso di errore: input invalido, offline, permesso negato, dato mancante.
5. Controlla storage: cookie, localStorage, sessionStorage, IndexedDB se rilevante.
6. Guarda il terminale/log server durante le richieste.
7. Scrivi conclusione: confermato, parziale, falso, non verificato.
8. Chiedi fix all’AI usando evidenze, non impressioni.

Laboratorio guidato

Feature: form newsletter generato dall’AI.

Affermazioni da verificare:

1. email vuota viene rifiutata;
2. email malformata viene rifiutata lato server;
3. doppio click non crea doppia iscrizione;
4. errore di rete mostra messaggio e non blocca il form;
5. nessun dato sensibile finisce in console.

Esecuzione:

Setup:
- DevTools aperti, tab Console pulita.
- Tab Network aperta, "Preserve log" attivo.
- Server dev visibile nel terminale.

Caso 1:
- invio email vuota.
- atteso: nessuna chiamata o chiamata 400, messaggio inline.

Caso 2:
- disabilito validazione HTML dal browser o invio request manuale con payload {"email":"abc"}.
- atteso: API 400. Se API 200, validazione solo client: bug.

Caso 3:
- doppio click su submit.
- atteso: una sola request oppure seconda bloccata.

Caso 4:
- Network offline, submit.
- atteso: messaggio errore, pulsante riabilitato, nessun crash console.

Report:

Verifica newsletter - commit abc123

Confermato:
- email vuota bloccata lato UI;
- offline mostra messaggio.

Falso:
- API accetta "abc" se bypasso UI: validazione non server-side.
- doppio click produce due POST identiche.

Non verificato:
- duplicato email, perché ambiente locale non ha seed.

Decisione:
- bloccare merge finché validazione server e debounce/disable submit non sono corretti.

Output atteso

Un report di verifica breve, salvato nel task o in qa/, con:

• feature e commit/versione;
• affermazioni verificate;
• evidenze essenziali;
• problemi trovati;
• decisione finale.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: usare browser, console, tab Network e log applicativi per controllare il comportamento reale invece di fidarsi della descrizione del modello. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Console e runtime: errori, warning, stack trace, log utili e log rumorosi.
• Network: status code, payload, header, redirect, caching, richieste duplicate e dati sensibili esposti.
• Verifica guidata: collegare ogni affermazione dell’AI a un segnale osservabile nel browser o nel terminale.

3. Applicazione: svolgi il laboratorio: aprire una feature generata, eseguire un flusso utente e raccogliere evidenze da console, Network e log server. L’output da ottenere è: un report di verifica con screenshot/log essenziali e conclusione: confermato, da correggere o non verificabile.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• apro DevTools prima di testare, non dopo;
• controllo Console e Network durante il flusso principale;
• verifico almeno un caso di errore;
• controllo payload e status code, non solo messaggio UI;
• cerco dati sensibili in URL, storage, console e log;
• distinguo “confermato” da “non verificato”;
• passo all’AI log e osservazioni concrete quando chiedo fix.

Errori comuni

Guardare solo la UI. La UI può mentire per omissione. Network mostra cosa è successo davvero.

Non simulare errori. Il caso felice dice poco. Offline, 400, 401, 500 e dati mancanti rivelano qualità.

Copiare log incompleti. “Non funziona” non aiuta. Servono azione, request, status, errore, stack.

Esporre segreti durante il debug. Screenshot e log possono contenere token o email. Oscura prima di condividere.

Fidarsi del messaggio dell’AI. “Ho aggiunto validazione server-side” va controllato con request diretta o bypass UI.

Prompt di lavoro

Ho verificato la feature con DevTools. Non voglio una diagnosi astratta: usa queste evidenze.

Task originale:
[descrizione]

Osservazioni:
- Console: [errori/warning]
- Network: [method, URL, status, payload rilevante]
- Log server: [estratto]
- Passi per riprodurre: [1, 2, 3]
- Atteso: [...]
- Osservato: [...]

Chiedimi eventuali dettagli mancanti, poi proponi:
1. causa probabile;
2. file da controllare;
3. patch minima;
4. verifica da rieseguire.

Non fare refactor non collegati.

Esercizio finale

Scegli una feature già generata e scrivi tre affermazioni da verificare. Per ciascuna trova una prova in DevTools, Network o log. Non serve correggere subito: l’obiettivo è allenare lo sguardo. Alla fine devi avere una tabella in cui almeno una riga sia “non verificato” o “parziale”. Se tutte le righe sono “confermato” senza fatica, probabilmente hai scelto affermazioni troppo facili.