Boucle Gauntlet
La méthode derrière Claude of Duty, généralisée à tout travail qu'un agent peut inspecter. Une seule invite a produit environ 55 000 lignes d'un jeu de tir jouable de style AAA sans aucune intervention humaine. Le modèle n'était pas le facteur différenciant. La boucle l'était.
Cycle central :
Diviser → construire → juger par rapport à une barre externe → répéter.
Méthode par Matt Shumer. Voir references/origin.md.
Contrat d'exécution
C'est vous qui exécutez ce protocole. L'utilisateur, non.
Lorsque cette compétence se déclenche, ne renvoyez pas une invite, un plan à approuver ou une description de ce à quoi ressemblerait une Boucle Gauntlet. Fixez la barre, décomposez l'objectif, lancez les bâtisseurs et les critiques, exécutez les tours et fournissez l'artefact final.
L'utilisateur a donné un objectif une fois. Tout ce qui suit vous appartient.
- Ne posez aucune question de clarification. Chaque inconnue est une décision que vous prenez et que vous enregistrez dans le résumé final.
- Choisissez la barre vous-même. Énoncez-la en une phrase, puis poursuivez. Ne demandez jamais quelle référence utiliser.
- Routez les modèles vous-même. Choisissez le modèle et l'effort de raisonnement pour chaque agent lancé en fonction de ce que le harnais propose. Ne demandez jamais à l'utilisateur quel modèle utiliser, et ne laissez jamais tout sur la valeur par défaut de la session.
- Ne faites aucun rapport en cours de route. L'avancement va dans le fichier de progression en direct, pas dans la conversation.
- Interrompez uniquement pour un identifiant bloqué, une ressource payante manquante ou une instruction qui causerait un préjudice.
Si l'utilisateur demande explicitement à être consulté aux points de contrôle, respectez cela. En l'absence de ce signal, allez jusqu'au bout.
Quand cela s'applique
Trois conditions :
- La demande consiste à créer ou améliorer quelque chose, pas à répondre à une question.
- La sortie peut être inspectée objectivement : rendue, exécutée, ouverte, mesurée, testée, lue.
- Plus d'un tour est abordable.
Ignorez-la pour les recherches, les corrections d'une ligne et les explications. Cela coûte du calcul réel et ne paie que lorsque la qualité importe plus que la vitesse.
Livret de bord
1. Détecter le harnais
Lisez references/harness-setup.md et choisissez le câblage avant de faire quoi que ce soit d'autre. Il détermine si les critiques proviennent d'agents secondaires parallèles, de sessions séparées ou de passes strictement séparées. N'annoncez jamais cette étape, adaptez-vous simplement.
Pendant que vous y êtes, énumérez les modèles et les paramètres d'effort de raisonnement que ce harnais expose. Vous ne pouvez pas router ce que vous n'avez pas listé.
2. Définir le budget et la table de routage
La boucle multiplie les appels. Si elle n'est pas routée, chacun d'eux hérite du modèle et de l'effort de la session, et un déploiement d'éditions mécaniques tourne sur un modèle frontalier avec un raisonnement maximal sans gain.
Lisez references/model-routing.md et décidez, une fois, avant de construire :
- Les niveaux. Mappez les modèles disponibles sur T0 (une commande, pas de modèle), T1 (petit et rapide), T2 (milieu), T3 (frontière à effort élevé).
- La table. Quel rôle reçoit quel niveau : le chef et chaque appel de jugement à T3, la construction standard à T2, les éditions mécaniques et la comptabilité à T1, tout ce qu'une commande peut vérifier à T0.
- Le budget. Respectez celui de l'utilisateur s'il en a donné un, sinon définissez-en un, et réservez environ un quart pour les critiques.
Deux règles l'emportent sur toute économie. Le jugement n'est jamais routé vers le niveau le moins cher, car un critique faible approuve tôt et annule la méthode. Et une pièce qui concerne le goût ou la nouveauté commence haut, car un bâtisseur bon marché qui perd quatre tours coûte plus cher qu'un bâtisseur coûteux qui en gagne un.
Enregistrez la table dans le fichier de progression. Ne l'annoncez pas et ne demandez pas à l'utilisateur de l'approuver.
3. Fixer la barre
La barre décide si l'exécution fonctionne du tout. Pas des barres : « rendez-le incroyable », « qualité professionnelle », « suivez les meilleures pratiques ». Une barre est un artefact ou une mesure externe réelle à côté de laquelle la sortie peut être placée et contre laquelle elle peut perdre.
Choisissez-en une en utilisant references/quality-bars.md, qui couvre le travail visuel, le front end, l'interface utilisateur du produit, le backend, le mobile, l'écriture, les systèmes de conception, la recherche, les données et le marketing.
Règles :
- Inspectable dans l'exécution. Une capture d'écran sauvegardée dans l'espace de travail, une URL que vous pouvez ouvrir, une suite qui s'exécute, un fichier que vous pouvez lire. Pas une barre mémorisée dans l'entraînement.
- N'a pas besoin d'être atteignable. Claude of Duty n'a jamais battu Call of Duty. La barre existe pour empêcher l'exécution de se contenter de « bon pour l'IA ».
- Surmontée au premier tour signifie qu'elle était trop basse. Augmentez-la et continuez.
Récupérez ou générez les artefacts de la barre maintenant, avant toute construction, et stockez-les dans l'espace de travail pour que chaque critique puisse y accéder.
4. Prendre l'objectif, pas l'implémentation
N'imposez pas votre propre architecture au départ et n'acceptez pas une décomposition inventée avant de regarder l'artefact. Reformulez la destination et laissez la forme émerger.
Si l'utilisateur a fixé une pile ou une architecture, c'est une contrainte réelle. Respectez-la et laissez tout le reste ouvert.
5. Diviser le travail
Divisez l'objectif en plus petits morceaux qui peuvent être améliorés et jugés séparément, et décidez lesquels exécuter en parallèle.
La granularité est le levier. « Améliorer le site » est intraitable. « Faire en sorte que cette section de prix batte la section de prix de référence » est un problème que vous pouvez attaquer jusqu'à gagner. De même pour « faire en sorte que p95 batte 120 ms sous cette charge » et « rendre ce paragraphe au moins aussi clair que ce paragraphe de référence ».
6. Construire et juger, jamais dans le même contexte
Pour chaque morceau, un bâtisseur et un critique distinct. Toujours des contextes différents, jamais le même agent.
Le bâtisseur a vu chaque décision et se souvient pourquoi il les a prises, ce qui le rend excellent pour expliquer pourquoi le résultat est raisonnable. Raisonnable n'est pas la cible.
Briefer-les en utilisant assets/delegation-templates.md. Le critique reçoit l'objectif, la barre, les contraintes et l'artefact réel. Il ne reçoit jamais le compte-rendu du bâtisseur, l'explication du bâtisseur, ni quel côté est le nôtre.
Routez chaque lancement au fur et à mesure, en utilisant la table de l'étape 2. Posez les trois questions avant chaque bâtisseur : le succès est-il vérifiable par une commande (pas de modèle, exécutez-la), l'état cible est-il déjà entièrement spécifié (le plus petit modèle, effort minimal), ou la réduction de l'écart nécessite-t-elle de décider à quoi ressemble le bien (frontière). Les critiques jugeant le goût sont toujours frontaliers ; les critiques vérifiant un nombre exécutent d'abord la commande et n'ont besoin que d'un petit modèle pour la rapporter.
Procédure complète dans references/critic-protocol.md. Éléments essentiels : comparaison en aveugle A/B, inspecter la chose réelle, verdict binaire, nommer le plus grand écart unique, renvoyer.
7. Continuer à boucler
Ne définissez jamais un nombre de tours. Tout tour final convenu devient un plafond.
Arrêtez-vous quand l'une de ces conditions est vraie, et enregistrez laquelle :
- L'utilisateur, depuis le fichier de progression, déclare que c'est terminé.
- Les gains par tour ont cessé d'importer pour l'objectif.
- Le budget de calcul a été épuisé, par rapport au budget fixé à l'étape 2.
Passez une pièce à un niveau supérieur uniquement sur preuve : deux pertes consécutives sur le même écart augmentent son effort, une troisième augmente son modèle. Une pièce qui commence à gagner redescend pour le reste de l'exécution. À 80 % du budget dépensé, arrêtez d'ajouter des tours aux pièces qui gagnent déjà et mettez le reste dans la pièce la plus éloignée de la barre.
Si le même écart survit à trois tours consécutifs, arrêtez cette pièce et re-décidez au niveau de la direction. C'est structurel, ou la barre est mauvaise pour cette pièce, ou le bâtisseur et le critique mesurent des choses différentes. Dépenser plus à ce stade est la façon la plus courante de brûler un budget pour rien.
8. Tenir un fichier de progression en direct
Maintenez une page HTML simple ou un fichier markdown dans l'espace de travail, mis à jour au fur et à mesure que le travail aboutit : captures d'écran, brouillons, résultats de tests, verdicts tour par tour, écarts ouverts. Ne précisez pas trop le format et indiquez à l'utilisateur où il se trouve dans votre première ligne de sortie.
Cela existe pour que l'utilisateur puisse regarder sans interrompre. L'interruption coûte une fenêtre de contexte et casse la boucle.
9. Passe de lissage entre les vagues
Lorsque de nombreux agents éditent des parties séparées d'un artefact, les parties deviennent individuellement bonnes et collectivement incohérentes.
À la fin de chaque vague majeure, lancez un agent frais pour inspecter l'ensemble du résultat, résoudre les conflits et lui donner l'impression d'être une seule chose. Il ne reconçoit rien.
Utile, pas fondamental. Le cœur reste : diviser, construire, juger, répéter.
Clôture de l'exécution
Livrez l'artefact, puis un court résumé contenant :
- La barre utilisée et pourquoi.
- Jusqu'où le travail est allé par rapport à elle.
- Le dernier écart non comblé, qui est le point de transfert pour celui qui reprendra le travail.
- Les hypothèses faites à la place des questions non posées.
- Quelle condition d'arrêt a mis fin à l'exécution.
- Ce qu'elle a coûté : tours effectués, où le budget est allé approximativement, et toute pièce qui a consommé une grande part sans progresser.
Pas d'éloge pour le travail. Les verdicts du critique ont déjà dit tout ce qui importe.
Anti-patrons
| Symptôme | Correctif |
|---|---|
| Remettre à l'utilisateur une invite à exécuter lui-même | Exécutez le protocole, c'est tout l'intérêt |
| « Ça a l'air super ! » de la part du bâtisseur | Lancez un critique avec un contexte propre, sans historique |
| Le critique lit un rapport au lieu de l'artefact | Forcez l'inspection de la sortie réelle |
| Barre subjective (« de classe mondiale », « niveau Apple ») | Remplacez par un artefact concret que vous pouvez ouvrir |
| Décomposition fixée avant de voir l'artefact | Laissez la forme émerger du travail |
| « Faites 3 itérations » | Boucle ouverte avec une condition d'arrêt explicite |
| Demander quelle référence utiliser | Choisissez-en une, justifiez en une phrase, poursuivez |
| Mises à jour de statut dans la conversation | Fichier de progression en direct |
| Bonnes parties, ensemble incohérent | Passe de lissage à la fin de la vague |
| Barre surmontée au premier tour | La barre était trop basse, augmentez-la |
| Même écart survivant à trois tours | Escaladez, c'est structurel |
| Chaque agent héritant du modèle et de l'effort de la session | Routez chaque lancement : frontière pour le jugement, petit pour le travail mécanique |
| Modèle frontière en effort max pour renommer une variable | T1 à effort minimal, ou une commande sans modèle du tout |
| Critique bon marché, pour économiser un tour | Règle zéro. Un critique faible approuve tôt et annule la méthode |
| Bâtisseur bon marché sur une pièce qui concerne le goût | Quatre tours perdants coûtent plus cher qu'une victoire coûteuse |
| Augmenter le niveau parce qu'une pièce semble difficile | Escaladez sur les verdicts répétés, pas sur des intuitions |
| Budget du critique dépensé en tours de construction supplémentaires | La réserve n'est pas un pool. Le jugement l'obtient |