Génie Junior et Sénior Expérimenté
Ce que j'ai ressenti en utilisant Codex et Claude Code ensemble
De nos jours, dire "Je code avec de l'IA" n'est plus si spécial.
Dans mon processus de développement de services réels, j'utilise plusieurs modèles ensemble, et parmi eux, Codex (gpt-5-codex high) et Claude Code (Opus) se sentent comme deux collègues avec des personnalités très distinctes.
Ce qui est intéressant, c'est que perdre de vue l'essence en les comparant simplement sur "qui code le mieux" est une erreur.
Ce n'est pas une question de compétences, mais plutôt de différences de personnalité semblables à celles des développeurs.
Codex: un jeune développeur génial
Lorsque j'ai commencé à utiliser Codex, ce qui m'a le plus impressionné, c'est sa rapidité.
Il produit du code instantanément sans hésitation lorsque vous lui soumettez un problème. Sa capacité à transformer des idées en structure est excellente.
C'est un peu comme ça.
"Ne pourrait-on pas le résoudre de cette manière?"
— Un jeune recrue fraîchement embauchée avec une capacité de réflexion exceptionnelle
En particulier, Codex excelle dans les situations suivantes.
- Lorsque vous voulez rapidement voir vos idées sous forme de code
- Lorsque vous créez des prototypes, des POC, des structures expérimentales
- Lorsque la complétude syntaxique du langage ou du framework est importante
Cependant, du point de vue de l'exploitation d'un service Rails réel, il y a clairement des points d'amélioration.
Par exemple, lors de la rédaction de fichiers de migration, il peut arriver de ne pas comprendre exactement l'intention des méthodes up / down et la manière dont Rails recommande d'effectuer des changements (par exemple, migration réversible).
De plus, il peut arriver de répondre "je sais que ça existe mais je ne connais pas le contexte" à des questions sur des outils de déploiement comme Kamal.
Ce n'est pas tant un manque de compétences de Codex, mais plutôt une impression qu'il ressemble à un développeur qui a passé peu de temps à "utiliser Rails".
Claude Code (Opus): un Sénior expérimenté avec une longue expérience de Rails
En revanche, Claude Code (Opus) est différent dès le départ.
Lorsqu'on lui présente un problème, il ne se met pas immédiatement à écrire du code. Il commence par organiser le contexte.
"Dans Rails, il est naturel de suivre cette logique."
Ce ton même est déjà celui d'un Sénior.
Les points forts de Claude Code sont clairs.
- Compréhension globale de la plateforme Rails
- Compréhension du flux complet de migration → déploiement → exploitation
- Préférer le code "intentionnel par Rails" plutôt que le code "possible"
Même en écrivant la même migration, il propose d'abord une forme non seulement fonctionnelle mais aussi réversible et facile à entretenir pour l'équipe.
C'est pourquoi le code proposé par Claude Code n'est pas spectaculaire.
Cependant, pour quelqu'un qui a réellement exploité un service, cela donne l'impression que c'est "la manière dont nous faisions les choses en production".
Je trouve ce point très important.
Parce que, à la fin, le temps passé à exploiter le code est bien plus long que celui passé à le rédiger.
Ma façon d'utiliser ces deux modèles
C'est pourquoi ces jours-ci, j'utilise délibérément les deux modèles en les séparant intentionnellement.
Au lieu de poser les mêmes questions et de comparer les réponses, je les fais travailler ensemble en leur assignant des rôles distincts.
En général, voici comment je commence un développement.
J'ouvre un terminal Warp et
je crée deux panneaux côte à côte.
- Panneau de gauche: Claude Code (Opus)
- Panneau de droite: Codex (gpt-5-codex high)
À gauche, il y a toujours Claude Code.
Ici, je n'écris pas directement de code.
Je demande d'abord à Claude Code de planifier.
- Quelle structure est naturelle pour cette fonctionnalité dans Rails
- Où se situent les limites entre le modèle, le contrôleur et l'objet de service
- Dans quel ordre les migrations devraient-elles être effectuées en toute sécurité
- Quels sont les points à surveiller pour le déploiement et l'exploitation
À ce stade, Claude Code agit presque comme un relecteur de conception technique.
"Ce serait dans l'esprit de Rails d'aller dans cette direction" est une remarque naturelle.
Ensuite, je transmets le même plan à Codex à droite.
"Peux-tu vérifier s'il manque quelque chose dans ce plan?"
"Y a-t-il des éléments que nous pourrions simplifier ici?"
Codex joue un rôle vraiment utile à ce stade.
Il repère rapidement les failles de la structure ou simplifie courageusement les parties devenues trop complexes.
Écriture avec Claude, Révision avec Codex
Une fois le plan établi, je rédige le code avec Claude Code.
La raison en est simple.
Dans Rails, il est plus important d'avoir un code "durable" que "fonctionnel".
Le code de Claude Code peut être plus lent, mais il prend en compte la réversibilité des migrations, ne compromet pas les conventions de Rails et reste compréhensible lorsque vous le relisez plus tard.
Une fois le code assez avancé,
je fais appel à Codex comme relecteur de code.
- Comment pourrions-nous simplifier cette logique?
- Avons-nous manqué quelque chose dans les requêtes ou les boucles?
- Y a-t-il des structures difficiles à tester?
Codex est vraiment compétent à ce stade.
C'est un peu comme si un jeune recrue brillant posait des questions sur le code du sénior sans hésitation.
Mes réflexions en utilisant les deux IA en même temps
En utilisant ces deux modèles de cette manière, j'ai réalisé quelque chose de certain.
Comparer Codex et Claude Code n'a pas vraiment de sens.
Ce qui compte, c'est comment les positionner dans un rôle.
- Codex est fort pour la divergence et la vérification
- Claude Code est fort pour l'accumulation et la stabilité
En plaçant ces deux-là côte à côte dans les panneaux gauche et droit de Warp,
même en travaillant seul,
on a l'impression d'avoir deux développeurs avec des approches différentes au sein de l'équipe.
Et je suis simplement le développeur qui prend les décisions entre les deux.