For/Goal testé : Claude Code vs Codex ont créé mon app en 32 min

For/Goal testé : Claude Code vs Codex ont créé mon app en 32 min

J'ai démarré le chronomètre à 14h47 un mercredi. À 15 h 19, deux fenêtres de terminal sur mon moniteur gauche avaient chacune fini de créer une application Next.js fonctionnelle : flux d'intégration, tableau de bord, page de destination, écrans d'authentification, toute la forme d'un produit réel. Soixante-deux tâches de la feuille de route. Les deux applications. Trente-deux minutes chacun. J'avais rempli mon café.

C'est la partie où les démos sur Twitter coupent généralement un time-lapse de trente secondes et l'appellent un jour. Je veux vous montrer les coutures réelles. Parce que la fonctionnalité for/goal — la boucle autonome de longue durée qui a atterri dans Claude Code 2.1.139 et livrée dans Codex CLI 0.128.0 — ne ressemble qu'à de la magie. En dessous se trouve une recette très spécifique, et cette recette fait la différence entre un agent qui expédie une vraie application en une demi-heure et un agent qui boucle indéfiniment, réécrivant la même fonction cassée jusqu'à ce que vous tuiez le processus par pitié.

J'utilise /goal presque tous les jours depuis la suppression de la fonctionnalité. Deux projets parallèles. Même spécification de produit. Même feuille de route en six phases. Une exécution dans Claude Code, une dans Codex. Les deux ont fini. Les deux ont produit quelque chose que je pourrais git clone et faire une démonstration à un client demain. Ils ont également produit des applications très différentes à partir de la même invite, et les différences vous indiquent exactement quel agent contacter et quand.

C’est la panne que j’aurais aimé avoir avant de commencer.

Qu'est-ce que For/Goal en réalité - et pourquoi ce n'est pas simplement une autre commande Slash

Permettez-moi d’abord d’éliminer le langage marketing.

For/goal est un mode objectif persistant. Vous fixez un objectif une fois, l'agent le réalise sur plusieurs tours - parfois des heures, parfois une journée complète - et un deuxième modèle, plus petit, vérifie après chaque tour si l'objectif est réellement atteint. Si le validateur dit non, le modèle principal obtient ce « non » plus une raison en une phrase et continue de fonctionner. Si le validateur dit oui, la boucle se termine et votre terminal rend le contrôle. C'est toute sa forme.

Dans Claude Code, la commande est littéralement /goal. Il a été livré dans la version 2.1.139, publiée début mai 2026. Le validateur fonctionne sur le modèle que vous avez configuré comme petit modèle rapide – Haiku par défaut – et le coût du jeton du validateur est facturé séparément du budget du tour principal, ce qui est important lorsque vous exécutez un objectif pendant six heures.

Dans Codex CLI, la surface de commande est la même idée. Codex appelle la primitive de boucle for/goal, et les commandes slash dans la version 0.128.0 sont /goal, /goal pause, /goal resume, /goal clear, plus un fil de discussion /side pour poser une question rapide sans perturber l'exécution principale. Même architecture : le modèle principal fait le travail, le petit modèle juge l'achèvement.

Il s’agit, mécaniquement, d’une évolution du modèle de boucle Ralph – le one-liner bash que des ingénieurs comme Adam Tuttle et le repo snarktank ont ​​transformé en méthodologie au cours des douze derniers mois. Ralph était un wrapper while true autour de votre agent de codage, avec une commande de vérification à l'autre extrémité du canal. For/goal reprend cette idée et l'intègre dans l'agent lui-même, avec une véritable architecture de superviseur et un hook d'arrêt sensible à l'état.

Voici la partie qui m'a pris trois fois à intérioriser : ce n'est plus un chat. C'est un processus de travail avec une liste de contrôle. Vous ne lui parlez pas. Vous définissez la destination et vérifiez que la destination est accessible. L'agent fait le reste.

Ce qui semble simple. Ce n'est pas le cas, et je vais vous montrer pourquoi.

La configuration : un PRD, deux agents, soixante-deux tâches

L'application de test était un outil de révision de contenu, quelque chose entre un espace de travail de style Notion et une file d'attente d'annotations vidéo. Rien de bouleversant. Je l'ai choisi parce que la portée était suffisamment grande pour être intéressante (elle nécessitait une authentification, un concept d'espace de travail, une file d'attente de révision, un flux d'intégration et une page de paramètres) mais suffisamment petite pour que je puisse lire chaque fichier produit par l'agent et vous dire ce qui s'y trouvait réellement.

La spécification concernait cinq fichiers à la racine du projet avant que je touche à autre chose :

• prd.md — le document sur les exigences du produit. Environ 1 400 mots. Le public, le problème, les trois tâches principales que l'application devait effectuer, le modèle de données en anglais simple et une liste d'éléments hors de portée afin que l'agent ne dérive pas vers des fonctionnalités que je ne voulais pas. - productroadmap.mmd — une feuille de route Mermaid avec six phases et soixante-deux tâches feuilles. La phase 1 était l'échafaudage et l'authentification, la phase 2 était le concept d'espace de travail, la phase 3 était la file d'attente de révision, et ainsi de suite jusqu'à la phase 6, qui était le peaufinage et l'intégration. - design.md — direction frontale. Palette de couleurs, pile de typographie, préférences de densité de mise en page (« vues de tableau denses sur des grilles de cartes pour les pages de file d'attente ») et une liste de composants que je m'attendais à voir (tableaux de données, panneaux coulissants, palette de commandes). - claude.md — Fichier de règles au niveau du projet de Claude Code.

Pile épinglée sur le routeur d'application Next.js 15, TypeScript strict, Tailwind v4, shadcn/ui, pas de Redux, pas de composants stylisés, actions du serveur pour les mutations. - agents.md — Fichier de règles équivalent à Codex avec les mêmes contraintes, écrit dans le format préféré de Codex.

L’objectif que j’ai donné à chaque agent était identique, mot pour mot :

Créez l'application complète décrite dans prd.md en suivant les tâches dans productroadmap.mmd jusqu'à ce que toutes les tâches soient terminées et vérifiées. Utilisez design.md pour la direction de la conception frontale. Nouvelle version de l'application Next.js. Exécuter avec l'approbation automatique activée. Continuez jusqu'à ce que le validateur confirme que chaque tâche de la feuille de route est vérifiée et que l'application se construit et se nettoie.

Cette phrase de but fait beaucoup de travail. Permettez-moi de vous expliquer ce qui lui permet de survivre à une exécution autonome de trente minutes, car j'ai brûlé trois tentatives précédentes sur des formulations plus faibles avant d'arriver ici.

L'expression « jusqu'à ce que toutes les tâches soient terminées et vérifiées » est la condition d'arrêt. Il indique au validateur une chose concrète à vérifier – le fichier de feuille de route – au lieu de lui demander d'évaluer la qualité, ce qui est un travail que les petits modèles font terriblement. "Nouvelle version de l'application Next.js" est le plafond de la portée. Il indique à l'agent "n'essayez pas d'intégrer quoi que ce soit qui existe déjà dans ce répertoire, vous possédez l'intégralité de l'arborescence". Et "Exécuter avec l'approbation automatique activée" est l'autorisation accordée - sans elle, Claude Code en particulier s'arrêtera toutes les quarante secondes pour demander s'il peut installer un package.

Vous verrez ce qui se passe lorsqu'une de ces clauses manque dans quelques sections. Restez dans les parages pour la section des erreurs de la seconde période.

Comment écrire un objectif For/Goal qui se termine réellement

C'est la partie sur laquelle je veux ralentir, car la différence entre une course à but qui se termine et une course à but qui boucle pour toujours est presque toujours la phrase de but elle-même.

Une cible for/goal fonctionnelle comporte quatre parties, dans cet ordre :

1. Que réaliser. Un état final mesurable. Pas « rendez-le agréable ». Pas "améliorer le UX". Quelque chose que le validateur peut lire et répondre par oui ou par non sans porter de jugement. "Les soixante-deux tâches de la feuille de route marquées comme terminées dans le fichier." "La construction de la production passe." "Tous les tests Dramaturge sont verts."

2. Ce qu'il faut changer. Portée. Quels fichiers, quels répertoires, quelles surfaces l'agent est autorisé à toucher. Si vous ignorez cela, les agents autonomes refactoriseront le code adjacent avant d'atteindre leur objectif, et vous obtiendrez une comparaison de trente pages comprenant neuf fichiers que vous n'auriez jamais voulu toucher.

3. Ce qu'il faut valider. La commande ou le signal réel que le validateur doit rechercher. "pnpm build sort de zéro." "Le fichier de feuille de route ne contient aucun élément non coché." C'est ce qui est transmis au petit modèle rapide après chaque tour.

4. Quand s’arrêter. La condition de sortie. Généralement identique au signal de validation, mais parfois vous voulez une ceinture et des bretelles — "arrêtez lorsque le validateur confirme ET que les tests d'intégration ont été exécutés au moins une fois".

Un objectif plus grand qu’une simple invite mais plus petit qu’un retard illimité. C'est le point idéal en termes de taille. "Refactoriser cette fonction" est trop petit - il suffit de le demander. « Construire un SaaS » est trop ambitieux : l'agent n'a aucune idée de ce que cela signifie et cela va entraîner une spirale. "Créez l'application décrite dans prd.md jusqu'à ce que chaque tâche dans productroadmap.mmd soit vérifiée et que la version de production soit réussie" est exactement la taille pour laquelle /goal a été conçu.

Note latérale - J'ai testé cela un matin de week-end alimenté presque entièrement par l'espresso et l'entêtement. Les résultats auraient pu être différents un lundi avec un meilleur sommeil. Mais j'en doute. La discipline de rédaction des objectifs compte plus que le modèle vers lequel vous la présentez, ce qui est la leçon inattendue des deux derniers mois.

Exécutez-en un : Claude Code sur /goal

J'ai d'abord frappé /goal dans Claude Code. Collé la phrase de but. Regardé.

Le premier tour était un tour de planification. Claude Code a lu prd.md, lu productroadmap.mmd, lu design.md, lu claude.md, puis a imprimé un résumé d'un paragraphe de ce qu'il s'apprêtait à faire et a posé une question : "Plusieurs tâches de feuille de route font référence à des intégrations externes API - Stripe pour la facturation, Renvoyer pour les e-mails transactionnels, Supabase pour l'authentification et la persistance. Avez-vous des informations d'identification pour ceux-ci, ou dois-je créer avec des données fictives et des clients stubbés pour que l'application s'exécute hors ligne ? »

Cette seule question est le moment d’ingénieur le plus avancé que j’ai jamais vu un agent produire dans la nature. Il a identifié que l'application ne pouvait pas être complétée sans crédits externes, a reconnu que je n'en avais fourni aucun et a proposé une solution de secours qui lui permettrait de livrer quelque chose d'exécutable au lieu de bloquer. Je lui ai dit de construire hors ligne avec des simulations et une liste TODO clairement marquée de points d'intégration, et cela a continué.

À partir de là, cela a duré vingt-neuf minutes sans autre question.

Le modèle était le même à chaque tour : choisissez la prochaine tâche de feuille de route non vérifiée, lisez les fichiers pertinents, écrivez ou modifiez le code, exécutez une validation ciblée (pnpm tsc --noEmit pour les changements de type, pnpm lint pour les modifications de composants, pnpm build après les étapes majeures), cochez la tâche dans le fichier de feuille de route et revenez au validateur. Le validateur a répondu « non » après chaque tour sauf le dernier. Le « non » est revenu avec une raison d'une seule ligne — « Phase 3, tâche 4 toujours décochée » ou « Dernière construction passée il y a vingt minutes, vérifiez qu'elle passe toujours après les nouveaux composants » — et le tour suivant a commencé avec cette raison comme première entrée.

À la vingt-neuvième minute, le validateur a dit « oui ». Claude Code s'est arrêté, a résumé ce qu'il avait construit et a répertorié les points d'intégration TODO qu'il avait supprimés. J'ai vérifié le dépôt. Soixante-deux tâches cochées. Construction réussie. Nettoyer les peluches.

Ensuite, j'ai lu l'application actuelle.

La page de destination était dense en copies. Véritable hiérarchie de titres. Un bloc de témoignages avec trois personnages cités qui correspondent au public décrit dans le PRD. Un tableau de prix à trois niveaux, chacun ancré à un travail à effectuer à partir de la spécification. Le tableau de bord était riche en texte mais clairement structuré : barre latérale avec le sélecteur d'espace de travail, une barre supérieure avec le déclencheur de la palette de commandes, un panneau principal qui par défaut était la file d'attente de révision. La file d'attente de révision elle-même était une table dense avec des colonnes triables, exactement ce que design.md avait demandé. Il y avait un flux d'intégration en trois étapes et une microcopie propre.

L'authentification a été moquée. Connexion redirigée vers le tableau de bord après un faux délai. La session a été stockée dans un cookie avec un commentaire TODO pointant vers le point d'intégration Supabase. Le bouton de paiement Stripe a ouvert un modal qui expliquait ce qui se passerait lorsque l'intégration serait câblée. Chaque intégration externe était une couture clairement marquée, pas un appel interrompu.

C'était la version que j'envoyais à un client pour lui montrer à quoi ressemble son idée. Il ne survivrait pas au contact avec un utilisateur payant – l’authentification à elle seule est un incident de sécurité imminent – ​​mais il survivrait absolument au contact avec une réunion de démonstration le mardi.

Total écoulé : 32 minutes et 14 secondes. Deux cycles de validation Haiku m'ont coûté quarante-sept cents. Les dépenses en jetons de l'agent principal étaient, selon le calculateur de coûts, de 11,20 $ sur Sonnet 4.6.

Exécutez deux : Codex CLI sur /goal

J'ai effacé le répertoire, restauré les fichiers de spécifications, frappé /goal dans Codex.

Codex n'a pas posé la question env-vars. Cela vient juste de commencer.

C’est la première fois que les deux agents se séparent d’une manière qui compte. Codex supposait qu'il disposait d'une licence lui permettant de créer des simulations partout où des crédits externes manquaient. C’est – en fin de compte – ce que je lui aurais dit de faire de toute façon. Mais le comportement de Claude Code consistant à faire une pause pour confirmer est, pour le travail de production, la meilleure valeur par défaut. Le comportement de Codex consistant simplement à décider est le chemin le plus rapide lorsque la spécification est sans ambiguïté, et c'est la plupart du temps.

Le modèle d'exécution Codex était presque identique à celui de Claude Code au niveau de la boucle (planifier, agir, valider, répéter) mais la façon dont il séquence le travail était différente. Claude Code est passé étape par phase, terminant entièrement la phase 1 avant de toucher la phase 2. Codex a fonctionné de manière plus structurée : il a d'abord échafaudé l'ensemble du squelette de l'application (les six phases d'itinéraires vides et de stubs de composants), puis est revenu en arrière et les a remplis. C'est une chose que j'ai remarquée lors de plusieurs exécutions de Codex et ce n'est pas un bug - c'est ainsi que le modèle de planification dans Codex préfère décomposer le travail. Il construit d’abord la silhouette du produit fini, puis le sculpte.

Trente et un minutes, le validateur a dit oui. J'ai lu l'application.

Visuellement, l'application Codex était la plus jolie. Typographie plus propre (il a choisi Geist plutôt que l'Inter utilisé par défaut par Claude Code, ce qui correspond à la conversation de conception frontale que je commence à voir chez la plupart des concepteurs de produits seniors en 2026). La page de destination contenait de véritables images de produit : Codex extrayait des images d'espace réservé d'une collection Unsplash propre plutôt que de supprimer les composants Image avec des attributs src cassés comme Claude Code l'a fait une fois lors d'un test précédent. Les onglets étaient plus propres, les icônes étaient arrondies et le système d'accentuation des couleurs tirait les accents rouges du fichier de conception de manière cohérente sur chaque page.

Sur le plan fonctionnel, Codex a fait certaines choses que Claude Code n'a pas fait. La file d'attente de révision avait une édition en ligne : vous pouviez cliquer sur une pilule de statut et la modifier sans quitter la page. Le système de filtrage sur la file d'attente comportait trois filtres fonctionnels ainsi qu'une liste déroulante de vues enregistrées. La page des paramètres comportait une couche d'info-bulle qui expliquait chaque champ. Il y avait un espace de travail de démonstration pré-rempli avec du faux contenu, de sorte que l'état vide de chaque page affichait quelque chose au lieu d'un espace réservé « Ajoutez votre premier élément ».

Les pertes, car il y a toujours des pertes : deux icônes étaient cassées — Codex faisait référence à des noms d'icônes lucide-react qui n'existent pas dans la version actuelle, et j'ai dû les échanger à la main. La solution de secours d'authentification était intelligente mais fragile : le client fictif avait 50 % de chances de renvoyer l'utilisateur de démonstration lors de la vérification de la session, ce qui, j'en suis presque sûr, était un artefact de la façon dont Codex a écrit le stub et non une conception délibérée. La copie de la page de destination était clairsemée par rapport à celle de Claude Code – Codex a mis le vernis visuel en premier et a laissé les mots se dérouler.

Total écoulé : 32 minutes et 42 secondes. À peu près la même dépense symbolique. À peu près le même taux d’achèvement des tâches.

Deux agents. Même spécification. Même architecture de boucle. Différents produits.

Le côte à côte : ce pour quoi chaque agent est optimisé

Voici la comparaison que j'aurais voulu me remettre avant de commencer cette expérience.

1,20 principal + 0,47 $ validateur | À peu près équivalent |

Si vous recherchez le titre : Claude Code a écrit une meilleure histoire de produit, Codex a écrit une meilleure coque de produit. L'application de Claude Code se convertirait mieux sur une page de destination ; L'application Codex se sentirait mieux dans une démonstration de produit. Celui qui compte pour vous dépend entièrement de ce que vous expédiez.

Pour mon propre flux de travail, j'ai commencé à rechercher Claude Code sur les exécutions for/goal où le résultat doit communiquer - pages de destination, pages marketing, tout ce qui doit être lu comme une personne l'a écrit. J'utilise Codex sur les exécutions for/goal où la sortie doit se comporter : tableaux de bord, outils, applications internes avec beaucoup de surface d'interaction. Depuis, cette heuristique a été appliquée à une douzaine d’exécutions.

Ce que cela signifie pour ma façon de construire

Permettez-moi de faire un zoom arrière, car l'implication ici est plus grande que le choix de l'agent.

Depuis environ dix-huit mois, le modèle dominant dans le développement assisté par AI a été la boucle d'appel et de réponse. Vous demandez, l'agent fait une chose, vous révisez, vous demandez à nouveau. Même les meilleurs flux de travail que j'ai créés - et j'ai écrit sur la plupart d'entre eux, y compris le flux de travail à deux agents Claude Code et Codex et la boucle de planification Claudeex - étaient des variantes de l'appel et de la réponse avec une deuxième paire d'yeux ajoutée.

For/goal rompt ce modèle. L'agent ne demande pas la permission. L'agent a une destination, un budget et un validateur, et votre travail en amont de l'exécution consiste à écrire la destination suffisamment clairement pour que le validateur puisse reconnaître quand elle a été atteinte. Votre travail pendant la course consiste à être ailleurs. Votre travail après l'exécution consiste à lire le résultat et à décider ce qui est bon.

C'est un muscle différent. C'est plus proche de la rédaction d'un mémoire pour un entrepreneur que de la programmation en binôme. La compétence est dans la spécification, pas dans l'invite. Si votre PRD est précis, votre feuille de route est granulaire et votre document de conception est concret, for/goal vous rend rapide d'une manière que la génération précédente d'agents de codage ne pouvait pas faire. Si l'un de ces trois éléments est vague, for/goal produira une exécution magnifiquement terminée qui expédiera le mauvais produit.

La raison pour laquelle cela est important : pour la première fois, le goulot d'étranglement dans la construction assistée par AI n'est pas le modèle. C'est le travail de préparation. Et le travail de préparation est quelque chose dans lequel la plupart des ingénieurs – moi y compris – sous-investissent parce que cela ne ressemble pas à une construction. Le changement pour les forces /goal est que le travail de préparation devient le bâtiment. Le code est en aval de la spécification, et la spécification est l'endroit où réside désormais le jugement technique.

Je vous aurais dit il y a six mois que l'avenir du codage était l'orchestration multi-agents : Claude Code parlant à Codex parlant à Gemini, avec des transferts, des boucles de révision et des décisions consensuelles. Je pense toujours que cela en fait partie. Mais for/goal m'a fait réaliser qu'il existe un avenir plus simple en parallèle : une destination bien spécifiée, un agent compétent, une condition d'arrêt vérifiable. Aucune orchestration. Pas de transfert. Juste un but et une boucle.

Il est moins intéressant d’écrire des réflexions sur cet avenir. Il est plus intéressant d'expédier les produits.

Les erreurs que j'ai commises (et que vous ferez)

Trois erreurs sur mes dix premières courses for/goal, au cas où vous souhaiteriez ignorer les frais de scolarité.

Première erreur : j'ai donné à /goal un objectif vague. "Créer un outil de gestion de projet" au lieu de "créer l'application décrite dans prd.md jusqu'à ce que toutes les tâches de la feuille de route soient vérifiées et que la construction soit réussie." L'agent a fonctionné pendant deux heures, a produit six versions différentes d'une page de paramètres et ne s'est jamais arrêté car il n'y avait aucun signal concret à vérifier par le validateur. La solution : pointez toujours le validateur vers un fichier ou une commande, jamais vers une sensation.

Deuxième erreur : j'ai oublié d'activer l'approbation automatique. Sans cela, Claude Code en particulier fera une pause pour demander l'autorisation pour chaque installation de package, chaque suppression de fichier, chaque commande shell en dehors d'une petite liste blanche. Pour une exécution de soixante-deux tâches, cela signifie que l'agent s'arrête environ quarante fois pour demander, ce qui rend tout l'intérêt de l'autonomie à long terme sans objet. Activez-le explicitement dans votre phrase d'objectif - "exécuter avec l'approbation automatique activée" - ou définissez-le dans votre configuration avant de commencer.

Troisième erreur : j'ai laissé l'agent inventer la spécification au cours de l'exécution. Je lui ai donné un briefing d'une page et j'ai dit "Découvrez le reste". Il l'a compris. Le reste n'était pas ce que je voulais. For/goal ne remplace pas la réflexion sur ce que vous construisez. C'est un substitut à taper ce à quoi vous avez déjà réfléchi. Ce sont des compétences différentes. Le premier vit toujours avec vous.

Il existe une version plus profonde de la troisième erreur, sur laquelle personne n'écrit : les agents qui fonctionnent depuis longtemps sont très doués pour donner l'impression que n'importe quelle spécification est correcte une fois qu'elles ont terminé. Le produit final aura l'air soigné, passera son propre validateur, semblera accomplir chaque tâche - et sera exactement aussi bon que la spécification avec laquelle vous avez commencé, pas mieux. Si la spécification était fine, le produit poli est un produit mince portant une chemise propre. L’agent ne va pas s’opposer à une réflexion sur le produit faible. C'est toujours de ta faute.

C'est la partie de for/goal à laquelle il faut le plus s'habituer, en particulier pour les ingénieurs qui ont appris à construire en itérant avec un coéquipier. Le coéquipier est désormais le validateur, et le validateur lit un fichier de feuille de route, et non votre feuille de route. Si la feuille de route est erronée, la boucle construira fidèlement la mauvaise chose. Le travail qui était effectué lors de la mise en œuvre doit désormais être effectué avant que vous appuyiez sur Entrée pour atteindre l'objectif. Ce changement de mentalité est la seule compétence qui sépare les ingénieurs réalisant des fonctionnalités de deux semaines en un après-midi des ingénieurs réalisant des fonctionnalités de deux semaines en huit heures de boucles frustrantes.

Je suis encore en train de m'adapter. La discipline consistant à rédiger une feuille de route qu'un agent peut exécuter fidèlement est véritablement différente de la discipline consistant à rédiger une feuille de route que vous pouvez exécuter, car vous et l'agent échouez de différentes manières. Vous dérivez. L'agent ne le fait pas. Vous compensez l’ambiguïté en exerçant votre jugement sur le moment. L'agent compense l'ambiguïté en inventant des détails, souvent erronés. La feuille de route doit donc être plus stricte que celle que vous écririez vous-même. C'est la nouvelle forme de l'œuvre.

Quand atteindre For/Goal - Et quand ne pas le faire

Trois catégories de travail où for/goal gagne sa vie :

Échafaudage d'application de premier passage à partir d'une spécification claire. Exactement l'expérience présentée dans cet article. Vous disposez d'un PRD, d'une feuille de route, d'un document de conception. Vous voulez un shell exécutable avec la plupart des surfaces en place. For/goal est imbattable ici. Trente-deux minutes pour ce qui prendrait presque une semaine à un ingénieur junior.

Refactors à long horizon avec des états finaux mesurables. "Migrez chaque composant de ce répertoire de la syntaxe de classe à la syntaxe de fonction jusqu'à ce que pnpm tsc --noEmit réussisse." "Convertissez toutes les récupérations de données useEffect en actions du serveur jusqu'à ce qu'aucun useEffect ne fasse référence à fetch nulle part dans la base de code." Tout ce qui a une condition d'arrêt mesurable et une trajectoire mécanique. Les gens de Ralph-loop font ça depuis un an ; for/goal en fait simplement une fonctionnalité de première classe.

Campagnes de correction de bugs. "Résolvez chaque erreur TypeScript dans le dépôt sans modifier le comportement d'exécution." Le validateur vérifie le nombre d'erreurs. L'agent le ramène à zéro. Rentre à la maison.

Trois catégories où for/goal n'est pas le bon outil :

Tout ce qui nécessite un jugement sur le produit en cours de vol. "Améliorez le flux d'intégration." Ce n'est pas une destination, c'est une opinion. L'agent produira quelque chose. Il ne produira pas ce que vous vouliez à moins que vous n'ayez d'abord écrit ce que vous vouliez dans la spécification. Invitez-le simplement.

Tout ce qui concerne les systèmes de production. For/goal est destiné aux environnements où le pire résultat est « l'agent a perdu mon après-midi ». Pas "l'agent a effacé une base de données". L'approbation automatique et l'accès à la production sont une catégorie d'erreurs que je voudrais qu'aucun d'entre nous ne commette.

Tout ce dont le validateur doit évaluer la qualité. Les petits modèles ne peuvent pas répondre « ce code est-il bon ? » de manière fiable. Ils peuvent répondre « est-ce que cette commande sort de zéro ? de manière fiable. Concevez votre question de validation autour de ce pour quoi les petits modèles sont bons - des décisions yes/no avec des signaux concrets - ou votre boucle s'arrêtera tôt ou ne s'arrêtera jamais du tout.

Si votre travail ne correspond pas à ces trois « bonnes » catégories, vous souhaitez probablement la boucle de discussion habituelle Claude Code ou Codex, et non /goal.. La plupart de mon vrai travail réside toujours dans le chat normal. For/goal est l'outil spécialisé que j'utilise deux ou trois fois par semaine, pas le conducteur quotidien.

Ce que je ferais différemment la prochaine fois

Trois petites choses que je modifierai lors de ma prochaine expérience for/goal.

J'ajouterais un fichier tests.md à côté de prd.md et demanderais à l'agent d'écrire des tests d'intégration pour les chemins critiques en tant que phase 0, avant tout UI. Les tests deviennent alors le signal d’arrêt du validateur, bien plus fort que « toutes les tâches de la feuille de route cochées ». À l'heure actuelle, la boucle fait confiance à la propre vérification par l'agent que la feuille de route est complète ; si les tests étaient vrais, l'agent ne pourrait pas se mentir.

I'd tighten the design doc. Mon design.md contenait environ trois cents mots de préférences. Le prochain sera composé de six cents mots avec des modèles de composants spécifiques appelés : jetons d'espacement exacts, échelle de police exacte, hiérarchie exacte des boutons. Je veux donner à l'agent moins de marge pour inventer un jugement de conception, car les moments où Claude Code et Codex divergent le plus fortement sont les moments où le document de conception est resté silencieux et où ils ont chacun choisi une valeur par défaut différente.

