Home
Blog
La revisione del codice AI migliora quando i modelli discutono: Claude vs Gemini vs Codex vs Qwen vs MiniMax

La revisione del codice AI migliora quando i modelli discutono: Claude vs Gemini vs Codex vs Qwen vs MiniMax

Engineering

February 26, 2026

Li Liu

Di recente ho utilizzato i modelli di intelligenza artificiale per esaminare una richiesta di pull e i risultati sono stati contraddittori: Claude ha segnalato una corsa ai dati, mentre Gemini ha detto che il codice era pulito. Questo mi ha fatto venire la curiosità di sapere come si sarebbero comportati altri modelli di intelligenza artificiale, così ho sottoposto gli ultimi modelli di punta di Claude, Gemini, Codex, Qwen e MiniMax a un benchmark strutturato per la revisione del codice. I risultati? Il modello più performante ha individuato solo il 53% dei bug noti.

Ma la mia curiosità non è finita qui: cosa succederebbe se questi modelli di intelligenza artificiale lavorassero insieme? Ho provato a farli discutere tra loro e, dopo cinque round di dibattito, il rilevamento dei bug è salito all'80%. I bug più difficili, quelli che richiedono una comprensione a livello di sistema, hanno raggiunto il 100% di rilevamento in modalità dibattito.

Questo post illustra il progetto dell'esperimento, i risultati per modello e ciò che il meccanismo del dibattito rivela su come utilizzare effettivamente l'intelligenza artificiale per la revisione del codice.

Analisi comparativa di Claude, Gemini, Codex, Qwen e MiniMax per la revisione del codice

Se avete utilizzato i modelli per la revisione del codice, probabilmente avrete notato che non differiscono solo per l'accuratezza, ma anche per il modo in cui leggono il codice. Per esempio:

Claude di solito percorre la catena di chiamate da cima a fondo e dedica tempo ai percorsi "noiosi" (gestione degli errori, tentativi, pulizia). Spesso è lì che si nascondono i veri bug, quindi non odio la meticolosità.

Gemini tende a iniziare con un verdetto forte ("questo non va bene" / "sembra a posto") e poi lavora a ritroso per giustificarlo da un punto di vista progettuale/strutturale. A volte è utile. A volte sembra che abbia fatto una scrematura e poi si sia impegnato in una presa di posizione.

Il Codex è più silenzioso. Ma quando segnala qualcosa, spesso è concreto e perseguibile: meno commenti, più "questa riga è sbagliata perché X".

Si tratta però di impressioni, non di misurazioni. Per ottenere numeri reali, ho impostato un benchmark.

Impostazione

Sono stati testati cinque modelli di punta:

Claude Opus 4.6
Gemini 3 Pro
GPT-5.2-Codex
Qwen-3.5-Plus
MiniMax-M2.5

Strumenti (Magpie)

Ho usato Magpie, uno strumento di benchmarking open-source che ho costruito. Il suo compito è quello di fare la "preparazione alla revisione del codice" che normalmente si fa manualmente: raccogliere il contesto circostante (catene di chiamate, moduli correlati e codice adiacente pertinente) e darlo in pasto al modello prima di esaminare la PR.

Casi di test (PR di Milvus con bug noti)

Il set di dati consiste in 15 richieste di pull da Milvus (un database vettoriale open-source creato e mantenuto da Zilliz). Queste PR sono utili come benchmark perché ognuna di esse è stata unita, solo per richiedere in seguito un revert o una hotfix dopo che un bug è emerso in produzione. Quindi ogni caso ha un bug noto che possiamo valutare.

Livelli di difficoltà dei bug

Non tutti i bug sono ugualmente difficili da trovare, quindi li ho classificati in tre livelli di difficoltà:

L1: Visibile solo dalla diff (use-after-free, off-by-one).
L2 (10 casi): Richiede la comprensione del codice circostante per individuare cose come i cambiamenti semantici dell'interfaccia o i concurrency race. Questi rappresentano i bug più comuni nella revisione quotidiana del codice.
L3 (5 casi): Richiede una comprensione a livello di sistema per individuare problemi come incongruenze di stato tra moduli o problemi di compatibilità con gli aggiornamenti. Questi sono i test più difficili per verificare quanto profondamente un modello possa ragionare su una base di codice.

Nota: ogni modello ha individuato tutti i bug L1, quindi li ho esclusi dal punteggio.

