Test d’OpenAI Codex en conditions réelles

• OpenAI Codex est un agent de code multitâche basé sur l’intégration GitHub, qui fournit une interface permettant d’assigner plusieurs tâches en parallèle via le langage naturel
• L’utilisateur peut déverser rapidement une journée entière de travail et lui confier jusqu’à la création automatique de branches et l’ouverture de PR, avec en plus une utilisation possible sur mobile, ce qui peut à terme soutenir un workflow centré sur le travail à distance
• En revanche, à l’heure actuelle, il est inadapté aux gros travaux de refactorisation en raison de problèmes tels qu’une gestion des erreurs insuffisante, une qualité de code instable, la difficulté à mettre à jour des branches existantes et le blocage réseau du sandbox
• Codex est en revanche utile pour automatiser de petites tâches de maintenance et reste pratique pour traiter rapidement des tâches répétables
• Si des améliorations du modèle, du mixage multi‑modèles et des fonctions d’intégration avancées sont ajoutées à l’avenir, il pourrait évoluer en outil d’orchestration de haut niveau

---

Fonctionnement d’OpenAI Codex

• OpenAI Codex propose une UI basée sur le chat, accessible sur invitation ou via l’abonnement Pro à 200 $/mois
• L’utilisateur doit passer par une authentification à plusieurs facteurs puis approuver l’application GitHub Codex pour chaque organisation ; Codex clone ensuite le dépôt dans son propre sandbox pour exécuter des commandes et créer des branches à sa place
• Lorsqu’on gère des dizaines de dépôts publics et privés, son efficacité pour basculer entre de nombreux projets et gérer une file de tâches est excellente
• Si l’on ne gère qu’un ou deux dépôts, un LLM classique ou un éditeur doté de fonctions IA peut être une option plus légère

Les points forts de Codex

• Traitement parallèle de multiples tâches et interface

  • Il est possible de spécifier le dépôt et la branche pour chaque tâche, ce qui rend naturel le fait d’enregistrer en parallèle, en langage naturel, les tâches d’une journée
  • Codex encourage le traitement simultané d’un grand nombre de tâches, ce qui correspond bien à cette manière de travailler

• Workflow flexible et prise en charge du mobile

  • Codex fonctionne de façon adaptée au mobile, y compris sur smartphone, ce qui ouvre de bonnes perspectives de productivité hors du bureau
  • Le scénario idéal visé consiste à enregistrer plusieurs tâches en début de journée, puis à continuer de gérer le planning et l’avancement même en déplacement

• Feedback via le chat et création de PR

  • Les logs et l’état des tâches en cours se consultent facilement dans l’interface de chat, avec possibilité d’ajouter des consignes
  • Si les modifications conviennent, Codex crée une Pull Request (ci-après PR) et complète automatiquement sa description
  • Il est appréciable de pouvoir vérifier, étape par étape, les logs d’exécution et l’historique des commandes

Les points à améliorer

• Gestion des erreurs insuffisante

  • L’absence de retour clair lorsque le démarrage d’une tâche ou la création d’une PR échoue dégrade l’expérience d’utilisation

• Qualité du code et exécution en une seule fois

  • Le modèle Codex appartient à la famille GPT-3 et prend en charge plus de 12 langages, mais en exécution parallèle, le niveau de satisfaction n’atteint qu’environ 40 à 60 %
  • Il est utile pour de petites tâches de maintenance, mais pour les refactorisations à grande échelle, la création répétée de PR réduit son efficacité

• Absence de prise en charge des mises à jour continues dans une branche

  • Comme il est difficile d’enchaîner des commits sur une PR ou une branche existante, les travaux de refactorisation en plusieurs étapes sont peu efficaces
  • À ce stade, Codex convient surtout à des tâches simples pouvant être transmises directement en une seule demande

• Restrictions d’accès réseau dans le sandbox d’exécution

  • Par choix de conception, l’accès au réseau externe est impossible, ce qui limite de nombreux travaux pratiques comme la mise à jour de packages ou la gestion de dépendances
  • Exemple : une demande d’installation d’un package externe ne fonctionne pas
  • Pour ce type de tâche, il faut encore intervenir localement ou s’appuyer sur des bots existants comme Dependabot

Did it unlock insane productivity gains for me?

• Pour l’instant, cela n’a pas encore apporté de gain de productivité spectaculaire
• Pour que Codex débouche sur une véritable révolution de productivité, il faudrait
  • une conception sur mesure et des améliorations algorithmiques permettant de résoudre davantage de tâches en une seule passe
  • une amélioration du flux de mise à jour des PR sur des branches existantes
  • un renforcement des capacités de délégation et de gestion intégrée, ainsi qu’une extension des intégrations avec plusieurs API d’OpenAI
  • que Codex évolue vers un orchestrateur de haut niveau
