99% des gens utilisent /goal et les boucles de manière incorrecte.
Le battage médiatique qu'ils entendent, c'est « des boucles longues qui pilotent un agent autonome » : pointez-le vers une tâche, partez, revenez pour du code qui fonctionne.
Mais les meilleurs ingénieurs en agentic font ça sans /goal depuis 6 mois (depuis la sortie de GPT-5.2 et Opus 4.5). Ça s'appelle harness engineering + spec-driven development :
- construire un harnais pour que l'agent observe le problème
- écrire un cahier des charges serré avec tous les cas de test
- laisser Codex ou Claude Code boucler sans surveillance jusqu'à ce que tous soient satisfaits.
Je lance ces runs régulièrement la nuit — 2 à 5 heures par exécution. En avril, l'un d'eux a résolu un bug de cache de build Turbo dans notre monorepo Vercel et tout était vert au matin. Aucun /goal n'est réellement nécessaire.
Alors, à quoi sert vraiment /goal ?
Voici ce qu'un seul prompt a accompli pendant mon absence :
- ~30 heures, 6 300 lignes de code, 92 000 pages explorées, 40 $ dépensés en API
- Cloner la boucle centrale d'un autre produit — toute l'architecture a été rétro-conçue à partir de zéro
- Notre version produisait des résultats ~50× meilleurs que le produit de référence sur les mêmes requêtes. (Il s'agit d'une nouvelle couche de données qui alimentera newsjack.sh — les compétences open-source de news-intel sur lesquelles je travaille)
Le secret est le développement par fonction de perte (Loss Function Development, LFD) : vous écrivez un objectif que l'agent doit optimiser, pas un cahier des charges à construire.
C'est un exemple concret du tweet de Peter, mis en œuvre.
Le cahier des charges utilisé dans le spec-driven development devient désormais le point de départ, et non plus la ligne d'arrivée.
Il m'a fallu quelques expérimentations pour bien faire les choses. Mais voici le guide complet — il faut d'abord commencer par comment ça s'est mal passé pour que vous compreniez comment concevoir ces /goal.
L'agent a triché 3 fois.
Tout a commencé comme d'habitude : un cahier des charges.
J'ai simplement pointé Codex vers le site public de l'autre produit : « comment pouvons-nous construire ça nous-mêmes ? ». En 30 minutes, il est revenu avec une architecture système complète et des cas de test — le cahier des charges.
Mais cette fois, j'ai essayé un prompt différent.
« /goal implémente jusqu'à ce que ta sortie corresponde exactement à la leur »
Et voici ce qui s'est passé :
Boucle 1 (5 minutes)
L'agent a pris l'ensemble d'évaluation, généré des données initiales qui le reflétaient, et a déclaré victoire en cinq minutes.
« 100% de rappel, zéro généralité » — un moteur de recherche qui ne pouvait trouver que les 30 choses que je lui avais données lol.
Correction → le rendre aveugle. L'évaluation cachée pendant l'exécution, révélée seulement lors du scoring, avec une liste d'échecs par élément.
Boucle 2 (20 minutes) - aveugle, 30 éléments.
J'ai rendu l'agent aveugle à l'ensemble d'évaluation, mais il a appris par les échecs — chaque « tu n'as pas trouvé X » devenait un mot-clé au cycle suivant. Après quelques boucles : il utilisait exactement 30 mots-clés, un par élément, et il a « gagné » à nouveau.
Correction → élargir l'ensemble d'évaluation. Des centaines d'éléments à scorer, trop nombreux pour être énumérés.
Boucle 3 (30 minutes) - aveugle, 200 éléments.
Après avoir ajouté 200 éléments au nouvel ensemble d'évaluation, l'agent a encore triché.
Assez drôle, l'agent a quand même énuméré. La liste de mots-clés a gonflé jusqu'à des centaines, chaque terme étant un appât précis pour le prochain échec.
Trois rounds, trois tricheries.
C'est là que j'ai compris : l'agent ne faisait qu'optimiser.
La tricherie n'était pas un bug dans l'agent. C'était un bug dans ma cible : je lui ai dit où aller et j'ai laissé tous les raccourcis grands ouverts.
Chaque chemin bon marché que tu ne barricades pas est une direction dans laquelle l'optimiseur va s'engouffrer. Et ma cible initiale avait sauté toutes les barrières.
Boucle 4 (30 heures) - aveugle, 200 éléments, limites strictes.
J'ai donc commencé à bloquer des directions. Limiter la liste de mots-clés, rendre l'évaluation aveugle, élargir la date — chaque correction fermait un chemin bon marché de plus, jusqu'à ce que la seule direction restante qui faisait bouger le chiffre soit de devenir réellement meilleur dans la tâche.
Il a arrêté de tricher.
Puis il a tourné. ~30 heures de calcul, 92 000 pages explorées, ~40 $ en tokens, 6 300 lignes de code.
Il s'avère que le produit que nous prenions comme référence était le plancher, pas le plafond : nous avons fini par obtenir ~50× plus de résultats sur les mêmes requêtes.
(Le parcours complet et les preuves ici pour les curieux)
Développement par fonction de perte (LFD) - l'anatomie d'une bonne fonction de perte
Quand la plupart des gens essaient de construire un produit, ils utilisent des agents pour passer de zéro à livré en quelques heures.
Mais le piège, c'est ce qui vient après — la longue traîne. Les cas limites que le cahier des charges n'a jamais imaginés ne se révèlent qu'en production, un journal d'erreur à la fois. Vous les corrigez un par un. Les cas que vous ne rattrapez pas dans les logs sont signalés par les utilisateurs, ce qui est la manière la plus coûteuse de trouver un bug.
J'ai automatisé le bout bon marché de ce processus. Mon agent OpenClaw Zoe surveille les logs d'erreur chaque jour et génère des Codex sur les nouvelles erreurs dès qu'elles apparaissent, créant des PR — c'est à peu près aussi serré que cette boucle peut l'être. (Configuration complète documentée ici
La traîne prend encore des mois. C'est pourquoi construire un bon produit prend encore du temps même avec des agents qui font le travail.
LFD accélère la traîne. Si vous pouvez obtenir en amont des exemples réels de sortie attendue — ce à quoi ressemble le « bon », à grande échelle — vous effectuez le rodage avant de livrer : des centaines de cas limites frappent l'agent en une seule optimisation, pas un goutte-à-goutte trimestriel de rapports de bugs. Et la raison pour laquelle cela devient soudainement réalisable est que pour de plus en plus de problèmes, ces exemples sont simplement publics.
Spec-driven development :
Construis ça. Fais passer les tests.
Loss-function development :
Construis ça. Fais passer les tests. Ensuite itère sur ces 1 000 cas d'évaluation.
Une suite de tests est finie — terminée dès qu'elle est verte. Une évaluation de 1 000 cas à 95% est une cible vers laquelle vous descendez ; il n'y a pas de sortie autre que l'atteinte du seuil. Cela compte car l'agent prend des centaines de décisions que vous ne verrez jamais, et chacune se résout en fonction de quelque chose. Si vous n'avez pas écrit la cible, l'agent en choisit une — et comme les rounds 1 à 3 l'ont montré, il choisit la moins coûteuse à satisfaire.
La fonction de perte est plus grande que l'évaluation. Elle comporte 4 éléments : la cible, les contraintes, les instruments et l'entropie forcée. Quatre pièces.
1. Cible
- Assez grande pour que l'énumération ne paie pas. Une évaluation de 28 éléments a été mémorisée en un round. Plus il y en a, mieux c'est.
- Rendre l'agent aveugle au corrigé. Les données d'évaluation n'existent que pour le scoring post-hoc. Si l'agent peut voir les réponses pendant l'exécution, il trouvera un moyen de les regarder.
2. Contraintes
Ce que l'agent a le droit de faire, et ce qu'il n'a pas le droit de faire.
- Le temps est la contrainte que l'agent oublie toujours. Les agents n'ont pas de notion du temps. Ils peuvent grinder pendant 10 heures pour un gain de 2% parce que la métrique bouge nominalement. Mais une solution à 80% en 2 heures bat une solution à 100% terminée en 30 jours. Solution : fixer un budget de temps réel.
- Argent. Des limites strictes sur chaque appel payant : crédits de crawler, dépenses LLM, plafond total en dollars sur une clé jetable.
- Surface. Tous les fournisseurs, modèles autorisés, plafonds de concurrence. Isoler l'agent aux seules choses que vous voulez qu'il touche.
- Méthodologie. L'analyse LLM est-elle autorisée, ou seulement la logique déterministe ? À quelles sources de données l'agent a-t-il accès ? Énoncez-le clairement.
3. Instruments (le harnais)
Une contrainte sans instrument est un vague sentiment — l'agent la violera joyeusement parce qu'il ne peut pas savoir qu'il la viole. Pour chaque contrainte ci-dessus, fournissez une commande CLI que l'agent peut utiliser pour l'inspecter.
- Mesure de la cible, à la bonne résolution. Choisissez l'instrument de mesure avec soin. Exemple réel : un juge naïf qui fait « évaluer deux captures d'écran par LLM » approuve des clones d'interface avec des erreurs de 12px, car les LLM ne peuvent pas voir les images, ils les convertissent en embeddings puis comparent les embeddings. Donc si vous voulez des clones d'interface pixel-perfect, donnez à votre agent un outil de comparaison pixel par pixel. Puis /goal jusqu'à ce que la différence soit 0.
- Comptabilité temporelle. Horodatez chaque exécution et chaque étape. L'agent doit savoir combien de temps chaque étape a pris, le temps total écoulé. Le temps est un instrument de première classe, pas une note en bas de page.
- Budget fournisseur. « Combien brûlons-nous sur les crawlers en ce moment ? » devrait être une seule commande, pas une estimation. Suivez les crédits de scraping restants, la consommation de cette boucle, la consommation cumulée, et la consommation projetée avant le prochain lot payant.
- Dépenses LLM. Donner une clé API LLM à utiliser dans le plan de données peut simplifier beaucoup de logique. Mais l'agent doit les dépenser de manière responsable, en sachant d'abord combien il dépense réellement.
- Utilisation de Codex. Celle-ci est un peu méta. La boucle doit être consciente d'elle-même : combien de tokens est-ce que je dépense sur cette optimisation ? Utile pour connaître le gradient de l'étape d'optimisation actuelle.
Le modèle est le même vieux dicton : vous ne pouvez pas optimiser ce que vous ne pouvez pas voir.
Si vous débutez avec ces boucles, ne lancez pas et partez. Asseyez-vous avec le premier cycle. Regardez ce qu'il touche. Confirmez que le harnais que vous avez construit est bien utilisé. Puis allez vous coucher. (Et essayez de vous endormir sans penser à ce que vous trouverez au réveil)
4. Entropie forcée
Pourquoi l'entropie forcée est importante : chaque boucle continue à partir du contexte entier de l'exécution précédente. Le modèle ne repart pas de zéro — il lit ses propres cent dernières décisions et le gradient qui a fonctionné jusqu'à présent.
Dans une boucle /goal, atteindre un maximum local est l'état par défaut. Sans un coup de pied explicite, l'agent continue de monter la même colline, et « la même colline » est là où il se trouvait quand il a cessé de s'améliorer.
Par exemple, si un petit réglage améliore le résultat de 0,1%, l'agent continuera de tourner ce même bouton même s'il en a 1000 autres à essayer.
L'entropie doit être forcée dans l'exécution de manière explicite, car le modèle ne le fera pas de lui-même :
- Réflexion sur le surapprentissage à chaque cycle. Est-ce que je construis une solution plus générale, ou est-ce que je mémorise l'évaluation ? Si c'est de la mémorisation, la prochaine modification doit supprimer un artefact lié à l'évaluation (limiter une liste, masquer une fonctionnalité, élargir l'évaluation, rejeter une donnée initiale), pas en ajouter un.
- Forcer l'entropie en cas de stagnation. Si le dernier cycle n'a pas fait bouger la métrique, le suivant ne peut pas être « même idée, plus fort ». Le modèle doit faire un saut réel non évident — « sortir des sentiers battus » est un bon prompt - empêche l'agent de simplement tourner le même bouton plus fort.
- Tenir un journal des itérations. Faites en sorte que l'agent consigne l'hypothèse, le mode de défaillance attendu, le diagnostic à chaque étape, afin de pouvoir revenir en arrière et réfléchir entre les compressions.
Le méta-méta-prompt
J'écrivais ces objectifs moi-même, puis j'ai rapidement appris que c'est aussi un travail pour les agents.
J'ai donc écrit une compétence qui produit ce type d'objectifs pour une bonne exécution de loss-function-development.
Maintenant open-sourcé ici :
https://github.com/elvisun/loss-function-development
/lfd-design pour générer le harnais et l'objectif
Descente de gradient jusqu'en bas : les deux boucles
Prenez du recul et c'est de la descente de gradient jusqu'en bas.
La boucle interne est l'agent : écrire du code, exécuter les tests, corriger. Horizon court, feedback rapide, un seul objectif — faire passer les tests. C'est la boucle interne d'un développeur, et le spec-driven development est la manière de l'exécuter. Les agents de codage l'ont déjà automatisée.
La boucle externe est /goal : piloter tout le système vers une métrique de résultat sur plusieurs cycles — livrer, mesurer, changer de cap, descendre. Horizon long, feedback rare. C'est traditionnellement la boucle d'une équipe produit, les mois de livraison-mesure-itération compressés en une seule exécution.
Les deux boucles sont désormais automatisées. Ce qui vous reste est la définition de la fonction de perte — vers quoi exactement /goal doit optimiser et de quelle manière.
Vous distillez un produit — ou tout ce qui laisse un artefact public
Autre perspective : c'est essentiellement de la distillation, déplacée du temps d'entraînement au temps de prompt. C'est ainsi que la lignée DeepSeek, Kimi, Minimax a comblé la plupart de l'écart avec GPT et Claude — entraînez votre modèle sur les sorties de quelqu'un d'autre jusqu'à ce que les vôtres les reproduisent.
Mais au lieu de distiller un modèle, vous pouvez maintenant utiliser /goal et LFD pour effectuer un ajustement de distillation sur n'importe quels artefacts publiquement trouvables — cela n'inspecte jamais les entrailles et n'en a pas besoin.
Appuyez sur le mot publiquement. Distiller la production de quelqu'un protégée par des CGU, un mur de connexion ou payante n'est pas justifiable. Mais ce qui est publié en libre accès — les sorties qu'une entreprise livre pour gagner des clients — a toujours été juste à apprendre. Cette partie n'est pas nouvelle — c'est la plus vieille astuce du logiciel. Ce qui est nouveau, c'est que c'est maintenant bon marché et peut être fait en heures au lieu de mois.
Prenez du recul, et voici le changement majeur. Le coût d'exécution s'effondre à ~0 $ là où il y a symétrie d'information — quand les sorties sont publiques, tout le monde peut voir à quoi ressemble le « bon », donc n'importe qui peut le distiller en un week-end pour 40 $.
Voici donc un nouveau fossé qui devient de plus en plus précieux : l'asymétrie d'information.
L'entreprise open-source canonique a déjà cillé. En avril 2026, cal.com (5 M$ de chiffre d'affaires annuel récurrent) a rendu son code de production privé et est passé en closed-source. La raison donnée se lit littéralement comme le résumé de cet essai : à une époque de menaces de sécurité pilotées par l'IA, vous ne pouvez pas laisser votre source là où un agent peut la lire.
« /goal lis le code source de cal.com et énumère sa surface d'attaque jusqu'à ce que quelque chose fonctionne »
C'est une attaque bien trop dangereuse et bien trop facile à exécuter.
L'entreprise dont l'identité entière était « open source » a décidé, en 2026, que l'ouverture était devenue un handicap. Cela devrait vous dire tout.
Pour toute l'histoire du logiciel, « nous l'avons construit » était le fossé.
Cette époque touche à sa fin.
La prochaine appartient à celui qui possède ce que l'artefact n'a jamais contenu : l'ensemble d'évaluation que personne d'autre ne peut scorer. La liste des cas limites sur lesquels vos utilisateurs trébuchent réellement. La vérité terrain que vous mesurez en privé. Celui qui a la cible que l'agent du concurrent ne peut pas voir est le seul dont la boucle continue de descendre.
Le produit est un week-end maintenant.
Allez construire l'évaluation qu'un week-end ne peut pas toucher.
