L'examen du code de l'IA s'améliore lorsque les modèles débattent : Claude vs Gemini vs Codex vs Qwen vs MiniMax

J'ai récemment utilisé des modèles d'IA pour examiner une demande d'extraction, et les résultats étaient contradictoires : Claude a signalé une course aux données, tandis que Gemini a déclaré que le code était propre. J'ai donc lancé les derniers modèles phares de Claude, Gemini, Codex, Qwen et MiniMax dans un benchmark structuré de révision de code. Quels sont les résultats ? Le modèle le plus performant n'a détecté que 53 % des bogues connus.

Mais ma curiosité ne s'est pas arrêtée là : et si ces modèles d'IA travaillaient ensemble ? J'ai fait l'expérience de les faire débattre l'un avec l'autre et, après cinq rounds de débat contradictoire, la détection des bogues a grimpé à 80 %. Les bogues les plus difficiles, ceux qui nécessitent une compréhension au niveau du système, ont atteint une détection de 100 % en mode débat.

Ce billet présente la conception de l'expérience, les résultats par modèle, et ce que le mécanisme de débat révèle sur la façon d'utiliser l'IA pour la revue de code.

Analyse comparative de Claude, Gemini, Codex, Qwen et MiniMax pour la revue de code

Si vous avez utilisé des modèles pour la revue de code, vous avez probablement remarqué qu'ils ne diffèrent pas seulement par leur précision, mais aussi par la façon dont ils lisent le code. Par exemple, Claude parcourt généralement la chaîne d'appels de haut en bas :

Claude parcourt généralement la chaîne d'appels de haut en bas et passe du temps sur les chemins "ennuyeux" (gestion des erreurs, tentatives, nettoyage). C'est souvent là que se cachent les vrais bogues, donc je ne déteste pas cette minutie.

Les Gémeaux ont tendance à commencer par un verdict fort ("c'est mauvais" / "ça a l'air bien") et travaillent ensuite à rebours pour le justifier du point de vue de la conception/structure. Parfois, c'est utile. Parfois, on a l'impression qu'il a survolé la question et qu'il s'est ensuite engagé à prendre une décision.

Le Codex est plus silencieux. Mais lorsqu'il signale quelque chose, c'est souvent concret et exploitable - moins de commentaires, plus de "cette ligne est mauvaise parce que X".

Il s'agit toutefois d'impressions, et non de mesures. Pour obtenir des chiffres réels, j'ai mis en place un benchmark.

Configuration

Cinq modèles phares ont été testés :

• Claude Opus 4.6

• Gemini 3 Pro

• GPT-5.2-Codex

• Qwen-3.5-Plus

• MiniMax-M2.5

Outil (Magpie)

