Titre original : Un guide pour /goal
Auteur original : @dkundel, membre des relations développeurs d'OpenAI
Traduction : Peggy

Note de l'éditeur : Cet article, rédigé par Dominik Kundel, membre des relations développeurs d'OpenAI, résume son expérience d'utilisation de la fonction Codex « goal mode / /goal ». Il ne s'agit pas d'une technique de prompt ordinaire, mais d'une évolution du rôle de l'outil d'IA de programmation : Codex ne se limite plus à répondre à des instructions ponctuelles, mais devient un agent exécuteur capable de progresser en continu autour d'objectifs précis.

En mode /goal, l'important n'est pas d'écrire des demandes de plus en plus détaillées, mais de définir pour Codex des critères de sortie clairs et vérifiables. Par exemple : « réduire le temps de déploiement de 30 % », « atteindre 100 % de couverture de tests », « faire descendre le LCP en dessous de 2,5 secondes ». Ces indicateurs permettent à Codex de juger si la tâche est terminée, évitant qu'il ne s'engage dans une boucle d'essais infructueux dans un objectif flou. Par ailleurs, l'utilisateur doit fournir suffisamment d'orientations, d'outils et un environnement réel pour que Codex puisse mesurer ses progrès, valider ses résultats, plutôt que de se limiter à une solution théorique ou locale.

L'article rappelle aussi que les tâches visuelles sont particulièrement susceptibles de faire perdre Codex dans les détails. Plutôt que de demander « une restitution pixel-perfect à 100 % », il vaut mieux décomposer l'objectif visuel en une liste de fonctionnalités, en un système de design, ou en des indicateurs d’évaluation. Pour des tâches longues, s'étendant sur plusieurs heures ou jours, il faut aussi suivre l'avancement via des commits, des PR brouillons, des documents de progression, des mises à jour Slack ou des discussions annexes, afin d'éviter d'obtenir à la fin une série de modifications non traçables.

Ce qui distingue cet article, c'est qu'il redéfinit /goal comme un « mécanisme de gestion de tâches à long terme ». Lorsqu'une IA peut s'exécuter pendant des dizaines ou centaines d'heures, la compétence centrale du développeur évolue : 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 mesures, de configurer l'environnement d'exécution, et enfin de faire une revue et une rétrospective. En somme, la programmation IA passe de « donner des prompts » à « gérer un agent d'exécution continue ».

Voici le texte original :

Nous avons lancé le mode objectif (goal mode, ou /goal), pour vous aider à faire avancer Codex vers un résultat concret en continu. Une fois que vous avez défini un objectif, Codex travaille sans interruption jusqu'à ce qu'il soit atteint — que cela prenne quelques heures ou plusieurs jours. Certains ont déjà fait travailler Codex plus de 120 heures d'affilée sur un même objectif.

Le mode objectif est très puissant. Pour en tirer le meilleur parti, voici 7 points importants à considérer lors de l'utilisation de /goal.

Définir des critères clairs et vérifiables

Lorsque vous activez le mode objectif, le prompt que vous saisissez peut servir d'amorce, mais surtout, il devient le critère de sortie de l'objectif. Codex vérifiera après chaque étape : l'objectif est-il atteint ?

Ainsi, votre prompt d'objectif ne doit pas être trop long, mais doit se concentrer sur un standard clair : dans quelles conditions l'objectif est-il considéré comme réalisé ?

Dans la majorité des cas, un bon objectif inclut un indicateur numérique précis, permettant au modèle de juger s'il a réussi. Par exemple :

« Réduire le temps de construction et de déploiement de 30 %. »

« Migrer cette fonctionnalité de TypeScript vers Rust, avec 100 % de tests en accord. »

« Optimiser le scaffolding de l'application pour que le Largest Contentful Paint (LCP) en production soit inférieur à 2,5 secondes. »

Ce prompt n'a pas toujours besoin d'inclure un chiffre, mais en général, un chiffre facilite la progression des étapes suivantes.