Due modalità di valutazione

Ogni modello è stato eseguito in due modalità:

Raw: il modello vede solo il PR (diff + qualsiasi cosa contenga il PR).
R1: Magpie estrae il contesto circostante (file rilevanti / siti di chiamata / codice correlato) prima della revisione del modello. Questo simula un flusso di lavoro in cui si prepara il contesto in anticipo invece di chiedere al modello di indovinare ciò di cui ha bisogno.

Risultati (solo L2 + L3)

Modalità	Claude	Gemelli	Codice	MiniMax	Qwen
Grezzo	53% (1°)	13% (ultimo)	33%	27%	33%
R1 (con contesto di Magpie)	47% ⬇️	33%⬆️	27%	33%	40%⬆️

Quattro indicazioni:

1. Claude domina la recensione grezza. Ha ottenuto il 53% di rilevamento complessivo e un perfetto 5/5 sui bug L3, senza alcuna assistenza contestuale. Se si utilizza un solo modello e non si vuole perdere tempo a preparare il contesto, Claude è la scelta migliore.

2. Gemini ha bisogno di essere assistito dal contesto. Il suo punteggio grezzo del 13% era il più basso del gruppo, ma con Magpie che forniva il codice circostante è salito al 33%. Gemini non riesce a raccogliere bene il proprio contesto, ma ha prestazioni rispettabili quando si fa questo lavoro in anticipo.

3. Qwen è il più forte esecutore assistito dal contesto. Ha ottenuto il 40% in modalità R1, con 5/10 sui bug L2, il punteggio più alto a quel livello di difficoltà. Per le revisioni quotidiane di routine in cui si è disposti a preparare il contesto, Qwen è una scelta pratica.

4. Un contesto più ampio non sempre aiuta. Ha migliorato Gemini (13% → 33%) e MiniMax (27% → 33%), ma ha danneggiato Claude (53% → 47%). Claude eccelle già da solo nell'organizzazione del contesto, quindi le informazioni aggiuntive hanno probabilmente introdotto rumore piuttosto che chiarezza. La lezione è: adeguare il flusso di lavoro al modello, piuttosto che presumere che un contesto più ampio sia universalmente migliore.

Questi risultati sono in linea con la mia esperienza quotidiana. Claude al primo posto non è sorprendente. Il fatto che Gemini abbia ottenuto un punteggio inferiore a quello che mi aspettavo ha senso a posteriori: di solito uso Gemini in conversazioni a più turni in cui sto iterando su un progetto o sto affrontando un problema insieme, e si comporta bene in questo contesto interattivo. Questo benchmark è una pipeline fissa a passaggio singolo, che è esattamente il formato in cui Gemini è più debole. La sezione dedicata al dibattito mostrerà che quando si offre a Gemini un formato multi-turno, in contraddittorio, le sue prestazioni migliorano sensibilmente.

Lasciare che i modelli di intelligenza artificiale discutano tra loro

Ogni modello ha mostrato punti di forza e punti deboli diversi nei singoli benchmark. Volevo quindi verificare: cosa succede se i modelli esaminano l'uno il lavoro dell'altro, anziché solo il codice?

Ho quindi aggiunto un livello di dibattito sopra lo stesso benchmark. Tutti e cinque i modelli partecipano a cinque round:

Nel primo round, ogni modello esamina la stessa PR in modo indipendente.
Dopodiché, trasmetto le cinque revisioni a tutti i partecipanti.
Nel secondo round, ogni modello aggiorna la propria posizione in base a quella degli altri quattro.
Ripetiamo fino al quinto round.

Alla fine, ogni modello non reagisce solo al codice, ma anche ad argomenti che sono già stati criticati e rivisti più volte.

Per evitare che il tutto si trasformi in un "LLM che si accordano ad alta voce", ho imposto una regola ferrea: ogni affermazione deve indicare un codice specifico come prova, e un modello non può limitarsi a dire "buona osservazione", ma deve spiegare perché ha cambiato idea.

Risultati: Migliore modalità Solo vs. Dibattito

Modalità	L2 (10 casi)	L3 (5 casi)	Rilevamento totale
Miglior individuo (Raw Claude)	3/10	5/5	53%
Dibattito (tutti e cinque i modelli)	7/10 (raddoppiato)	5/5 (tutti presi)	80%

Cosa si distingue

