Codex /goal command : mon avis honnête sur autonomous coding

La première fois que j'ai donné à Codex un /goal et que je me suis éloigné de mon bureau, je suis revenu quarante minutes plus tard pour constater qu'il avait réécrit la même fonction onze fois. Onze. Chaque version est un peu différente. Aucun d’eux n’est objectivement meilleur que le précédent. Le agent tournait en boucle - pas dans le sens productif de Ralph-loop, mais dans le sens "Je ne sais pas quand m'arrêter". Mon objectif était de "rendre le rendu plus rapide". C'était toute l'invite. C'était tout le problème.

J'avais donné une cible vague à un agent autonome de longue date, puis j'avais agi surpris lorsqu'il errait.

La commande Codex /goal a atterri dans la version 0.128.0 fin avril et change la forme de ce qu'un codage agent est censé faire. La plupart des commandes slash sont réactives : vous demandez, elles répondent, vous demandez à nouveau. /goal est le contraire. Vous définissez un objectif une fois, et Codex continue de planifier, d'agir, de tester, d'évaluer et de répéter, jusqu'à ce que l'objectif soit atteint de manière vérifiable ou que vous lui disiez d'arrêter. C'est la chose la plus proche de "tirer et oublier" autonomous coding que j'ai utilisé et qui ne semble pas complètement déséquilibrée.

Mais « ne se sent pas complètement déséquilibré » fait beaucoup de travail dans cette phrase. Parce que la différence entre une exécution /goal qui offre un gain de performances de 25 % et une exécution qui produit onze versions de la même fonction cassée n'est pas le modèle. Ce n'est pas non plus l'invite. C'est quelque chose de plus subtil – et une fois que vous le voyez, vous ne pouvez pas l'ignorer.

J'ai passé les deux dernières semaines à vivre dans ce commandement. Voici ce que j'ai appris, ce que je me suis trompé et le cadre que j'utilise maintenant pour décider si un travail appartient à une exécution /goal ou à une demande d'extraction normale.

Qu'est-ce que la commande Codex /goal ?

Permettez-moi d'abord de supprimer le langage marketing de cette chose, car le journal des modifications de OpenAI est - comme toujours - extrêmement concis sur ce qui a été livré.

La commande Codex /goal est un mode objectif persistant pour le Codex CLI. Vous lui donnez un objectif. Il ne reprend pas le contrôle après une seule réponse. Il mappe votre repo, planifie, modifie les fichiers, exécute des tests, évalue le résultat par rapport à vos critères d'arrêt et déclare l'objectif terminé ou démarre une autre itération. Le agent reste attaché au thread lors de nombreux appels d'outil. Il survit aux limites du contexte grâce à la manière dont Codex compacte et réutilise l'état. Il enregistre les progrès. Il respecte les règles d'agrément.

Ce n'est pas une discussion. C'est un processus de travail avec une liste de contrôle.

Il a été livré en tant que fonctionnalité expérimentale, ce qui signifie OpenAI pour "c'est réel mais nous ne le mettons pas encore sur la page d'accueil". Vous l'activez manuellement dans votre fichier de configuration, exécutez Codex dans votre terminal et un petit ensemble de nouvelles commandes slash apparaissent dans la TUI.

Voici la surface de commande réelle à partir de Codex CLI 0.128.0 :

/goal <objective> – fixez un objectif à long terme et démarrez la boucle
/goal pause — terminez l'étape en cours, puis faites une pause
/goal resume : reprendre un objectif en pause
/goal clear — efface entièrement l'objectif actif
/goal (aucun argument) — affiche la progression, l'utilisation des jetons et le temps écoulé
/side <prompt> — ouvre un fil de discussion secondaire pour poser une question sans perturber l'objectif principal ; revenir en arrière avec la touche d'échappement

La commande /side est la partie dont personne ne parle, et c'est secrètement la meilleure fonctionnalité du bundle. Nous en reparlerons plus tard.

