Il existe une catégorie de travail où un seul agent IA échoue silencieusement : les nettoyages importants en plusieurs étapes où une seule hypothèse erronée se répercute sur des dizaines de modifications. Ma réponse est la revue de code IA hybride — deux modèles de pointe différents en boucle, l'un construisant et l'autre révisant — et la semaine dernière, cela a permis de passer d'un prototype SwiftUI chaotique à zéro blocage pour l'App Store en un après-midi, sans que j'écrive une seule ligne de code.
Les deux modèles étaient Claude Opus 4.8 en tant qu'ingénieur et Codex (GPT-5.5) en tant que réviseur, faisant passer chaque tâche par mon pont IA jusqu'à ce qu'elle réussisse une build réelle. D'après mon expérience, cette configuration de revue de code IA hybride surpasse systématiquement l'un ou l'autre modèle travaillant seul, et cette exécution en est la preuve la plus claire à ce jour. Voici exactement comment cela a fonctionné.
Commencer par un plan, pas par une intuition
Vous ne confiez pas à un agent « rendez ceci prêt pour la production ». C'est ainsi que vous obtenez des absurdités confiantes.
J'ai donc commencé par un plan. J'ai demandé à Claude de cloner le dépôt (une application iOS à mémoire limitée pour enfants appelée Kiddays), de lire l'*intégralité* de la base de code avec des sous-agents parallèles, et de produire un audit de readiness pour la production : 39 éléments concrets — 9 blocages majeurs pour l'App Store, le reste étant de sévérité élevée et moyenne. Chaque élément avait un fichier, une ligne, une estimation d'effort et une correction proposée.
Cet audit est devenu `PRODUCTION_READINESS.md` — une checklist markdown avec des cases `- [ ]`, triées par ordre de blocage en premier. Un seul fichier, l'unique source de vérité. Chaque tâche qu'il contenait était petite, spécifique et *vérifiable*. Ce dernier mot est important : si vous ne pouvez pas cocher une case et le prouver, ce n'est pas une tâche, c'est un souhait.
La boucle de revue de code IA hybride, étape par étape
J'ai exécuté l'ensemble sur une boucle auto-rythmée (le mode /loop de Claude Code). Chaque itération traitait une tâche, ou un groupe restreint de tâches connexes, et suivait toujours le même rythme.
Le rythme en cinq étapes
bash codex exec --sandbox read-only -o /tmp/answer.txt <<'PROMPT' Pair-reviewing a fix for this SwiftUI app. Here are the files... Recommend the idiomatic iOS 17 approach, flag pitfalls, validate the diff. PROMPT
Ensuite, la boucle se déclenche à nouveau, encore et encore, pendant des heures, sans surveillance. Tout l'intérêt de la revue de code IA hybride est que ce cycle s'exécute sans que j'aie à le surveiller — c'est la build, et non mon attention, qui valide chaque étape.
Pourquoi deux modèles valent mieux qu'un
La magie ne réside dans aucun des modèles individuellement — les deux sont excellents, et j'ai déjà écrit sur la façon dont Claude Opus 4.8 a battu Codex sur ma propre base de code→. La magie vient du fait qu'ils ont des angles morts différents, et qu'un réviseur qui n'a pas écrit le code n'a aucun ego investi dans le diff.
Les pièges qui ont justifié la configuration
Quelques moments réels de cette exécution :
C'est la différence entre un cachet en caoutchouc et une revue. Codex a réfuté des choses ; Claude a intégré les bonnes réfutations et défendu le reste. Le diff s'est amélioré à la frontière entre deux modèles qui ne partagent pas un cerveau — ce qui est tout l'argument derrière les workflows d'agents gouvernés→ : les handoffs structurés battent un modèle qui se parle à lui-même.
La partie honnête : les agents plantent, donc construisez un watchdog
À deux reprises, le CLI Codex s'est figé sur moi — pas pendant la réflexion, mais à l'arrêt, lorsque ses serveurs MCP en arrière-plan n'ont pas réussi à se fermer proprement. J'ai tracé le premier blocage jusqu'au bootstrap MCP moi-même, après que le processus soit resté mort pendant plusieurs minutes. Dans une boucle non surveillée, un seul blocage fige tout.
La solution a été un watchdog strict : un minuteur de kill autour de chaque consultation, plus la désactivation complète de MCP pour l'appel (`-c mcp_servers={}`) afin qu'il n'y ait rien sur quoi se figer. La boucle a détecté le blocage, tué le processus zombie, récupéré la réponse qui était déjà écrite, et a continué. « Rien ne se bloque » n'est pas un plus dans le travail autonome — c'est tout le jeu.
Le résultat
Ce qu'il reste est uniquement le travail qu'aucun modèle ne peut faire pour vous : créer les produits d'achat in-app dans App Store Connect, mettre en place le backend réel, faire signer la politique de confidentialité par un avocat. Chacun est signalé dans la checklist avec exactement ce qui est nécessaire.
Méthode et sources
Ceci est un récit de première main d'une exécution réelle sur ma propre base de code Kiddays. Le réviseur était le CLI Codex (GPT-5.5) ; le handoff modèle-à-modèle a utilisé ma compétence open-source ai-collab-bridge. Les décisions spécifiques à iOS ont été vérifiées contre la documentation propre d'Apple sur StoreKit, SwiftData et la protection des fichiers — et, plus important encore, chaque changement a été confirmé par une `xcodebuild` propre depuis zéro avant que je ne la considère comme terminée. Je ne rapporte pas ce que les modèles ont prétendu ; je rapporte ce qui a compilé.
La conclusion : une équipe, pas un assistant
Dans tous les projets où j'ai compté sur la revue de code IA hybride, le déblocage n'a jamais été « trouver le modèle unique qui fait tout ». C'était une stack :
Un modèle qui écrit du code est un assistant. Deux modèles qui se révisent mutuellement face à une build qui peut dire non commencent à ressembler à une équipe — et lors de cette exécution, cette équipe a livré 39 corrections en production pendant que je regardais.