• Aujourd’hui, Codex est surtout utile pour automatiser des tâches routinières de maintenance et de petites mises à jour
• Pour le développement de grandes fonctionnalités et les refactorisations importantes, la collaboration entre IDE et assistance LLM reste plus adaptée

Réflexions finales

• Codex est un outil discret mais prometteur
• Au vu des fonctions à venir, il a de fortes chances de s’imposer comme point de départ et outil de coordination du travail
• Pour l’instant, c’est le moment de se concentrer sur les tâches légères et répétitives en attendant des améliorations

[yangeok]

On dirait que ce n’est pas encore le moment d’y cramer 200 dollars.

[GN⁺]

Avis Hacker News

• J’étais abonné Plus et j’ai fait l’upgrade vers Pro pour tester Codex, mais honnêtement le résultat m’a plutôt déçu d’après mon expérience
  L’UX ne semble pas encore vraiment aboutie, et c’est frustrant de ne pas savoir combien de temps il faudra pour obtenir un résultat
  Le côté au moins positif de Codex, c’est sa nature asynchrone, qui permet de lancer plusieurs tâches en même temps
  Un autre reproche, c’est que pour que l’outil soit réellement utile, il faut définir un environnement séparé
  Le fait de ne pas pouvoir lancer les conteneurs nécessaires aux tests réduit fortement son utilité
  L’environnement étant complètement isolé d’Internet, les usages restent limités
  Si o3 de ChatGPT est puissant, c’est parce qu’il peut aussi utiliser le web pour aller chercher des informations par lui-même, et c’est justement ce qui manque à Codex
  À titre de comparaison, j’utilise aussi souvent Claude, et quand on crée un projet à partir d’un repo GitHub comme source, il trouve bien même des bugs peu familiers dans des apps React complexes
  Gemini aussi s’en sort bien sur ce type de fonctions grâce à sa grande fenêtre de contexte
  Bien sûr, je comprends aussi la direction que vise OpenAI
  J’aimerais que Codex soit un vrai collègue capable de prendre en charge plusieurs tâches et de les résoudre, mais à ce stade j’ai l’impression qu’il est trop centré sur les pull requests
  Donc je vais repasser sur Plus et attendre encore un peu

  • Je pense vraiment que le support des conteneurs est indispensable

• Je travaille chez OpenAI, mais pas dans l’équipe Codex, et j’ai déjà utilisé Codex avec succès sur plusieurs projets
  Ma façon de travailler est la suivante
  Je lance toujours le même prompt plusieurs fois afin d’obtenir des résultats différents à chaque exécution
  Je compare plusieurs implémentations pour trouver la meilleure, puis je réfléchis à la manière dont j’aurais pu modifier le prompt pour orienter vers un meilleur résultat
  Je corrige dans le prompt ce que le modèle a mal fait, puis j’itère
  En découpant ainsi le travail en petites unités et en répétant des expérimentations en parallèle, on peut terminer même un projet massif en quelques heures, uniquement avec de l’ajustement de prompts et de la revue de code
  Cette méthode est très utile non seulement pour les transformations d’API, mais aussi pour du code profond comme des kernels Triton

  • « Je choisis la meilleure parmi plusieurs implémentations, puis je réfléchis à ce qu’il aurait fallu ajouter au prompt pour obtenir un meilleur résultat »
    Je pense que les non-spécialistes se demanderont comment on distingue ce qui est vraiment « le meilleur »
    Au final, il faut une expertise du domaine pour trouver la bonne direction, et je pense que c’est justement pour cela que les LLM ne peuvent pas supprimer les emplois d’ingénieur logiciel

  • Je me dis que cette manière de travailler, faite manuellement, pourrait en fait servir de base à l’apprentissage par renforcement (RL)
    En ajustant légèrement cette expérience dans l’UI pour l’exploiter comme vraies données, on obtiendrait probablement un bon dataset d’entraînement

  • Je me demande à quel point cette méthode est réellement plus rapide que d’écrire le code soi-même

  • Je me demande si, quand un changement important survient après avoir modifié le prompt, il arrive d’abandonner tout le travail effectué jusque-là
    Il me semble que de petits changements peuvent avoir un grand impact sur le résultat, et que c’est encore plus difficile pour des problèmes sans exemples préalables
    Si cette façon de travailler se répète, j’ai l’impression qu’on peut finir par s’épuiser ou s’éloigner de l’essentiel
    Pour moi cela pourrait sembler inefficace, mais je me demande si d’autres ont simplement plus de patience pour ce genre de travail répétitif

