[🤖] L’IA ne cessait de me donner raison, alors j’ai décidé d’en faire intervenir une autre pour la contredire

✨ Résumé de GPT-5.6 Sol

En cherchant la cause de l’échec d’un travail d’UI de 16 heures, j’ai constaté que l’IA changeait de conclusion à chacune de mes objections. Voici comment j’ai fait circuler les critiques entre plusieurs sessions avant d’en faire une Skill avec un fresh critic et deux tours de revue au maximum.

Je ne pouvais même pas croire telle quelle la réponse censée expliquer un échec de 16 heures

Hier, après une longue discussion, j’ai rédigé des spécifications page par page pour une refonte complète de l’UI/UX, puis j’ai lancé un Codex Goal chargé de les implémenter. Le Goal a tourné pendant 16 heures. Aujourd’hui, j’ai ouvert l’écran réel avec beaucoup d’attentes, et le résultat était tout simplement nul.

J’avais tout prévu, jusqu’aux vues calendrier et table, mais l’ensemble ressemblait à l’ancien écran recouvert d’explications et de cards. Pendant ce temps, les rapports « implémentation terminée », « audit réussi » et « build réussi » s’étaient accumulés. J’ai demandé ce qui avait bien pu être fait pendant 16 heures et exigé qu’on analyse d’abord la cause de ce désastre.

Au passage, j’ai appris que le problème contre lequel je me débattais commençait à être désigné sous le nom de Graph Engineering. Découper un travail long en petits résultats et étapes de vérification, puis séparer l’implémentateur de l’auditeur pour empêcher une mauvaise direction de se propager, semblait clairement utile dans ce cas.

Mais avant même la méthode, un autre problème m’a sauté aux yeux. Quand je proposais une solution, l’IA disait très vite qu’elle était juste. Quand je formulais une objection, elle disait ensuite que l’objection était juste. Chaque réponse paraissait convaincante, mais la conclusion suivait toujours ma remarque la plus récente.

Même l’explication de l’échec était difficile à croire sans la remettre en question.

« S’il vous plaît, critiquez »

J’ai donc transmis la réponse d’une session à une autre pour une revue critique. J’ai rapporté la critique à la session initiale afin qu’elle réponde, puis j’ai montré la nouvelle réponse à une autre session.

C’était au moins mieux que de laisser une session répondre et s’applaudir elle-même. L’une repérait les présupposés que l’autre avait considérés comme évidents, et faisait apparaître des coûts opérationnels ou des modes d’échec absents de la première réponse. À l’inverse, lorsque la session critique allait trop loin, la session initiale pouvait aussi la contredire avec des preuves.

Pourtant, je devais encore les retenir. Dès que je collais une critique venue d’une autre session, elles acceptaient trop facilement que « cette critique est juste ». J’ai fini par dire :

S’il vous plaît, critiquez.

Je ne voulais pas voir deux IA parvenir poliment à un accord. Je voulais douter à la fois de la première réponse et de la critique suivante, puis vérifier jusqu’au bout ce qui correspondait réellement aux preuves. Le fait que plusieurs voix disent la même chose n’en fait pas une vérité, et appeler un Agent critic ne le rend pas automatiquement plus exact.

J’aimais le principe d’échanger les réponses entre sessions et d’adopter à la fin la conclusion qui résistait. Le problème était l’effort pénible consistant à copier-coller chaque fois le texte source, la réponse et la réfutation entre GPT et Codex.

J’ai réduit à nouveau le grand système de débat

Au début, j’imaginais une « Skill de débat » capable de créer jusqu’à trois critics et de mener plusieurs tours. J’ai même envisagé de payer Claude Code pour le faire dialoguer avec Codex via la CLI.

L’IA a proposé de séparer Coordinator, Worker et Auditor et de maintenir un état supplémentaire. Ce n’était pas faux, mais à mes yeux le travail redevenait inutilement complexe. Le Goal de 16 heures avait échoué parce qu’il s’agissait d’une longue tâche sans contrôle. Construire une autre orchestration gigantesque pour l’éviter semblait étrange.

Mon idée était beaucoup plus simple.

Pourquoi ne pas ouvrir un seul fresh subagent et échanger les revues avec lui ?

La session principale envoie sa conclusion actuelle à un critic. Sans être entraîné par l’ambiance de la conversation précédente, le critic cherche les contre-exemples et les présupposés cachés. La session principale classe chaque remarque comme acceptée, réfutée par des preuves ou non résolue. Si elle corrige la réponse, elle la montre une seule fois de plus au même critic. Ils vérifient que le problème est bien résolu, puis s’arrêtent.

