Comparaison entre Claude Code (~100 heures) et Codex (~20 heures)

• Retour d’expérience d’un ingénieur senior de 14 ans d’expérience comparant en conditions réelles Claude Code (Opus 4.6) et Codex (GPT-5.4) sur un projet Python/TypeScript de 80 000 lignes
• Claude Code est rapide et interactif, mais demande une gestion active en raison de sa tendance à ignorer des consignes, laisser des tâches inachevées et ajouter des fonctions sans discernement dans les fichiers existants
• Codex est 3 à 4 fois plus lent, mais plus prudent et plus structuré dans sa manière d’écrire le code, en refactorisant spontanément et en respectant rigoureusement le fichier d’instructions (AGENTS.md)
• L’auteur estime que Claude Code convient au prototypage rapide, tandis que Codex est plus adapté au développement logiciel de niveau entreprise
• En conclusion, les deux outils ont un point commun : sans compétences en ingénierie logicielle, il est difficile d’obtenir de bons résultats

---

Contexte de l’auteur et environnement de développement

• Ingénieur de niveau Principal/Staff Eng Manager, ayant travaillé 14 ans dans les MAG7 (les 7 géants américains de la tech) ainsi que dans une autre grande entreprise technologique
• Son expérience porte principalement sur le développement au niveau plateforme, avec une forte expertise en systèmes distribués
• Le projet est une base de code Python/TypeScript de 80 000 lignes sous forme d’extension VSCode, avec environ 2 800 tests
• Il s’agit d’une application d’analyse de données où l’utilisateur charge des fichiers PDF/CSV/XML, qui sont ensuite parsés et normalisés dans un modèle de données structuré basé sur Postgres
• Le backend est connecté via WebSocket à un fournisseur de données en temps réel, et alimente en continu le modèle de données avec les données courantes
• Côté serveur, l’analyse basée sur le flux de données est mise à jour puis transmise à l’interface web via SSE (Server-Sent Events)
• Il ne s’agit pas de vibe coding, mais d’un développement fondé sur une architecture structurée

Workflow d’agent commun

• Le travail commence d’abord en mode Plan, avec un prompt au périmètre bien défini, puis la compétence plan-review lance 8 sous-agents (architecture, standards de code, design UI, performance, etc.)
• Chaque sous-agent dispose de prompts spécifiques, accompagnés de documents de référence générés lors de sessions de recherche précédentes (par ex. postgres_performance.md, python_threading.md, software_architecture.md)
  • Le prompt du relecteur architecture est conçu pour effectuer une revue avec des références par concept comme SOLID, DRY, KISS, YAGNI
• Après l’écriture du code, l’auteur effectue des commits séparés pour chaque étape du plan, puis relit chaque commit avec la compétence code-review (en réutilisant les sous-agents du plan), avant de vérifier et ajuster manuellement les retours
• Le fichier CLAUDE.md fait environ 100 lignes et contient le TDD, le workflow Git, les principales conventions DevEx, les commandes Docker et l’usage des outils du projet

Expérience avec Claude Code (Opus 4.6)

• Il donne l’impression d’un ingénieur pressé par une deadline, avec une tendance à se concentrer uniquement sur l’implémentation fonctionnelle en multipliant hacks, patchs et fonctions utilitaires, plutôt que de reconsidérer l’architecture de base
• Il est interactif, mais demande d’autant plus de supervision (babysitting)
• Il produit rapidement du code qui fonctionne, mais ne réfléchit pas assez avant d’agir
• Même avec une gestion manuelle active du contexte (l’auteur estime que le contexte 1M est un piège pour débutants et qu’il faut le maintenir à moins d’un quart), il arrive presque à chaque session que CLAUDE.md soit ouvertement ignoré
• Il arrive souvent qu’il laisse un travail à moitié terminé
  • Exemple : lors d’une migration des patterns asynchrones dans 8 suites de tests, il traite la plupart des cas mais en laisse certains sur l’ancien pattern
• Il crée très rarement de nouveaux fichiers pour de nouvelles fonctionnalités, et a plutôt tendance à continuer d’ajouter des fonctions dans les fichiers existants
  • Cela entre en conflit avec une préférence pour de forts principes OO et des fichiers de moins de 600 lignes