1. Il rilevamento di L2 è raddoppiato. I bug di routine, di media difficoltà, sono passati da 3/10 a 7/10. Questi sono i bug che appaiono più frequentemente nelle basi di codice reali e sono esattamente la categoria in cui i singoli modelli sbagliano in modo incoerente. Il contributo maggiore del meccanismo di discussione è quello di colmare queste lacune quotidiane.

2. Bug L3: zero errori. Nell'esecuzione di un singolo modello, solo Claude ha individuato tutti e cinque i bug a livello di sistema L3. In modalità di discussione, il gruppo ha eguagliato questo risultato, il che significa che non è più necessario puntare sul modello giusto per ottenere una copertura completa di L3.

3. Il dibattito colma i punti ciechi piuttosto che alzare il tetto. I bug a livello di sistema non erano la parte più difficile per l'individuo più forte. Claude li aveva già. Il contributo principale del meccanismo di dibattito è quello di correggere la debolezza di Claude nei bug di routine L2, dove il singolo Claude ne ha individuati solo 3 su 10, ma il gruppo di discussione ne ha individuati 7. È qui che si verifica il 53% → di copertura L3. Ecco da dove deriva il salto del 53% → 80%.

Come si presenta il dibattito nella pratica

I numeri di cui sopra dimostrano che il dibattito funziona, ma un esempio concreto mostra perché funziona. Ecco una sintesi di come i cinque modelli hanno gestito la PR #44474, che ha introdotto il caricamento pigro delle chiavi primarie durante la ricerca.

PR #44474: Un'ottimizzazione del caricamento pigro che ha cambiato la ricerca per recuperare le chiavi primarie su richiesta invece di caricarle tutte in anticipo.

Primo round

Gemini ha aperto in modo aggressivo:

"Questa PR è un campo minato di cattive pratiche, potenziali comportamenti non definiti e regressioni delle prestazioni mascherate da "ottimizzazione"".

Claude e Qwen si sono concentrati sul comportamento indefinito e sulle prestazioni, convergendo sulla stessa preoccupazione:

"Il modello di memoria del C++ non garantisce la sicurezza delle scritture simultanee su indici diversi dello stesso vettore senza un'adeguata sincronizzazione".

Tutti e tre hanno trovato problemi reali, ma nessuno di loro ha colto il bug più profondo. Poi Codex, che aveva a malapena parlato, ha segnalato qualcosa che agli altri era sfuggito: il vettore primary_keys_ viene ridimensionato, ma solo le posizioni che passano attraverso la fase di riduzione vengono effettivamente popolate. Tutte le altre posizioni rimangono a valore zero.

Secondo round

Claude raccolse la scoperta di Codex e ne tracciò la conseguenza a valle:

"L'ho trovato: SortEqualScoresByPks viene eseguito prima di ReduceResultData. Quindi, quando SortEqualScoresByPks viene eseguito, non sono ancora state recuperate le PK in modo pigro. L'intero vettore primary_keys_ è pieno di valori PkType costruiti di default".

In parole povere, la funzione di ordinamento viene eseguita prima che le chiavi siano state caricate, quindi ordina degli zeri. Claude ha riconosciuto apertamente la mancanza:

"codex-cli ha identificato un vero e proprio bug critico di correttezza. Mi è sfuggito nel mio primo giro".

Quale combinazione di modelli può trovare il maggior numero di bug?

Il salto dal 53% all'80% è avvenuto perché cinque modelli hanno coperto i rispettivi punti ciechi. Ma non tutti possono permettersi di configurare ed eseguire cinque modelli in cinque round di discussione per ogni revisione del codice.

Ho quindi provato la versione più semplice: se si possono eseguire solo due modelli, quale coppia si avvicina di più al tetto massimo di più modelli?

Ho usato le prove assistite dal contesto (R1) e ho contato quanti dei 15 bug noti ha trovato ciascun modello:

Claude: 7/15 (47%)
Qwen: 6/15 (40%)
Gemini: 5/15 (33%)
MiniMax: 5/15 (33%)
Codex: 4/15 (27%)

Ciò che conta, quindi, non è solo il numero di bug individuati da ciascun modello, ma anche quali bug non vengono individuati. Degli 8 bug mancati da Claude, Gemini ne ha individuati 3: una concurrency race condition, un problema di compatibilità con le API di cloud storage e un controllo di autorizzazione mancante. Nell'altra direzione, Gemini non ha individuato la maggior parte dei bug relativi alle strutture dati e alla logica profonda, mentre Claude li ha individuati quasi tutti. I loro punti deboli si sovrappongono appena, il che li rende una coppia forte.