Si vous n'êtes pas encore sûr de comment définir un objectif, ou si vous souhaitez simplement faire un brainstorming avec Codex, il n'est pas nécessaire de commencer directement en mode /goal.

Codex peut aussi définir ses propres objectifs. Vous pouvez commencer une conversation normale, puis, lorsque vous êtes prêt à faire exécuter Codex, lui demander de fixer un objectif basé sur la discussion précédente.

Vous pouvez aussi modifier l'objectif à tout moment : en cliquant sur le bouton d'édition dans l'application Codex, ou en utilisant à nouveau /goal dans le CLI.

Fournir autant d'orientations que possible

Des prompts comme « Réduire le temps de construction et de déploiement de 30 % » ont l'air impressionnants, et peuvent pousser Codex à trouver des solutions créatives. Mais si vous savez déjà où le problème se situe, ce type de prompt peut aussi faire dévier l'IA.

Il est donc préférable, si possible, d'indiquer à Codex par où commencer le diagnostic, quels outils utiliser, ou d'autres conseils pour éviter qu'il ne s'égare dans une mauvaise direction.

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, en précisant certaines limites acceptables, comme laisser Codex générer lui-même un dataset lors de l'entraînement d'un modèle.

De même, si vous souhaitez réduire le temps de build et que vous savez où se concentre la majorité du temps, il est judicieux de diriger Codex vers cette étape en priorité.

Une autre approche consiste à faire faire à Codex une étude préliminaire en mode planification (plan mode), puis à lui demander de créer un fichier de planification pour recenser des 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 d’approcher la but, il est crucial de lui fournir des outils pour mesurer ses avancées.

Pour certains types de tâches, cela peut sembler évident. Par exemple, optimiser le temps de build ou augmenter la couverture de tests, car Codex peut déjà utiliser des outils pertinents ou en créer de nouveaux.

Mais pour d’autres objectifs, il vaut mieux faire un brainstorming avec Codex : quels outils peuvent aider à suivre la progression ? Ou lui donner des indices pour qu’il sache comment vérifier qu’il se rapproche de l’objectif. Par exemple, créer un outil de comparaison visuelle pour deux captures d’écran, ou une suite d’évaluation pour un agent en cours de débogage.

J’ai déjà demandé à Codex de reproduire certains composants à partir d’une vidéo, et il a créé un outil pour comparer des captures d’écran et détecter des différences. Il a aussi continué à faire évoluer cet outil, en ajoutant différents modes de comparaison.

Image : une capture d’écran générée par Codex, utilisée pour comparer visuellement deux images.

Selon la tâche, il faut aussi considérer s'il y a des standards additionnels à mesurer ou vérifier. Sinon, Codex pourrait penser que la tâche est terminée alors qu’elle ne l’est pas vraiment.

Par exemple, pour « une restitution pixel-perfect » d’une interface utilisateur, Codex pourrait simplement découper une référence graphique et l’intégrer dans la page ; ou, pour atteindre 100 % de couverture de tests, réduire cette couverture. Ce qui n’est pas ce que vous souhaitez réellement.

Créer un environnement réel

Pour que Codex fasse réellement des progrès vers l’objectif, il doit fonctionner dans un environnement suffisamment représentatif.

Concrètement, si vous souhaitez optimiser le déploiement ou la latence, Codex doit pouvoir accéder à l’environnement de déploiement et de test, qui doit être aussi proche que possible de la production : même stack technologique, mêmes configurations, bases de données similaires.

Par exemple, lors de l’optimisation du temps de build et de déploiement de developers.openai.com, nous utilisions déjà des déploiements de prévisualisation. Codex pouvait ainsi déployer dans ces environnements, mais ceux-ci n’étaient pas identiques à la production, notamment en désactivant certains chemins de build.

Finalement, il a fallu faire un déploiement manuel dans un environnement plus proche de la configuration de production pour vraiment diagnostiquer le problème.

