Comment utiliser Goals dans Codex

• Goals est une fonctionnalité d’objectif persistant qui permet à un thread Codex de poursuivre un travail sur plusieurs tours vers un résultat défini
• Adapté aux tâches difficiles à traiter avec un seul prompt, comme le profiling, les patchs, le benchmarking, la reproduction de tests flaky et les audits fondés sur des preuves
• En définissant le résultat (outcome), le moyen de vérification (verification surface) et les contraintes (constraints), Codex peut déterminer lui-même, sur la base de preuves, si le travail est terminé
• Le cycle de vie peut être contrôlé avec les commandes /goal, /goal pause, /goal resume, /goal clear, avec une prise en charge à partir de Codex 0.128.0
• Il s’agit d’une structure de contrat d’achèvement (completion contract) limitée au périmètre du thread, dont l’essentiel est une persistance sous contrôle de l’utilisateur, et non une exécution autonome illimitée

---

Définition de Goals et contexte d’introduction

• Goals est une fonctionnalité qui donne à Codex une condition d’achèvement (completion condition), en définissant ce qui doit être vrai, comment vérifier le succès et quelles contraintes doivent être respectées
• Codex fonctionne déjà bien pour des tâches de code à périmètre clair comme l’inspection d’un dépôt, la correction de bugs, l’ajout de tests, l’explication d’échecs ou l’implémentation de modifications ciblées
• Goals convient aux tâches où l’étape suivante dépend de ce que Codex apprend en cours de route
  • profiling, patchs, benchmarking, reproduction de tests flaky, transformation de questions de recherche en audits fondés sur des preuves
• Ce type de travail nécessite non pas un prompt plus long, mais un objectif persistant
• Lorsqu’un Goal est actif, Codex conserve l’objectif, évalue si l’achèvement est atteint et choisit l’action suivante sans qu’il soit nécessaire de reformuler le but à chaque résultat intermédiaire
• Un Goal n’est pas une autonomie d’arrière-plan sans limites, mais un contrat d’achèvement cadré et sous contrôle de l’utilisateur

Quickstart : utiliser Goals

• Utilisez un Goal pour des tâches dont le point d’arrivée est clair, mais dont le chemin pour y parvenir est incertain
  • Bons candidats : optimisation des performances, investigation de tests flaky, migration de dépendances, suivi de bugs nécessitant une reproduction, refactoring en plusieurs étapes, tuning fondé sur des benchmarks, travaux de recherche nécessitant un livrable final
  • Pour une modification ponctuelle, un prompt classique est plus adapté

• Installation et vérification de version

  • Goals est disponible à partir de Codex 0.128.0
  • npm : après npm install -g @openai/codex@latest, exécutez codex --version
  • Homebrew : après brew update && brew upgrade --cask codex, exécutez codex --version

• Définition d’un Goal et commandes de cycle de vie

  • Définition au format /goal <résultat>, par exemple : /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal : afficher le Goal actuel
  • /goal pause : mettre en pause le Goal actif
  • /goal resume : reprendre un Goal mis en pause
  • /goal clear : supprimer le Goal actuel

• Condition d’arrêt (stopping condition)

  • Arrêt en cas de succès, de pause, de suppression, d’interruption, d’atteinte de la limite de budget ou d’apparition d’un bloqueur nécessitant une intervention de l’utilisateur
• Dans les situations où il faudrait autrement répéter à chaque tour des instructions comme « continue », « essaie ensuite une autre modification possible », « relance le benchmark » ou « vérifie maintenant les tests », Goal exprime explicitement cette intention

Goals vs prompts

• Prompt classique : « fais cette prochaine tâche »
• Goal : « continue à travailler jusqu’à ce que ce résultat soit vrai »

• Différence de fonctionnement

  • Avec une requête classique, Codex exécute l’instruction immédiate, rend le résultat, puis attend
  • Avec un Goal, une cible durable (durable target) est attachée au thread ; à la fin du tour, Codex examine les preuves disponibles et détermine si l’objectif est atteint
  • Si ce n’est pas le cas, que le Goal est toujours actif et que le budget le permet, le travail peut se poursuivre à partir de l’état le plus récent