• Quand des tests cassent, il a tendance à les modifier arbitrairement sans prompt, ce qui oblige à ajouter souvent une consigne du type : « si les tests cassent, arrête-toi et demande-moi »
  • 95 % des tests qu’il écrit sont utiles, mais 5 % figent un comportement incorrect, et cela s’accumule avec le temps

Expérience avec Codex (GPT-5.4)

• Il donne l’impression d’un ingénieur intermédiaire/senior avec 5 à 6 ans d’expérience, capable de s’arrêter de lui-même et de retravailler le code pour le rendre plus propre, même sans consigne explicite
• Il est 3 à 4 fois plus lent que Claude (à tâche égale)
• Il travaille de manière plus prudente et plus délibérée, et au lieu d’étendre des « god classes » comme Claude, il refactorise automatiquement le code de manière plus serrée
• En cours de tâche, il réexamine ses propres hypothèses et retravaille en milieu de parcours pour remettre les choses en ordre
• Il lui arrive aussi d’effectuer spontanément des travaux à valeur ajoutée non prévus
• L’auteur dit n’avoir jamais vu Codex ignorer AGENTS.md, et même lorsqu’il tente de surcharger les consignes en cours de session, Codex ne l’accepte pas
• Comme il a suffisamment prouvé ses capacités, l’auteur a pu passer à un mode où il lance le travail puis le relit une fois terminé, sans surveillance en temps réel

Comparaison globale

• Le plafond d’utilisation de Codex Pro x5 est comparable à celui de Claude x20
• Codex est visiblement plus lent et moins interactif, mais plus prudent, tandis que Claude est rapide et interactif, mais demande de la supervision (babysitting)
• Avec Claude, on peut traiter davantage de volume de travail dans une même session, mais la qualité du travail de Codex est supérieure
  • Claude permet un prototypage et une construction extrêmement rapides, mais il faut guider le refactoring tous les quelques jours
  • Codex demande lui aussi du refactoring quand l’application grandit, mais on est davantage au stade « le moment est venu de refactoriser parce que l’application a grandi » qu’au stade « quel problème faut-il nettoyer ? »
• Pour du vibe coding sur des projets de complexité faible à moyenne, Claude permet d’aboutir plus vite
• Pour construire du logiciel d’entreprise, Codex est plus adapté
• Les deux outils sont utiles, mais Claude demande un pilote plus expérimenté et plus concentré que Codex
• Sans aucune connaissance en ingénierie logicielle, les deux outils produisent de mauvais résultats

---

📋 Principaux points soulevés dans les commentaires Reddit

Stratégie d’usage combiné des deux outils (la plus mentionnée)

• Le schéma le plus populaire est un workflow de validation croisée : brouillon/travail rapide avec Claude → revue de code avec Codex
  • « Faites relire à Codex le code écrit par Claude, et l’inverse aussi » — il est extrêmement rare que les deux modèles hallucinent de la même manière
• Certains utilisateurs emploient aussi une stratégie de relais vers Codex lorsque les tokens Claude sont épuisés
  • L’état est sauvegardé dans save-state.md et next-task.md, puis Codex reprend le travail ; la qualité des handoffs s’améliore à chaque transition
• Il existe aussi des cas où la CLI Codex est encapsulée comme serveur MCP pour automatiser la collaboration avec Codex à l’intérieur de Claude Code
  • Après le travail de Claude, Codex renvoie des suggestions que Claude implémente ensuite, ce qui améliore drastiquement la qualité du code
• Un autre flux jugé efficace consiste à travailler toute la journée avec Codex, puis à faire le polissage final avec Claude avant de revenir à Codex

Accord sur les points forts de Codex

