Ce 10 août 2021, OpenAI ouvre une bêta privée qui pourrait changer notre rapport quotidien à la programmation. Le laboratoire dévoile une version améliorée de Codex, un modèle qui prend des instructions en anglais courant et rend du code qui fonctionne. Lors de la démonstration diffusée en direct, un cofondateur d'OpenAI construit un petit jeu à partir de phrases comme « fais rebondir la balle sur les bords de l'écran », sans jamais nommer une seule variable. Derrière la mise en scène, une réalité technique solide : Codex est déjà le moteur de GitHub Copilot, l'assistant de programmation lancé en préversion quelques semaines plus tôt. Ce qui se joue ici dépasse le gadget de démonstration. C'est une nouvelle manière de dialoguer avec une machine à écrire des programmes.
Cet article propose de comprendre ce qu'est réellement Codex, comment il fonctionne, ce qu'annoncent les chiffres publiés par OpenAI, et pourquoi cette étape compte pour l'avenir du développement logiciel. Nous partirons du modèle lui-même — un GPT réentraîné sur du code — pour aller vers ses résultats mesurés sur le jeu d'évaluation HumanEval, ses forces et ses limites reconnues, et les usages concrets qu'il rend possibles. L'objectif n'est pas de céder à l'enthousiasme, mais de lire posément une avancée technique dont on mesure encore mal la portée.
Un mot de méthode d'abord. Beaucoup de commentaires se concentrent sur la démonstration spectaculaire et sur l'idée, séduisante mais imprécise, que « l'IA écrit désormais le code à notre place ». La contribution de Codex est plus nuancée, et plus intéressante à examiner. Elle tient à un déplacement : de la génération de texte vers la génération de programmes exécutables, avec une méthode d'évaluation qui mesure non pas la ressemblance superficielle du code produit, mais sa correction fonctionnelle réelle. C'est ce point précis qui mérite qu'on s'y arrête.
Codex, un GPT entraîné à écrire du code
Pour saisir ce qu'est Codex, il faut partir de sa filiation. Le modèle descend directement de GPT-3, le grand modèle de langage qu'OpenAI a présenté à l'été 2020. GPT-3 avait déjà surpris par sa capacité à produire du texte cohérent, à traduire, à résumer, à répondre à des questions — le tout en apprenant simplement à prédire le mot suivant sur d'immenses volumes de texte. Certains observateurs avaient alors remarqué une capacité inattendue : GPT-3 savait produire un peu de code, alors qu'il n'avait pas été conçu pour cela. Cette étincelle a orienté la suite.
Codex est, pour le dire simplement, un GPT réentraîné en se concentrant sur le code. Là où GPT-3 avait été nourri principalement de texte en langage naturel, Codex a été entraîné sur une quantité massive de code source public collecté sur GitHub, en plus du texte. Le résultat est un modèle qui a conservé la compréhension du langage humain héritée de GPT-3, mais qui a acquis une maîtrise bien plus fine des langages de programmation. Cette double compétence est précisément ce qui lui permet de faire le pont entre une demande formulée en français ou en anglais et un fragment de code qui répond à cette demande.
Meilleur en Python, à l'aise dans une douzaine de langages
Codex est le plus compétent en Python, langage sur lequel une grande partie de l'évaluation d'OpenAI s'est concentrée. Mais le modèle ne s'y limite pas : il se débrouille dans plus d'une douzaine de langages, parmi lesquels JavaScript, Go, Perl, PHP, Ruby, Swift, TypeScript, ou encore les scripts Shell. Cette polyvalence n'est pas anecdotique. Elle reflète la diversité du code public sur lequel le modèle s'est formé, et elle élargit considérablement l'éventail des tâches auxquelles il peut s'attaquer.
Il faut toutefois nuancer d'emblée : la compétence n'est pas homogène d'un langage à l'autre. Le modèle est nettement plus solide sur les langages abondamment représentés dans son corpus d'entraînement, Python en tête. Sur un langage plus rare ou plus spécialisé, la qualité des suggestions décline. Cette dépendance à la fréquence des exemples est une caractéristique structurelle des modèles entraînés sur de grands corpus, et il est utile de la garder en tête avant de généraliser un enthousiasme observé sur un cas précis.
Un moteur, plusieurs produits
Il est important de distinguer le modèle du produit. Codex est le moteur ; les produits sont les applications qui l'utilisent. La bêta privée ouverte aujourd'hui donne accès à Codex via une API : les développeurs candidats décrivent leur projet, et l'équipe d'OpenAI examine les demandes pour un accès sans coût et progressif. Cette API doit permettre de bâtir des outils qui n'existaient pas encore — assistants, générateurs, interfaces en langage naturel pour des logiciels existants.
L'autre produit, déjà connu, c'est GitHub Copilot. Une version de production distincte de Codex alimente cet assistant. Autrement dit, quand un développeur voit Copilot compléter son code dans son éditeur, c'est un dérivé spécialisé de Codex qui travaille en coulisses. Cette architecture — un modèle de fond, des versions ajustées pour chaque usage — préfigure une manière de déployer l'IA qui deviendra courante.
« Nous pensons que cela offre une nouvelle façon d'interagir avec les logiciels existants », résume Wojciech Zaremba, qui pilote le projet Codex chez OpenAI.
HumanEval : mesurer la correction, pas la ressemblance
La partie la plus solide du travail d'OpenAI n'est pas la démonstration, aussi impressionnante soit-elle. C'est la manière dont l'équipe a choisi de mesurer les capacités de Codex. Cette rigueur méthodologique mérite qu'on s'y attarde, car elle change la façon dont on peut discuter des résultats.
Évaluer un modèle qui écrit du code pose un problème particulier. Comment juger la qualité d'un programme ? On pourrait comparer le code produit à une solution de référence, mot pour mot — mais deux programmes très différents dans leur texte peuvent résoudre exactement le même problème, et un programme qui ressemble beaucoup à la solution attendue peut néanmoins comporter un bogue qui le rend inutilisable. La ressemblance textuelle est donc un mauvais juge.
Un jeu de 164 problèmes, testés par exécution
OpenAI a choisi une autre voie, plus exigeante et plus honnête. L'équipe a publié un nouveau jeu d'évaluation baptisé HumanEval, composé de 164 problèmes de programmation originaux. Chaque problème est accompagné d'une consigne — une description de la fonction à écrire — et d'une série de tests unitaires, en moyenne 7,7 par problème. Le principe est simple : on demande au modèle de produire une fonction, puis on l'exécute réellement contre les tests. Si tous les tests passent, la solution est comptée comme correcte ; sinon, elle échoue. On ne mesure pas la ressemblance, mais la correction fonctionnelle.
Cette approche a un mérite considérable : elle est objective. Un test qui passe ou échoue ne prête pas à interprétation. Elle évite aussi le piège de récompenser un code élégant mais faux, ou de pénaliser un code inhabituel mais juste. En publiant HumanEval ouvertement, OpenAI offre par ailleurs à la communauté un étalon commun, réutilisable par d'autres équipes pour comparer leurs propres modèles. C'est une contribution qui dépasse le seul cas de Codex.
Les chiffres publiés
Que disent les résultats ? Sur HumanEval, en générant une seule solution par problème, Codex en résout 28,8 %. Ce chiffre, pris isolément, peut sembler modeste. Il prend tout son sens dans la comparaison :
- GPT-3, le modèle généraliste dont Codex est dérivé, résout 0 % des problèmes — il n'a tout simplement pas été entraîné à écrire du code fonctionnel ;
- GPT-J, un modèle ouvert de référence à l'époque, en résout 11,4 % ;
- Codex atteint donc 28,8 %, soit un net progrès sur ces points de comparaison.
L'écart avec GPT-3 illustre à lui seul l'apport de l'entraînement spécialisé sur le code. Le même socle, réorienté vers un corpus de programmes, passe de zéro à près de trois problèmes sur dix résolus du premier coup. C'est la démonstration concrète que la spécialisation compte, et qu'un modèle généraliste, aussi puissant soit-il, gagne beaucoup à être affiné pour une tâche précise.
À retenir. Le même socle de modèle passe de 0 % (GPT-3) à 28,8 % (Codex) sur HumanEval. Cette progression chiffre l'apport décisif de la spécialisation : réorienter un grand modèle de langage vers un domaine précis — ici le code — transforme radicalement ses capacités sur ce domaine.
L'effet du tirage répété
Un résultat, en particulier, a retenu l'attention des chercheurs. Si l'on autorise le modèle à proposer non pas une, mais plusieurs solutions — cent échantillons par problème — et qu'on retient le meilleur, le taux de réussite grimpe à 70,2 %. Autrement dit, pour beaucoup de problèmes que Codex échoue à résoudre du premier coup, une solution correcte existe bel et bien parmi ses tentatives ; il suffit de la trouver.
Ce constat est riche d'enseignements. Il suggère que le modèle « connaît » souvent la bonne réponse sans la produire systématiquement en premier. En pratique, cela ouvre une stratégie efficace : générer plusieurs candidats et sélectionner celui qui passe les tests. Dans un environnement réel, où l'on peut exécuter le code, ce tirage répété devient un levier puissant. C'est aussi une piste de recherche : comment aider le modèle à hiérarchiser ses propres propositions pour placer la bonne en tête ?
Codex résout 28,8 % des problèmes HumanEval avec une seule tentative, mais 70,2 % lorsqu'on lui accorde cent essais et qu'on retient le meilleur : le savoir est souvent présent, la difficulté est de le faire émerger du premier coup.
Un mot de prudence, néanmoins, car c'est le cœur d'une lecture honnête. Le chiffre de 70,2 % ne signifie pas que Codex résout sept problèmes sur dix « tout seul ». Il décrit une capacité conditionnée à une procédure — cent tirages et une sélection par exécution des tests. Confondre le taux avec une seule tentative et celui avec cent tentatives, c'est se tromper sur ce que le modèle sait faire de façon autonome. Cette distinction, discrète dans les gros titres, est essentielle pour évaluer objectivement l'outil.
À retenir. Les chiffres 28,8 % et 70,2 % ne décrivent pas la même chose. Le premier est ce que Codex fait seul, du premier coup. Le second suppose cent tentatives et une sélection par exécution des tests — une procédure lourde, pas une performance autonome. Confondre les deux, c'est se tromper sur ce que l'outil sait faire réellement.
Comment Codex traduit une phrase en programme
Reste une question intuitive : par quel mécanisme un modèle qui a « seulement » appris à prédire la suite d'un texte parvient-il à écrire du code juste ? La réponse tient à la nature même de l'entraînement et à ce qu'il permet d'apprendre implicitement.
Fondamentalement, Codex fait ce que faisait GPT-3 : il prédit la suite la plus probable d'une séquence. Mais parce qu'il a été entraîné sur d'énormes quantités de code réel, cette prédiction devient étonnamment pertinente pour la programmation. Face à un commentaire décrivant une fonction, le modèle a vu, durant son entraînement, d'innombrables exemples où un commentaire similaire précédait une implémentation. Il a intériorisé des régularités : les conventions de nommage, la structure des boucles, la manière d'appeler une bibliothèque courante, les motifs récurrents d'un algorithme. Générer du code revient, pour lui, à prolonger la consigne de la façon la plus vraisemblable au vu de tout ce qu'il a lu.
Du commentaire à la fonction
Concrètement, l'usage typique consiste à écrire une consigne — souvent sous forme de commentaire ou de nom de fonction explicite — puis à laisser Codex compléter. On peut lui demander « écrire une fonction qui télécharge des données depuis une API publique et les trie par date », et il proposera une implémentation plausible. Dans la démonstration d'aujourd'hui, c'est exactement ce mécanisme qui est mis en scène : chaque phrase en anglais devient une brique de programme, et l'assemblage progressif finit par produire un jeu jouable.
Greg Brockman, cofondateur d'OpenAI, a illustré l'intérêt par une remarque parlante à propos du code répétitif que tout développeur connaît :
« C'est la pire partie de la programmation. J'ai écrit ce genre de code sans doute une vingtaine de fois, et j'oublie toujours exactement comment il fonctionne », observe Greg Brockman à propos des tâches fastidieuses que Codex peut prendre en charge.
Cette citation cerne bien la promesse immédiate de l'outil. Il ne s'agit pas, dans l'état actuel, de confier à la machine la conception d'une architecture logicielle complète, mais de décharger le développeur des portions répétitives et mécaniques : le code d'assemblage, les appels d'API standard, les conversions de format, les boucles de traitement. Autant de tâches où l'humain apporte peu de valeur créative et perd du temps.
Ce que Codex ne comprend pas
Il faut être clair sur un point : Codex ne « comprend » pas un programme comme un ingénieur le comprend. Il ne raisonne pas sur la correction logique, ne vérifie pas ses propres sorties, n'a aucune garantie de produire un code sûr ou performant. Il propose ce qui est statistiquement plausible au vu de son entraînement. Cela suffit souvent à produire du code juste, mais explique aussi ses erreurs : le modèle peut inventer un appel de fonction qui n'existe pas, mal gérer un cas limite, ou produire une solution qui compile mais ne fait pas exactement ce qui était demandé. La supervision humaine reste indispensable.
Le rôle décisif des données d'entraînement
Un dernier élément mérite d'être souligné, car il éclaire à la fois les forces et les faiblesses du modèle : l'importance capitale du corpus d'entraînement. La compétence de Codex n'a rien de magique ; elle est le reflet direct du code public sur lequel il s'est formé. Là où ce corpus est riche — pensons aux motifs Python largement partagés sur les dépôts publics —, les suggestions sont pertinentes et variées. Là où il est pauvre — un langage de niche, une bibliothèque récente et peu documentée —, le modèle patine, faute d'avoir vu suffisamment d'exemples.
Cette dépendance a une conséquence pratique importante. Les régularités que Codex reproduit sont celles du code réel, avec ses bonnes pratiques mais aussi ses maladresses et ses habitudes discutables. Un modèle entraîné sur ce que le monde a écrit hérite autant des qualités que des travers de ce corpus. C'est une raison supplémentaire de relire ses suggestions avec un œil critique, et de ne pas confondre « fréquemment observé dans les dépôts publics » avec « recommandé ». Cette lucidité sur l'origine des compétences du modèle est le meilleur antidote à une confiance excessive.
Codex et GitHub Copilot : le premier grand déploiement
Si Codex retient l'attention aujourd'hui, c'est aussi parce qu'il ne reste pas confiné au laboratoire. Depuis fin juin 2021, une version de production du modèle alimente GitHub Copilot, un assistant de programmation développé en collaboration entre GitHub et OpenAI, disponible en préversion technique.
Copilot s'intègre directement dans l'éditeur de code. Pendant que le développeur écrit, l'assistant propose des complétions — parfois une ligne, parfois une fonction entière — qu'il suffit d'accepter ou d'ignorer. La préversion fonctionne particulièrement bien avec Python, JavaScript, TypeScript, Ruby et Go, tout en restant utilisable sur un ensemble plus large de langages et de cadres logiciels. L'expérience se veut fluide : le code suggéré apparaît dans le flux de travail habituel, sans rupture.
Une réception enthousiaste, à tempérer
Selon GitHub, des centaines de développeurs internes utilisaient déjà l'outil quotidiennement lors du lancement de la préversion, avec des réactions souvent très positives. Cet accueil s'explique : pour beaucoup de tâches courantes, voir une suggestion pertinente apparaître d'elle-même fait gagner un temps réel et réduit la charge mentale.
Il convient toutefois de rester mesuré. Un outil qui suggère du code impose une vigilance accrue : le développeur doit relire, comprendre et valider chaque proposition avant de l'intégrer. Une suggestion plausible n'est pas nécessairement correcte, ni adaptée au contexte précis du projet. Les questions de qualité, de sécurité et de licence du code suggéré font d'ailleurs l'objet de discussions légitimes dans la communauté. La bonne posture, à ce stade, est celle d'un assistant que l'on garde sous contrôle, et non d'un pilote automatique auquel on délègue aveuglément.
Forces et limites, sans complaisance
Toute avancée technique appelle une lecture équilibrée. Codex a des atouts remarquables, mais aussi des limites que les auteurs eux-mêmes documentent. Les présenter côte à côte est le meilleur moyen d'en apprécier la portée réelle.
Du côté des forces, l'essentiel tient en trois points. D'abord, la capacité à traduire une intention exprimée en langage naturel en code exécutable, ce qui abaisse la barrière d'entrée de nombreuses tâches. Ensuite, la polyvalence linguistique, avec une compétence répartie sur plus d'une douzaine de langages de programmation. Enfin, la démonstration méthodologique apportée par HumanEval, qui installe une manière rigoureuse de mesurer les progrès — un acquis qui bénéficiera à tout le domaine.
Les limites reconnues
Du côté des limites, plusieurs points appellent à la prudence :
- La fiabilité n'est pas garantie. Le taux de 28,8 % en une seule tentative rappelle que, sur des problèmes non triviaux, le modèle se trompe plus souvent qu'il ne réussit du premier coup. Il produit une aide, pas une certitude.
- La qualité dépend du langage et du domaine. Excellente en Python, la compétence diminue sur les langages ou les bibliothèques peu représentés dans les données d'entraînement.
- Le modèle peut se tromper avec assurance. Une suggestion peut sembler correcte tout en comportant une erreur subtile, ce qui exige une relecture attentive.
- Les questions de sécurité et de conformité restent ouvertes. Le code généré doit être vérifié avant tout usage en production, tant sur le plan fonctionnel que sur celui des dépendances et des licences.
Ces limites ne sont pas des défauts rédhibitoires ; elles définissent le bon périmètre d'usage. Codex, à l'été 2021, est un assistant puissant pour accélérer le travail d'un développeur compétent, capable de juger et de corriger ses suggestions. Il n'est pas un substitut à l'expertise humaine, et rien dans les résultats publiés ne prétend le contraire. Cette honnêteté sur les limites est, en soi, un signe de maturité dans la manière dont l'outil est présenté.
À retenir. Le bon périmètre de Codex à l'été 2021 : assister un développeur compétent sur le code répétitif, en lui laissant la relecture et la décision finale. Architecture, sécurité, conformité — tout cela reste humain. L'outil accélère ; il ne remplace pas.
Pourquoi cette étape compte
Prenons de la hauteur. Au-delà des chiffres et de la démonstration, pourquoi l'arrivée de Codex marque-t-elle un jalon ? La réponse tient à ce qu'elle rend possible et à la tendance qu'elle amorce.
D'abord, Codex déplace la frontière de l'interface entre l'humain et la machine. Pendant des décennies, programmer un ordinateur a exigé d'apprendre un langage formel, précis et exigeant. Codex esquisse une autre voie, où l'on décrit son intention en langage courant et où le modèle propose une traduction en code. Cette bascule ne supprime pas le besoin de comprendre la programmation, mais elle en abaisse le seuil pour certaines tâches, et elle accélère le travail de ceux qui maîtrisent déjà le métier. Pour les non-spécialistes, elle entrouvre la porte de l'automatisation de petites tâches jusque-là hors de portée.
Un usage nouveau des modèles de langage
Ensuite, Codex illustre une idée qui va structurer les années à venir : un grand modèle de langage n'est pas cantonné au texte. En le spécialisant sur un domaine — ici le code — on obtient un outil taillé pour une tâche précise, bien plus performant que le modèle généraliste dont il dérive. Le passage de 0 % à 28,8 % sur HumanEval entre GPT-3 et Codex est la preuve chiffrée de cette logique. On peut raisonnablement anticiper que la même recette s'appliquera à d'autres domaines spécialisés.
Enfin, la mise à disposition via une API en bêta ouvre un espace d'expérimentation. En laissant des développeurs extérieurs bâtir leurs propres outils sur Codex, OpenAI transforme un modèle de recherche en une plateforme. Les usages qui émergeront dépasseront sans doute ce que ses concepteurs ont imaginé — c'est la promesse, et l'intérêt, d'une diffusion ouverte, même prudente et progressive.
« Programmer, c'est avoir une vision et la découper en morceaux, puis écrire le code de chacune de ces pièces », rappelle Greg Brockman : Codex prend en charge une partie de la seconde étape, sans dispenser de la première.
Ce que cela change, concrètement, pour un développeur
Redescendons sur le terrain. Pour un praticien qui découvre Codex aujourd'hui, quelles sont les implications concrètes ? Trois pistes se dégagent, à explorer sans précipitation.
La première concerne le code répétitif. Les portions mécaniques — appels d'API standard, conversions de format, structures de données courantes, tests unitaires simples — sont précisément là où Codex excelle et où le développeur perd le plus de temps. Déléguer ces tâches, tout en relisant les suggestions, peut libérer de l'énergie pour les parties réellement créatives d'un projet.
La deuxième touche à l'apprentissage et l'exploration. Face à une bibliothèque inconnue ou à un langage peu familier, un assistant capable de proposer un exemple fonctionnel peut accélérer la prise en main. À condition, là encore, de vérifier et de comprendre le code proposé plutôt que de le recopier mécaniquement — sans quoi l'on troque une dépendance à la documentation contre une dépendance à l'outil.
La troisième invite à expérimenter avec méthode. La stratégie du tirage répété, validée par le taux de 70,2 % sur HumanEval, suggère qu'il est souvent payant de générer plusieurs propositions et de sélectionner celle qui passe les tests. Dans un flux de travail où l'on exécute son code, cette approche transforme un modèle imparfait en un assistant efficace. La bonne démarche consiste à intégrer Codex comme un outil parmi d'autres, avec ses forces et ses angles morts, plutôt que comme un oracle.
La question utile n'est pas « l'IA va-t-elle remplacer les développeurs ? » mais « quelles tâches puis-je lui confier en gardant le contrôle ? » — et la réponse, à l'été 2021, est déjà substantielle sur le code répétitif.
Un jalon, pas un aboutissement
Que retenir de cette étape ? D'abord, que Codex est une avancée réelle et mesurée. En réentraînant GPT-3 sur du code, OpenAI obtient un modèle qui traduit le langage naturel en programmes exécutables avec une efficacité inédite pour un outil grand public. Le passage de 0 % à 28,8 % sur HumanEval, face à un modèle généraliste, chiffre concrètement l'apport de la spécialisation.
Ensuite, que la rigueur de l'évaluation vaut autant que le modèle lui-même. En mesurant la correction fonctionnelle plutôt que la ressemblance textuelle, et en publiant HumanEval ouvertement, OpenAI pose un cadre honnête pour discuter des progrès à venir. C'est un acquis méthodologique qui servira bien au-delà de Codex.
Enfin, que la lecture nuancée l'emporte sur le slogan. Codex n'écrit pas le code à notre place ; il assiste un développeur qui reste aux commandes, relit, corrige et décide. Ses limites — fiabilité variable, dépendance au langage, nécessité de vérification — définissent un périmètre d'usage clair plutôt qu'elles ne disqualifient l'outil. Comprendre cette distinction, c'est se donner les moyens d'évaluer sereinement une technologie qui, à l'évidence, ne fait que commencer son parcours.
Pour un praticien, la bonne posture n'est ni l'emballement ni le rejet, mais la curiosité informée. Codex ouvre une voie où l'intention exprimée en langage courant se traduit en code fonctionnel. Ce que cette voie deviendra dépendra des usages qu'en feront les développeurs, des outils qu'ils bâtiront sur l'API, et des progrès que la méthode d'évaluation permettra de mesurer. À l'été 2021, une chose est sûre : la manière dont nous écrivons des programmes vient de gagner un nouvel interlocuteur.
Avec le recul
(depuis 2026) La bêta de 2021 fut le point de départ d'une lignée d'outils de programmation assistée par IA qui se sont largement diffusés dans les années suivantes. HumanEval, publié à cette occasion, est resté un étalon de référence pour comparer les modèles de code, même si des jeux d'évaluation plus exigeants l'ont depuis complété. Rétrospectivement, l'apport durable de Codex tient moins à ses scores — vite dépassés — qu'à deux idées installées ce jour-là : spécialiser un grand modèle de langage sur le code, et mesurer sa valeur par l'exécution réelle plutôt que par la ressemblance. Ces deux principes structurent encore la discipline.
Testez votre compréhension
Quatre affirmations tirées de l'article — saurez-vous distinguer le vrai du faux ?
1. HumanEval juge le code de Codex en comparant son texte à une solution de référence.
2. En une seule tentative, Codex résout environ trois problèmes HumanEval sur dix.
3. Le score de 70,2 % signifie que Codex résout sept problèmes sur dix de façon pleinement autonome.
4. Le code produit par Codex doit systématiquement être relu et vérifié avant intégration.
Sources
Cet article s'appuie sur des sources publiques et vérifiables :
- Mark Chen et al., « Evaluating Large Language Models Trained on Code » (arXiv, soumis le 7 juillet 2021) — arXiv 2107.03374 (jeu HumanEval, taux 28,8 % / 70,2 %, comparaison GPT-3 et GPT-J).
- OpenAI / GitHub, code et jeu de données HumanEval — github.com/openai/human-eval (164 problèmes, tests unitaires).
- TechCrunch, « OpenAI upgrades its natural language AI coder Codex and kicks off private beta » (10 août 2021) — techcrunch.com (annonce, bêta privée, démonstration, citations).
- The Register, « OpenAI's GPT-3-based pair programming model – Codex – now open for private beta testers through an API » (16 août 2021) — theregister.com (API, langages supportés, lien avec GPT-3).
- The GitHub Blog, « Introducing GitHub Copilot: your AI pair programmer » (29 juin 2021) — github.blog (Copilot en préversion, propulsé par Codex, langages, réception).