Revisione del codice con Claude Opus 5.5: il prompt che trova i bug prima del merge
Come usare Claude Opus 5.5 per la revisione del codice prima del merge: il prompt ufficiale, perché il livello di sforzo basso basta, e come verificare ogni segnalazione.
La revisione del codice è il caso d'uso in cui Claude Opus 5.5 dà il risultato più sorprendente, e non per il livello di sforzo massimo: Anthropic riporta che un primo utilizzatore ha visto Opus 5.5 al livello di sforzo più basso trovare più bug di Opus 5 al livello alto, con meno falsi allarmi. Se è vero anche sul tuo codice — e si verifica in un pomeriggio — la revisione pre-merge diventa un passaggio a costo quasi nullo.
Il metodo sta tutto in un prompt, quello della guida ufficiale, e in una regola: ogni segnalazione deve dire come far fallire il codice. Dati verificati il 23 settembre 2026.
In sintesi
- Chiedi solo i problemi bloccanti, non tutte le osservazioni.
- Per ognuno: file e riga, perché è sbagliato, come dimostrare che fallisce.
- Parti dal livello di sforzo basso: per la revisione può bastare, e costa meno.
- Una segnalazione senza dimostrazione è un'opinione.
- Sostituisce la prima passata, non la revisione umana.
- Le descrizioni delle pull request sono più leggibili: il modello spiega in linguaggio piano.
Il prompt ufficiale, riga per riga
Tradotto dalla guida di Anthropic:
"Rivedi il diff di questo branch rispetto a main. Elenca solo i problemi per cui bloccheresti il merge. Per ognuno, dammi il file e la riga, perché è sbagliato, e come dimostrare che fallisce."
| Frase | Cosa ottiene |
|---|---|
| "il diff di questo branch rispetto a main" | Perimetro preciso: non tutto il repository, solo le modifiche |
| "solo i problemi per cui bloccheresti il merge" | Lista corta. Niente stile, niente preferenze |
| "file e riga" | Ogni voce è raggiungibile in un clic |
| "perché è sbagliato" | Distingue un bug da un'abitudine diversa |
| "come dimostrare che fallisce" | La verifica: un test, un input, una sequenza di passi |
L'ultima riga è quella che separa questa revisione da un commento generico. Se il modello non riesce a dire come si riproduce il problema, la segnalazione non è un bug: è un'opinione, e la tratti come tale.
Perché il livello di sforzo basso può bastare
Opus 5.5 ha cinque livelli di ragionamento, da low a max, e il default è medium. L'istinto dice: per trovare bug serve il massimo. Il dato riportato da Anthropic dice il contrario per la revisione: al livello più basso ha trovato più bug di Opus 5 al livello alto, con meno falsi positivi.
La spiegazione plausibile è che la revisione di un diff è un compito di attenzione, non di ragionamento profondo: leggere bene ogni riga conta più di pensare a lungo. Il livello alto serve quando il bug è nell'interazione fra parti lontane del sistema, non nella riga sbagliata.
La conseguenza economica è che la revisione pre-merge diventa quasi gratuita: livello basso, prompt corto, diff limitato. Come si impostano e cosa costano i livelli è in i livelli di ragionamento di Opus 5.5.
Il metodo in quattro passi
- Prima passata al livello basso con il prompt ufficiale. Ottieni una lista corta di segnalazioni, ciascuna con la sua dimostrazione.
- Verifica le dimostrazioni: in Claude Code il modello può eseguire il test che propone; nell'app lo esegui tu. Quello che non fallisce come descritto si scarta.
- Seconda passata a livello alto solo se serve: quando il diff tocca logica distribuita, concorrenza, o parti lontane fra loro.
- Revisione umana su quello che resta: architettura, leggibilità, scelte di prodotto. Le cose che un test non misura.
Cosa chiedere e cosa no
Chiedi
- Problemi bloccanti, con file, riga e dimostrazione
- Condizioni non gestite: input vuoti, valori nulli, errori di rete
- Regressioni rispetto ai test esistenti
- Differenze fra quello che il codice fa e quello che la pull request dice di fare
Non chiedere
- "Cosa ne pensi di questo codice"
- Suggerimenti di stile mescolati ai bug
- Di riscrivere tutto "in modo migliore"
- Di mostrare il ragionamento interno: viene segnalato dai filtri
Un caso a parte è la descrizione della pull request: Opus 5.5 spiega le proprie modifiche in linguaggio piano, e Anthropic lo indica come una delle differenze rispetto a Opus 5. Chiedigli di scriverla: "Descrivi cosa cambia questo diff e perché, in modo che chi non ha visto il codice possa decidere se approvare."
Trasformare le segnalazioni in test
Il valore di una revisione non sta nella lista: sta in quello che ne fai. Ogni segnalazione verificata contiene già la materia prima di un test, perché il prompt ha chiesto "come dimostrare che fallisce": quell'input, quella sequenza, quel caso limite.
- Prendi la dimostrazione proposta dal modello — l'importo con tre decimali, il campo vuoto, la richiesta ripetuta due volte.
- Chiedi il test: "Scrivi un test che riproduce questo problema e che oggi fallisce." In Claude Code il modello lo esegue e conferma che fallisce.
- Correggi, e chiedi di rieseguire: il test deve passare, e il resto della suite anche.
- Lascia il test nel repository. È così che il bug non torna, ed è così che la suite cresce sui casi veri invece che su quelli immaginati.
In un mese questo ciclo produce una suite che copre esattamente gli errori che il tuo codice tende a fare, non quelli dei manuali. Per l'impostazione del lavoro in Claude Code — regole di stop, checklist su file, subagenti — vedi Opus 5.5 in Claude Code; per capire perché il livello basso può bastare e cosa costa alzarlo, i livelli di ragionamento.
Revisione di codice non tuo
Un caso frequente nelle PMI: il fornitore consegna un modulo, o un freelance lascia un progetto, e nessuno in azienda è in grado di giudicarlo. Il prompt della revisione funziona anche qui, con una modifica: invece del diff rispetto a main, il perimetro è il modulo intero, e alla richiesta si aggiunge "segnala anche tutto ciò che dipende da servizi esterni, credenziali o configurazioni che non vedo".
Il risultato non è un giudizio sulla qualità del fornitore. È una lista di cose concrete da chiedere prima dell'accettazione: quel valore scritto nel codice, quella chiamata senza gestione dell'errore, quel test che manca. Chi non programma può portarla in riunione, come spiegato in Claude per il codice.
Esempi pratici
Software house, 8 sviluppatori, Bologna. Pull request di 600 righe su un modulo di fatturazione. Prima passata al livello basso: quattro segnalazioni, tre con test riproducibile, una senza (scartata). Una delle tre era un arrotondamento sbagliato sui totali con IVA: il test proposto dal modello era un importo con tre decimali. Tempo totale: dodici minuti, di cui dieci per eseguire i test.
Sviluppatore singolo, e-commerce su misura, Rimini. Usa il prompt nell'app incollando il diff prima di ogni deploy, perché non lavora in Claude Code. Il modello non può eseguire i test, ma la richiesta "come dimostrare che fallisce" produce comunque l'input esatto da provare. Ha smesso di chiedere "trova errori" — che restituiva venti osservazioni di stile — e chiede solo i bloccanti.
Errori da evitare
- Chiedere tutte le osservazioni. I due bug veri spariscono fra le venti preferenze.
- Accettare segnalazioni senza dimostrazione. Senza un modo per farlo fallire, non è un bug.
- Partire dal livello massimo. Costa di più e, per la revisione, non è detto che trovi di più.
- Far rivedere tutto il repository invece del diff. Perimetro largo, segnalazioni deboli.
- Saltare la revisione umana perché "l'AI ha già guardato". Ha guardato i bug meccanici, non le scelte.
- Chiedere il ragionamento interno per "capire come ha trovato il bug". Viene segnalato e la richiesta passa a un modello precedente.
Come applicarlo in azienda
Per un team, la revisione con Opus 5.5 funziona se diventa un passaggio fisso, non un'iniziativa del singolo:
- Il prompt ufficiale in un file condiviso del repository, così tutti usano lo stesso.
- Prima passata obbligatoria prima di aprire la pull request, al livello basso.
- Le dimostrazioni diventano test: ogni bug trovato aggiunge un caso alla suite, così non torna.
- La revisione umana legge la lista corta, non il diff intero. Il tempo del revisore va sulle scelte.
Per il quadro generale del lavoro in Claude Code — run lunghe, regole di stop, subagenti — vedi Opus 5.5 in Claude Code. Per il confronto con altri strumenti, Claude per il codice.
Conclusione
La revisione del codice con Opus 5.5 vale per una ragione precisa: costa quasi niente e produce segnalazioni verificabili. Il prompt è di tre righe, il livello di sforzo può restare basso, e la regola "dimmi come farlo fallire" trasforma ogni voce in qualcosa che si controlla in un minuto. Il revisore umano resta, ma legge una lista di quattro cose invece di seicento righe.
Se vuoi passare dai test con ChatGPT a un sistema AI integrato nei processi aziendali, Giallo Studio progetta agenti e automazioni su misura.
Come lo applichiamo in azienda
Risorse correlate
FAQ
Qual è il prompt per la revisione del codice con Opus 5.5?
Quello della guida ufficiale: rivedi il diff di questo branch rispetto a main; elenca solo i problemi per cui bloccheresti il merge; per ognuno dai file e riga, perché è sbagliato, e come dimostrare che fallisce. La parte decisiva è l'ultima: ogni segnalazione deve essere verificabile.
Serve il livello di sforzo massimo per la revisione?
No. Anthropic riporta che un primo utilizzatore ha visto Opus 5.5 al livello di sforzo più basso trovare più bug di Opus 5 al livello alto, con meno falsi allarmi. Per la revisione conviene partire dal livello basso e alzare solo se i risultati lo richiedono.
Perché chiedere solo i problemi che bloccano il merge?
Perché una revisione che elenca tutto — stile, preferenze, suggerimenti — nasconde i due errori veri fra venti osservazioni. Restringere alle segnalazioni bloccanti rende la lista corta e ogni voce pesante.
Come si verifica una segnalazione del modello?
Con la dimostrazione che il prompt richiede: come far fallire il codice. Se il modello non sa dire come si riproduce il problema, la segnalazione è un'opinione e va trattata come tale.
La revisione con l'AI sostituisce quella umana?
No. Sostituisce la prima passata: quella che trova i bug meccanici, le condizioni non gestite, gli errori di logica evidenti. La revisione umana resta per architettura, scelte di prodotto e leggibilità.
Vale anche per chi non usa Claude Code?
Sì. Lo stesso prompt funziona nell'app incollando il diff, con l'unica differenza che il modello non può eseguire i test da solo. In Claude Code può farlo, ed è la dimostrazione più forte.