Accoppiamento di due modelli	Copertura combinata
Claude + Gemini	10/15
Claude + Qwen	9/15
Claude + Codex	8/15
Claude + MiniMax	8/15

Tutti e cinque i modelli insieme hanno coperto 11 su 15, lasciando 4 bug che ogni modello ha mancato.

Claude + Gemini, come coppia di due modelli, raggiunge già il 91% del tetto massimo di cinque modelli. Per questo benchmark, è la combinazione più efficiente.

Detto questo, Claude + Gemini non è la combinazione migliore per ogni tipo di bug. Quando ho scomposto i risultati per categoria di bug, è emerso un quadro più sfumato:

Tipo di bug	Totale	Claude	Gemelli	Codice	MiniMax	Qwen
Lacune di convalida	4	3	2	1	1	3
Ciclo di vita della struttura dati	4	3	1	1	3	1
Gare di concomitanza	2	0	1	0	0	0
Compatibilità	2	0	1	1	0	1
Logica profonda	3	1	0	1	1	1
Totale	15	7	5	4	5	6

La suddivisione per tipo di bug rivela perché nessuna accoppiata è universalmente la migliore.

Per i bug relativi al ciclo di vita delle strutture dati, Claude e MiniMax sono in parità a 3/4.
Per quanto riguarda le lacune nella validazione, Claude e Qwen sono a pari merito a 3/4.
Per quanto riguarda i problemi di concorrenza e compatibilità, Claude ha ottenuto un punteggio pari a zero in entrambi i casi e Gemini è quello che colma queste lacune.
Nessun modello copre tutto, ma Claude copre la gamma più ampia e si avvicina di più a un modello generalista.

Tutti i modelli non hanno individuato quattro bug. Uno riguardava la priorità delle regole grammaticali ANTLR. Uno riguardava la mancata corrispondenza semantica dei blocchi di lettura/scrittura tra le funzioni. Uno richiedeva la comprensione delle differenze di logica aziendale tra i tipi di compattazione. E uno era un errore di confronto silenzioso in cui una variabile utilizzava i megabyte e un'altra i byte.

Ciò che accomuna questi quattro casi è la correttezza sintattica del codice. I bug risiedono nelle ipotesi che lo sviluppatore aveva in testa, non nel diff e nemmeno nel codice circostante. Questo è più o meno il punto in cui la revisione del codice da parte dell'intelligenza artificiale raggiunge il suo limite oggi.

Dopo aver trovato i bug, qual è il modello migliore per risolverli?

Nella revisione del codice, trovare i bug è metà del lavoro. L'altra metà è correggerli. Per questo motivo, dopo i round di discussione, ho aggiunto una valutazione tra pari per misurare l'effettiva utilità dei suggerimenti di correzione di ciascun modello.

Per misurare questo aspetto, ho aggiunto un round di valutazione tra pari dopo il dibattito. Ogni modello ha aperto una nuova sessione e ha agito come giudice anonimo, assegnando un punteggio alle recensioni degli altri modelli. I cinque modelli sono stati mappati in modo casuale sul recensore A/B/C/D/E, in modo che nessun giudice sapesse quale modello aveva prodotto quale recensione. Ogni giudice ha assegnato un punteggio su quattro dimensioni, valutate da 1 a 10: accuratezza, agibilità, profondità e chiarezza.

Modello	Accuratezza	Agibilità	Profondità	Chiarezza	Complessivamente
Qwen	8.6	8.6	8.5	8.7	8,6 (a pari merito con il 1°)
Claude	8.4	8.2	8.8	8.8	8,6 (a pari merito con il 1°)
Codice	7.7	7.6	7.1	7.8	7.5
Gemelli	7.4	7.2	6.7	7.6	7.2
MiniMax	7.1	6.7	6.9	7.4	7.0

Qwen e Claude si sono aggiudicati il primo posto con un netto margine. Entrambi hanno ottenuto punteggi costantemente alti in tutte e quattro le dimensioni, mentre Codex, Gemini e MiniMax si sono posizionati un punto in più o in meno. In particolare, Gemini, che si è rivelato prezioso come partner per la ricerca di bug per Claude nell'analisi dell'accoppiamento, si posiziona in fondo alla classifica della qualità delle revisioni. Essere bravi a individuare i problemi ed essere bravi a spiegare come risolverli sono evidentemente abilità diverse.

