2 481 revues croisées : Claude Code et Codex vérifient leur travail mutuellement

Claude Code termine le travail, puis Codex le lit avant toute publication. Quand Codex écrit, Claude lit.

Une banque fonctionne de la même façon. Personne n'approuve son propre prêt. Quelqu'un prépare le dossier, quelqu'un d'autre signe, et personne ne le prend mal. Nous appelons notre version Dual Brain : deux agents d'IA travaillent en binôme sur une même tâche, l'un l'exécute, l'autre la révise. C'est intégré à Sno Station, et nous travaillons ainsi depuis la mi-juillet.

Chaque revue laisse une ligne dans un fichier journal sur notre machine de compilation. Il y a quelque temps, la curiosité m'a pris et je les ai comptées.

Le décompte

Du 19 juillet au 21 septembre, les deux agents d'IA se sont relus mutuellement 2 481 fois. Ils ont travaillé pendant 63 de ces jours, soit environ 39 revues par jour. Ils ont lu 3,2 millions de lignes dans 9 452 fichiers.

Une revue prend environ deux minutes. La médiane est de 141 secondes, et neuf sur dix se terminent en moins de six minutes. Ce chiffre compte plus qu'il n'y paraît. Une revue humaine prend une journée, passée surtout à attendre la personne. À deux minutes, vous ne vous demandez plus si quelque chose mérite une revue. Tout y passe.

Je pensais que la plupart des travaux seraient approuvés.

Parmi les revues qui ont rendu un verdict, 431 ont approuvé le travail. Dans 1 953 cas, il fallait intervenir. Quatre fois sur cinq, le second agent d'IA a donc renvoyé le travail.

Quatre fois sur cinq. Ce ne sont pas les brouillons bâclés d'un stagiaire fatigué. Le modèle avait déjà exécuté ses tests et déclaré le travail terminé.

Le code et les plans

J'ai ensuite compté séparément les revues de code et celles des plans.

Le code a été approuvé dans 27 pour cent des cas. 398 approbations sur 1 475 revues. Ce n'est pas formidable, mais on peut faire avec.

Les plans ont été approuvés dans 3,6 pour cent des cas. 33 sur 907.

J'ai dû regarder deux fois. Un plan est un document. Il dit ce que nous allons construire et pourquoi. On pourrait croire qu'il est plus facile de réussir un document que du code, puisqu'il n'a pas à compiler. C'est l'inverse. La réalité corrige le code chaque fois que vous l'exécutez. Un plan peut affirmer que la base de données possède une colonne inexistante, et cette phrase paraîtra tout à fait raisonnable jusqu'à ce que quelqu'un construise quelque chose dessus.

Nous donnons donc maintenant au réviseur les faits avec le plan. Avant la revue d'un plan, l'agent d'IA qui l'a rédigé exécute les commandes, compte les lignes, extrait le schéma et joint les résultats bruts. Le réviseur peut alors confronter les affirmations à quelque chose. Sinon, c'est un examen sans documents. Il peut trouver les contradictions internes au texte, mais pas voir que le texte contredit la réalité.

La plupart des constats les plus graves viennent précisément de cet écart. Sur la même période, les réviseurs ont signalé 4 277 problèmes graves dans 1 395 revues. Je ne les ai pas tous vérifiés, et ils ne sont pas tous réels. Mais ceux qui l'étaient se ressemblaient souvent : une chose affirmée avec assurance que personne n'avait réellement vérifiée.

Ce qui a mal tourné

Si je m'arrêtais là, ce serait une belle histoire. J'aimerais croire que toutes ces revues ont amélioré le travail.

Ce n'est pas si simple. Le fait est qu'un réviseur trouve toujours quelque chose.

Regardez les tours suivants. Après que l'auteur a corrigé les constats et demandé une nouvelle revue, le travail a été approuvé dans 21 pour cent des cas. Au premier tour, c'était 17 pour cent. Corriger chaque constat changeait à peine les chances. Un même travail a traversé quinze tours.

Cela ne veut pas dire que l'auteur a échoué quinze fois. Le réviseur faisait ce que font les réviseurs. Demandez à un modèle compétent de trouver des problèmes : il en trouve. Si le parcours normal est sain, il cherche dans les coins. Deux requêtes qui arrivent à la même milliseconde. Une annulation au milieu d'une écriture. Des cas possibles, plus ou moins, comme il est possible de recevoir une météorite sur la tête.

Et l'auteur, conciliant, corrige chacun d'eux en ajoutant quelque chose.

Plus tôt ce mois-ci, nous avons eu un petit bogue. Sa correction a traversé six tours de revue. À chaque tour, le réviseur soulevait une nouvelle inquiétude, et l'auteur ajoutait une protection. Un plafond pour le nombre de jetons. Un verrou par session. Une table distincte pour suivre ce qui avait déjà été fourni. Une correspondance des alias. À la fin, le correctif était une petite forteresse.

Aucun de ces mécanismes n'a jamais servi en production. Et sous tout cela, la correction elle-même contenait encore une erreur d'identité sur une seule ligne, que personne n'a vue tant elle était enfouie sous les défenses. C'était comme monter le gain pour entendre un instrument discret et récolter surtout du souffle.

La règle ajoutée

Nous avons donc écrit une règle, la chose la plus utile issue de toute l'expérience.

Un constat n'est pas un ordre d'ajouter du code.

La revue revient maintenant avec deux groupes de constats. Le premier contient les problèmes qu'un véritable utilisateur rencontrerait un jour ordinaire et dont la correction minimale n'ajoute rien de nouveau. Ceux-là sont corrigés. Le second contient tout le reste : les cas exotiques et ce qui nécessiterait un nouveau verrou, une nouvelle tentative ou une nouvelle table. Nous les consignons et les signalons. Ils ne deviennent du code que si une personne le décide.

Nous demandons aussi au réviseur de chercher le superflu avant de chercher ce qui manque. Un verrou dont personne n'avait besoin. Un paramètre utilisé à un seul endroit. Un test qui ne fait que répéter le code. Supprimer quelque chose compte désormais comme un constat.

Et il y a une limite. Trois tours pour le code. Un pour les tests. Ensuite, le débat revient à un humain, là où il aurait probablement dû se trouver.

Ce que cela vaut

Je ne peux pas vous donner de chiffre net pour la valeur de cette pratique. J'aimerais bien. Je n'ai pas de groupe témoin, une seconde entreprise qui aurait publié le même travail sans revue.

Ce que j'ai, c'est ceci : quatre fois sur cinq, un autre modèle voulait changer quelque chose dans un travail que le premier avait déclaré terminé. Une partie n'est que du bruit. Mais un agent d'IA qui révise son propre travail ne le renvoie presque jamais, parce qu'il croit déjà ce qu'il a écrit. Le second avis doit venir d'ailleurs. D'un autre modèle, entraîné par d'autres personnes, qui n'était pas là quand le premier a décidé que tout allait bien.

Deux têtes valent mieux qu'une. Il s'avère que c'est vrai même quand aucune des deux n'est humaine.

Sno Station est open source, et la revue croisée en fait partie. Vous le trouverez sur sno.ai.