OpenAI Codex a conçu un jeu DOS complet de style Asteroids en assembleur x86 16 bits, fournissant 18 fichiers sources et environ 2 500 lignes de code sans une seule ligne d'assembleur écrite par un humain. L'expérience montre qu'une IA peut piloter un cycle de vie logiciel complet — de la planification au débogage — sans intervention directe d'un programmeur, allant au-delà des habituelles démonstrations de « complétion de code ».

Pourquoi ce test était important

La plupart des démonstrations publiques de codage par IA s'arrêtent à de courts extraits ou à de simples utilitaires. Pour tester les limites supérieures, l'expérience a contraint Codex à l'environnement le plus restreint imaginable : l'assembleur x86 16 bits sur DOS, sans moteur de jeu, sans bibliothèque graphique, ni le confort des langages de haut niveau. L'objectif était de voir si une IA pouvait non seulement générer du code, mais aussi gérer les tâches d'ingénierie environnantes.

Comment les rôles ont été répartis

Les responsabilités humaines se sont limitées à trois actions :

  • Définir l'objectif global du projet (un jeu de tir de style Asteroids).
  • Répondre à toute question relative au gameplay.
  • Tester chaque version et signaler les bugs observés.

Les responsabilités de Codex couvraient tout le reste :

  • Rédiger un plan de projet et une architecture.
  • Écrire les fichiers sources en assembleur.
  • Déboguer, refactoriser et restructurer le code.
  • Maintenir le dépôt Git, y compris les commits et la gestion des branches.
  • Compiler le binaire et l'exécuter dans un émulateur DOS.

L'humain n'a jamais tapé une seule instruction en assembleur, n'a jamais invoqué de compilateur et n'a jamais lancé le jeu pendant le développement. L'interaction s'est limitée à la description des symptômes des bugs ; l'IA a localisé et corrigé la cause profonde par elle-même.

Le flux de travail itératif

Chaque cycle commençait par une proposition de jalon de la part de Codex (par exemple, « implémenter le mouvement du vaisseau du joueur »). Elle produisait ensuite les fichiers sources correspondants, les commitait, compilait l'exécutable et remettait la version exécutable au testeur. Codex analysait le symptôme, le traçait à travers la base de code et émettait un correctif sans autre guidage humain.

Ce que contient le produit final

  • 18 fichiers sources en assembleur, organisés selon une structure de dépôt conventionnelle.
  • ≈2 500 lignes d'assembleur, couvrant la gestion des entrées, le dessin de sprites, la détection de collisions et un système de score élevé.
  • Un exécutable DOS jouable qui fonctionne dans un environnement DOS standard et imite le gameplay classique d'Asteroids.
  • Zéro ligne d'assembleur écrite par l'humain, confirmant que l'IA a géré toutes les tâches de programmation de bas niveau.

Enjeux et implications

Si une IA peut piloter de manière autonome un projet, de sa conception à un binaire fonctionnel, le rôle traditionnel du programmeur en tant qu'orchestrateur principal d'une base de code change. Les entreprises pourraient réduire le temps passé sur la configuration de base (boilerplate), la documentation et le débogage de routine, libérant ainsi les ingénieurs pour qu'ils se concentrent sur la conception et la stratégie produit.

L'expérience met également en lumière des limites. L'environnement de test était délibérément restreint : un jeu DOS solo avec des mécaniques bien comprises. L'extension de cette approche à de grands systèmes multi-modules avec des dépendances externes, des contraintes de sécurité ou des chemins de code critiques pour les performances reste à prouver. De plus, le testeur humain a toujours agi comme le dernier rempart de qualité ; une erreur logique non détectée aurait pu passer entre les mailles du filet sans cette surveillance.

Contre-arguments et questions ouvertes

  • Fiabilité : La programmation en assembleur est impitoyable ; une seule erreur de décalage (off-by-one) peut faire planter tout le programme. Codex a corrigé les bugs qu'il a vus, mais il pourrait manquer des problèmes de synchronisation subtils qui n'apparaissent que lors de tests de charge.
  • Maintenabilité : Le code généré sans directives de style humain peut être plus difficile à lire ou à étendre pour les futurs développeurs, surtout si les conventions de nommage de l'IA diffèrent des standards de l'équipe.
  • Propriété intellectuelle : À qui appartient le code lorsqu'une IA l'écrit ? Les cadres de licence actuels supposent une paternité humaine, laissant une zone grise pour les artefacts produits par l'IA.

À surveiller ensuite

  • Benchmarks plus larges : Appliquer le même flux de travail autonome à des applications réseau, des applications mobiles ou des projets C/C++ modernes permettra de tester si l'approche peut s'étendre au-delà des jeux de style rétro.
  • Intégration d'outils : L'intégration de Codex dans les pipelines CI/CD pourrait automatiser non seulement la génération de code, mais aussi les tests, l'analyse de sécurité et le déploiement.
  • Évolution des politiques : À mesure que le code généré par l'IA prolifère, les politiques juridiques et d'entreprise devront aborder les questions de propriété, de responsabilité et de conformité.

Le constat est clair : l'IA peut désormais agir comme un ingénieur logiciel unique pour des projets bien définis et délimités, fournissant un code fonctionnel de bas niveau sans codage manuel humain. La question de savoir si cette capacité transformera le développement conventionnel dépend de la rapidité avec laquelle l'écosystème pourra répondre aux enjeux de fiabilité, de maintenabilité et aux préoccupations juridiques.