Note de la rédaction : Cet article est de Dominik Kundel, membre des relations développeurs chez OpenAI, qui résume son expérience d'utilisation de la fonction « goal mode » ou /goal de Codex. Il ne s'agit pas d'une simple astuce de prompt, mais d'un changement de rôle en cours dans les outils de programmation IA : Codex n'est plus seulement un assistant de code répondant à des instructions ponctuelles, mais commence à devenir un Agent exécutif capable de progresser continuellement autour d'un objectif clair.
En mode /goal, ce qui compte vraiment n'est pas d'écrire une demande de plus en plus longue et détaillée, mais de fixer à Codex des critères de sortie clairs et vérifiables. Par exemple, « réduire le temps de déploiement de 30 % », « atteindre une couverture de test de 100 % en parité » ou « ramener le LCP sous 2,5 secondes ». Ces indicateurs permettent à Codex de juger si la tâche est accomplie et l'empêchent de tâtonner indéfiniment sur des objectifs flous. Parallèlement, l'utilisateur doit fournir suffisamment d'orientation, d'outils et d'environnement réel pour que Codex puisse mesurer les progrès et vérifier les résultats, au lieu de produire une solution simplement plausible dans des conditions locales ou hypothétiques.
L'article souligne particulièrement que les tâches visuelles sont les plus susceptibles de faire sombrer Codex dans les détails. Plutôt que d'exiger une « reproduction exacte au pixel près à 100 % », il vaut mieux décomposer l'objectif visuel en une liste de fonctionnalités, des spécifications de système de design et des indicateurs évaluables. Pour les tâches longues, s'étalant sur plusieurs heures voire jours, il est également nécessaire d'assurer un suivi continu via des commits, des PR brouillons, des documents de progression, des mises à jour Slack ou des discussions parallèles (side chat), afin d'éviter de se retrouver au final avec un tas de modifications impossibles à retracer.
L'apport informatif de cet article réside dans sa redéfinition de /goal comme un « mécanisme de gestion de tâches de longue durée ». Lorsque l'IA peut exécuter des tâches en continu pendant des dizaines, voire des centaines d'heures, les compétences centrales du développeur évoluent également : il ne s'agit plus seulement de faire générer du code par l'IA, mais de lui définir des objectifs, d'établir un système de mesure, de configurer son environnement d'exécution, et enfin d'effectuer une revue et une rétrospective. En d'autres termes, la programmation IA passe de « l'écriture de prompts » à « la gestion d'un exécutant d'ingénierie travaillant en continu ».
Voici l'article original :
Nous avons lancé le mode objectif (goal mode, ou /goal) pour vous aider à faire progresser Codex continuellement vers un résultat spécifique. Lorsque vous définissez un objectif, Codex continuera à travailler jusqu'à ce qu'il soit atteint — que cela prenne quelques heures ou quelques jours. Certaines personnes ont déjà laissé Codex travailler plus de 120 heures d'affilée pour le même objectif.
Le mode objectif est très puissant. Pour en tirer le maximum, voici 7 points à garder à l'esprit lors de l'utilisation de /goal.
Définir des critères clairs et vérifiables
Le prompt que vous saisissez lors de l'activation du mode objectif sert à la fois de prompt initial et, plus important encore, de critère de sortie pour cet objectif. Après chaque cycle de travail, Codex vérifiera : cet objectif est-il déjà atteint ?
Par conséquent, votre prompt d'objectif ne doit pas être trop long, mais se concentrer sur un critère clair : dans quelles circonstances peut-on considérer que l'objectif est atteint ?
Dans la plupart des cas, un bon objectif inclut idéalement une mesure numérique explicite que le modèle peut utiliser pour juger de son achèvement. Par exemple :
« Réduire le temps de construction et de déploiement de 30 %. »
« Migrer cette fonctionnalité de TypeScript vers Rust, et atteindre une cohérence de test à 100 %. »
« Optimiser l'échafaudage de l'application pour que le LCP (Largest Contentful Paint, mesure de la vitesse de chargement du contenu principal de la page) en production soit inférieur à 2,5 secondes. »
Ce prompt ne doit pas toujours contenir un chiffre, mais en général, les chiffres facilitent les étapes suivantes.
Si vous n'êtes pas encore sûr de la façon de définir l'objectif, ou si vous souhaitez d'abord brainstormer ce projet avec Codex, vous n'êtes pas obligé de démarrer la conversation directement en mode objectif.
Codex peut définir lui-même un objectif. Vous pouvez commencer une conversation normale, puis, lorsque vous êtes prêt à ce que Codex commence à exécuter, lui demander de définir un objectif basé sur la discussion précédente.
Vous pouvez également éditer l'objectif à tout moment : en cliquant sur le bouton d'édition dans l'application Codex, ou en utilisant à nouveau /goal dans la CLI.
Fournir des orientations autant que possible
Un prompt comme « Réduire le temps de construction et de déploiement de 30 % » semble cool et pourrait amener Codex à trouver des solutions créatives. Mais si vous avez déjà une idée générale de l'origine possible du problème, ce type de prompt pourrait aussi l'envoyer dans la mauvaise direction.
Donc, dans la mesure du possible, il est préférable de dire à Codex par où commencer l'investigation, quels outils il peut utiliser pour atteindre l'objectif, ou de lui donner d'autres indices pour éviter qu'il ne s'égare.
Par exemple, mon collègue @reach_vb a fait cela lors d'une expérience : il a dit à Codex qu'il pouvait utiliser Chrome pour accéder à Google Colab, et a spécifié certaines contraintes acceptables, comme le fait de laisser Codex générer lui-même le jeu de données lorsqu'il entraînait un modèle.
De même, si vous souhaitez réduire le temps de construction et que vous savez déjà quelle partie consomme la majeure partie du temps, il vaut mieux orienter d'abord Codex vers cette zone dans le prompt.
Une autre approche consiste à laisser d'abord Codex faire des recherches préliminaires en mode plan (plan mode) et lui demander de créer un fichier de plan pour enregistrer les solutions potentielles. Ensuite, vous pouvez faire référence à ce plan dans votre objectif.
Rendre les progrès mesurables
Si votre objectif est ambitieux, ou si Codex a plusieurs façons de s'en approcher progressivement, il est crucial de lui fournir les outils pour mesurer ses progrès.
Pour certaines tâches, cela peut être naturel. Par exemple, optimiser le temps de construction ou améliorer la couverture de test, car Codex peut généralement déjà utiliser les outils pertinents, ou les créera naturellement.
Mais pour d'autres objectifs, il est préférable de brainstormer d'abord avec Codex : quels outils pourraient aider à juger des progrès ? Ou lui donner des indices sur la façon de confirmer qu'il se rapproche de l'objectif. Par exemple, créer un outil de comparaison visuelle (diff) pour deux captures d'écran, ou créer un jeu d'évaluation pour l'agent intelligent que vous déboguez.
J'ai une fois demandé à Codex de recréer des composants à partir d'une vidéo ; il s'est alors créé un outil pour comparer des captures d'écran et vérifier les différences. Plus tard, il a itéré sur cet outil en ajoutant différents modes de comparaison.
Selon la tâche, vous devez également réfléchir à la nécessité de mesurer ou vérifier des critères supplémentaires. Sinon, Codex pourrait penser que la tâche est terminée, alors qu'à vos yeux, elle ne l'est pas encore.
Par exemple, Codex pourrait, pour « reproduire pixel par pixel » une interface utilisateur, simplement recadrer l'image de référence et l'intégrer dans la page ; ou pour atteindre un taux de réussite de test de 100 %, réduire la portée des tests. Ce ne sont pas les façons dont vous souhaitez réellement voir la tâche achevée.
Créer un environnement réaliste
Si vous voulez que Codex progresse véritablement et efficacement vers l'objectif, il a besoin d'être exécuté dans un environnement suffisamment réaliste.
En pratique, cela signifie : si vous voulez optimiser le temps de déploiement ou la latence, Codex doit avoir accès à des environnements de déploiement et de test qui reproduisent autant que possible l'environnement de production. C'est-à-dire utiliser la même pile technologique, les mêmes configurations, et une base de données similaire.
Par exemple, nous avons un jour débogué l'optimisation du temps de construction et de déploiement de developers.openai.com. Nous utilisions déjà des prévisualisations de déploiement, donc Codex pouvait les utiliser pour déployer et consulter les logs. Mais le problème était que nos déploiements de prévisualisation, comparés à l'environnement de production complet, désactivaient certains chemins de construction.
Par conséquent, Codex a finalement dû effectuer des déploiements manuels, en mettant le code dans un environnement plus proche de la configuration de production, pour véritablement identifier le problème.
De manière similaire, vous pouvez également permettre à Codex d'utiliser l'« utilisation d'ordinateur » (computer use - capacité du modèle à interagir avec des interfaces d'application réelles) pour tester l'application en conditions réelles. Pour optimiser certains problèmes de performance sur iOS, @dimillian a même utilisé un appareil physique pour obtenir l'environnement de test le plus précis possible.
Définir les objectifs visuels avec prudence
Donner à Codex un objectif visuel, comme « reproduire cette interface utilisateur à 100 % pixel par pixel selon cette image », est certes tentant. Mais selon la configuration, cela peut aussi poser problème.
Si vous ne fournissez pas des orientations et des contraintes appropriées, Codex pourrait s'enliser dans des détails et négliger l'objectif global. Par exemple, si l'image de référence contient des éléments graphiques et que vous attendez de Codex qu'il les génère — que ce soit des icônes SVG ou des images — il pourrait passer beaucoup de temps sur « comment reproduire précisément ces éléments » plutôt que de décomposer correctement l'ensemble du problème.
De plus, Codex a besoin d'outils pour effectuer correctement des comparaisons visuelles. Cela signifie plus d'entrées d'images, une consommation globale de tokens plus élevée, sans nécessairement offrir à Codex un moyen simple d'identifier les opportunités d'amélioration réellement pertinentes.
Ainsi, les images sont généralement plus adaptées comme contexte pour un objectif, plutôt que comme seul critère d'achèvement. Vous devriez chercher d'autres moyens pour permettre à Codex de juger si l'objectif est atteint, comme une liste de fonctionnalités, des spécifications d'implémentation, la conformité à un système de design, etc.
Suivre les progrès
Si Codex travaille en arrière-plan pendant des heures, voire des jours, ou même s'il s'exécute sur une autre machine, il est facile d'oublier où il en est exactement et ce qu'il a déjà accompli.
En fonction des objectifs, j'ai trouvé les méthodes suivantes utiles :
· Faire committer le code par Codex à des étapes clés, et le pousser vers une Pull Request brouillon. C'est particulièrement utile lorsque vous travaillez sur un site web et que vous avez des prévisualisations de déploiement.
· Faire mettre à jour par Codex un livrable pour la direction. Cela peut être un fichier HTML que vous gardez ouvert dans le navigateur intégré à l'application ; cela peut être une page déployée via Sites pour que l'équipe la consulte ; cela peut être un graphique de progression rendu, ou simplement un fichier Markdown ordinaire.
Indiquer à Codex de publier activement des mises à jour de progression. Vous pouvez également l'inclure dans l'objectif : demander à Codex d'envoyer des mises à jour sur un canal Slack, ou ailleurs où vous souhaitez enregistrer les avancées, lorsqu'il réalise des progrès significatifs.
Utiliser d'autres fenêtres de chat pour demander l'état. Si vous voulez simplement un aperçu rapide de la situation actuelle, vous pouvez exécuter /side pour démarrer un nouveau chat latéral (side chat) et y poser votre question. Comme il bifurquera à partir du thread actuel, il aura tout le contexte jusqu'à présent, mais sa durée de vie sera courte.
Une autre alternative dans l'application Codex est : ouvrir une nouvelle conversation normale, demander à Codex de lire le thread d'un autre objectif, et répondre à vos questions. Cela devient particulièrement puissant si vous demandez à Codex de configurer une tâche automatisée pour vérifier régulièrement les progrès.
Nettoyer et finaliser les résultats
Super, l'objectif est enfin atteint ! Est-ce qu'on peut maintenant simplement balancer le résultat à l'équipe et arrêter là ?
Généralement, en particulier dans les tâches d'optimisation, je trouve utile de laisser Codex revoir et examiner le travail qu'il a accompli. Vous pouvez d'abord exécuter une revue de code locale avec /review, mais il vaut aussi la peine de laisser Codex réfléchir plus en profondeur : Quelles approches a-t-il tentées pour atteindre l'objectif ? Lesquelles ont fonctionné ? Lesquelles n'ont pas fonctionné ? Puis nettoyer le code en conséquence.
Parce que Codex continue à travailler jusqu'à atteindre l'objectif, il a peut-être essayé des méthodes qui n'étaient pas assez efficaces, voire totalement inefficaces, et ces modifications résiduelles pourraient subsister dans le code final.
Définissez aussi un goal pour votre prochaine tâche
La fonction objectif de Codex est un outil extrêmement puissant qui peut vous aider à résoudre certains des défis d'ingénierie les plus significatifs. Mais ce n'est que lorsque vous fournissez le bon environnement et les bonnes instructions qu'il peut atteindre son but plus efficacement.
Qu'avez-vous fait avec /goal ?










