Prompt per debug: sintomo, non causa

Nel debug, il prompt deve partire dal sintomo. Se parti dalla causa presunta, il modello tenderà a confermarla. “È un problema di cache” è molto meno utile di “dopo il login la UI resta anonima finché non aggiorno la pagina”.

Perché questa lezione conta

Un LLM può aiutare molto nel debug: ordinare log, proporre ipotesi, isolare variabili, suggerire test di regressione. Ma se riceve una diagnosi già confezionata, rischia di costruire una spiegazione plausibile attorno a quella diagnosi.

Il prompt di debug deve comportarsi come un buon bug report.

Anatomia del prompt di debug

Include:

• comportamento atteso;
• comportamento osservato;
• passi di riproduzione;
• frequenza;
• ambiente;
• log o errore;
• cosa è cambiato di recente;
• cosa hai già provato;
• cosa non vuoi modificare.

Esempio:

Sintomo:
Dopo login valido, la pagina dashboard mostra ancora "Accedi".

Atteso:
Mostrare nome utente senza refresh manuale.

Osservato:
Dopo refresh la sessione appare corretta.

Ambiente:
Solo produzione dietro LiteSpeed, non in locale.

Cambi recenti:
Refactor gestione cookie.

Prima di proporre patch:
1. formula massimo 3 ipotesi;
2. indica come falsificarle;
3. chiedi dati mancanti se necessari.

Ipotesi prima della patch

Nel debug, una patch precoce può nascondere la causa. Chiedi prima un piano di isolamento.

Buona struttura:

Ipotesi	Prova	Esito atteso
cookie non inviato	controllare header Set-Cookie	cookie assente o attributi errati
stato frontend non aggiornato	log dopo login	sessione server ok, UI stale
cache intermedia	confrontare header cache	risposta autenticata cacheata male

Il modello deve aiutarti a falsificare, non solo a indovinare.

Patch e regressione

Quando arriva la patch, chiedi sempre:

• modifica minima;
• perché quella modifica verifica l’ipotesi;
• test o scenario manuale;
• rischio di regressione;
• cosa controllare se non funziona.

Laboratorio guidato

Prendi tre richieste di debug vaghe:

1. “non funziona il login”;
2. “la build si rompe”;
3. “il salvataggio ogni tanto fallisce”.

Riscrivile come bug report per LLM. Poi chiedi al modello prima ipotesi, non patch.

Confronta:

• qualità delle ipotesi;
• domande di chiarimento;
• riduzione di fix casuali;
• test di regressione proposti.

Output atteso

Un template di bug report ottimizzato per l’AI:

Sintomo:
Atteso:
Osservato:
Passi:
Frequenza:
Ambiente:
Log:
Cambi recenti:
Già provato:
Vincoli:
Output richiesto: ipotesi -> prove -> patch minima.

Checklist di verifica

• descrivo sintomo prima della causa;
• distinguo atteso e osservato;
• includo ambiente e cambi recenti;
• chiedo ipotesi falsificabili;
• chiudo con test di regressione.

Errori comuni

Dire al modello la causa. Se sbagli causa, il modello può rafforzare l’errore.

Incollare solo lo stack trace. Serve anche cosa stavi facendo e cosa ti aspettavi.

Accettare patch senza prova. Una patch che “sembra giusta” non è debug completato.

Collegamenti

• Modulo: Prompt per il ciclo di codice — lezione 19 del corso.
• Lezione precedente: Prompt per code review: severità e categorie.
• Prossima lezione: Prompt per test e documentazione.