• Exemple : /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Fournit un résultat mesurable, un moyen de vérification et des contraintes
  • Codex peut alors enchaîner exécution du benchmark → inspection du hot path → modification ciblée → relance du benchmark → exécution de la suite de validation de la correction, et continuer si le résultat reste insuffisant

• Modèle mental

  • Prompt : ask → work → result → wait
  • Goal : work → check → continue or complete
• Le Goal fournit la ligne d’arrivée, mais le travail doit toujours être audité à partir de preuves

Comment rédiger un Goal

• Un bon Goal n’est pas un prompt plus long, mais un contrat concis sur la manière de travailler de Codex, sur ce qui constitue un succès et sur ce qu’il doit faire lorsqu’il n’a pas encore atteint ce succès

• Les 6 éléments définis par un Goal solide

  • Outcome : ce qui doit être vrai une fois le travail terminé
  • Verification surface : les tests, benchmarks, rapports, artefacts, sorties de commande ou sources qui le prouvent
  • Constraints : ce qui ne doit pas régresser pendant le travail de Codex
  • Boundaries : les fichiers, outils, données, dépôts et ressources autorisés
  • Iteration policy : la manière de décider quoi faire ensuite après chaque tentative
  • Blocked stop condition : le moment où il faut signaler l’absence de chemin défendable dans les limites actuelles et s’arrêter

• Patron de rédaction

  • /goal <état final souhaité> verified by <preuve concrète> while preserving <contraintes>. Use <entrées/outils/limites autorisés>. Between iterations, <manière de choisir la meilleure action suivante>. If blocked or no valid paths remain, <ce qu’il faut rapporter et les entrées nécessaires pour progresser>.

• Exemple faible vs exemple fort

  • Faible : /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Fort : préciser explicitement le moyen de vérification (checkout benchmark), le périmètre d’action (service checkout, fixtures de benchmark, tests associés), la politique d’itération (consigner les changements, les résultats de benchmark et l’expérience suivante) ainsi que la condition de remontée des bloqueurs

• Goals de recherche et d’investigation

  • Quand une preuve exacte peut être impossible, définissez le standard de preuve (evidence standard) avant de commencer
  • Exemple : /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Confier la rédaction du Goal à Codex

  • Workflow recommandé en deux étapes : décrire la tâche en langage simple → demander à Codex de rédiger un brouillon de Goal → affiner les conditions de succès, le moyen de vérification, les contraintes et la condition d’arrêt sur bloqueur avant activation

Ce qui change lorsqu’un Goal est actif

• L’objectif reste visible en permanence

  • Même si un test échoue, le thread conserve son objectif initial
  • Si un benchmark s’améliore mais reste sous le seuil requis, Codex continue
  • Si un parcours de recherche se heurte à un manque de données, le plan de preuve s’ajuste sans perdre le standard de recherche

• Possibilité de continuation sur un thread inactif

  • Il n’y a pas de continuation si un autre tour est actif, si une entrée utilisateur est en file d’attente ou si un autre travail du thread est en attente
  • La continuation n’a lieu que si le thread est inactif, que le Goal est actif et que le budget n’est pas dépassé

• L’achèvement doit être fondé sur des preuves

  • Le simple fait que le modèle « pense que c’est probablement terminé » ne suffit pas
  • L’achèvement n’est possible qu’après vérification de l’objectif par rapport aux fichiers concernés, aux tests, aux logs, aux sorties de benchmark, aux artefacts générés et à d’autres preuves concrètes
• Principe central de conception : Codex peut continuer à avancer, mais ce sont les preuves qui décident de l’achèvement

Structure de conception des Goals dans Codex

• Goals est implémenté comme un état persistant au niveau du thread (persisted thread state), et non comme une mémoire globale ni comme une directive au niveau du projet
  • L’objectif appartient au thread qui contient le contexte associé : fichiers inspectés, commandes exécutées, diff générés, logs consultés et historique de raisonnement

• Couches d’architecture

  • En tant qu’état persistant et circonscrit au thread, il enregistre l’objectif, le cycle de vie, le budget et la comptabilité de progression
  • États possibles du Goal : active, paused, complete, budget-limited
  • Selon cet état, Codex décide s’il doit continuer, attendre l’utilisateur ou résumer la progression au lieu de lancer un nouveau travail