De même, vous pouvez faire utiliser à Codex la capacité de manipulation d’applications réelles (computer use) pour tester des applications concrètes. Pour optimiser certains problèmes de performance sur iOS, @dimillian a même utilisé des appareils physiques pour obtenir un environnement de test précis.

Précautions pour les objectifs visuels

Fixer un objectif visuel, comme « 100 % restitution pixel-perfect de cette interface », peut sembler très séduisant. Mais selon la configuration, cela peut aussi poser problème.

Sans directives et contraintes appropriées, Codex risque de se perdre dans les détails, en négligeant l’objectif global. Par exemple, si la référence contient des éléments graphiques, et que vous attendez que Codex reproduise ces éléments — que ce soit des icônes SVG ou des images — il pourrait consacrer beaucoup d’efforts à « reproduire précisément » ces éléments, plutôt qu’à décomposer le problème dans sa globalité.

De plus, Codex a besoin d’outils pour faire une comparaison visuelle efficace. Cela implique plus d’images en entrée, une consommation accrue de tokens, mais ne garantit pas une identification simple des améliorations pertinentes.

Ainsi, une image doit plutôt servir de contexte pour l’objectif, plutôt que comme seul critère de réussite. Il faut aussi utiliser d’autres moyens pour vérifier si l’objectif est atteint, comme une liste de fonctionnalités, des spécifications, ou la conformité à un système de design.

Suivi de l’avancement

Si Codex travaille en arrière-plan pendant plusieurs heures ou jours, ou sur une autre machine, il est facile d’oublier où il en est, ce qu’il a fait.

Selon l’objectif, voici quelques méthodes utiles :

· Demander à Codex de faire des commits à des étapes clés, puis de pousser dans une PR brouillon, surtout si vous travaillez sur un site avec déploiement de prévisualisation.

· Demander à Codex de mettre à jour un livrable pour la direction, comme un fichier HTML consultable dans un navigateur intégré, ou une page déployée via un site, ou une simple image de progression, ou un fichier Markdown.

· Indiquer à Codex de publier des mises à jour de progression. Vous pouvez aussi l’intégrer dans l’objectif : qu’il envoie des updates dans Slack ou autre plateforme à chaque étape importante.

· Utiliser une autre fenêtre de chat pour demander le statut. Si vous souhaitez une réponse rapide, lancez /side pour ouvrir une discussion parallèle, qui aura tout le contexte actuel mais sera courte.

· Une autre méthode consiste à ouvrir une nouvelle conversation normale, demander à Codex de lire un autre fil d’objectif, ou de répondre à vos questions. Si vous lui demandez de créer une tâche automatisée pour vérifier régulièrement l’avancement, cela peut être très efficace.

Finaliser et valider le résultat

Super, l’objectif est atteint ! Peut-on alors simplement transmettre le résultat à l’équipe et clore le sujet ?

En général, surtout pour des tâches d’optimisation, il est utile que Codex relise et examine son propre travail. Vous pouvez d’abord lancer /review pour une revue locale, mais il est aussi intéressant de demander à Codex de faire une réflexion plus approfondie : quelles méthodes ont été essayées ? Quelles ont fonctionné ? Quelles ont échoué ? Et de nettoyer le code en conséquence.

Puisque Codex travaille jusqu’à ce que l’objectif soit atteint, il peut avoir essayé des approches peu efficaces ou inutiles, qui laissent des résidus dans le code final.

Et pour votre prochain objectif, n’hésitez pas à lui fixer un nouveau goal.

La fonction d’objectif de Codex est un outil extrêmement puissant pour relever certains des défis techniques les plus complexes. Mais elle ne sera efficace que si vous lui fournissez un environnement et des instructions adaptés.

Et vous, qu’avez-vous déjà fait avec /goal ?

[ lien vers l’original ]

Cliquez pour découvrir les opportunités chez BlockBeats

Rejoignez la communauté officielle de BlockBeats :

Groupe Telegram : https://t.me/theblockbeats

Groupe de discussion Telegram : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia