Prompt per code review: severità e categorie

Una review generica produce commenti generici. Una review utile ha categorie, severità, soglia di intervento e formato. Il modello deve sapere cosa cercare e cosa ignorare.

Perché questa lezione conta

Gli LLM sono bravi a trovare molte osservazioni. Questo è anche il problema: una lista lunga di note non ordinate può rallentare il team. In una review professionale conta distinguere bug bloccanti, rischi concreti, suggerimenti e preferenze personali.

Categorie

Definisci le categorie prima della review:

• correttezza;
• sicurezza;
• regressioni;
• performance;
• accessibilità;
• manutenibilità;
• test mancanti;
• documentazione necessaria.

Non tutte servono sempre. Su una patch backend, accessibilità può non essere rilevante. Su una UI pubblica, invece, può essere bloccante.

Severità

Una scala semplice:

Severità	Significato
P0	bug critico o rischio immediato
P1	blocca merge
P2	da correggere, ma non sempre bloccante
P3	suggerimento
Nit	nota minore, spesso da omettere

Nel prompt devi dire quale soglia mostrare.

Prompt operativo

Ruolo: code reviewer pragmatico.

Revisiona questo diff.

Mostra solo finding P0-P2.
Ignora stile, naming e preferenze personali se non causano bug.

Per ogni finding:
- severità;
- categoria;
- file/riga se disponibile;
- problema;
- impatto;
- fix suggerito.

Se non trovi problemi sostanziali, dillo chiaramente.

Questo prompt produce una review più simile a una review umana senior: pochi commenti, ma utilizzabili.

Cosa fornire al modello

Una review richiede contesto:

• diff;
• obiettivo della patch;
• file rilevanti non presenti nel diff;
• test esistenti;
• vincoli di sicurezza;
• standard del team;
• parti fuori scope.

Senza obiettivo, il modello può giudicare una scelta corretta come “strana” solo perché non conosce il motivo.

Laboratorio guidato

Prendi un diff reale o simulato. Fai due review:

1. prompt: “fai una code review”;
2. prompt con categorie, severità e soglia.

Confronta:

• numero commenti;
• commenti azionabili;
• falsi positivi;
• problemi bloccanti trovati;
• tempo necessario per decidere cosa fare.

Output atteso

Un template di prompt per code review da integrare nel workflow Git.

Template:

Review target:
Obiettivo PR:
Diff:
Categorie da valutare:
Soglia severità:
Contesto extra:
Formato finding:

Checklist di verifica

• la review distingue categorie e severità;
• i finding hanno impatto e fix suggerito;
• il modello sa cosa ignorare;
• il prompt include l’obiettivo della PR;
• il risultato può diventare commento di review senza riscrittura completa.

Errori comuni

Chiedere tutti i possibili problemi. Produce rumore.

Non definire severità. Il modello mette sullo stesso piano bug e preferenze.

Dimenticare l’obiettivo della patch. Senza obiettivo, la review giudica il codice fuori contesto.

Collegamenti

• Modulo: Prompt per il ciclo di codice — lezione 18 del corso.
• Lezione precedente: Prompt per refactor: prima il piano, poi il diff.
• Prossima lezione: Prompt per debug: sintomo, non causa.