• La continuation est pilotée par les événements

  • Ce n’est pas une simple boucle ; les vérifications n’ont lieu qu’à des frontières de sécurité : fin de tour, absence de travail en attente, file utilisateur vide, thread inactif
  • Le comportement du dispatcher est conservateur : un travail purement de planification ne déclenche pas la continuation, une interruption met l’objectif en pause, une reprise de thread peut restaurer l’objectif si c’est approprié, et si un tour de continuation n’effectue aucun appel d’outil, la continuation automatique suivante est supprimée pour éviter le spin

• Couche de prompting

  • Le prompt de continuation aligne Codex sur l’objectif actif, tout en exigeant un audit avant l’achèvement
  • L’objectif est comparé à des preuves concrètes : fichiers modifiés, commandes exécutées, tests passés, sorties de benchmark, artefacts générés, preuves de recherche

• Gestion du budget

  • Lorsque le budget est atteint, le travail effectif s’arrête, la progression et les bloqueurs sont résumés, et l’étape suivante utile est identifiée
  • Atteindre la limite de budget n’équivaut pas à l’achèvement du Goal

• Contrat d’outil (tool contract)

  • Le modèle peut démarrer un Goal, mais ne peut marquer un Goal existant comme terminé que si les preuves appuient cet achèvement
  • La mise en pause, la reprise, la suppression et le passage en limite de budget restent sous contrôle de l’utilisateur ou du système

Transformer un Goal faible en Goal fort

• Exemple de tuning de performance

  • Faible : /goal Improve performance
  • Fort : /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • La version forte fournit le résultat, la méthode de vérification et les contraintes, et permet de savoir quand il ne faut pas s’arrêter
    • Si le p95 passe de 180 ms à 135 ms, le Goal n’est pas terminé
    • Si la latence descend sous 120 ms mais que les tests de correction échouent, le Goal n’est pas terminé
    • Si le benchmark ne peut pas être exécuté, il faut faire remonter le bloqueur au lieu de déclarer le succès

• Le bon périmètre pour un Goal

  • Il doit être assez étroit pour être auditable, et assez large pour permettre de choisir l’action suivante
  • « Fix the failing checkout test » est trop étroit si la vraie cause est une dépendance en amont
  • « Improve the whole system » est trop large faute de surface d’audit
  • « Make the checkout test suite pass on the current branch without changing public API behavior » constitue un bon niveau de cadrage

• Même principe pour les artefacts générés

  • Faible : /goal Write docs for this feature
  • Fort : /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • La version forte fournit une page vérifiable, une commande de build et le comportement attendu des commandes

• Standard de preuve pour les Goals de recherche

  • À définir avant l’investigation : ce qui compte comme reproduction exacte, reconstruction partielle, appui par proxy ou bloqueur
  • Un Goal de recherche fort exige de constituer un inventaire des affirmations, de faire la correspondance entre affirmations et preuves, d’implémenter les parties exécutables, d’étiqueter les bloqueurs et de produire un audit séparant affirmations confirmées, preuves uniquement de soutien, affirmations bloquées et incertitudes restantes

Utiliser Goals pour une recherche complexe : cas de reproduction d’un article quantitatif

• Aperçu du cas

  • Cible : l’article Deep Hedging de Buehler, Gonon, Teichmann et Wood
  • Sujet de l’article : déterminer si des stratégies de trading par réseau neuronal peuvent reproduire une couverture fondée sur un modèle dans des contextes de préférence au risque, de coûts de transaction et de marchés à haute dimension
  • Le bon Goal n’est pas le vague « reproduire l’article », mais tenter les affirmations chiffrées principales, distinguer les mécanismes exacts des substituts d’apprentissage approximatifs, et préciser ce qui est impossible à reproduire exactement avec les matériaux disponibles

• Goal de recherche faible vs fort

  • Faible : /goal Reproduce Buehler et al., "Deep Hedging"
    • On ne sait pas quelles sections comptent, ce qui constitue une reproduction, comment traiter l’absence d’état d’apprentissage, ni comment distinguer une correspondance approximative d’une reproduction exacte
  • Fort : /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Ce que Codex fait concrètement

  • Séparer les affirmations principales des affirmations de soutien
  • Mettre les affirmations en correspondance avec les preuves disponibles
  • Reconstruire localement les parties testables
  • Étiqueter les affirmations qu’il est impossible de reproduire exactement avec les matériaux disponibles