Un nouveau sujet reçoit un fresh critic ; la nouvelle revue d’une correction sur le même sujet retourne au même critic. Si la première critique ne trouve aucun problème important, inutile de forcer un second tour. Même avec plusieurs critics, la conclusion n’est pas décidée à la majorité.

Cela suffisait à automatiser presque exactement ce que je faisais à la main, sans transformer le débat lui-même en nouveau grand projet.

Je voulais une Skill qui ne dissimule pas les réfutations

Une fois la direction fixée, j’ai donné à Codex des instructions précises pour créer une Skill globale. Par défaut : un critic et deux tours de revue au maximum. Le critic serait un fresh subagent qui n’hériterait pas de toute la conversation. Une correction sur le même sujet serait renvoyée au critic initial. Le workflow serait en lecture seule, sans toucher aux fichiers, à Git, au Runtime ni à un état externe.

Mon exigence principale était de ne pas adopter automatiquement la réponse du critic.

La session principale doit traiter chaque critique importante de l’une des trois façons suivantes.

• L’accepter et modifier la conclusion.
• La réfuter avec des preuves.
• La conserver comme désaccord non résolu.

La réponse finale doit rendre publics non seulement les changements provoqués par la critique, mais aussi les remarques rejetées et les incertitudes restantes. Je voulais éviter que les objections gênantes disparaissent en silence ou qu’une conclusion soit décorée d’un « trois Agents sont d’accord ».

Au début, j’avais utilisé le nom visible Custom - Debate, puis je l’ai fait remplacer par Custom - Deliberate pour respecter les règles communes de nommage des Skills. Le directory et le nom d’appel étaient custom-deliberate depuis le début. Ce nom correspondait aussi mieux à la fonction : non pas désigner un vainqueur, mais délibérer et tenter de réfuter une conclusion avant de l’arrêter.

J’ai immédiatement utilisé la Skill pour qu’elle s’examine elle-même

Je ne me suis pas arrêté parce que la Skill existait. J’ai immédiatement utilisé $custom-deliberate pour vérifier si le processus était adapté. Puis j’ai demandé si l’application de ces critiques améliorerait réellement les performances.

Ce passage a rendu la Skill un peu plus sobre. Elle indique désormais que le simple fait de ne pas transmettre la conversation précédente ne crée pas un critic parfaitement indépendant. Il partage encore le même modèle et les mêmes règles supérieures, et peut se tromper de la même manière selon les preuves que la session principale place dans le packet. Elle distingue aussi les possibilités simplement imaginables des material objections capables de modifier réellement la conclusion. En l’absence d’objection importante, elle s’arrête tôt ; si les preuves sont insuffisantes, elle l’admet au lieu de forcer un accord.

Ce que je faisais en copiant les réponses entre sessions était désormais dans la Skill. Je ne crois pas la première réponse, mais je n’accepte pas automatiquement la critique non plus. Je n’adopte que la conclusion qui tient encore après réfutation et nouvelle revue.

Désormais, j’essaie de casser une réponse avant de l’accepter

Cette Skill ne garantit pas la vérité. Pour vraiment rompre les biais partagés par une même famille de modèles, connecter un autre modèle comme Claude Code pourrait être plus efficace. Si je donne de mauvais éléments au critic, il peut simplement produire une réponse fausse plus sophistiquée. Les préférences et les jugements de valeur réels restent finalement les miens.

Malgré tout, avant d’ajouter un nouvel abonnement à 150 000 wons, je veux d’abord essayer cette petite méthode.

Je ne confirme pas immédiatement une conclusion. Je demande à un fresh critic d’essayer de la casser. Je note quelles objections j’ai acceptées, pourquoi j’en ai rejeté d’autres et ce qui reste non résolu. Je ne montre la réponse corrigée au même critic qu’une seule fois de plus.

J’avais déjà écrit que Claude Code comme Codex ont finalement besoin d’un harness. Cette fois, j’ai appliqué cette idée au processus de jugement. Faire terminer le travail par l’IA est important, mais empêcher l’IA de me donner aveuglément raison et de figer trop vite une conclusion l’est tout autant.

À l’avenir, pour une décision non triviale prise avec l’IA, au lieu de demander une réponse supplémentaire, je demanderai d’abord ce qui peut être faux dans la réponse actuelle. Si je recommence la même série de copier-coller, il sera alors temps de connecter Claude Code ou un autre modèle. Pour l’instant, c’est le dispositif critique minimal que je voulais.