Maintenant, avant d'aborder la façon d'utiliser tout cela, il y a une chose dans la vidéo source que j'ai regardée qui est fausse, et vous vous épargnerez un après-midi frustrant si vous le savez maintenant.

Le seul détail de configuration que tout le monde se trompe

La procédure pas à pas que j'ai suivie à l'origine m'a dit d'activer les objectifs dans config.yml. J'ai passé vingt minutes confuses à me demander pourquoi rien ne se passait avant de vérifier la documentation Codex.

Codex CLI n'utilise pas YAML. Il utilise TOML.

Le fichier est ~/.codex/config.toml et l'indicateur réside sous une table [features]. Le bloc d'activation minimal ressemble à ceci :

[features]
goals = true

Vous pouvez également le faire à partir de la ligne de commande : codex features enable goals écrit la même valeur dans le même fichier. Dans tous les cas, enregistrez le fichier, redémarrez Codex et les commandes /goal et /side apparaissent dans la palette de commandes slash. Si ce n'est pas le cas, soit vous avez modifié le mauvais fichier, soit vous utilisez une version Codex antérieure à 0.128.0. Exécutez codex --version pour confirmer.

Une fois que features.goals = true est défini globalement, la fonctionnalité fonctionne à la fois dans les applications Codex CLI et Codex. Il vous suffit de l'activer une seule fois, dans le CLI, et il se propage.

Petit détail. Grande différence entre « ça marche » et « je perds une heure ».

Cela étant dit, parlons de ce qui compte réellement : c'est-à-dire quand vous devriez utiliser cette commande en premier lieu, car la réponse est "beaucoup moins souvent que vous ne le pensez".

Les deux types de travail de codage – et pourquoi /goal est mauvais pour l'un d'eux

Voici le modèle mental sur lequel il m'a fallu une semaine d'abus pour atterrir.

Presque tous les travaux de codage que j’effectue appartiennent à l’une des deux catégories suivantes. Les catégories se ressemblent de l’extérieur. Un ingénieur senior peut généralement les distinguer en trente secondes environ. Un code agent – et franchement, beaucoup d’ingénieurs débutants – ne peuvent pas du tout les distinguer. Et /goal n'est que le bon outil pour l'un d'entre eux.

Catégorie 1 : travail bien défini. Vous connaissez l'entrée. Vous connaissez le résultat. Vous savez à peu près à quoi ressemble la différence avant de commencer. "Intégrez Notion API afin que nous puissions synchroniser les briefs clients dans la base de données d'un projet." "Ajoutez un gestionnaire de webhook Stripe qui se connecte à notre table d'événements existante." "Migrer le modèle utilisateur des clés primaires basées sur le courrier électronique vers les clés primaires basées sur l'UUID." Ces tâches ont une forme. Il y a un nombre fini de fichiers à modifier, une définition claire de ce qui est fait, et le chemin est principalement mécanique une fois qu'on y a réfléchi pendant dix minutes.

