J'ai commencé à traiter les agents de codage IA moins comme des fenêtres de chat et plus comme des travailleurs sous contrat. La différence ne réside pas dans le modèle. La différence réside dans le fait que l'agent sait quoi continuer à faire, comment prouver sa progression et quand s'arrêter.
C'est là que /loop et /goal prennent tout leur sens.
Claude Code expose désormais directement ces deux concepts : /goal pour une condition d'achèvement, et /loop pour des invites répétées tant qu'une session reste ouverte. OpenAI Codex dispose de /goal en tant que commande documentée, et OpenAI documente également les boucles d'amélioration pilotées par l'évaluation (eval) comme un flux de travail. Le détail important : je ne décrirais pas OpenAI Codex comme ayant la même commande slash officielle /loop, à moins que celle-ci n'apparaisse dans votre liste de commandes installées. Dans la documentation actuelle que j'ai consultée, /goal est officiel ; « loop » est un motif (pattern).
Cette distinction est importante car ces outils semblent similaires de l'extérieur, mais je les utilise pour des tâches différentes.
Réponse rapide
Utilisez /goal lorsque l'agent doit poursuivre un résultat durable jusqu'à ce qu'une condition claire soit remplie.
Utilisez /loop lorsque l'agent doit répéter une invite à intervalle régulier ou selon un rythme autonome tant que la session reste ouverte.
Utilisez une boucle pilotée par l'évaluation (eval) lorsque la sortie peut être notée et améliorée de manière répétée : qualité du code, qualité visuelle, performance, SEO, migrations, tests, ou toute tâche où chaque passage peut être mesuré.
La règle pratique est simple : un objectif a besoin d'une ligne d'arrivée ; une boucle a besoin d'un rythme ; les deux ont besoin de vérification.
Ce que fait Claude Code /goal
La référence des commandes de Claude décrit /goal [condition|clear] comme un moyen de définir une condition afin que Claude continue de travailler d'un tour à l'autre jusqu'à ce que cette condition soit remplie. La documentation des hooks ajoute un détail d'implémentation utile : /goal se comporte comme un raccourci intégré pour une condition d'arrêt limitée à la session.
En termes simples, /goal dit à Claude :
C'est puissant, mais seulement si la condition est concrète.
Faible :
text /goal Rendre l'application meilleure
Utile :
text /goal Corriger le bug du paiement, garder tout le comportement de paiement existant intact, et s'arrêter uniquement lorsque pnpm test, pnpm build, et le parcours de paiement Playwright réussissent tous.
La deuxième version donne à Claude une cible, des limites et une preuve. Il peut décider du chemin, mais pas redéfinir le succès en cours de route.
J'utilise /goal pour des travaux comme :
Dès qu'une tâche a plusieurs résultats non liés, je n'utilise pas un seul grand objectif. Je la divise. Un objectif par résultat est plus propre et plus facile à信任.
Ce que fait Claude Code /loop
La référence des commandes de Claude liste /loop [intervalle] [invite] comme une compétence groupée. Elle exécute une invite de manière répétée tant que la session est ouverte. Vous pouvez lui donner un intervalle, laisser Claude s'auto-rythmer, ou omettre l'invite et le laisser utiliser une invite de maintenance configurée lorsque cela est disponible.
Cela rend /loop plus opérationnel que /goal.
Exemples :
text /loop 5m vérifier si le déploiement de prévisualisation Vercel est prêt, puis vérifier /blog et /api/health
text /loop prendre le prochain élément non coché dans PRODUCTION_READINESS.md, le corriger, exécuter le test pertinent, puis mettre à jour la liste de contrôle
text /loop toutes les 10m vérifier le CI, résumer les échecs, et arrêter l'escalade uniquement après que la dernière exécution soit verte
Le meilleur cas d'utilisation est la vérification répétée ou les petites unités de travail répétées. Dans ma boucle hybride de revue de code IA→, le motif utile n'était pas « écrire indéfiniment ». C'était : prendre un élément de la liste de contrôle, l'implémenter, demander à un autre modèle de le réviser, exécuter la build, cocher la case, répéter.
C'est ce qui rend /loop dangereux si vous écrivez une invite paresseuse. Si l'invite ne dit pas quoi vérifier, l'agent peut continuer à faire un travail plausible que personne ne devrait croire.
Ce que fait OpenAI Codex /goal
OpenAI documente /goal pour Codex à la fois dans l'application et le CLI. Le guide Codex le présente comme un objectif durable pour un travail de longue durée, en particulier lorsque la tâche a une condition de réussite claire et une boucle de validation.
La référence des commandes CLI de Codex liste /goal comme la commande pour définir, mettre en pause, reprendre, afficher ou effacer un objectif de tâche. La documentation de l'application dit la même chose en termes de produit : un objectif est persistant, visible, et peut être mis en pause ou repris.
Un bon objectif Codex ressemble presque identiquement à un bon objectif Claude :
text /goal Terminer la migration vers Next.js 16 sans changer les routes publiques. S'arrêter uniquement lorsque pnpm build réussit, que la page d'accueil se charge, que /blog se charge, et que les routes modifiées retournent 200.
Pour Codex, j'aime les objectifs qui nomment :
Les propres conseils d'OpenAI pour les problèmes difficiles sont proches de ma façon de travailler : donner à Codex un système d'évaluation, faire des améliorations ciblées, relancer le score, inspecter les artefacts, et continuer jusqu'à ce que le score soit suffisamment bon.
C'est le cœur du travail agentique. Pas l'autonomie pour l'autonomie. L'autonomie liée à la mesure.
OpenAI a-t-il /loop ?
C'est là que les gens peuvent devenir négligents avec le wording.
Claude Code a une commande /loop documentée. OpenAI Codex a des flux de travail documentés de type boucle : boucles d'évaluation, boucles de réparation, mode objectif avec validation, hooks et automatisations. Mais dans la référence actuelle des commandes slash de Codex que j'ai consultée, j'ai trouvé /goal, /plan, /review, /status, /mcp, et bien d'autres, mais pas de commande officielle /loop équivalente à celle de Claude.
Donc ma formulation est :
Ce n'est pas une faiblesse. Cela change simplement la façon dont je le configure. Dans Codex, j'exprime généralement la boucle à l'intérieur de l'objectif ou de l'invite :
text /goal Améliorer ce composant jusqu'à ce que le score de régression visuelle soit supérieur à 95%. Faire un changement ciblé à la fois, exécuter la comparaison de captures d'écran après chaque changement, tenir un journal des scores, et s'arrêter lorsque la cible est atteinte deux fois de suite.
Cela donne à Codex le même rythme opérationnel sans prétendre qu'il existe une commande slash /loop séparée.
Ma configuration pratique
Pour un travail sérieux, j'utilise un motif en cinq couches.
1. Une cible écrite
Je commence par un court plan ou une liste de contrôle. Cela peut être `PLAN.md`, `PRODUCTION_READINESS.md`, un ticket GitHub, ou une simple invite. Le format importe moins que la vérifiabilité.
Une tâche faible dit « améliorer le système d'articles ».
Une tâche forte dit « empêcher la publication lorsque les URL externes retournent 404, un soft 404, un content-type erroné, ou une redirection vers la mauvaise cible ; garder les sauvegardes de brouillon autorisées ; le prouver avec une build et un cas de validation ciblé ».
C'est le genre d'instruction sur laquelle un agent peut continuer à agir.
2. Un modèle propriétaire
Choisissez qui pilote. Claude peut être l'implémenteur. Codex peut être l'implémenteur. Ne laissez pas les deux modifier les mêmes fichiers en même temps, sauf si vous avez des worktrees ou un passage de relais strict. L'autonomie sans propriété devient du théâtre de conflits de fusion.
3. Un deuxième avis
Pour les travaux à haut risque, j'aime toujours la revue de modèle à modèle. J'ai écrit sur mon pont de revue par les pairs IA→ car il détecte des modes de défaillance différents de ceux qu'un seul modèle vérifierait lui-même.
Le réviseur peut être en lecture seule. Il n'a pas besoin d'accès en écriture pour être utile. Il a besoin du diff, de l'objectif, des fichiers à risque, et de la permission de dire « c'est faux ».
4. Un validateur rigide
Les tests battent la confiance. Les builds battent les résumés. Les captures d'écran du navigateur battent « ça devrait s'afficher ». Les logs battent les intuitions.
Pour le travail web, cela signifie généralement :
bash pnpm build pnpm lint pnpm test
plus des vérifications de routes, des captures d'écran, ou des flux Playwright lorsque la tâche est orientée utilisateur.
Pour les flux de travail de contenu, ma préférence est l'assurance qualité des URL avant publication : non seulement « le lien a-t-il retourné 200 », mais « a-t-il atteint la page que l'article prétendait ? ». C'est le même principe. Le validateur doit vérifier ce que le lecteur expérimente réellement.
5. Une règle d'arrêt
C'est la partie que les gens sautent.
Une boucle sans règle d'arrêt devient coûteuse. Un objectif sans règle d'arrêt devient vague. Une règle d'arrêt doit être ennuyeuse et littérale :
Cette dernière ligne est importante. Les bons agents ne cachent pas l'incertitude. Ils la mettent en surface.
Quand j'utilise chacun d'eux
| Situation | Meilleur outil | Pourquoi |
|---|---|---|
| --- | ---: | --- |
| Une grande tâche avec une définition claire de « fini » | /goal | L'agent peut continuer à avancer vers un état final durable |
| Vérification du statut de déploiement toutes les quelques minutes | Claude /loop | La même vérification doit s'exécuter de manière répétée |
| Amélioration d'un artefact généré par rapport à un score | Boucle d'évaluation (Eval loop) | Le score indique à l'agent si le dernier passage a amélioré quelque chose |
| Nettoyage élément par élément d'une liste | /loop ou /goal | Utilisez /loop pour les éléments répétés, /goal pour le résultat final |
| Recherche avec une direction incertaine | Invite normale ou mode plan | Ne démarrez pas l'autonomie avant que la cible ne soit claire |
| Action de production sensible | Portail d'approbation humaine | Les agents peuvent préparer l'action, mais ne doivent pas l'exécuter silencieusement |
Invites à copier-coller
Claude Code /goal
text /goal Terminer cette correction de bug sans changer le comportement non lié. D'abord lire AGENTS.md et les fichiers de route/composant pertinents. Faire de petits commits uniquement dans la logique, exécuter pnpm build et le parcours de régression ciblé, et s'arrêter uniquement lorsque le bug original ne se reproduit plus et que toute la vérification réussit.
Claude Code /loop
text /loop prendre le prochain élément non coché dans TODO.md, inspecter d'abord les fichiers réels, faire une correction ciblée, exécuter la commande de validation pertinente, mettre à jour la case à cocher uniquement après vérification, et signaler tout blocage au lieu de le sauter
OpenAI Codex /goal
text /goal Terminer la migration décrite dans PLAN.md. Préserver le comportement public, garder les fichiers non liés inchangés, exécuter les commandes de validation listées après chaque jalon, tenir un court journal de progression, et s'arrêter uniquement lorsque chaque jalon est terminé et que la build finale réussit.
Invite de boucle pilotée par l'évaluation pour Codex
text Je veux ceci comme une boucle d'amélioration pilotée par l'évaluation. Trouver ou créer la commande qui note la sortie. Faire une amélioration ciblée à la fois, relancer le score après chaque changement, inspecter directement tout artefact généré, journaliser les changements de score, et continuer à itérer jusqu'à ce que le score cible soit atteint deux fois de suite. Si le score cesse de s'améliorer, expliquer le goulot d'étranglement et s'arrêter.
Erreurs courantes
La première erreur est d'utiliser /goal comme une phrase de motivation. « Rendre ceci prêt pour la production » n'est pas un objectif. C'est une humeur.
La deuxième erreur est d'utiliser /loop sans validateur. Si chaque itération se termine par une affirmation non vérifiée, la boucle n'est qu'une répétition.
La troisième erreur est de regrouper des travaux non liés. « Corriger l'authentification, refondre le tableau de bord, mettre à jour les tarifs et nettoyer le SEO » devrait être quatre tâches, pas une course autonome héroïque.
La quatrième erreur est de donner à l'agent un accès en écriture avant qu'il ne comprenne les règles du dépôt. Dans mes propres projets, je veux que les agents lisent `AGENTS.md`, respectent les règles de déploiement, évitent les secrets, et vérifient avant de revendiquer le succès. La couche de contrôle autour du modèle compte autant que le modèle. C'est pourquoi je reviens toujours aux flux de travail de développement MCP→ : les outils, les permissions, les preuves et les actions rejouables sont ce qui transforme un chat intelligent en un système opérationnel.
Le vrai point
La chose intéressante à propos de /loop et /goal n'est pas la syntaxe de la commande slash. La chose intéressante est le changement de responsabilité.
Une invite normale dit : réponds-moi.
Un objectif dit : termine ceci, et sais ce que « fini » signifie.
Une boucle dit : continue de vérifier ou d'améliorer jusqu'à ce que la condition change.
C'est ainsi que je veux que les agents de codage IA fonctionnent. Pas comme de la magie. Pas comme un chaos non supervisé. Comme des travailleurs avec un contrat, un validateur et une règle d'arrêt propre.
Si vous utilisez Claude Code, /loop est le moyen le plus rapide de transformer une vérification opérationnelle répétée en quelque chose que l'agent peut gérer pendant que vous continuez à travailler. /goal est le meilleur outil lorsque le travail a un état final durable unique.
Si vous utilisez OpenAI Codex, /goal vous donne l'objectif durable, et la boucle appartient à la conception de la validation : tests, évaluations, artefacts, hooks, journaux de progression, et une condition d'arrêt que l'agent ne peut pas redéfinir tranquillement.
C'est le motif auquel je fais confiance : pas « laisser l'IA tourner », mais « laisser l'IA tourner à l'intérieur d'un système qui peut lui dire non ».