J'ai utilisé Magpie, un outil de benchmarking open-source que j'ai construit. Son rôle est de faire la "préparation de l'examen du code" que vous feriez normalement manuellement : rassembler le contexte environnant (chaînes d'appels, modules connexes et code adjacent pertinent) et l'introduire dans le modèle avant qu' il n'examine la PR.

Cas de test (PR Milvus avec bogues connus)

L'ensemble de données se compose de 15 demandes d'extraction de Milvus (une base de données vectorielle open-source créée et maintenue par Zilliz). Ces PR sont utiles en tant que référence car chacune a été fusionnée, pour ensuite nécessiter un revert ou un hotfix après l'apparition d'un bug en production. Chaque cas a donc un bogue connu sur lequel nous pouvons nous baser.

Niveaux de difficulté des bogues

Tous ces bogues ne sont pas aussi difficiles à trouver, c'est pourquoi je les ai classés en trois niveaux de difficulté :

• L1 : Visible à partir du diff seul (use-after-free, off-by-one).

• L2 (10 cas) : Nécessite de comprendre le code environnant pour repérer des choses comme des changements sémantiques d'interface ou des courses de concurrence. Il s'agit des bogues les plus courants dans l'examen quotidien du code.

• L3 (5 cas) : Nécessite une compréhension au niveau du système pour repérer des problèmes tels que des incohérences d'état entre modules ou des problèmes de compatibilité avec les mises à jour. Il s'agit des tests les plus difficiles pour déterminer à quel point un modèle peut raisonner sur une base de code.

Note : Chaque modèle a détecté tous les bogues L1, je les ai donc exclus de la notation.

Deux modes d'évaluation

Chaque modèle a été exécuté en deux modes :

• Raw : le modèle ne voit que le PR (diff + ce qui se trouve dans le contenu du PR).

• R1 : Magpie extrait le contexte environnant (fichiers pertinents / sites d'appel / code connexe) avant que le modèle ne révise. Cela simule un flux de travail où vous préparez le contexte à l'avance au lieu de demander au modèle de deviner ce dont il a besoin.

Résultats (L2 + L3 uniquement)

Mode	Claude	Gemini	Codex	MiniMax	Qwen
Brut	53% (1er)	13% (dernier)	33%	27%	33%
R1 (avec contexte par Magpie)	47% ⬇️	33%⬆️	27%	33%	40%⬆️

Quatre points à retenir :

1. Claude domine l'évaluation brute. Il a obtenu un score global de 53% pour la détection et un score parfait de 5/5 pour les bogues L3, sans aucune assistance contextuelle. Si vous utilisez un seul modèle et que vous ne voulez pas passer du temps à préparer le contexte, Claude est le meilleur choix.

2. Gemini a besoin de contexte. Son score brut de 13% était le plus bas du groupe, mais avec Magpie fournissant le code environnant, il a grimpé à 33%. Gemini ne rassemble pas bien son propre contexte, mais il obtient des résultats respectables lorsque vous faites ce travail en amont.

3. Qwen est le plus performant en matière d'assistance contextuelle. Il a obtenu un score de 40 % en mode R1, avec 5/10 sur les bogues L2, ce qui est le score le plus élevé à ce niveau de difficulté. Pour les examens quotidiens de routine où vous êtes prêt à préparer le contexte, Qwen est un choix pratique.

4. Plus de contexte n'est pas toujours utile. Il a amélioré Gemini (13 % → 33 %) et MiniMax (27 % → 33 %), mais il a en fait nui à Claude (53 % → 47 %). Claude excelle déjà dans l'organisation du contexte par lui-même, de sorte que les informations supplémentaires ont probablement introduit du bruit plutôt que de la clarté. La leçon à retenir : adapter le flux de travail au modèle, plutôt que de supposer que plus de contexte est universellement meilleur.

Ces résultats correspondent à mon expérience quotidienne. Claude en tête n'est pas surprenant. Le fait que Gemini ait obtenu un score inférieur à mes attentes est logique avec le recul : j'utilise généralement Gemini dans le cadre de conversations à plusieurs tours, lorsque j'élabore une conception ou que je cherche à résoudre un problème ensemble, et il donne de bons résultats dans ce contexte interactif. Ce benchmark est un pipeline fixe à un seul passage, ce qui est exactement le format dans lequel Gemini est le plus faible. La section consacrée au débat montrera plus loin que lorsque vous donnez à Gemini un format contradictoire à plusieurs tours, ses performances s'améliorent sensiblement.

Laisser les modèles d'IA débattre entre eux

Chaque modèle a montré des forces et des faiblesses différentes dans les tests individuels. J'ai donc voulu faire un test : que se passe-t-il si les modèles examinent le travail des autres plutôt que le code ?

J'ai donc ajouté une couche de débat au-dessus du même benchmark. Les cinq modèles participent à cinq tours :

• Au cours du premier tour, chaque modèle examine le même PR de manière indépendante.

• Ensuite, je diffuse les cinq évaluations à tous les participants.

• Au deuxième tour, chaque modèle met à jour sa position en fonction des quatre autres.

• Répétez l'opération jusqu'au 5e tour.

À la fin, chaque modèle ne se contente pas de réagir au code, il réagit à des arguments qui ont déjà été critiqués et révisés à plusieurs reprises.

Pour éviter que cela ne se transforme en "LLMs qui s'accordent bruyamment", j'ai appliqué une règle stricte : chaque revendication doit s'appuyer sur un code spécifique comme preuve, et un modèle ne peut pas simplement dire "bon point" - il doit expliquer pourquoi il a changé d'avis.

Résultats : Best Solo vs Debate Mode

Mode	L2 (10 cas)	L3 (5 cas)	Détection totale
Meilleur individu (Raw Claude)	3/10	5/5	53%
Débat (les cinq modèles)	7/10 (doublé)	5/5 (tous pris)	80%

Ce qui ressort

1. La détection de L2 a doublé. Les bogues de routine et de difficulté moyenne sont passés de 3/10 à 7/10. Ce sont les bogues qui apparaissent le plus fréquemment dans les bases de code réelles, et c'est exactement la catégorie dans laquelle les modèles individuels manquent de cohérence. La plus grande contribution du mécanisme de débat est de combler ces lacunes quotidiennes.

2. Bogues L3 : zéro erreur. Dans les essais avec un seul modèle, seul Claude a détecté les cinq bogues L3 au niveau du système. En mode débat, le groupe a obtenu le même résultat, ce qui signifie qu'il n'est plus nécessaire de parier sur le bon modèle pour obtenir une couverture complète de L3.

3. Le débat comble les angles morts au lieu de relever le plafond. Les bogues au niveau du système n'étaient pas la partie la plus difficile pour l'individu le plus fort. Claude les avait déjà. La principale contribution du mécanisme de débat est de combler la faiblesse de Claude sur les bogues L2 de routine, où Claude n'en a détecté que 3 sur 10, alors que le groupe de débat en a détecté 7. C'est de là que vient le bond de 53 % → 80 %.

A quoi ressemble le débat dans la pratique

Les chiffres ci-dessus montrent que le débat fonctionne, mais un exemple concret montre pourquoi il fonctionne. Voici un résumé de la manière dont les cinq modèles ont traité le PR #44474, qui a introduit le chargement paresseux des clés primaires lors de la recherche.

PR #44474 : Une optimisation du chargement paresseux qui a modifié la recherche pour récupérer les clés primaires à la demande au lieu de les charger toutes à l'avance.

Premier tour

Gemini a ouvert le bal de manière agressive :

Cette PR est un champ de mines de mauvaises pratiques, de comportements potentiellement indéfinis et de régressions de performances déguisées en "optimisation".

Claude et Qwen se sont concentrés sur les comportements non définis et les performances, convergeant vers la même préoccupation :

"Le modèle de mémoire C++ ne garantit pas la sécurité des écritures simultanées sur différents indices du même vecteur sans synchronisation appropriée.

Les trois ont trouvé des problèmes réels, mais aucun d'entre eux n'a détecté le bogue le plus profond. Puis Codex, qui avait à peine parlé, a signalé quelque chose que les autres avaient manqué : le vecteur primary_keys_ est redimensionné, mais seules les positions qui passent par la phase de réduction sont effectivement remplies. Toutes les autres positions sont laissées à zéro.

Deuxième tour

Claude a repris la découverte de Codex et en a retracé les conséquences en aval :

"J'ai trouvé : SortEqualScoresByPks s'exécute avant ReduceResultData. Ainsi, lorsque SortEqualScoresByPks s'exécute, aucun PK n'a encore été récupéré paresseusement. L'ensemble du vecteur primary_keys_ est rempli de valeurs PkType construites par défaut."

En clair, la fonction de tri s'exécute avant que les clés n'aient été chargées, donc elle trie des zéros. Claude a reconnu ouvertement l'erreur :

"codex-cli a identifié un véritable bogue de correction critique. Je l'ai raté lors de mon premier tour".

Quelle combinaison de modèles permet de trouver le plus grand nombre de bogues ?

Le bond de 53 % à 80 % s'explique par le fait que cinq modèles ont couvert les angles morts des uns et des autres. Mais tout le monde ne peut pas se permettre de mettre en place et d'exécuter cinq modèles au cours de cinq cycles de débats pour chaque examen de code.

J'ai donc testé une version plus simple : si vous ne pouvez utiliser que deux modèles, quelle paire vous rapproche le plus du plafond multi-modèle ?

J'ai utilisé les exécutions assistées par le contexte (R1) et j'ai compté combien de bogues sur les 15 connus chaque modèle avait trouvés :

• Claude : 7/15 (47%)

• Qwen : 6/15 (40%)

• Gemini : 5/15 (33%)

• MiniMax : 5/15 (33%)

• Codex : 4/15 (27%)

Ce qui importe, alors, ce n'est pas seulement le nombre de bogues que chaque modèle trouve, mais les bogues qu'il manque. Sur les 8 bogues manqués par Claude, Gemini en a détecté 3 : une condition de concurrence, un problème de compatibilité avec l'API de stockage en nuage et une vérification de permission manquante. Dans l'autre sens, Gemini a manqué la plupart des bogues liés aux structures de données et à la logique profonde, alors que Claude les a presque tous détectés. Leurs faiblesses se chevauchent à peine, ce qui en fait une paire solide.

Appariement de deux modèles	Couverture combinée
Claude + Gemini	10/15
Claude + Qwen	9/15
Claude + Codex	8/15
Claude + MiniMax	8/15

Les cinq modèles réunis ont couvert 11 des 15 bogues, ce qui laisse 4 bogues que chaque modèle a manqués.

Claude + Gemini, en tant que paire de deux modèles, atteint déjà 91% de ce plafond de cinq modèles. Pour ce benchmark, c'est la combinaison la plus efficace.

Cela dit, Claude + Gemini n'est pas la meilleure combinaison pour tous les types de bogues. Lorsque j'ai décomposé les résultats par catégorie de bogues, une image plus nuancée est apparue :

Type de bogue	Total	Claude	Gemini	Codex	MiniMax	Qwen
Lacunes en matière de validation	4	3	2	1	1	3
Cycle de vie des structures de données	4	3	1	1	3	1
Courses à la concurence	2	0	1	0	0	0
Compatibilité	2	0	1	1	0	1
Logique profonde	3	1	0	1	1	1
Total	15	7	5	4	5	6

La répartition par type de bogue révèle pourquoi aucun couple n'est universellement meilleur.

• Pour les bogues liés au cycle de vie des structures de données, Claude et MiniMax sont à égalité à 3/4.

• Pour les lacunes de validation, Claude et Qwen sont à égalité à 3/4.

• Pour les problèmes de concurrence et de compatibilité, Claude a obtenu un score nul dans les deux cas, et Gemini est celui qui comble ces lacunes.

• Aucun modèle ne couvre tout, mais Claude couvre la gamme la plus large et se rapproche le plus d'un modèle généraliste.

Quatre bogues ont été omis par tous les modèles. L'un d'eux concernait la priorité des règles de grammaire ANTLR. L'un d'entre eux concernait la priorité des règles de grammaire ANTLR. L'un d'entre eux nécessitait de comprendre les différences de logique d'entreprise entre les types de compactage. Et l'autre était une erreur de comparaison silencieuse où une variable utilisait des mégaoctets et une autre des octets.

Ce que ces quatre erreurs ont en commun, c'est que le code est syntaxiquement correct. Les bogues résident dans les hypothèses que le développeur a formulées dans sa tête, et non dans le diff, ni même dans le code environnant. C'est à peu près là que l'examen du code par l'IA atteint son plafond aujourd'hui.

Après avoir trouvé les bogues, quel est le meilleur modèle pour les corriger ?

Dans l'examen du code, la détection des bogues représente la moitié du travail. L'autre moitié consiste à les corriger. Après les débats, j'ai donc ajouté une évaluation par les pairs pour mesurer l'utilité des suggestions de correction de chaque modèle.

Pour ce faire, j'ai ajouté un cycle d'évaluation par les pairs après le débat. Chaque modèle a ouvert une nouvelle session et a joué le rôle de juge anonyme, notant les évaluations des autres modèles. Les cinq modèles ont été associés de manière aléatoire aux évaluateurs A/B/C/D/E, de sorte qu'aucun juge ne savait quel modèle avait produit telle ou telle évaluation. Chaque juge a évalué quatre dimensions, notées de 1 à 10 : la précision, l'actionnabilité, la profondeur et la clarté.

Modèle	Précision	Capacité d'action	Profondeur	Clarté	Dans l'ensemble
Qwen	8.6	8.6	8.5	8.7	8,6 (1er ex aequo)
Claude	8.4	8.2	8.8	8.8	8,6 (1er ex aequo)
Codex	7.7	7.6	7.1	7.8	7.5
Gemini	7.4	7.2	6.7	7.6	7.2
MiniMax	7.1	6.7	6.9	7.4	7.0

Qwen et Claude sont à égalité pour la première place, avec une nette avance. Tous deux ont obtenu des scores élevés sur les quatre dimensions, tandis que Codex, Gemini et MiniMax se sont classés un point ou plus en dessous. Notamment, Gemini, qui s'est avéré précieux en tant que partenaire de Claude pour la recherche de bogues dans l'analyse d'appariement, se classe près du bas de l'échelle pour la qualité de l'examen. Il est évident qu'être bon pour repérer les problèmes et être bon pour expliquer comment les résoudre sont des compétences différentes.

Conclusion

Claude est celui à qui vous feriez confiance pour les révisions les plus difficiles. Il travaille sur des chaînes d'appels entières, suit des chemins logiques profonds et tire parti de son propre contexte sans que vous ayez besoin de le nourrir à la petite cuillère. En ce qui concerne les bogues au niveau du système L3, rien d'autre ne s'en rapproche. Il est parfois trop confiant dans les mathématiques, mais lorsqu'un autre modèle prouve qu'il a tort, il l'assume et explique où son raisonnement s'est arrêté. Utilisez-le pour le code principal et les bogues que vous ne pouvez pas vous permettre de manquer.

LesGémeaux arrivent en force. Il a des opinions bien arrêtées sur le style du code et les normes d'ingénierie, et il est prompt à formuler les problèmes de manière structurelle. L'inconvénient est qu'il reste souvent à la surface et ne creuse pas assez, ce qui explique son faible score lors de l'évaluation par les pairs. C'est en tant que challenger que Gemini mérite vraiment sa place : ses coups de gueule obligent les autres modèles à revérifier leur travail. Associé à Claude, il offre la perspective structurelle que ce dernier omet parfois.

Codex ne dit presque rien. Mais lorsqu'il le fait, il compte. Son taux de réussite sur les bogues réels est élevé, et il a le don d'attraper la chose que tout le monde a ignorée. Dans l'exemple du PR #44474, Codex a été le modèle qui a repéré le problème des clés primaires à valeur nulle qui a déclenché toute la chaîne. Considérez-le comme le réviseur supplémentaire qui attrape ce que votre modèle principal a manqué.

Qwen est le modèle le plus complet des cinq. La qualité de ses évaluations est équivalente à celle de Claude et il est particulièrement doué pour rassembler différentes perspectives afin de formuler des suggestions concrètes sur lesquelles vous pouvez agir. Il a également le taux de détection de L2 le plus élevé en mode contextuel, ce qui en fait un excellent outil par défaut pour les examens quotidiens de relations publiques. Sa seule faiblesse : dans les longs débats à plusieurs tours, il perd parfois la trace du contexte antérieur et commence à donner des réponses incohérentes dans les tours suivants.

MiniMax a été le plus faible pour trouver des bogues par lui-même. Il est préférable de l'utiliser pour compléter un groupe multi-modèle plutôt que comme évaluateur autonome.

Limites de cette expérience

Quelques mises en garde pour garder cette expérience en perspective :

L'échantillon est de petite taille. Il n'y a que 15 PRs, tous issus du même projet Go/C++ (Milvus). Ces résultats ne s'appliquent pas à tous les langages ou bases de code. Considérez-les comme des indications, et non comme des conclusions.

Les modèles sont intrinsèquement aléatoires. L'exécution de la même invite deux fois peut produire des résultats différents. Les chiffres présentés dans cet article représentent un instantané unique, et non une valeur attendue stable. Les classements des modèles individuels doivent être pris à la légère, bien que les tendances générales (le débat surpasse les individus, différents modèles excellent pour différents types de bogues) soient cohérentes.

L'ordre des interventions a été fixé. Le débat a utilisé le même ordre pour tous les tours, ce qui a pu influencer la façon dont les modèles qui ont parlé plus tard ont réagi. Une expérience future pourrait randomiser l'ordre de parole pour chaque tour afin de contrôler ce phénomène.

Essayez vous-même

Tous les outils et les données de cette expérience sont en libre accès :

• Magpie: Un outil open-source qui rassemble le contexte du code (chaînes d'appels, PRs associés, modules affectés) et orchestre un débat contradictoire multi-modèle pour l'examen du code.

• AI-CodeReview-Arena: Le pipeline d'évaluation complet, les configurations et les scripts.

• Cas de test: Les 15 RP avec les bogues connus annotés.

Les bogues de cette expérience proviennent tous de demandes d'extraction réelles dans Milvus, une base de données vectorielle open-source conçue pour les applications d'IA. Nous avons une communauté assez active sur Discord et Slack, et nous aimerions que plus de gens s'intéressent au code. Et si vous finissez par exécuter ce benchmark sur votre propre base de code, n'hésitez pas à partager les résultats ! Je suis vraiment curieux de savoir si les tendances se maintiennent à travers différents langages et projets.

Lire la suite

• GLM-5 vs. MiniMax M2.5 vs. Gemini 3 Réflexion approfondie : Quel modèle convient à votre pile d'agents d'IA ?

• Ajouter une mémoire persistante au code Claude avec le plugin léger memsearch

• Nous avons extrait le système de mémoire d'OpenClaw et l'avons mis en open-source (memsearch)