Note de la rédaction : Cet article provient de Dominik Kundel, membre de l'équipe des relations avec les développeurs d'OpenAI, et résume son expérience avec la fonction « goal mode / /goal » de Codex. Il ne s'agit pas d'une simple technique de prompt, mais d'un changement de rôle des outils de programmation par IA : Codex ne se contente plus d'être un assistant de code répondant à des instructions uniques, mais commence à devenir un agent exécutif capable de progresser de manière continue vers un objectif défini.

Dans le mode /goal, ce qui compte vraiment, ce n'est pas d'écrire les exigences aussi longues et détaillées que possible, mais de définir pour Codex des critères de sortie clairs et vérifiables. Par exemple : « réduction du temps de déploiement de 30 % », « couverture des tests atteignant 100 % de parité », « LCP inférieur à 2,5 secondes ». Ces indicateurs permettent à Codex de déterminer si la tâche est terminée et évitent qu'il ne s'engage dans des essais infinis à cause d'objectifs vagues. Parallèlement, l'utilisateur doit fournir suffisamment de direction, d'outils et d'environnements réels afin que Codex puisse mesurer la progression et valider les résultats, et non pas simplement livrer une solution apparemment viable dans un environnement local ou hypothétique.

L'article souligne particulièrement que les tâches visuelles sont les plus susceptibles de faire plonger Codex dans un marais de détails. Au lieu de demander une « reconstitution pixel parfait à 100 % », il vaut mieux décomposer les objectifs visuels en une liste de fonctionnalités, des normes de système de conception et des indicateurs évaluables. Pour les tâches longues durant plusieurs heures voire plusieurs jours, il est également essentiel de suivre continuellement l'avancement via des commits, des pull requests provisoires, des documents de progression, des mises à jour Slack ou des discussions parallèles, afin d'éviter de se retrouver avec un ensemble de modifications non traçables.

L'apport de cet article réside dans la redéfinition de /goal comme un « mécanisme de gestion de tâches à long terme ». Lorsque l'IA peut exécuter continuellement des dizaines, voire des centaines d'heures, les compétences fondamentales des développeurs évoluent : il ne s'agit plus seulement de faire générer du code à l'IA, mais de lui définir des objectifs, établir un système de mesure, configurer son environnement d'exécution, puis effectuer enfin une revue et une analyse post-exécution. Autrement dit, la programmation par IA passe de la « rédaction de prompts » à la « gestion d'un exécutant d'ingénierie en continu ».

Voici le texte original :

Nous avons lancé le mode objectif (goal mode, ou /goal) pour vous aider à faire progresser Codex vers un résultat spécifique. Une fois que vous avez fixé un objectif, Codex continue de travailler jusqu'à ce que l'objectif soit atteint — qu'il faille quelques heures ou plusieurs jours. Certains utilisateurs ont déjà fait travailler Codex pendant plus de 120 heures consécutives pour le même objectif.

Le mode objectif est très puissant. Pour en maximiser l'efficacité, voici 7 points à retenir lors de l'utilisation de /goal.

Établir des critères clairs et vérifiables

Les prompts que vous entrez lors de l'activation du mode cible servent à la fois de prompt initial et, plus important encore, constituent le critère de sortie pour cette cible. Codex vérifie à la fin de chaque itération si cette cible a été atteinte.

Ainsi, votre indication d'objectif ne doit pas être trop longue, mais doit se concentrer sur un critère clair : dans quelles conditions l'objectif est-il considéré comme atteint ?

Dans la plupart des cas, une bonne cible devrait inclure un indicateur numérique clair permettant au modèle de déterminer si elle a été atteinte. Par exemple :

Réduisez le temps de construction et de déploiement de 30 %.

Migrer cette fonction de TypeScript vers Rust et atteindre une cohérence de test de 100 %.

Optimisez le squelette de l'application pour que la peinture du contenu le plus important (Largest Contentful Paint, indicateur mesurant la vitesse de chargement du contenu principal de la page) soit inférieure à 2,5 secondes en production.

Cette indication n'a pas toujours besoin de contenir des chiffres, mais en général, les chiffres facilitent les étapes suivantes.

Si vous n'êtes pas encore sûr de la manière de définir vos objectifs, ou si vous souhaitez d'abord faire un brainstorming sur ce projet avec Codex, vous n'avez pas besoin de démarrer la conversation en utilisant le mode objectif.

Codex peut définir ses propres objectifs. Vous pouvez d'abord entamer une conversation normale, puis, une fois prêt à faire démarrer Codex, lui demander de définir un objectif en se basant sur les échanges précédents.

Vous pouvez également modifier votre objectif à tout moment : cliquez sur le bouton Modifier dans l'application Codex, ou utilisez à nouveau /goal dans l'CLI.

Fournissez autant de directives que possible

Des indications comme « réduire le temps de construction et de déploiement de 30 % » peuvent sembler impressionnantes et inciter Codex à trouver des solutions créatives. Mais si vous avez déjà une idée approximative de l'endroit où le problème se situe, cette indication pourrait également orienter Codex dans la mauvaise direction.

Ainsi, dans la mesure du possible, il est préférable d'indiquer à Codex d'où commencer les recherches, quels outils utiliser pour atteindre l'objectif, ou de fournir d'autres indices afin d'éviter qu'il ne parte dans une mauvaise direction.

Par exemple, mon collègue @reach_vb a fait cela lors d'une expérience : il a indiqué à Codex qu'il était possible d'accéder à Google Colab via le navigateur Chrome, tout en précisant certaines limites acceptables, comme permettre à Codex de générer lui-même un jeu de données lors de l'entraînement du modèle.

De même, si vous souhaitez réduire le temps de construction et que vous savez déjà où la majorité du temps est consommée, il est préférable de diriger Codex vers cette zone dès le début dans votre prompt.

Une autre approche consiste à faire d’abord effectuer à Codex une étude préliminaire en mode planification, afin qu’il crée un fichier de plan détaillant les solutions potentielles, puis à faire référence à ce plan par votre cible.

Rendre les progrès mesurables

Si votre objectif est ambitieux ou si Codex dispose de plusieurs façons d'atteindre progressivement cet objectif, il est essentiel de fournir à Codex des outils pour mesurer les progrès.

Pour certaines tâches, cela peut être naturellement vrai. Par exemple, optimiser le temps de construction ou augmenter la couverture des tests, car Codex peut généralement déjà utiliser les outils associés ou les créer naturellement.

Mais pour d'autres objectifs, il vaut mieux commencer par faire un brainstorming avec Codex : quels outils permettent d'évaluer les progrès ? Ou lui fournir quelques indications pour qu'il sache comment déterminer s'il s'approche de son objectif. Par exemple, créer un outil de comparaison visuelle de différences entre deux captures d'écran, ou établir un ensemble d'évaluations pour l'agent que vous êtes en train de déboguer.

J'ai précédemment demandé à Codex de recréer certains composants à partir d'une vidéo, au cours de laquelle Codex a créé un outil pour comparer des captures d'écran et détecter les différences. Par la suite, il a continué à itérer sur cet outil en ajoutant différents modes de comparaison des différences.

En fonction de la tâche, vous devez également envisager si des critères supplémentaires doivent être mesurés ou vérifiés. Sinon, Codex pourrait penser que la tâche est terminée, alors qu'elle vous semble encore incomplète.

Par exemple, Codex pourrait, pour une reconstitution « pixel parfait » d’une interface utilisateur, découper directement une image de référence et l’incorporer dans la page ; ou bien, pour atteindre un taux de réussite des tests de 100 %, réduire à la baisse la couverture des tests. Ce ne sont pas les méthodes que vous souhaitez réellement adopter.

Créez un environnement réel

Si vous souhaitez que Codex réalise des progrès efficaces vers son objectif, il doit fonctionner dans un environnement suffisamment réel.

En pratique, cela signifie que si vous souhaitez optimiser les temps de déploiement ou résoudre des problèmes de latence, Codex doit avoir accès aux environnements de déploiement et de test, et ces environnements doivent simuler autant que possible l’environnement de production : utilisez la même pile technologique, les mêmes paramètres de configuration et des bases de données similaires.

Par exemple, nous avons précédemment optimisé les temps de construction et de déploiement sur developers.openai.com. À l'époque, nous utilisions déjà des aperçus de déploiement, ce qui permettait à Codex d'utiliser ces environnements d'aperçu pour le déploiement et d'accéder aux journaux associés. Toutefois, le problème était que nos déploiements d'aperçu désactivaient certaines chemins de construction par rapport à l'environnement de production complet.

Ainsi, Codex a fini par devoir effectuer un déploiement manuel pour déployer le code dans un environnement plus proche de la configuration de production, afin de pouvoir véritablement identifier le problème.