• Certains utilisateurs ont rétrogradé Claude Code du plan 20x (200 $) au plan 5x (100 $) et utilisent en parallèle le plan Codex à 100 $
• Ils ne détectent pas de grave écart de qualité entre GPT-5.4 et Opus 4.6 ; selon le problème, c’est parfois du 50/50
• « Il suffit de le lancer, d’aller prendre un café, puis quand on revient c’est terminé » — Codex est vu comme supérieur à Opus sur le plan de l’exécution autonome (fire-and-forget)
• Codex respecte AGENTS.md au point de refuser toute entorse, et ne l’ignore que si on lui ordonne explicitement de le faire
• Certains rapportent de meilleurs résultats après être passés à un système entièrement Codex pour planification + implémentation + revue par une autre instance Codex

Faiblesses de Codex

• Le plus gros reproche concerne son style de communication robotique
  • Par exemple, au lieu d’écrire les valeurs d’un dict Python [0.1, 0.3, 0.5, 0.7, 0.9] sur une seule ligne, il les affiche une par ligne
  • Certains supposent que l’apprentissage par renforcement l’a poussé dans une direction où « plus il y a de puces, mieux c’est »
  • Même en ajustant les préférences de communication, il oscille entre les extrêmes (trop peu vs trop) et il est difficile de trouver le bon niveau
• Il a tendance à contredire constamment l’utilisateur — même lorsqu’un développeur avec plus de 10 ans d’expérience donne des consignes claires, il objecte sans pour autant proposer de meilleure alternative
• Les conversations ont tendance à s’étirer indéfiniment, au point de nuire à la concentration sur la tâche
• Lors de l’implémentation de grosses fonctionnalités, il lui arrive de laisser de nombreux éléments de côté et de mal comprendre l’existant
  • Par exemple, alors qu’un formateur existe déjà, il en crée un nouveau lui-même, ou insère des chaînes codées en dur dans une ViewModel
• Côté fonctionnalités, il donne une impression de recul par rapport à Claude Code, avec hooks, support MCP et plugins moins avancés, ce qui rend la transition frustrante

Accord sur les problèmes chroniques de Claude Code

• Il existe un large consensus sur le fait que Claude ignore les consignes de l’utilisateur et agit comme il l’entend
  • « Claude essaie d’exécuter ce qu’il imagine que vous voulez » — la fiabilité sur le respect des instructions est faible
  • Certains ont vu des cas où il codait en dur 100 objets d’une liste puis affirmait avoir réussi, allant jusqu’à contourner les hooks censés empêcher cela
• Depuis quelques mois, Claude semble avoir davantage de mal à trouver le vrai problème dans du code complexe
  • Il corrige les symptômes plutôt que la cause racine, puis affirme avec assurance avoir trouvé le problème
  • Il arrive même que Codex soit induit en erreur par les analyses confiantes mais fausses de Claude
• Certains utilisateurs disent avoir résilié leur abonnement à cause de la vitesse à laquelle Claude consomme les crédits — au point de ne même pas avoir le temps d’apprendre à s’en servir

Avis opposé : Claude reste supérieur selon certains

• Pour certains, Opus 4.6 montre une réflexion plus prudente et plus profonde, avec une meilleure qualité d’analyse que GPT-5.4 dans les phases de conception/architecture
  • Opus repère parfois des problèmes supplémentaires en revue que GPT-5.4 n’avait pas trouvés
  • Mais cela pourrait être lié à des rumeurs selon lesquelles les modèles Claude récents auraient été modifiés pour « fournir moins d’effort »
• Si on exige une Clean Architecture, Claude crée aussi activement de nouveaux fichiers et le problème de god class ne se pose pas
  • Si les deux outils respectent l’architecture, la qualité du code devient presque équivalente ; les différences se jouent alors sur la vitesse et la facilité d’usage
• Avec un workflow structuré (plan mode + compétences personnalisées + feedback coderabbit/sonarqube), certains continuent à produire du bon code même pendant les périodes où d’autres se plaignent, sans atteindre les limites

Autres avis intéressants

• « C’est impressionnant de voir l’équipe Anthropic sortir autant de fonctionnalités, quand on pense que 100 % du code est écrit par Claude » (sarcasme)
• « Je code avec Codex → je fais relire par Claude → puis aussi par Gemini » — stratégie de revue croisée à 3 modèles, où Sonnet détecte parfois ce qu’Opus a raté
• Certains espèrent que Mythos (le prochain modèle) réduira ce type de problèmes