• J’ai partagé avec mon équipe une review de Codex dans le pod (https://latent.space/p/codex)
  C’est un modèle extrêmement fort pour produire du code d’un seul coup (on confirme dans le pod qu’il a été particulièrement fine-tuné pour les tâches SWE d’OpenAI en oneshot)
  En revanche, il manque relativement de capacités d’intégration (par exemple pas d’intégration navigateur, et l’intégration GitHub laisse aussi à désirer — comme il demande d’ouvrir une nouvelle pull request à chaque itération, il est pénible d’ajouter des commits de suivi sur une branche existante, ce qui est frustrant)
  Malgré tout, je m’attends à ce que ces fonctions d’intégration s’améliorent avec le temps
  Le fait de pouvoir lancer 60 instances Codex en parallèle par heure me semble être une différence de nature par rapport à Devin (5 en parallèle) ou Cursor (1 en parallèle avant l’arrivée des agents en arrière-plan)
  Je n’ai pas personnellement ressenti de différence flagrante dans les performances du modèle Codex, et même si OpenAI explique que Codex dérive de GPT-3, en pratique il s’agit d’un fine-tuning de o3

  • Je pense que l’affirmation « fine-tuning de o3 » est elle-même source de confusion
    OpenAI a aussi une nomenclature qui prête à confusion, et c’est un problème que la plupart des entreprises d’IA rencontrent
    Codex était à l’origine un ancien modèle basé sur GPT-3, et aujourd’hui le même nom est réutilisé à plusieurs endroits, comme le CLI et d’autres outils
    Google fait exactement pareil en utilisant « Gemini Ultra » à la fois comme nom de modèle et comme nom d’abonnement, ce qui crée aussi de la confusion

  • Ce qui me gêne le plus, ce sont les restrictions d’accès réseau

    1. impossible de faire git fetch, de synchroniser avec l’upstream ou de corriger des bugs d’intégration
    2. impossible de récupérer de nouvelles bibliothèques externes pour tester leur intégration
       On dirait même que des domaines sont bloqués au point d’empêcher apt install dans le script de setup
       L’agent a aussi tendance à commencer par faire un git grep au lieu d’essayer de comprendre le contexte global du code (ça se voit dans l’UI), donc je trouve ça assez moyen

  • Je me demande en quoi cela diffère de Claude Code

• Je trouve vraiment formidable la possibilité de modifier rapidement plusieurs repos
  Je gère beaucoup d’apps d’exemple en parallèle, et quand il faut changer le format du README ou remplacer des liens, cela devient vraiment pénible au-delà de 20 endroits
  Si je peux confier ce genre de tâches ingrates à Codex et me contenter ensuite d’appuyer sur le bouton de merge, je serais très heureux

  • Je ressens exactement la même chose
    Je pense que ça va évoluer dans ce sens très bientôt
    Pour l’instant, je vais sans doute continuer à répartir les petites tâches de maintenance sur Codex, tout en gardant les gros refactorings et le développement important dans l’IDE

• Je me demande si ce type d’outil pourrait permettre à des non-développeurs d’apporter des modifications au code
  Pour les changements de contenu ou de petites modifications CSS, je n’ai vraiment pas envie de m’en charger moi-même, et comme les tests peuvent se faire visuellement, il me suffirait de faire la review de code
  Un non-développeur pourrait lire le ticket, lancer le travail, puis simplement dire « ça a l’air bien », et moi je vérifierais
  Je pense que ce serait un workflow idéal pour les petits bugs et améliorations de fonctionnalités dans le backlog

  • Je pense que des outils comme AI Assist pourraient finir par devenir la meilleure plateforme low-code possible
    J’espère qu’on ne finira pas réellement par arriver au jour où les ingénieurs logiciels seront remplacés

  • Mais même les changements de contenu demandent souvent une réflexion approfondie
    Dès qu’il y a un peu d’ampleur, il existe des dépendances amont et aval, et l’ajout d’un seul champ peut avoir des conséquences sur tout le système
    Même de petites modifications CSS peuvent sembler mineures, mais il est difficile pour l’utilisateur de savoir à quel point elles le sont réellement

  • Ils apprendront aussi très vite qu’il y a quantité d’enjeux comme l’accessibilité, le multiplateforme (mobile/desktop), etc.
    Au point que cette tendance ressemble presque à un funnel qui fait entrer les gens « par l’amont » dans le métier d’ingénieur logiciel

• Sur de petites tâches, je pense qu’un taux de réussite de 40 à 60 % est déjà plutôt correct
  C’est utile de savoir qu’il y a des difficultés dès qu’on passe à des tâches plus complexes et à une logique plus profonde

  • D’après mes tests, dès qu’une tâche demande ne serait-ce qu’un peu d’esprit critique, Codex se perd complètement
    À l’heure actuelle, ses performances sont au niveau d’un ingénieur junior catastrophique
    Par exemple, quand on lui demande un changement, il supprime les avertissements du compilateur en rendant nullable en masse les valeurs d’une classe
    En apparence, ça marche et ça compile, mais le résultat est totalement faux, au point de détruire l’intégrité des données
    Ce genre de cas est assez fréquent
    Si on lui confie toute une codebase sans supervision, je pense que la dette technique va s’accumuler très vite

• L’idée que Codex nous aidera à travailler correctement pendant que nous ne sommes pas là me semble beaucoup trop optimiste
  Pour beaucoup, « travailler efficacement pendant notre absence » touche en réalité à la question de la file des chômeurs

  • Je trouve déjà étonnant que les développeurs se réjouissent de ce changement
    Je suis surpris par cette ambiance qui laisse croire qu’un jour nous serons simplement assis à regarder les agents tout faire pendant qu’on est payés
    Même si le travail devient plus facile, on peut tout aussi bien aller vers une disparition des emplois eux-mêmes

  • Dans l’histoire des gains de productivité, il y a très peu de précédents où les travailleurs ont réellement gagné plus de temps libre
    Au final, on retrouve surtout le même schéma : plus de profits pour les actionnaires et les dirigeants, deux fois plus de travail pour les employés restants, et du chômage pour les autres

  • À court terme, j’ai quand même l’impression qu’il faudra encore du temps avant qu’on en arrive au chômage de masse
    Je pense qu’il faudra un effort énorme pour que ces modèles accomplissent correctement 90 à 95 % d’un large éventail de tâches
    Les premiers 60 à 70 % sont faciles pour presque tout, mais les derniers 5 à 10 % sont les plus difficiles
    Comme mentionné plus haut, exécuter plusieurs fois pour produire différents résultats puis sélectionner le bon coûte aujourd’hui nettement plus cher, et si on veut appliquer cela à toutes les tâches, le coût d’inférence devient un vrai problème
    À un certain moment, la revue de code deviendra elle aussi indispensable précisément parce que le code sera écrit par des machines
    Pour les petits projets ou les petites fonctionnalités, on pourra peut-être faire confiance au travail machine, mais pour une codebase destinée à durer, il faudra continuer à confier la conception de l’architecture et la validation à des humains
    L’IA peut aider à explorer plus vite différentes approches, mais la décision finale reste humaine, et il faudra continuer à maintenir la qualité par la conception directe ou la revue
    Dans un avenir proche, les équipes d’ingénierie vont probablement chercher comment exploiter activement des agents en arrière-plan
    Je reste sceptique face à l’idée d’externaliser comme aujourd’hui l’ensemble du travail à un modèle puissant
    Le travail actuel de revue de code par IA est assez frustrant, donc il faut de meilleurs workflows
    Pendant plusieurs années, les « agents en arrière-plan » eux-mêmes vont probablement devenir une infrastructure indispensable propre à chaque entreprise
    La plupart des entreprises utiliseront sans doute cette infrastructure d’agents via API plutôt que de l’héberger elles-mêmes
    L’infrastructure d’ingénierie fondée sur les agents en est encore à un stade extrêmement précoce, donc il y aura probablement aussi beaucoup de nouvelles opportunités de travail dans les 3 à 5 prochaines années

  • Si l’on veut être optimiste, on peut aussi dire que plus quelque chose devient bon marché à produire (par exemple du code), plus la demande pour cette chose augmente
    Des non-développeurs pourront peut-être jouer un rôle de gestionnaire, mais d’expérience, plus une tâche est importante, plus les gens veulent la confier à une personne fiable — donc à un humain

  • Je me demande si on peut comparer les développeurs logiciels aux chevaux, et les nouveaux agents-modèles comme Codex ou Claude Code aux automobiles
    Dans ce cadre, certains chevaux deviennent les conducteurs des voitures, tandis que d’autres se retrouvent au chômage parce qu’ils n’ont plus besoin de tirer des charrettes

• Je n’ai trouvé nulle part une liste claire des langages pris en charge
  Ni la présentation officielle ni les reviews ne l’expliquent correctement, la plupart se contentant d’exemples comme la correction de fautes sur une page web

• On dirait un niveau qu’on pourrait bricoler en une semaine avec gptel-tool

[horace]

C’est donc utile quand on l’utilise comme un larbin !