Pour ce type de travail, /goal est excessif, voire nuisible. Vous ne voulez pas d'une boucle d'auto-évaluation. Vous voulez un PR propre. Vous souhaitez que le agent fasse exactement ce que vous avez demandé, restitue le contrôle et vous laisse réviser. Le flux de travail standard Codex (invite unique, réponse unique, examen normal) gère cela à merveille. J'écris sur la façon dont j'exécute cette boucle dans mon [répartition du workflow Codex et Claude Code à deux agent] (https://www.mejba.me/blog/claude-code-codex-two-agent-workflow), et 90 % de mon vrai travail y réside toujours.

Catégorie deux : travail exploratoire. C'est là que le but est connu mais pas le chemin. "Réduisez de 20 % la latence P95 sur ce API." "Réduisez notre empreinte mémoire sur le pool de travailleurs." "Trouvez et corrigez le changement de mise en page qui provoque un cratère de notre score Lighthouse sur mobile." Vous pouvez décrire le résultat souhaité avec une métrique. Vous ne pouvez cependant pas décrire la différence à l’avance. La solution peut être un changement de configuration, une optimisation de requête, une refactorisation de code, un échange d'algorithme – ou une combinaison des quatre découvertes en séquence après l'exécution des profileurs.

C'est pour cela que /goal a été conçu. La boucle de raisonnement – planifier, agir, tester, évaluer, itérer – est exactement la bonne forme pour l’exploration. Vous définissez un objectif vérifiable et laissez le agent travailler. Il essaie quelque chose. Les tests lui indiquent si le changement a modifié la métrique. Si oui, il essaie d’aller plus loin. Si non, il recule et essaie un angle différent.

L'histoire d'amélioration de 25 % du FPS que vous verrez circuler dans les démos Codex ? C'est la catégorie deux. Quelqu'un a posé à Codex un problème de performances de rendu avec un objectif clair et mesurable et l'a laissé fonctionner pendant des heures. Ils ne savaient pas quelle optimisation allait aboutir avant de commencer. Le agent a compris quoi essayer et quoi conserver.

L'idée la plus profonde ici, que j'ai dû apprendre à mes dépens : la plupart des ingénieurs adoptent par défaut une réflexion de catégorie un, même lorsqu'ils travaillent sur des problèmes de catégorie deux. Ils essaient de spécifier la solution avant d'avoir compris l'espace de recherche. /goal vous oblige à inverser cela : vous devez vous engager sur la destination sans vous engager sur l'itinéraire. C'est inconfortable. C'est aussi là que se trouve l'effet de levier.

Mais cela ne fonctionne que si votre destination est réelle. Ce qui nous amène à la discipline qui fait ou défait chaque course de but.

La vérifiabilité des objectifs est tout le jeu

Regardez ce qui se passe lorsque vous donnez à Codex un objectif vague.

J'ai essayé /goal make the search faster sur un petit projet parallèle de Laravel. Codex a commencé par exécuter la recherche existante, obtenant une référence (bonne). Ensuite, il a ajouté un index sur la colonne la plus interrogée (bon). Ensuite, il a effectué une nouvelle analyse comparative et a constaté une amélioration de 14 % (bonne). Puis ça a continué. Il a ajouté la mise en cache des résultats de requête. Ensuite, il a refactorisé le contrôleur de recherche. Ensuite, il a ajouté une couche Redis. Ensuite, il a suggéré une migration de la recherche en texte intégral vers Meilisearch. À aucun moment cela ne s'est arrêté, car à aucun moment je ne lui avais dit ce que signifiait « assez vite ».

Codex injecte une instruction système au début de chaque itération qui dit, en substance, « traiter l'incertitude comme non réalisée ». C'est un garde-fou contre les fausses déclarations d'achèvement. Mais cela va dans les deux sens. Si votre objectif est véritablement invérifiable – s’il n’existe aucune métrique, aucune liste de contrôle, aucun test pouvant renvoyer une réussite – alors le agent considérera l’objectif comme perpétuellement non atteint. Il continuera à répéter jusqu'à ce que vous manquiez de jetons, de patience ou d'argent.

Le correctif est simple à décrire et étonnamment difficile à exécuter. Chaque /goal que vous définissez doit contenir deux éléments :

Une cible concrète. Soit une métrique ("P95 sous 250 ms"), un test réussi ("tous les tests e2e en vert tests/checkout/"), ou une liste de contrôle vérifiable ("la barre latérale du tableau de bord affiche le lien d'administration de Filament, les tests automatisés réussissent, aucune nouvelle erreur de console dans le journal de construction").
Une définition de done que le agent peut vérifier lui-même. Non "jusqu'à ce que tout semble bon". Non "jusqu'à ce que les performances soient acceptables". Le agent doit être capable d'exécuter une commande, d'observer un résultat et de décider en fonction de cette seule observation.

Comparez ces deux invites. Même intention. Comportement très différent :

Mauvais : /goal speed up the dashboard
Bon : /goal Reduce dashboard initial paint from current 2.4s baseline to under 1.0s on the staging environment. Success criteria: Lighthouse performance score above 90 on /dashboard, all existing e2e tests in tests/dashboard/ continue to pass, no new TypeScript errors in the build.

Le premier est un souhait. Le deuxième est un contrat. Codex peut exécuter des contrats. Il ne peut pas exaucer les souhaits – et pire encore, il fera semblant d’essayer.

Lorsque je ne sais pas comment rédiger le contrat, je fais quelque chose que les documents OpenAI Codex recommandent explicitement et que je refuse maintenant de sauter : je réfléchis à l'objectif avec Codex d'abord, en mode de discussion normal, avant d'exécuter /goal. Je décris le problème. Je demande à Codex quels critères de réussite vérifiables il proposerait. Je conteste cela. Je resserre les critères. Ensuite, et alors seulement, j'ouvre un fil de discussion propre et j'exécute /goal avec le contrat affiné. Cette étape de brainstorming représente peut-être dix minutes de travail et cela m'a évité des heures de gaspillage de jetons.

Ce que Codex fait réellement une fois l'objectif commencé

Laissez-moi parcourir la boucle, car la mécanique compte.

Lorsque vous tapez /goal <objective>, Codex fait quelque chose qui semble banal mais qui constitue en réalité le fondement de tout ce qui suit : il mappe le repository. Il lit les structures de fichiers, les configurations de clés et les manifestes de packages. Il esquisse un modèle de votre projet et de la manière dont il est câblé. Ce n'est pas gratuit – cela coûte des jetons – mais c'est la différence entre un agent qui écrit du code d'apparence plausible et un autre qui écrit du code qui correspond réellement à votre base de code. J'examine pourquoi ce type de chargement de contexte initial est important dans mon article sur context engineering, et /goal est l'une des expressions les plus claires de ce principe dans n'importe quel outil AI actuel.

Ensuite, ça planifie. Codex esquisse une séquence d'étapes qui, selon lui, permettront d'atteindre l'objectif. Il choisit la première étape. Il le gère. Le "en cours d'exécution" peut être n'importe quoi : édition de fichiers, exécution de commandes shell, exécution de tests, frappe d'un API, lecture de journaux. Ensuite, il évalue. L'étape a-t-elle modifié la métrique ? A-t-il passé les tests ? Cela a-t-il satisfait à un élément de la liste de contrôle ?

Si oui, il choisit l'étape suivante. Si non, il essaie une variante ou recule et essaie un angle différent. La boucle continue.

Vous pouvez regarder cela se produire en temps réel, et c'est véritablement hypnotique. Il y a un rythme. Lire, écrire, tester, observer, décider. Le agent ne vous attend pas. Ça marche juste.

Pendant que cela fonctionne, vous pouvez émettre des commandes. /goal pause termine l'étape en cours et arrête la boucle proprement : pas de modifications à moitié appliquées, pas d'appels d'outils orphelins. /goal resume reprend là où il s'était arrêté. /goal sans argument vous montre un résumé de la progression, des dépenses en jetons et du temps écoulé sans rien interrompre.

Et puis il y a /side.

/side <prompt> ouvre un fil de discussion éphémère qui ne perturbe pas l'objectif principal. La boucle principale continue de fonctionner. Vous pouvez poser une question à Codex : "attendez, quelle est la différence entre un gestionnaire de défilement anti-rebond et limité ?" - et obtenez une réponse dans un contexte séparé, puis revenez au fil de discussion principal pour continuer à regarder l'objectif se dérouler. Cela semble mineur. Ce n'est pas le cas. Avant /side, chaque interruption interrompait le flux du agent. Avec /side, vous pouvez vérifier l'intégrité des décisions, rechercher des informations sans rapport ou même lancer une petite expérience de clarification, le tout sans empoisonner le contexte de l'objectif principal.

C’est cette fonctionnalité unique qui m’a incité à faire confiance à /goal pour des courses plus longues. La capacité de demander sans interrompre change la relation de « Je dois m'engager pleinement et espérer » à « Je peux superviser sans saboter ».

Le problème du compactage que personne ne voit venir

C'est ici que les choses deviennent techniques et où se situe la différence entre une exécution /goal productive et une exécution vouée à l'échec.

agents de longue durée accumule le contexte. Chaque appel d'outil, chaque lecture de fichier, chaque résultat de test : tout cela s'accumule dans l'historique des conversations. Finalement, vous accédez à la fenêtre contextuelle du modèle et quelque chose doit céder. Codex gère cela avec l'invite compaction. Il résume les transformations précédentes en un mémoire plus serré, puis continue à partir de là.

Le compactage semble simple. Ce n'est pas.

Un bon compaction préserve ce qui compte : l'objectif, l'état actuel du travail, les choses qui ont fonctionné, les choses qui ont échoué et pourquoi, les contraintes, les préférences de l'utilisateur. Après un bon compaction, le agent reprend là où il s'était arrêté et le travail semble continu. Le mauvais compaction supprime le contexte durement gagné - la raison spécifique de l'échec d'une approche antérieure, le choix de configuration qui a rendu un benchmark valide, le compromis explicitement choisi par l'utilisateur. Après un mauvais compaction, le agent réessaye les approches qui ont échoué, pose à nouveau des questions réglées et s'éloigne lentement de l'intention initiale.

J'ai vu cela se produire sur un vrai projet. Codex exécutait un /goal pour optimiser un pipeline de requêtes de base de données. Vers le troisième compaction, le fait que j'avais explicitement choisi de ne pas participer à la dénormalisation a été perdu. Cela suggérait à nouveau une dénormalisation. Je l'ai attrapé parce que je regardais, mais si j'avais été AFK, le agent aurait passé une heure à emprunter un chemin que j'avais déjà fermé.

Il existe de bonnes recherches de la communauté sur la façon dont Codex compaction fonctionne réellement sous le capot — l'enquête de Simon Zhou et le résumé plus large de la recherche compaction valent tous deux votre temps si vous voulez les détails de la salle des machines. La version courte : la qualité compaction dépend de la façon dont le harnais agent résume, ce qu'il préserve et ce qu'il rejette. Codex est raisonnablement bon dans ce domaine, mais pas parfait, et les objectifs plus longs le soulignent davantage.

L'implication pratique pour les utilisateurs de /goal est petite mais importante : écrivez la définition de votre objectif dans le type de langage qui survit à compaction. Utilisez des numéros spécifiques. Utilisez des fichiers et des fonctions nommés. Énoncez explicitement les contraintes avec « ne pas » plutôt que « préfère ne pas ». Tout ce que vous dites une fois et supposez que le agent se souviendra est en danger. Tout ce que vous intégrez dans la définition de l'objectif lui-même est réinjecté à chaque limite d'itération, ce qui signifie qu'il survit à chaque compaction.

J'écris maintenant mes définitions d'objectifs comme si j'écrivais un contrat qui doit être lu à haute voix au début de chaque réunion, car c'est effectivement ce qui se passe.

L'environnement compte plus que le choix du modèle

C'est la partie de /goal qui m'a le plus surpris.

J'ai supposé que la différence entre une bonne course et une course médiocre dépendrait du modèle que j'avais choisi. Ce n’est pas le cas. La variable la plus importante dans la qualité du /goal, de loin, est l'environnement dans lequel le agent peut fonctionner.

Une exécution /goal est aussi bonne que les signaux disponibles pour le agent. Si l'objectif est de « réduire la latence P95 de 20 % » et que le agent n'a aucun moyen de mesurer la latence P95, l'objectif est invérifiable en pratique, quelle que soit la précision avec laquelle vous l'avez écrit. Le agent devinera. Il optimisera ce qu'il peut voir, espérera que cela corresponde à ce qu'il ne peut pas voir et produira des changements qui peuvent ou non faire évoluer la métrique réelle.

Les environnements riches produisent d’excellentes exécutions /goal. Riche signifie :

Vrais journaux. Journaux d'application, structurés et interrogeables, idéalement à partir d'un environnement de test qui reflète le comportement de production.
Un cluster de test ou de test. Distribué si l'objectif implique quelque chose lié au réseau. Le agent doit être capable d'effectuer une modification, de la déployer et d'observer.
Mesures de coûts et de performances. En direct, interrogeables, avec des lignes de base claires. Si le agent ne peut pas extraire les chiffres actuels, il ne peut pas décider si c'est fait.
Graphiques et profileurs de flammes. Pour les travaux de performance, ceci n'est pas négociable. Le agent ne trouvera pas un chemin privilégié en lisant uniquement le code source.
** Accès complet à la base de code avec autorisation de modifier, d'exécuter des tests et d'inspecter l'état de git. ** Une exécution de /goal qui doit demander l'autorisation pour chaque commande perdra son temps sur les invites d'approbation plutôt que sur la progression.

Pour les objectifs à haut risque ou gourmands en ressources – tout ce qui va consommer du processeur pendant des heures, marteler une base de données ou exécuter une longue suite de benchmarks – je ne les exécute pas sur ma machine locale. Je lance un VPS cloud, j'y clone le repo, j'exécute Codex depuis une session SSH et je le laisse fonctionner. Il ne s’agit pas seulement du coût des ressources. Il s'agit de ne pas avoir le ventilateur de mon ordinateur portable qui hurle pendant six heures pendant qu'une boucle de référence s'exécute. Il s'agit d'isoler l'environnement afin que "le agent ait cassé quelque chose" reste contenu.

Si vous avez attendu l'exécution de cloud-based agent, c'est le cas d'utilisation qui justifie enfin sa configuration correcte. Je couvre le modèle plus large dans [mon article de longue date sur le harnais agent] (https://www.mejba.me/blog/anthropic-long-running-agent-harness), et /goal s'insère dans ce modèle aussi proprement que tout ce que j'ai vu.

Le piège des branches Scrappy — et la boucle PRD qui le résout

Voici la chose la plus contre-intuitive que j'ai apprise sur les exécutions /goal, et c'est la leçon que j'aurais aimé que quelqu'un me donne avant de commencer.

Le résultat d’une exécution réussie de /goal n’est presque jamais du code que vous devriez expédier.

Cette phrase semblera fausse si vous ne l’avez pas vécue. Laissez-moi vous expliquer.

Une exécution /goal est, de par sa conception, exploratoire. Le agent est à la recherche d'une solution qu'il ne connaît pas à l'avance. Le chemin emprunté comprendra des impasses, des instructions d'impression de débogage, des valeurs codées en dur utilisées pour les tests, des commentaires comme // TODO: revisit this hack et des raccourcis qui fonctionnaient localement mais ne survivraient pas à la révision du code. Le agent n'est pas paresseux. Il s'agit de faire exactement à quoi ressemble un travail d'exploration lorsqu'un humain le fait : faire fonctionner quelque chose, valider l'approche, puis nettoyer. Sauf que /goal manque généralement de temps, de jetons ou de patience avant la phase de nettoyage.

Ce que vous obtenez est ce que j'appelle maintenant un "branch décousu". Ça marche. Cela déplace la métrique. Il satisfait à la définition de l’objectif. C’est aussi, souvent, un véritable gâchis.

Les premières fois que j'ai exécuté /goal, j'ai essayé de fusionner directement ces branch. Toujours une erreur. Je trouverais des impressions de débogage dans le code de production deux semaines plus tard. Je trouverais un hack qui dépendait d'un fichier spécifique existant uniquement dans le répertoire de travail du agent. Je trouverais des approches qui résolvaient l'objectif immédiat mais introduisaient une dette technique subtile.

Le correctif est un flux de travail, pas un indicateur de configuration. Une fois qu'une exécution de /goal s'est terminée avec succès, je traite le résultat comme une preuve de concept et non comme un livrable. J'ai lu attentivement le différentiel. J'extrais l'insight — la technique réelle qui a résolu le problème. Ensuite, j'écris un court PRD décrivant ce qui a été appris : l'approche, les compromis, les contraintes, les parties qui ont fonctionné et les parties qui doivent être nettoyées.

Ensuite, je jette le branch décousu.

J'ouvre un nouveau fil de discussion, donne à Codex le PRD en tant que spécification propre et exécute une tâche normale - un travail de catégorie un, selon ma définition précédente - pour implémenter la même idée sur une base de code propre. Le résultat est nettement meilleur. Aucune impression de débogage. Pas de hacks. Aucun tissu cicatriciel accumulé lors de la phase d’exploration. Juste une mise en œuvre propre d’une approche qui a maintenant fait ses preuves.

Ce modèle en deux phases – exploration via /goal, puis mise en œuvre via un flux de travail normal – est le modèle de codage AI le plus efficace que j'ai trouvé cette année. Cela reflète à quel point les bons ingénieurs humains travaillent réellement sur des problèmes difficiles. Vous explorez. Vous apprenez. Vous jetez la pointe. Vous construisez la vraie chose.

Quelques ingénieurs de la communauté Ralph-loop ont écrit sur autonomous coding piloté par PRD dans le même sens, et la convergence n'est pas une coïncidence. Le modèle fonctionne car il sépare deux types de cognition que le agent ne devrait pas faire simultanément : déterminer ce qu'il faut construire et bien le construire.

Mon cadre de décision pour /goal par rapport au flux de travail normal

Après deux semaines de tests, voici l'arbre de décision que j'utilise maintenant avant d'accéder à /goal :

Question 1 : Pouvez-vous décrire la différence avant de commencer ?

Si oui → workflow standard. Écrivez une invite ciblée, obtenez une réponse ciblée, consultez le PR. /goal n'ajoute rien ici.
Si non → passer à la question 2.

Question 2 : Pouvez-vous décrire l'objectif comme un résultat vérifiable et mesurable ?

Si oui → /goal est sur la table. Continuer.
Si non → tu n'es pas prêt. Réfléchissez à l'objectif en mode normal jusqu'à ce que vous puissiez rédiger un contrat clair.

Question 3 : Le agent a-t-il accès aux signaux qu'il doit vérifier ?

Si oui → /goal est le bon outil. Exécutez-le.
Si non → corrigez d'abord l'environnement. Ajoutez des métriques. Ajoutez un cluster intermédiaire. Ajoutez de vrais journaux. Puis réévaluez.

Question 4 : Une fois l'exécution terminée, traitez-vous le résultat comme un livrable ou un pic ?

Traitez-le comme une pointe. Toujours. Distiller l’aperçu d’un PRD. Exécutez une passe d’implémentation propre par rapport à la spécification affinée. Expédiez ça.

C'est ça. C'est le cadre. Cela m'a permis d'économiser de l'argent réel en jetons et des heures réelles de travail de nettoyage, et c'est l'objectif à travers lequel je lis désormais chaque démo de /goal sur Twitter.

Si quelqu'un vous dit que son code d'exécution /goal a été envoyé directement au main, je lui demanderais très poliment à quoi ressemble son taux de bugs dans deux semaines. Parce que j'y suis allé. La première manche est enivrante. Le nettoyage est le lieu où vit la leçon.

Où je pense que cela va ensuite

/goal est expérimental. Cela va évoluer rapidement. Quelques choses que je regarde :

La frontière entre l'exploration /goal et l'exécution de tâches structurées va s'estomper. Le modèle de boucle PRD que j'ai décrit ci-dessus sera probablement intégré à l'outil lui-même - distiller, refactoriser, implémenter - plutôt que de vivre comme un flux de travail manuel par-dessus. Une fois que cela se produit, l’écart entre « J’ai eu une idée » et « J’ai un PR propre » s’effondre considérablement.

Le problème de l’environnement va être résolu avec de meilleurs paramètres par défaut. À l'heure actuelle, obtenir un /goal suffisamment riche en signaux pour vérifier son propre travail est un exercice de configuration complexe. La plupart des projets ne l'ont pas. La prochaine vague d'outils agent sera livrée avec des environnements de test gérés, une observabilité intégrée et des modèles d'objectifs pour les cibles d'optimisation communes. Nous n’en sommes pas encore là. Nous le serons bientôt.

Les différences de qualité compaction entre les outils de codage AI vont devenir un facteur de sélection majeur. À l'heure actuelle, la plupart des ingénieurs choisissent un codage agent en fonction du modèle. Dans un an, ils choisiront en fonction de la manière dont le harnais gère le contexte sur des courses autonomes de plusieurs heures. Codex, Claude Code, Anthropic gérés par agents — le modèle n'est pas le fossé. Le harnais est.

Si vous souhaitez continuer à suivre cet espace, j'écris chaque semaine sur les nouveaux outils de codage AI, et la [couverture Codex / Claude Code est l'endroit où atterrissent la plupart des leçons pratiques] (https://www.mejba.me/blog/codex-vs-claude-code-subscription).

Questions fréquemment posées

Comment activer la commande Codex /goal ?

Ajoutez [features] suivi de goals = true à votre fichier ~/.codex/config.toml, enregistrez et redémarrez le Codex CLI. Vous pouvez également exécuter codex features enable goals, qui écrit automatiquement la même valeur. Vérifiez en exécutant codex --version et en confirmant que vous utilisez la version 0.128.0 ou ultérieure : /goal et /side apparaîtront dans la palette de commandes slash une fois activées.

La commande Codex /goal peut-elle être exécutée en toute sécurité sans surveillance ?

C'est plus sûr que d'exécuter une boucle Ralph arbitraire, mais je ne la laisserais pas s'exécuter complètement sans surveillance sur du code adjacent à la production. Utilisez un VPS cloud ou un environnement isolé, définissez un budget de jetons et examinez attentivement le branch résultant. Traitez le résultat comme un pic, et non comme un livrable – voir la section décousue branch ci-dessus.

Quand dois-je utiliser /goal par rapport à une invite Codex normale ?

Utilisez /goal uniquement pour les travaux exploratoires où vous connaissez la destination mais pas l'itinéraire : optimisations des performances, réductions de latence, recherches de bogues. Utilisez des invites normales pour toute tâche où vous pouvez décrire la différence avant de commencer. La plupart des travaux de codage réels appartiennent à la deuxième catégorie.

Quelle est la différence entre /goal et /side dans Codex CLI ?

/goal définit un objectif persistant et démarre une boucle autonome de longue durée. /side ouvre une conversation secondaire temporaire qui ne perturbe pas un objectif actif : vous pouvez poser des questions, rechercher des informations ou mener de petites expériences pendant que l'objectif principal continue de s'exécuter. Revenez au thread principal avec la touche d'échappement.

Pourquoi mon exécution /goal ne se termine-t-elle jamais ?

Presque toujours parce que l'objectif n'est pas vérifiable. Codex injecte « traiter l'incertitude comme non atteinte » dans chaque itération, de sorte qu'un objectif vague comme « rendre les choses plus rapides » boucle indéfiniment. Réécrivez l'objectif sous forme de contrat concret - métrique spécifique, tests nommés, liste de contrôle explicite - et la boucle se termine correctement lorsque les critères sont remplis.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
Portefeuille : mejba.me
Ramlit Limited (solutions d'entreprise) : ramlit.com
ColorPark (conception et image de marque) : colorpark.io
xCyberSecurity (services de sécurité) : xcybersecurity.io

Codex /goal command : mon avis honnête sur autonomous coding