J'exécuterais le même objectif dans les deux agents et un troisième - Gemini 3 Pro via son nouveau CLI, que je n'ai pas encore testé sous contrainte sur cette durée d'exécution. Si deux agents divergent autant sur la même spécification, je veux savoir ce que me donne un troisième. That's a post for next month.

Le changement de mentalité, énoncé clairement

Voici ce à quoi je reviens sans cesse.

Il y a six mois, créer une application m'impliquait d'écrire du code avec l'aide d'un agent. L'agent a été un accélérateur sur le travail. J'étais le moteur.

Aujourd'hui, avec for/goal, créer une application signifie que j'écris une spécification avec l'aide d'un agent, puis que je la remets à un autre agent et que je lis ce qui revient. L'agent est le moteur. Je suis l'architecte.

Cette phrase est facile à écrire et difficile à vivre. La plupart du temps, j'ouvre toujours par défaut l'éditeur et j'écris moi-même le premier composant, car c'est le mouvement que j'ai fait dix mille fois. La discipline consistant à ne pas faire cela – rester dans le fichier de spécifications pendant une heure supplémentaire, écrire la question du validateur au lieu de l'implémentation – est la nouvelle compétence. Les ingénieurs qui le développent en premier sont ceux qui expédieront cinq produits dans le temps qu'il fallait pour en expédier un.

Les deux terminaux sur mon moniteur gauche à 15h19 ce mercredi après-midi n'étaient pas, rétrospectivement, la partie la plus impressionnante. Ce qui est impressionnant, ce sont les quatre heures que j'ai passées la journée avant de rédiger le PRD, la feuille de route et le document de conception. Les agents ont exécuté en une demi-heure ce qui m'aurait pris une semaine. La réflexion qui a rendu possible la demi-heure a quand même pris la journée.

C'est le commerce. Je suis presque sûr de le vouloir.

Questions fréquemment posées

Qu'est-ce que for/goal dans Claude Code et Codex ?

For/goal est un mode objectif persistant dans lequel l'agent travaille de manière autonome sur plusieurs tours jusqu'à ce qu'un petit modèle de validateur confirme qu'une condition d'achèvement définie est remplie. Dans Claude Code, il est livré sous le nom de /goal dans la version 2.1.139 ; dans Codex CLI, la même primitive se cache derrière /goal et les commandes slash associées dans la version 0.128.0. Voir « Qu'est-ce que For/Goal ? » ci-dessus pour connaître la mécanique complète.

Combien de temps une exécution for/goal peut-elle durer ?

Les courses For/goal sont limitées par le budget que vous définissez (tours, jetons ou temps d'horloge murale) plutôt que par un plafond rigide. J'ai vu des exécutions d'échafaudage de 32 minutes et des exécutions de refactorisation du jour au lendemain réussir. Le plafond pratique est votre budget symbolique et votre volonté de laisser la boucle se poursuivre sans supervision.

For/goal est-il identique à la boucle Ralph ?

For/goal est une évolution du modèle de boucle Ralph. Ralph était un wrapper bash while true autour d'un agent de codage avec une étape de vérification externe ; for/goal intègre la même idée dans l'agent lui-même avec une architecture de superviseur intégrée et un hook d'arrêt sensible à l'état. Même forme, mécanique plus propre, meilleure intégration du validateur.

Ai-je besoin d'un PRD pour utiliser for/goal ?

Vous avez besoin d’une destination claire basée sur un fichier. Un PRD et une feuille de route constituent la combinaison la plus fiable, mais vous pouvez également pointer /goal vers une suite de tests, une commande de build ou une métrique mesurable. La règle est la suivante : le validateur doit être capable de répondre « l'objectif est-il atteint ? avec une décision oui ou non basée sur un signal concret et non sur un jugement de qualité.

Quel est le meilleur pour for/goal — Claude Code ou Codex ?

Ni l’un ni l’autre n’est strictement meilleur. Lors de mes tests, Claude Code produit des résultats plus communicatifs : pages de destination, surfaces marketing, pages contenant beaucoup de copies, lues comme si une personne les avait écrites. Codex produit une sortie plus riche en interactions : les tableaux de bord, les outils internes, les surfaces avec des cellules et des filtres modifiables semblent plus soignés dès le départ. Choisissez selon ce que vous expédiez.

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