• Ce qui a pu être exécuté

  • Reconstruction des mécanismes de pricing et de couverture
  • Reproduction du prix de référence Heston
  • Entraînement d’une politique pour l’expérience de couverture CVaR
  • Reconstruction de l’histogramme principal et des artefacts de surface de couverture
  • Reproduction de la pente des coûts de transaction Black-Scholes
  • Exécution de vérifications entraînées pour les coûts de transaction Heston et les exemples en haute dimension

• Ce qui reste bloqué

  • L’article ne fournit ni seed aléatoire exacte, ni chemins d’entraînement générés, ni graphe TensorFlow, ni état de l’optimiseur, ni checkpoints, ni état complet de simulation d’origine
  • Le résultat le plus honnête est donc une reproduction partielle et approximative, et non une relecture exacte du réseau neuronal

• Préserver le niveau d’appui épistémique dans le rapport

  • Des substituts entraînés peuvent soutenir une affirmation, une proximité numérique peut renforcer la confiance, et des figures reconstruites peuvent valider une partie des résultats, mais rien de cela ne doit être présenté comme une restauration exacte de l’expérience d’origine
  • Exemple de ledger :
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: reconstruction du mécanisme du modèle, comparaison avec la couverture de référence, entraînement d’une politique par réseau neuronal
    • Evidence surface: vérifications de prix, histogrammes, surface de couverture
    • Status: Close approximate reproduction
    • Remaining uncertainty: impossibilité d’utiliser les chemins d’entraînement, les seeds et les checkpoints d’origine
• La valeur démonstrative de Goals en recherche tient au fait qu’il maintient le travail dans l’ambiguïté sans laisser un artefact plausible se transformer en conclusion suraffirmée ; l’achèvement y signifie audit fondé sur les preuves affirmation par affirmation, explicitation des approximations et honnêteté sur la frontière entre reproduction et relecture exacte

Quand ne pas utiliser Goals

• Inadapté aux modifications d’une ligne, aux explications simples, aux courtes revues de code ou aux questions pour lesquelles on souhaite s’arrêter après une seule réponse → un prompt Codex classique est plus adapté
• Inadapté lorsque la ligne d’arrivée est floue
  • « Make this better » ne fournit pas de condition d’achèvement fiable
  • « Refactor this code » reste faible si l’état final attendu, les tests et les contraintes ne sont pas définis
• Ne pas l’utiliser pour masquer l’incertitude
  • Si des données peuvent être indisponibles, indiquez-le dans le Goal
  • Si un benchmark peut être flaky, précisez comment le traiter
  • Si des preuves proxy sont autorisées, définissez comment les étiqueter
• Goals est le plus fort lorsque trois propriétés se combinent : objectif persistant, ligne d’arrivée fondée sur des preuves, chemin nécessitant une investigation sur plusieurs tours

Conclusion : l’objectif persiste, mais ce sont les preuves qui décident de l’achèvement

• Goals modifie le modèle opératoire de Codex en faisant passer le thread d’une succession de prompts isolés à une boucle de travail orientée état centrée sur un résultat défini
• L’architecture est volontairement bornée
  • Le Goal est limité au thread, possède un état de cycle de vie et une comptabilité de budget, et peut être mis en pause, repris, supprimé, terminé ou arrêté pour raison de budget
  • Codex peut continuer à avancer, mais uniquement dans le contrat défini par l’utilisateur
• C’est particulièrement utile pour les tâches où Codex apporte déjà le plus de valeur : débogage, optimisation, migration, tests et recherche
• L’utilisateur fournit l’objectif, Codex suit les preuves, et le Goal relie les deux jusqu’à ce que le travail soit terminé ou honnêtement bloqué
• Dans la recherche complexe, cela fait la différence entre produire une réponse et produire un audit
• Un bon Goal ne demande pas simplement à Codex de finir, il lui indique ce que signifie être terminé

[hmmhmmhm]

/goal D’ici 12 h pour la pause déjeuner, veuillez vérifier et faire avancer tout ce qui est faisable en vous basant sur les tâches que j’ai effectuées auparavant. Vous ne devez pas arrêter le travail avant 12 h.

[shakespeares]

Quelle commande sympa.