De même, vous pouvez également permettre à Codex d'utiliser l'usage de l'ordinateur (la capacité du modèle à interagir avec des interfaces d'applications réelles) pour tester des applications réelles. Pour optimiser certaines problématiques de performance sur iOS, @dimillian a même utilisé des appareils physiques afin d'obtenir l'environnement de test le plus précis.

Définissez prudemment vos objectifs visuels

Donner à Codex un objectif visuel, comme « reproduire à 100 % ce UI pixel par pixel à partir de cette image », est effectivement attrayant. Mais selon les paramètres spécifiques, cela peut aussi poser des problèmes.

Si vous ne fournissez pas de directives et de contraintes appropriées, Codex risque de s'engager trop profondément dans certains détails, au détriment de l'objectif global. Par exemple, si l'image de référence contient des éléments graphiques et que vous attendez que Codex les génère — qu'il s'agisse d'icônes SVG ou d'images — il pourrait consacrer une grande partie de ses efforts à « reproduire exactement ces éléments » plutôt qu'à 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 et une consommation totale de tokens plus élevée, mais ne fournit pas nécessairement à Codex un moyen simple d'identifier les véritables opportunités d'amélioration précieuses.

Ainsi, les images sont généralement plus adaptées en tant que contexte cible qu’en critère unique de complétion. Vous devriez chercher d’autres moyens pour permettre à Codex de déterminer si l’objectif a été atteint, par exemple une checklist fonctionnelle, une spécification d’implémentation, ou la conformité au système de design.

Suivre la progression

Si Codex fonctionne en arrière-plan pendant plusieurs heures, voire plusieurs jours, voire sur une autre machine, il est facile d'oublier à quel point il a progressé et quelles tâches il a déjà accomplies.

Selon différents objectifs, j'ai trouvé les méthodes suivantes très utiles :

· Faites soumettre le code par Codex aux points clés et poussez-le vers une PR brouillon. Cela sera particulièrement utile si vous travaillez sur un site web avec un déploiement de prévisualisation.

· Faites mettre à jour Codex avec un livrable destiné à la direction. Cela peut être un fichier HTML que vous pouvez garder ouvert dans un navigateur intégré à l'application ; ou une page déployée via Sites pour que l'équipe la consulte ; une image rendue de l'avancement, ou simplement un fichier Markdown classique.

Indiquez à Codex de publier activement des mises à jour sur ses progrès. Vous pouvez également inclure cela dans vos objectifs : faire en sorte que Codex envoie des mises à jour sur le canal Slack, ou tout autre endroit où vous souhaitez enregistrer les progrès, lorsqu'il réalise des avancées importantes.

Utilisez une autre fenêtre de discussion pour demander l'état. Si vous souhaitez simplement obtenir rapidement l'état actuel, exécutez /side pour démarrer une nouvelle discussion latérale et posez votre question là-bas. Étant donné qu'elle se sépare du fil actuel, elle dispose de tout le contexte jusqu'à présent, mais sa durée de vie est courte.

Une autre approche dans l'application Codex consiste à ouvrir un nouveau chat standard, à faire en sorte que Codex lise un autre fil cible et réponde à vos questions. Cette méthode devient particulièrement puissante si vous demandez à Codex de configurer une tâche automatisée pour vérifier régulièrement les progrès.

Nettoyer et confirmer définitivement les résultats

Super, l'objectif est enfin atteint ! Peut-on maintenant simplement transmettre les résultats à l'équipe et arrêter là ?

En général, surtout dans les tâches d'optimisation, je trouve utile de faire en sorte que Codex revienne sur son travail et le révise. Vous pouvez d'abord lancer une revue de code locale avec /review, mais il est également utile de demander à Codex de réfléchir plus profondément : quelles approches a-t-il essayées pour atteindre l'objectif ? Lesquelles ont fonctionné ? Lesquelles n'ont pas fonctionné ? Puis de nettoyer le code en conséquence.

Étant donné que Codex continuera de fonctionner jusqu'à atteindre l'objectif, il a pu essayer certaines méthodes peu efficaces, voire totalement inefficaces, dont les modifications résiduelles pourraient encore se trouver dans le code final.

Définissez un objectif pour votre prochaine tâche.

La fonctionnalité cible de Codex est un outil extrêmement puissant qui peut vous aider à résoudre certains des défis d'ingénierie les plus significatifs. Toutefois, il ne peut atteindre cet objectif de manière plus efficace que si vous lui fournissez l'environnement et les instructions appropriés.

Qu'avez-vous fait avec /goal ?