Conclusione

Claude è quello a cui affidare le revisioni più difficili. Lavora attraverso intere catene di chiamate, segue percorsi logici profondi e inserisce il proprio contesto senza bisogno di essere imitato. Per quanto riguarda i bug a livello di sistema L3, nessun altro si avvicina. A volte è troppo sicuro di sé con la matematica, ma quando un altro modello dimostra che si sbaglia, lo riconosce e spiega dove il suo ragionamento si è interrotto. Usatelo per il codice principale e per i bug che non potete permettervi di perdere.

Il Gemelli si fa sentire. Ha opinioni forti sullo stile del codice e sugli standard ingegneristici, ed è veloce nell'inquadrare i problemi dal punto di vista strutturale. L'aspetto negativo è che spesso rimane in superficie e non scava abbastanza in profondità, motivo per cui ha ottenuto un punteggio basso nella valutazione dei colleghi. Dove Gemini si guadagna davvero il posto è come sfidante: il suo pushback costringe gli altri modelli a ricontrollare il loro lavoro. È da abbinare a Claude per la prospettiva strutturale che Claude a volte tralascia.

Codex dice a malapena una parola. Ma quando lo fa, conta. Il suo tasso di successo sui bug reali è alto e ha la capacità di cogliere l'aspetto che tutti gli altri hanno ignorato. Nell'esempio del PR #44474, Codex è stato il modello che ha individuato il problema delle chiavi primarie a valore zero che ha dato il via all'intera catena. Consideratelo come un revisore supplementare che cattura ciò che il vostro modello principale non ha notato.

Qwen è il più completo dei cinque. La qualità delle sue recensioni è pari a quella di Claude, ed è particolarmente bravo a mettere insieme prospettive diverse in suggerimenti di correzione su cui si può agire. Inoltre, ha registrato il più alto tasso di rilevamento di L2 in modalità assistita dal contesto, il che lo rende una solida opzione predefinita per le recensioni PR di tutti i giorni. L'unico punto debole: nei dibattiti lunghi e a più riprese, a volte perde di vista il contesto precedente e inizia a dare risposte incoerenti nei turni successivi.

MiniMax è stato il più debole nel trovare i bug da solo. È meglio utilizzarlo per completare un gruppo multi-modello piuttosto che come esaminatore indipendente.

Limitazioni di questo esperimento

Alcuni avvertimenti per mantenere questo esperimento in prospettiva:

La dimensione del campione è piccola. Ci sono solo 15 PR, tutti provenienti dallo stesso progetto Go/C++ (Milvus). Questi risultati non sono generalizzabili a tutti i linguaggi o codebase. Considerateli come indicativi, non definitivi.

I modelli sono intrinsecamente casuali. Eseguire due volte lo stesso prompt può produrre risultati diversi. I numeri riportati in questo post rappresentano una singola istantanea, non un valore atteso stabile. Le classifiche dei singoli modelli devono essere prese alla leggera, anche se le tendenze più ampie (il dibattito supera i singoli, diversi modelli eccellono in diversi tipi di bug) sono coerenti.

L'ordine di parola è stato corretto. Il dibattito ha utilizzato lo stesso ordine in tutti i round, il che potrebbe aver influenzato la risposta dei modelli che parlano più tardi. Un esperimento futuro potrebbe randomizzare l'ordine per ogni round per controllare questo aspetto.

Prova tu stesso

Tutti gli strumenti e i dati di questo esperimento sono open source:

Magpie: Uno strumento open-source che raccoglie il contesto del codice (catene di chiamate, PR correlate, moduli interessati) e orchestra il dibattito multi-modello per la revisione del codice.
AI-CodeReview-Arena: L'intera pipeline di valutazione, le configurazioni e gli script.
Casi di test: Tutte le 15 PR con bug noti annotati.

I bug di questo esperimento provengono tutti da richieste di pull reali in Milvus, un database vettoriale open-source costruito per applicazioni di intelligenza artificiale. Abbiamo una comunità piuttosto attiva su Discord e Slack, e ci piacerebbe che più persone si dedicassero al codice. E se finite per eseguire questo benchmark sulla vostra base di codice, condividete i risultati! Sono davvero curioso di sapere se le tendenze si confermano in diversi linguaggi e progetti.