Stop coder, commence à piloter : Claude Code vs Codex

#Arrête de comparer les benchmarks

Quand on oppose Claude Code et Codex, le réflexe habituel est de sortir les benchmarks : lequel résout le plus de tickets, lequel produit le moins de bugs, lequel coûte le moins cher. C'est une comparaison utile, mais elle passe à côté de l'essentiel.

C'est la thèse défendue par Nate Jones dans sa vidéo « Stop Coding. Start Steering. » et l'article qui l'accompagne sur sa newsletter : ces deux outils ne t'apprennent pas seulement à produire du code. Ils t'entraînent à deux façons de manager le travail d'une IA radicalement différentes.

• Claude Code t'apprend à piloter (steering) : rester proche de l'agent, dialoguer, corriger la trajectoire en temps réel.
• Codex t'apprend à déléguer (dispatching) : rédiger un brief complet, lancer le travail, partir, puis exiger des preuves au retour.

La nuance peut sembler théorique. Elle ne l'est pas. Utilise l'un des deux assez longtemps, et il change ton réflexe face à un nouveau problème : est-ce que tu ouvres une conversation, ou est-ce que tu rédiges une meilleure mission ?

Dans ce guide, on va définir ces deux modes, identifier leurs pièges respectifs, puis construire une méthode concrète pour choisir le bon mode selon la tâche — et vérifier le résultat dans les deux cas.

#Deux philosophies, pas deux outils

Commençons par poser le vocabulaire.

Piloter (steering), c'est travailler avec l'agent en continu. Tu lances une tâche, tu observes ce qu'il fait, tu l'interromps quand il part dans la mauvaise direction, tu affines la demande au fil de la conversation. C'est le mode naturel de Claude Code : une session interactive dans ton terminal, où chaque étape est visible et corrigeable.

Déléguer (dispatching), c'est confier une mission complète à l'agent et t'absenter pendant l'exécution. Tu rédiges la tâche, l'agent travaille seul dans un environnement isolé, et tu reviens pour examiner un livrable fini — typiquement un diff ou une pull request. C'est le mode naturel de Codex : une file de jobs plutôt qu'une boucle interactive.

Ce qui compte, ce n'est donc pas l'outil que tu choisis, mais le mode de management que tu appliques à chaque tâche. Et chaque mode a son piège.

#Les deux théâtres : conversation et complétion

Les deux modes échouent différemment, et leurs échecs partagent un point commun : ils sont convaincants.

#Le théâtre de la conversation

En mode pilotage, le piège est subtil : une bonne conversation te persuade que le travail a été compris. L'agent reformule ta demande avec assurance, propose un plan cohérent, explique son raisonnement. Tout semble sous contrôle. Sauf que la qualité du dialogue ne garantit pas la qualité du code produit. Tu peux passer une heure à discuter brillamment avec un agent qui implémente, au final, autre chose que ce dont vous avez parlé.

#Le théâtre de la complétion

En mode délégation, le piège est symétrique : un run terminé paraît plus fiable qu'il ne l'est. L'agent revient avec un diff propre, des tests qui passent, un message de complétion confiant. Le livrable a l'air fini. Mais « terminé » ne veut pas dire « correct » : l'agent a pu contourner un test au lieu de corriger le bug, implémenter une interprétation plausible mais fausse de ta demande, ou casser quelque chose hors du périmètre de ses tests.

Dans les deux cas, la vraie question est la même : est-ce que c'est réel ? Tu reçois du travail produit par une machine sans avoir supervisé chaque étape. Ta valeur ajoutée ne se situe plus dans l'écriture du code, mais dans ta capacité à vérifier qu'il fait vraiment ce qu'il prétend faire.

#Six questions avant de lancer un agent

Avant de lancer une tâche — peu importe l'outil — passe-la au crible de ces six questions. Elles déterminent le mode adapté.

1. Sais-tu décrire le résultat attendu en une phrase vérifiable ? Si oui, la tâche est délégable. Si tu as besoin de trois paragraphes pleins de « ça dépend », il faut piloter.
2. Existe-t-il un test objectif de réussite ? Une suite de tests, un build qui passe, un comportement reproductible. Sans critère vérifiable, la délégation devient un pari.
3. Quel est le coût d'une erreur non détectée ? Migration de base de données, code touchant aux paiements, logique de sécurité : pilote. Refactoring couvert par des tests : délègue.
4. La tâche demande-t-elle des décisions en cours de route ? Si l'agent va rencontrer des choix d'architecture que tu veux arbitrer toi-même, reste dans la boucle.
5. Connais-tu déjà le terrain ? Sur un codebase que tu maîtrises, tu peux rédiger un brief précis. Sur un codebase inconnu, pilote d'abord — la session d'exploration t'apprendra de quoi écrire de meilleurs briefs ensuite.
6. Combien de fois cette tâche va-t-elle se répéter ? Une tâche récurrente mérite l'investissement d'un brief réutilisable. Une tâche unique et floue se traite plus vite en conversation.

