Comment OpenAI a créé 1 million de lignes de code uniquement avec des agents : les 5 principes du Harness Engineering

Le mot « harness » revient de plus en plus souvent ces derniers temps. Un article de blog publié par OpenAI a enfin donné à ce concept une définition claire. Voici ce que les ingénieurs doivent réellement faire à l’ère des agents.

Un harness est l’enveloppe d’outils qui permet à un agent IA d’agir sur le monde réel. Si le modèle de raisonnement est le cerveau, le harness est les mains et les pieds. Lire des fichiers, corriger du code, lancer des tests, déployer en production, tout cela se passe à l’intérieur du harness.

Une équipe interne d’OpenAI a démarré à partir d’un dépôt vide fin août 2025 et a construit un produit d’un million de lignes en utilisant uniquement des agents Codex. La condition : aucun code écrit par un humain. Le temps nécessaire a été divisé par dix par rapport au développement manuel. Les cinq principes découverts au cours de ce processus sont détaillés ci-dessous.

Ce que l’agent ne peut pas voir n’existe pas

Du point de vue de Codex, toute information inaccessible à l’exécution est comme si elle n’existait pas. Les documents de spécification dans Google Docs, les décisions d’architecture validées sur Slack, les connaissances tacites enfermées dans la tête de quelqu’un, rien de tout cela n’est visible. C’est exactement la situation d’une nouvelle recrue qui arriverait dans trois mois.

L’équipe a donc transféré chaque décision dans le dépôt sous forme de fichiers markdown, de schémas et de plans d’exécution (ExecPlans).

• ExecPlan est un document de conception autonome défini dans PLANS.md
• Le critère de validation : un débutant doit pouvoir le lire et implémenter la fonctionnalité de bout en bout
• Il existe des cas où Codex a travaillé en continu pendant plus de 7 heures sur un seul prompt
• La structure étend le concept ARCHITECTURE.md de matklad à l’utilisation par des agents

Demandez « quelle capacité manque » au lieu de « fais plus d’efforts »

Au début, la vélocité des agents était inférieure aux attentes. La cause n’était pas la performance du modèle, mais un environnement insuffisamment équipé. À chaque échec, l’équipe se demandait : « Quelle capacité manque et comment la rendre lisible et vérifiable par l’agent ? »

• Des helpers de concurrence développés en interne plutôt que des bibliothèques externes, avec une intégration à 100 % avec OpenTelemetry
• Les « technologies ennuyeuses » souvent évoquées dans l’industrie s’avèrent favorables aux agents (stabilité des API et forte représentation dans les données d’entraînement)

L’application mécanique, pas la documentation, maintient la cohérence du code

La documentation seule ne suffisait pas à maintenir la cohérence de la base de code générée par les agents. L’équipe a donc choisi d’appliquer mécaniquement des règles invariantes plutôt que de prescrire les détails d’implémentation. Le parsing aux frontières de données était obligatoire, mais le choix de la bibliothèque était laissé à l’agent. L’architecture a été figée en une structure de domaines en couches, avec des directions de dépendance vérifiées par des linters.

• Couches fixes par domaine métier : Providers → Service → Runtime → UI
• Structure de préoccupations transversales où Types, Config et Repo sont partagés aux niveaux inférieurs
• Des linters personnalisés et des tests structurels font échouer le build immédiatement en cas de violation
• Les linters eux-mêmes ont été écrits par Codex

Donnez des yeux à l’agent et il travaille seul pendant 6 heures

L’équipe a connecté le Chrome DevTools Protocol au runtime de l’agent, donnant à Codex l’accès aux snapshots DOM, aux captures d’écran et à la navigation. La structure compare les snapshots avant et après la tâche, observe les événements à l’exécution, puis applique des corrections en boucle jusqu’à ce que tout soit propre.

Les outils d’observabilité ont été branchés de la même manière. Une pile d’observabilité temporaire se lance par git worktree et disparaît une fois le travail terminé.

• Victoria Logs (LogQL) et Victoria Metrics (PromQL) permettent à l’agent de requêter directement les logs et les métriques
• Des prompts comme « faire démarrer le service en moins de 800 ms » deviennent exécutables
• Des exécutions Codex uniques maintiennent régulièrement leur concentration sur une seule tâche pendant plus de 6 heures

Donnez une carte, pas un manuel de 1 000 pages

La gestion du contexte détermine l’efficacité de l’agent. Au départ, l’équipe a tenté de tout regrouper dans un seul fichier AGENTS.md massif, sans succès. Le concept d’ARCHITECTURE.md écrit par matklad en 2021 a fait ses preuves ici. Le principe : offrir une vue d’ensemble concise de la structure du projet, en n’incluant que ce qui change rarement. Le même principe s’applique aux agents.

• ARCHITECTURE.md est une carte du code, pas un atlas du code
• Les invariants architecturaux s’expriment souvent sous la forme « quelque chose n’existe pas »
• Énoncer explicitement les frontières contraint toute l’implémentation en aval

Questions encore ouvertes

Même pour l’équipe Codex, certaines questions restent sans réponse. Personne ne sait si un système entièrement construit par des agents peut maintenir sa cohérence architecturale sur plusieurs années. Comment ce cadre lui-même évoluera à mesure que les modèles progressent reste également incertain.

Une chose est claire : l’ère où il fallait bien écrire du code touche à sa fin, et l’ère où il faut bien concevoir les environnements a commencé.