- Le critère clé pour choisir un agent de codage se déplace de la performance brute du modèle vers le temps disponible de l’utilisateur et le temps d’exécution autonome ; Claude Code et Codex sont utilisés en parallèle selon les situations
- Opus se distingue par sa gestion de la fenêtre de contexte et l’usage des outils ; il peut exécuter plusieurs sous-agents simultanément, ce qui favorise l’exploration rapide et l’élaboration de plans
- Codex surpasse Opus en précision du code, mais souffre d’un manque de délégation entre fenêtres de contexte, ce qui ralentit le traitement
- Grâce à l’automatisation via des skill, une boucle planification → implémentation → revue → correction de bugs a été construite par étapes ; plutôt que de tout concevoir dès le départ, l’approche la plus efficace consiste à automatiser progressivement les tâches manuelles répétitives
- À terme, la direction visée est celle d’agents travaillant de façon autonome 24/7, mais les limites de la fenêtre de contexte et la résistance aux injections de prompt restent les principaux obstacles
Contexte
- J’ai travaillé sur la version web de Codex et j’ai quitté OpenAI en juillet 2025
- J’ai rédigé ce billet pour structurer ma stratégie détaillée d’utilisation des agents de codage après le podcast YC Lightcone
- Les critères de choix d’un agent se déplacent de la performance du modèle vers le temps d’exécution autonome et l’importance métier
- Je suis abonné à Claude Max, ChatGPT Pro et Cursor Pro+, avec un très bon rapport coût/productivité
Principe fondamental : comprendre le contexte
- Pour bien utiliser un agent de codage, il faut absolument comprendre le contexte (context)
- Aussi performant soit-il, un agent finit toujours par faire de la next token prediction, et tous les tokens doivent tenir dans la fenêtre de contexte
- Principes clés qui en découlent :
- Il faut découper les problèmes à la bonne taille pour les faire entrer dans la fenêtre de contexte ; les problèmes trop gros prennent longtemps et donnent de moins bons résultats
- La compaction est une technique avec perte : l’agent décide quelles informations inclure ou omettre, et plus il y a de compaction, plus la performance tend à baisser
- En externalisant le contexte dans le système de fichiers, par exemple avec des documents de planification, l’agent peut lire et mémoriser sélectivement sans saturer le contexte global de la conversation
- Il est important de rester dans la “moitié intelligente” de la fenêtre de contexte ; comme l’entraînement fonctionne mieux sur des contextes courts, on obtient de meilleurs résultats quand la fenêtre est moins remplie — Dex Horthy parle de rester en dehors de la « dumb zone »
- Si l’agent manque un fichier ou un package pertinent, il peut partir dans une direction inattendue ; une « divulgation progressive (progressive disclosure) » de la structure et de l’architecture de la codebase aide beaucoup — OpenAI a déjà publié un billet sur sa manière de structurer plusieurs fichiers Markdown
- Les performances et la vitesse d’un modèle dépendent non seulement de ses capacités propres, mais aussi de sa gestion de plusieurs fenêtres de contexte et de sa capacité à déléguer à des sous-agents/équipes
Opus : gestion du contexte, usage des outils et sensation plus humaine
- J’utilise Claude Code comme outil principal pour la planification, l’orchestration dans le terminal et la gestion des tâches git/GitHub
- Opus est entraîné à fonctionner de manière très efficace à travers plusieurs fenêtres de contexte ; en pratique, Claude Code paraît donc plus rapide que Codex
- On voit souvent Opus lancer plusieurs sous-agents simultanément, via des appels comme
Explore ou Task
- L’outil Explore utilise Haiku, ce qui permet de traiter rapidement de gros volumes de tokens et de transmettre le contexte pertinent à Opus
- Il est aussi bien entraîné à l’usage d’outils locaux comme
gh, git et divers serveurs MCP
- L’extension
/chrome permet aussi de vérifier des bugs, mais elle peut être lente et instable
- Le modèle d’autorisations de Claude Code est plus simple à comprendre que celui de Codex — le modèle Codex a tendance à scripter des commandes bash, ce qui complique le whitelisting fin des outils CLI
- Petits avantages UX de Claude Code : mise à jour du titre du terminal selon la tâche, PR courante dans la barre d’état, petits messages d’état, etc.
- Opus est meilleur que Codex pour générer des descriptions de PR faciles à comprendre par un humain et des diagrammes d’architecture détaillés
- Quand je demande une explication de la structure du code, j’utilise surtout Claude Code
- Opus est plus “créatif” dans la planification, avec une capacité à proposer des éléments non mentionnés par l’utilisateur ou à signaler des zones floues
Codex : une précision du code écrasante
- Le domaine où Codex brille vraiment, c’est la correctness du code, et d’autres développeurs gros utilisateurs de ces modèles partagent ce constat
- En l’exécutant avec GPT-5.3-Codex-xhigh ou high, le code produit par Codex contient visiblement moins de bugs
- Exemples d’erreurs fréquentes chez Opus :
- un composant React passe les tests unitaires mais l’ajout au
<App> racine est oublié
- une erreur de type off-by-one évidente n’est pas détectée
- des dangling references ou race conditions subtiles
- Pendant longtemps, je pensais que l’écart entre les deux modèles était négligeable, mais après avoir vu suffisamment de PR via Codex et la revue automatique de Cursor Bugbot, j’ai conclu que les modèles d’OpenAI produisent un meilleur code
- Pour faire un A/B test direct, il suffit de checkout une branche puis de comparer
/code-review dans Claude Code avec /review dans Codex
- En revanche, Codex est lent — principalement parce qu’il délègue mal entre fenêtres de contexte, et j’ai aussi l’impression que la latence inter-token est plus élevée
- Le support expérimental des sous-agents (via le toggle
/experimental) fonctionne, mais reste moins fluide que chez Claude et encore limité en parallélisme
- En pratique, le pattern consiste donc à commencer avec Claude Code, le laisser ouvert, puis basculer sur Codex au moment de coder réellement
Outils et configuration utiles
- Je travaille actuellement sur une codebase greenfield, bien plus petite et plus efficace en tokens qu’une codebase de production
- Structure du repo : un dossier
plans/ dans chaque repo pour gérer des plans numérotés, séparation des services dans apps/, monorepo TypeScript géré avec turborepo, et bun pour des installations rapides
- Ghostty : le terminal de Mitchellh, rapide, natif et en amélioration continue — auparavant, j’exécutais plusieurs instances de Claude/Codex avec tmux, aujourd’hui j’utilise plusieurs panes dans le même onglet terminal
- Next.js sur Vercel, API sur Cloudflare Durable Objects : une architecture qui pré-partitionne la base de données, réveille à la demande et réduit les inquiétudes liées aux écritures concurrentes — bien adaptée, côté infra, à une époque où les agents manipulent de petits morceaux de données
- Cloudflare étend aussi cette direction avec la bibliothèque cloudflare/actors, qui regroupe calcul et petit stockage colocalisé
- Worktrees : comme le code est léger, j’exploite des worktrees en parallèle, avec validation locale via
bun install puis bun run dev sur chacun — j’utilise un skill worktree qui copie plan, variables d’environnement et mises à jour associées, puis démarre une nouvelle branche
- Avant l’arrivée des agents de codage, j’utilisais surtout des branches, mais la combinaison worktree + Claude Code est extrêmement utile
- Plan, Implement, Review : j’amène presque toujours le modèle à commencer par un plan — 1) pour externaliser le contexte au-delà d’une seule fenêtre 2) pour pouvoir revoir ce qui a été fait ou poser des questions — si l’agent s’arrête, on peut reprendre le plan dans une nouvelle fenêtre de contexte
- Preview deploys : chaque branche reçoit un nouveau déploiement Web + API, ce qui facilite l’exécution parallèle et les tests rapides — difficile de travailler sans cette capacité
- Cursor Bugbot et Codex Code Review : je comprends le code au niveau architecturel et fais des spot checks, mais je ne lis plus progressivement chaque ligne de chaque PR — les agents sont meilleurs pour trouver des bugs subtils
- Pendant un temps, j’utilisais Claude Code, Cursor Bugbot et Codex à trois, mais Claude Code ne trouvait pas de vrais problèmes ; Cursor est devenu l’option par défaut, tout en jugeant aussi les résultats de Codex très bons
Skills : le cœur de l’automatisation
- J’ai défini plusieurs skill et des fichiers AGENTS.md/CLAUDE.md partagés dans un repo appelé claudefiles
- Règle d’ajout des skill : ne pas les ajouter trop tôt ; uniquement après plusieurs répétitions, quand le workflow s’est stabilisé
- AGENTS/CLAUDE.md sert bien à orienter globalement le modèle, et les skill ont deux objectifs :
- Enchaînement et automatisation du workflow — créer un skill pour la planification, un autre pour l’implémentation par étapes, un autre pour la revue, puis un méta-skill qui les exécute dans l’ordre
- Découpage des fenêtres de contexte — dans Claude Code, si un appel de skill est configuré avec
context: fork, il peut s’exécuter dans une nouvelle fenêtre de contexte, ce qui sépare l’« orchestrateur maître » des sous-agents
- Les skill sont très efficaces en contexte : contrairement aux appels MCP (qui peuvent consommer des milliers de tokens), ils coûtent généralement ~50-100 tokens
Évolution de l’automatisation par skill
- Au départ, l’idée d’une marketplace de skill m’intéressait (installer des skill pour le design frontend, l’audit sécurité, la revue d’architecture, etc.), mais avec l’expérience j’ai renoncé à la plupart des skill écrits par d’autres
- À la place, je suis passé à une méthode où je fais d’abord le travail manuellement, puis je réfléchis à la manière de l’automatiser
- Évolution des skill :
/commit : au lieu de donner au modèle des consignes variées pour commit et push, j’ai tout regroupé dans un seul skill — directement inspiré de Claude Code/worktree : pour faire travailler l’agent dans un worktree séparé, avec création d’un nouveau worktree à partir d’un numéro de plan (par ex. 00034-add-user-auth)/implement : regroupe dans un seul skill la tâche répétitive consistant à exécuter une étape du plan puis lancer /commit/implement-all : relie le chemin du worktree courant à un numéro de plan pour implémenter automatiquement toutes les étapes — pour les exécutions nocturnes, /ralph-loop continue jusqu’à la fin de toutes les étapes, et /codex-review crée un processus codex --review en local/address-bugs : interroge l’API GitHub pour récupérer les commentaires Cursor + Codex depuis le dernier commit, puis tente de vérifier et corriger les bugs/pr-pass : s’exécute à la fin de /implement-all et 1) push sur le remote 2) attend que toute la CI passe 3) lance /address-bugs, puis répète éventuellement l’étape 1/focus : consulte le répertoire plans, les PR incomplètes et les worktrees afin de rafraîchir la mémoire et aider au suivi du travail
- Si j’avais essayé de construire tout ce processus dès le départ, je n’y serais sans doute pas arrivé ; la clé a été de l’assembler progressivement, en repérant au fil du temps de petits morceaux automatisables
Autres outils
- J’ai récemment essayé l’application Codex, avec une impression positive sur les détails et petites finitions — mais je préfère toujours la flexibilité des outils CLI et je n’ai donc pas basculé complètement
- J’ai aussi testé Cowork, sans réussir à le faire bien fonctionner ; dans les deux cas, le modèle de sandboxing fait une grande différence
- J’utilise parfois l’interface web pour le travail asynchrone, mais je dépends de plus en plus du CLI — à l’inverse d’il y a six mois, où j’utilisais surtout Cursor et ses agents/extensions intégrés
- J’utilise pencil.dev pour le travail UI frontend — son modèle de déploiement, qui shell out vers Claude Code en local pour réutiliser un abonnement existant, est intéressant
- Je ressens le besoin d’un issue tracker plus structuré ; Dex de David Cramer et beads de Steve Yegge paraissent prometteurs, mais me semblent encore plus complexes que nécessaire
- Je n’utilise pas actuellement d’e2e MCP automatisé comme Playwright
Conseils aux laboratoires
-
Feedback pour Anthropic
- Modèle : Opus donne une sensation plus humaine, excelle dans l’usage d’outils d’ingénierie, le découpage du contexte et les suggestions de choses « que l’utilisateur a peut-être oubliées », mais manque de précision sur le code — j’aimerais un mode « Opus Strict » qui renforce le RL sur le modèle de base pour améliorer cela
- Je commence avec Opus, mais c’est Codex qui écrit le code ; avec une contrainte budgétaire, je choisirais Codex
- Product harness : il y a très peu à redire, et les idées de Boris et Cat sont excellentes
- J’aimerais l’adoption d’un standard agent skills — travailler avec des symlinks de répertoires entre plusieurs CLI est pénible
- Je demande la publication du format de sortie de
--stream-json — je veux exécuter Claude Code en sandbox pour le compte des utilisateurs, mais les changements potentiels de format et la configuration des chemins sont plus contraignants qu’avec d’autres outils CLI (Codex, Cursor, Gemini)
-
Feedback pour OpenAI
- Modèle : la priorité absolue est d’améliorer le découpage entre fenêtres de contexte et la délégation à des sous-agents — l’idée du « faire plus que ce qui a été demandé » qu’Opus atteint en planification serait aussi utile
- Feedback détaillé sur le product harness :
- Le modèle de sandboxing est plus difficile à comprendre que celui de Claude Code — comme le modèle essaie de scripter, les demandes d’approbation se multiplient, ce qui inquiète en mode
--yolo
- J’aimerais des guides utilisateur intégrés au CLI, comme dans Claude Code — pour pouvoir poser des questions sur l’emplacement des skill, les champs pris en charge, la configuration du sandboxing, etc.
- Je demande que
/review soit transformé en skill générique plutôt qu’en commande packagée — afin que le modèle puisse l’appeler dynamiquement
- J’aimerais que le titre de l’onglet terminal change selon la tâche en cours, comme dans Claude Code — sinon on se perd facilement parmi des dizaines d’onglets
codex
- Il faudrait un entraînement spécialisé pour les descriptions de PR et de commits — le côté concis de Codex est appréciable, mais il faut développer davantage les explications
- J’aimerais la prise en charge de
context: fork dans les définitions de skill
- Quand un lien est renvoyé à la ligne dans un pane, il devrait rester cliquable
- J’aimerais voir dans la barre d’état le nom du worktree/de la PR/de la branche en cours
Perspectives
- Je cite le billet Gas Town de Steve Yegge — selon lui, il faut toujours utiliser le maximum de tokens, faire tourner un pool de workers 24/7, et s’attendre à planifier puis jeter beaucoup de choses
- Qu’on trouve ou non l’abstraction exacte, je pense que la direction est absolument juste
- Futur idéal : un laptop ou des sandboxes cloud qui traitent en permanence des idées en arrière-plan, pendant que l’utilisateur se contente d’orienter, faire de la recherche ou relire les résultats
- Le travail avec des agents de codage ressemble de plus en plus à un rôle d’engineering manager, sans avoir à gérer la motivation ni la personnalité des agents
- Nous sommes déjà assez proches de ce futur — sur Twitter, le sujet est survendu, mais en pratique j’ai réellement pris l’habitude de lancer 3 à 4 tâches dans Codex avant de dormir pour les relire le matin
- Mais on n’en est pas encore au point de faire tourner les agents 24/7
- Deux obstacles majeurs bloquent les progrès plus importants :
- La taille/l’orchestration de la fenêtre de contexte — un agent ne peut pas compresser/réutiliser indéfiniment la même fenêtre de contexte ; il faut un harness plus intelligent ou de meilleurs mécanismes de délégation
- La résistance aux injections de prompt — l’agent demande des approbations au bout de quelques minutes, et le mode
--yolo n’est pas digne de confiance, même s’il existe un sous-ensemble acceptable de permissions/domaines
- Sur le premier point, Cursor pousse déjà les limites avec des swarms d’agents sur plusieurs fenêtres de contexte ; sur le second, la recherche est très active
- L’exécution en sandbox reste aujourd’hui le meilleur contournement, mais sa configuration demeure pénible, et si un agent a à la fois accès à l’Internet ouvert et à des données privilégiées, il devient vulnérable à la « Lethal Trifecta » décrite par Simon Willison
- En tant qu’ingénieur solo, ce sont déjà les bonnes idées qui deviennent le goulot d’étranglement ; de plus en plus, ce seront les idées, l’architecture et le séquencement des projets qui limiteront la capacité à construire d’excellents produits
Aucun commentaire pour le moment.