En résumé : délègue ce qui est spécifiable et vérifiable, pilote ce qui est ambigu ou risqué.

#Écrire un brief de mission

Si tu décides de déléguer, la qualité du résultat dépend presque entièrement de la qualité du brief — ce que Nate Jones appelle une run spec. Un bon brief transforme une intention floue en mission bornée. Voici un gabarit que tu peux adapter :

## Objectif
Corriger le bug #342 : le formulaire d'inscription accepte
les emails sans domaine (ex: "user@").

## Périmètre
- Modifier uniquement : lib/validation.ts et ses tests
- NE PAS toucher : le schéma de base de données, les autres formulaires

## Critères de réussite (vérifiables)
- `bun test lib/validation.test.ts` passe
- Un nouveau test couvre le cas "user@" et le cas "user@domaine"
- `bun run typecheck` passe sans erreur

## Contraintes
- Pas de nouvelle dépendance
- Suivre le pattern de validation existant dans lib/validation.ts

## En cas de blocage
Si la correction demande de modifier d'autres fichiers que ceux
listés, STOPPER et expliquer pourquoi au lieu d'improviser.

Trois éléments font la différence avec un prompt classique :

• Le périmètre négatif (« ne pas toucher ») évite les dégâts collatéraux hors de ta zone de review.
• Les critères vérifiables donnent à l'agent — et à toi — une définition objective de « terminé ».
• La clause de blocage remplace l'improvisation par une escalade. Un agent qui s'arrête et explique vaut mieux qu'un agent qui invente un contournement.

#Vérifier que c'est réel

Le travail revient. Diff propre, message confiant. Avant de merger, joue le rôle de l'auditeur sceptique — voici une checklist minimale :

1. Relance les vérifications toi-même. Ne te fie pas au « les tests passent » rapporté par l'agent : exécute la suite de tests et le build sur ta machine. C'est la défense la plus simple contre le théâtre de la complétion.
2. Lis le diff en entier, pas le résumé. Le résumé décrit l'intention de l'agent ; le diff montre ce qu'il a réellement fait. Cherche en particulier les modifications hors périmètre du brief.
3. Vérifie les tests ajoutés, pas seulement leur statut. Un test qui passe peut être un test vide, trop permissif, ou qui teste autre chose que le bug. Demande-toi : « si le bug revenait, ce test échouerait-il ? »
4. Teste le cas qui a motivé la tâche. Reproduis manuellement le scénario d'origine. Si le bug #342 concernait « user@ », tape « user@ » dans le formulaire.
5. Croise les agents sur les tâches critiques. Pour du code sensible, donne le diff à un second agent avec une consigne adverse : « trouve ce qui est cassé ou incomplet dans ce changement ». Un agent qui review le travail d'un autre n'a aucun attachement au code produit — il est bien plus impitoyable que l'auteur.

Cette dernière technique — le contrôle croisé — est sous-utilisée alors qu'elle ne coûte qu'un prompt. Elle s'applique d'ailleurs dans les deux sens : un diff produit par Codex peut être audité par Claude Code, et inversement.

#Le coût que personne ne budgète

Un dernier point, souvent ignoré dans les comparatifs : la vérification a un coût, et il est rarement budgété.

Quand tu délègues, le temps gagné pendant l'exécution se paie en partie au retour : lire le diff, relancer les tests, reproduire le scénario. Si tu lances six agents en parallèle et que chaque review sérieuse prend vingt minutes, tu as créé deux heures de travail de vérification — pour toi. C'est exactement le goulot d'étranglement que rencontrent les équipes qui industrialisent les agents : la production de code accélère plus vite que la capacité à la relire.

La conséquence pratique : ne délègue pas plus que ce que tu peux vérifier sérieusement. Trois runs bien reviewés valent mieux que dix runs mergés sur la foi d'un message de complétion.

#Ce qu'il faut retenir

• Claude Code et Codex n'enseignent pas le même métier : le premier t'entraîne à piloter un agent en temps réel, le second à déléguer une mission et vérifier le livrable
• Chaque mode a son piège : le théâtre de la conversation (un bon dialogue ne garantit pas un bon code) et le théâtre de la complétion (un run terminé n'est pas un run correct)
• Avant de lancer : délègue ce qui est spécifiable et vérifiable, pilote ce qui est ambigu ou risqué
• Un bon brief de mission contient un objectif, un périmètre (positif et négatif), des critères vérifiables et une clause de blocage
• Au retour : relance les vérifications toi-même, lis le diff en entier, et utilise un second agent comme auditeur sur les tâches critiques
• Budgète la vérification : ne délègue jamais plus que ce que tu peux relire sérieusement

La compétence qui monte en valeur n'est ni la syntaxe ni la vitesse de frappe : c'est la capacité à découper le travail, à choisir le bon mode de supervision, et à distinguer un livrable réel d'un livrable convaincant. Autrement dit — un travail de manager.