Lorsque les humains devaient encore s'asseoir devant un clavier pour guider les agents ligne par ligne, la compétence essentielle était la rédaction de prompts. Aujourd'hui, les agents peuvent recevoir un objectif et s'exécuter automatiquement ; la nouvelle compétence essentielle est l'ingénierie des boucles.

Auteur de l'article : CyrilXBT

Article compilé, source : ME News

En juin 2026, en une semaine, trois personnes ont chacune arrivé indépendamment à la même conclusion.

Le développeur d'OpenClaw, Peter Steinberger, a déclaré publiquement que les gens devraient cesser d'écrire directement des invites pour des agents de programmation et privilégier la conception de systèmes en boucle capables d'envoyer automatiquement des instructions aux agents.

Presque en même temps, Boris Cherny, responsable d'Anthropic Claude Code, a également déclaré qu'il ne saisissait plus directement de prompts dans Claude. Il exécute désormais un ensemble de boucles qui appellent automatiquement Claude et déterminent la prochaine étape à effectuer, tandis que son véritable travail consiste à écrire et concevoir ces boucles.

Quelques jours plus tard, l'ingénieur Google Addy Osmani a systématiquement résumé cette pratique et lui a donné un nom :

Loop Engineering, ingénierie cyclique.

Ils n'ont pas créé ce mode de travail de toutes pièces, mais ont simplement donné un nom à un changement déjà en cours.

Car auparavant, les outils sous-jacents avaient franchi un point critique : les agents de programmation commençaient à pouvoir accomplir des tâches réelles sans surveillance ; le coût de l’ordonnancement automatique était devenu suffisamment faible pour que l’exécution répétée et planifiée d’une tâche ne paraisse plus une perte ; le coût d’une seule exécution d’agent avait également baissé à un nouveau niveau — il était désormais moins coûteux de laisser l’agent tenter cinq fois la tâche que de passer beaucoup de temps à y réfléchir soigneusement une seule fois.

C'est précisément la raison d'être de cette feuille de route.

Lorsque les humains devaient encore s'asseoir devant un clavier pour guider les agents ligne par ligne, la compétence essentielle était la rédaction de prompts. Aujourd'hui, les agents peuvent recevoir un objectif et s'exécuter automatiquement ; la nouvelle compétence essentielle est l'ingénierie des boucles.

Voici un parcours complet de 20 étapes pour passer d'un opérateur de prompts à un concepteur de systèmes. Ces étapes doivent être suivies dans l'ordre, car la séquence entre les étapes est souvent plus importante que n'importe quelle étape isolée.

L'ingénierie cyclique n'est pas une compétence unique que l'on maîtrise ou non, mais une pile de compétences superposées. Chaque niveau repose sur la solidité des fondations situées en dessous.

Par exemple, construire le déclencheur de planification automatique à l'étape 14 avant d'établir les conditions d'arrêt réelles à l'étape 10 ne conduira qu'à un système capable de gaspiller automatiquement des fonds sans surveillance. Autrefois, il gaspillait des ressources uniquement lorsque vous surveilliez l'écran ; maintenant, il peut continuer à brûler de l'argent tout seul.

De même, si vous mettez en place la couche de mémoire persistante à l'étape 11 avant d'avoir établi un mécanisme de vérification fiable aux étapes 6 et 7, vous risquez de sauvegarder scrupuleusement les enseignements tirés par un « réviseur » trop permissif qui autorise constamment des résultats erronés.

Cela n'aide pas seulement le système à progresser, mais fait accumuler des expériences erronées, transformant la couche mémoire de « temporairement inutile » en « activement nuisible ».

Par conséquent, sauter certaines étapes ne se limite pas à simplement omettre une fonctionnalité. Le problème plus grave est que vous construisez des capacités avancées et apparemment passionnantes sur une base fondamentalement incapable de les soutenir, et vous ne découvrez souvent les problèmes qu’après que le système a été mis à l’échelle et a causé des conséquences réelles.

Le véritable premier pas ne implique aucune technologie.

Vous devez admettre que, dans le flux de travail actuel, les facteurs limitant l'efficacité ne sont plus souvent la capacité du modèle, mais plutôt le fait que vous restez encore dans une boucle.

Chaque fois que vous vous asseyez devant votre ordinateur en attendant la réponse du modèle, en lisant les résultats, puis en saisissant la prochaine commande, vous devenez le maillon le plus lent de tout le système.

Le modèle peut exécuter, valider et réessayer, et ces opérations sont bien plus rapides que la supervision humaine pas à pas pour accomplir la tâche.

Cette étape ne comporte pas de prompt correspondant ; il s'agit d'une décision cognitive.

Avant d'accepter véritablement cela, toutes les étapes suivantes sembleront être des travaux supplémentaires inutiles, plutôt que leur véritable objectif : éliminer le plus grand goulot d'étranglement d'efficacité du système.

Lorsqu'une erreur se produit dans la sortie du modèle, la réaction la plus naturelle consiste généralement à ajouter une nouvelle règle au prompt initial.

Plusieurs mois plus tard, cette approche créera un mur composé de règles : dense, contradictoire et trop long pour que le modèle puisse traiter simultanément toutes les exigences dans sa mémoire de travail.

Finalement, le modèle ne peut souvent que faire correspondre des motifs en se basant sur les contenus les plus récents ou les plus visibles, tout en ignorant inconsciemment d'autres règles.

L'ingénierie cyclique a radicalement transformé cette approche.

Lorsqu'un problème survient, vous n'ajoutez plus simplement une nouvelle exigence à la prompt, mais vous ajoutez un nouvel composant au système, par exemple :

• Ajoutez une étape de vérification indépendante ;
• Ajouter un fichier de mémoire ;
• Ajouter un déclencheur planifié ;
• Ajoutez une étape d'évaluation structurée.

As the capabilities of external systems continue to improve, prompts themselves should become shorter, not longer.

Quelle que soit la nature de la tâche, chaque exécution dans la boucle peut être décomposée en cinq actions de base :

Identifier, transférer, vérifier, persister, planifier.

Découverte

Déterminez exactement quelle tâche doit être accomplie.

Transfert

Assignez la tâche au modèle, agent ou outil chargé de l'exécuter.

Vérification

Vérifiez si les résultats sont corrects selon les normes réelles.

Persistence

Enregistrez ce qui s'est produit lors de cette exécution et ce que vous avez appris, afin de ne pas perdre cette expérience lors de la prochaine exécution.

Planification

Déterminez quand ce processus doit être exécuté à nouveau.

Le flux de travail actuel de la plupart des personnes ne comprend explicitement que les deux premières actions : identifier la tâche et la transférer, généralement effectuées manuellement dans la fenêtre de discussion.

Les trois autres actions n'existent soit pas du tout, soit sont cachées dans le cerveau humain lui-même.

Le cœur du cycle d'ingénierie consiste à rendre explicites ces cinq actions et à les automatiser autant que possible.

Avant de commencer à construire le système, choisissez une tâche que vous effectuez déjà régulièrement et que vous pouvez décrire clairement en termes de normes de qualité.

Ne choisissez pas les problèmes les plus difficiles, ni les tâches d'innovation sans précédent.

La première tâche candidate doit répondre à trois conditions :

1. Vous devez le répéter plusieurs fois ;
2. Il possède des critères clairs qui peuvent être écrits ;
3. Il possède un état « terminé » facilement identifiable.

En d'autres termes, un collègue qui voit les résultats devrait être en mesure de déterminer rapidement si la tâche a été correctement accomplie.

Cette restriction est plus importante qu'il n'y paraît.

Si une tâche n'a pas de critères clairs de terminaison, il est impossible de construire un véritable processus de vérification. Un cycle sans mécanisme de vérification fiable n'est pas un véritable cycle, mais simplement une conjecture sans surveillance.

C'est l'étape que la plupart des gens sautent le plus facilement, mais elle est cruciale pour déterminer si le système fonctionnera correctement par la suite.

Avant d'écrire des instructions pour un agent, écrivez d'abord, dans un langage clair et naturel, à quoi devrait ressembler un résultat correct.

Vous avez besoin de critères concrets et vérifiables, et non d'évaluations de qualité vagues comme « ça donne une bonne impression » ou « ça a l'air professionnel ».

Vous pouvez utiliser le modèle suivant :

Nom de la tâche : [Nom de la tâche]

Définition terminée (Definition of Done, DoD) :

• [Critère spécifique et vérifiable 1]
• [Critères spécifiques et vérifiables 2]
• [Critère spécifique et vérifiable 3]

Même si la sortie finale semble complète et soigneusement révisée, cette tâche ne peut être considérée comme terminée tant qu'aucun des éléments ci-dessus n'est manquant.

Si vous ne pouvez pas remplir ce modèle pour la tâche actuellement sélectionnée, vous devez revenir à l'étape 4 et choisir une autre tâche plus adaptée à la construction d'une boucle.

C'est la décision d'architecture la plus importante de tous les systèmes cycliques.

The role responsible for generating results must be separated from the role responsible for reviewing results.

Cela s'explique par le fait que, lorsqu'un modèle examine immédiatement sa propre sortie après la génération du contenu, il a tendance à défendre la réponse qu'il vient de produire plutôt que d'analyser objectivement les problèmes qu'elle contient.

Dans un cycle raisonnable, il doit exister au moins deux rôles indépendants :

Constructeur

Les constructeurs disposent d'un certain espace de création et sont responsables de la génération de la première version du résultat.

Juge

Le réviseur reçoit la sortie du constructeur ainsi que la définition de terminaison établie à l'étape 5, et évalue si le résultat répond à ces critères.

Idéalement, les examinateurs devraient également avoir accès à des preuves indépendantes que les constructeurs ne peuvent pas consulter, par exemple :

• Suite de tests ;
• Source :
• Données en temps réel ;
• Base de données officielle ;
• Original task brief.

Ainsi, les jugements des examinateurs pourront s'appuyer sur des preuves réelles, et non sur une nouvelle opinion subjective générée selon la même logique que celle des concepteurs.

Si le réviseur ne peut voir que la sortie du constructeur, il ne peut qu'évaluer si le résultat « semble cohérent ».

Il ne peut pas déterminer si le résultat est véritablement correct.

Par conséquent, les examinateurs doivent disposer de bases objectives vérifiables, c'est-à-dire la Ground Truth. Selon le contexte, il peut être interprété comme « fait de référence », « données réelles » ou « référence autorisée ».

Les critères objectifs varient selon les tâches.

Tâche de programmation

The objective basis is the test suite and the output results after the code is executed in real conditions.

Tâche de production de contenu

Les bases objectives sont les documents d'origine et les briefs de contenu. Les relecteurs doivent comparer côte à côte les documents d'origine et le texte généré.

Tâche d'étude

The objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for the task.

Si vous ne pouvez pas préciser clairement ce sur quoi le réviseur doit baser son examen, alors votre boucle ne possède pas encore de mécanisme de vérification réel, peu importe à quel point la formulation du réviseur semble assurée.

Les résultats du constructeur et les conclusions du réviseur doivent tous deux suivre une structure clairement définie, et non pas un langage naturel libre.

Sinon, le gestionnaire suivant n'aura pas d'informations stables et fiables pour effectuer des jugements et des routages.

Les constructeurs peuvent utiliser le format de sortie suivant :

Sortie du constructeur :

• Contenu final livré ;
• Level of confidence in the result;
• Uncertainty known.

Les évaluateurs peuvent utiliser le format de sortie suivant :

Conclusion de l'évaluation :

• PASS : réussite ;
• ÉCHEC : échec ;
• NEEDS REVISION : besoin de révision ;
• Problèmes spécifiques découverts ;
• Les critères objectifs ou les preuves originales sur lesquels repose cet examen.

Avant d’activer l’ordonnancement automatique et les réessais automatiques, exécutez manuellement une fois le processus complet « Constructeur — Réviseur ».

Lisez attentivement le jugement fourni par l'examinateur et demandez-vous :

• Êtes-vous d'accord avec sa conclusion ?
• A-t-il laissé passer un résultat que vous saviez être erroné ?
• A-t-il incorrectement rejeté un résultat initialement合格 ?

Si un examinateur approuve un résultat que vous savez être erroné, ou rejette un résultat qui ne présente en réalité aucun problème, vous devez d'abord corriger les bases objectives ou les critères de référence, puis continuer à construire le système.

Automatiser une étape de vérification erronée ne fait que faire produire au système des résultats erronés à une vitesse plus rapide.

Pour rendre les cinq étapes ci-dessus plus concrètes, nous pouvons observer une tâche courante : transformer une source brute en un article complet.

Étape 5 : Finaliser la définition

Les critères de réussite de cette tâche peuvent être :

• Chaque fait dans le brouillon peut être retracé jusqu'à un contenu explicite dans la source originale ;
• Le brouillon répond à toutes les exigences spécifiques du briefing, y compris la longueur, le ton et la structure ;
• L'argument central du texte original est préservé de manière claire, sans être dilué par des contenus superflus.

Étape 6 : Le constructeur génère un brouillon

Le constructeur reçoit les matériaux bruts et le brief contenu pour générer une première version.

En parallèle, il doit également lister clairement les incertitudes présentes pendant le processus d'écriture, par exemple :

• Un certain chiffre est-il réellement apparu dans la source originale ;
• Whether the conclusion is explicitly stated in the original text or inferred by the model;
• Whether a fact lacks sufficient sources.

Étape 7 : Le réviseur vérifie par rapport au texte original

Les réviseurs reçoivent à la fois le brouillon et les documents d'origine, et non uniquement le brouillon.

Il doit vérifier séparément les trois critères définis et fournir une conclusion distincte de réussite ou d'échec pour chaque critère, au lieu de regrouper tous les axes en une seule note globale floue.

Fusionner trois normes différentes en un jugement global masque lequel des dimensions exactes présente un problème. C'est la cause la plus fréquente pour laquelle de nombreux cycles autrefois fonctionnels perdent progressivement leur valeur de rétroaction.

Étape 8 : Transmission structurée

La conclusion de l'examinateur doit être un objet structuré, et non un paragraphe de langage naturel rempli de formulations réservées.

Il doit produire trois résultats clairs, réussite ou échec, et fournir une raison spécifique pour chaque échec.

Étape 9 : Vérification manuelle du mécanisme d'avis

Exécuter manuellement un processus complet avant que le système ne fonctionne automatiquement peut vous aider à déterminer si les examinateurs sont trop indulgents ou trop stricts.

Des examinateurs trop indulgents pourraient laisser passer des données fictives simplement parce que l'article est bien rédigé.

Un examinateur trop strict pourrait rejeter à tort un article合格 en raison d'une préférence personnelle non mentionnée dans le brief.

Ces deux problèmes sont très courants lors de la première configuration.

Découvrir ces problèmes après que le système ait fonctionné 50 fois sans surveillance coûte bien plus cher que de les résoudre lors du premier test manuel.

Le gestionnaire (Manager) est chargé de lire les décisions des examinateurs et de déterminer la prochaine étape à suivre.

Les conditions d'arrêt doivent également être intégrées dans le gestionnaire et doivent être formulées comme une logique rigide et explicite, et non comme une instruction floue que le modèle peut contourner par une auto-interprétation.

Par exemple :

Condition d'arrêt :

• Nombre maximum de modifications : 3 ;
• Lorsque le troisième examen échoue toujours, soumettez l'historique complet à un traitement humain et n'initiez pas de quatrième modification ;
• Norme de qualité : Chaque élément défini doit afficher PASS ;
• Limite de budget : si le coût de la tâche dépasse X ou que le temps d'exécution dépasse Y, arrêtez-la immédiatement, quel que soit l'état actuel.

Une boucle sans condition d'arrêt réelle n'est pas un système, mais une responsabilité attendant d'exposer un risque.

Pourquoi les instructions souples comme « arrêter lorsque le résultat est suffisamment bon » ne sont-elles pas fiables ?

Because it's just a suggestion.

Lorsque le modèle a été modifié plusieurs fois de suite sans réussir, afin de fournir à la tâche une conclusion apparemment satisfaisante, il est probable qu'il se convainque lui-même que « cette version est suffisamment proche des normes », réduisant ainsi automatiquement ses propres critères d'évaluation.

En revanche, les itérations vérifiées mécaniquement par le code ou les règles explicites que le gestionnaire ne peut contourner par raisonnement ne présentent pas ce problème.

Si un cycle démarre à zéro à chaque lancement, il ne se souviendra pas de ce qu'il a appris lors de la précédente exécution.

Il est donc nécessaire d'ajouter une couche de persistance simple.

Vous pouvez créer un fichier pour chaque nouvelle expérience réelle, et résumer celle-ci en une phrase en haut du fichier :

• What did you learn?
• What was fixed;
• Pourquoi cette expérience est importante.

Le principe fondamental est de n'enregistrer que les nouvelles connaissances non encore sauvegardées ailleurs.

La mémoire répétée n'est pas un savoir, mais du bruit.

Pour que le mécanisme de persistance reste efficace à long terme, il faut faire preuve de retenue lors de l'écriture.

Il est facile d’avoir l’impulsion de consigner tous les détails d’exécution, mais cela ne fait que reproduire le problème des « invites encombrées » mentionné à l’étape 2, sauf que cette fois-ci, c’est le dossier de mémoire qui s’agrandit.

Les expériences véritablement dignes d'être notées sont celles qui, une fois oubliées, nécessitent beaucoup de temps pour être redécouvertes, et non les simples exécutions ordinaires qui se déroulent comme prévu.

Ajouter simplement un mécanisme de persistance finira par poser les mêmes problèmes qu'une longue invite.

Au fil du temps, le système accumule des dizaines de fichiers, dont beaucoup ne font que présenter de légères variations d’un même problème.

Il convient donc d'organiser les fichiers mémoire selon un cycle fixe. Une exécution hebdomadaire est généralement une fréquence raisonnable.

Le processus d'organisation comprend :

• Examiner les mémoires existantes ;
• Fusionner les contenus dupliqués ;
• Compresser plusieurs expériences similaires en un principe plus clair ;
• Supprimez les contenus démontrés comme erronés ou obsolètes.

L'objectif n'est pas d'accumuler de plus en plus de documents, mais d'acquérir un nombre plus réduit de connaissances à plus forte densité d'information.

Beaucoup de gens sauteront complètement cette étape, car elle ne procure pas de nouvelles capacités visibles immédiatement, mais prévient simplement des problèmes futurs.

Precisely because it lacks immediate feedback, it should be deliberately scheduled rather than deferred until someone realizes their memory folder has become unmanageable.

Dans la réalité, ces tâches « que je vais ranger plus tard » n'arrivent généralement jamais, jusqu'à ce que les performances du système commencent à diminuer en raison d'un grand nombre de souvenirs contradictoires, obsolètes et partiellement liés qui se disputent la fenêtre de contexte.

À chaque début d'une nouvelle tâche, faites en sorte que la boucle scanne d'abord un résumé d'une phrase dans le fichier de mémoire pour déterminer quelles expériences sont véritablement pertinentes pour la tâche actuelle, puis chargez uniquement ces éléments pertinents.

En outre, il faut clairement exiger au système que, si aucun souvenir existant ne s'applique à la tâche actuelle, il indique directement qu'aucune expérience pertinente n'est disponible.

Ne forcez pas à appliquer des expériences passées à un tout nouveau problème différent simplement parce qu’un système de mémoire existe déjà.

Ensuite, il faut déterminer à quel moment ce cycle s'exécutera automatiquement sans déclenchement manuel.

Les modes de déclenchement peuvent inclure :

• Tâche planifiée Cron ;
• File change listener ;
• Déclencheur de cycle basé sur le calendrier ;
• Déclenché lorsqu'un événement externe ou un état change.

Cette étape transforme un système que vous devez démarrer manuellement en un système qui continue de fonctionner pendant que vous dormez.

Ironiquement, c'est souvent l'étape la plus facile à réaliser dans toute la liste, mais aussi celle que de nombreuses personnes retardent, même après avoir accompli les autres composants.

Avant d'utiliser une boucle pour toute tâche importante, il est nécessaire de tester activement les quatre modes de défaillance.

Test 1 : Tâche impossible

Donnez au système une tâche véritablement insoluble pour vérifier que le gestionnaire peut se arrêter selon les conditions de cessation, et non entrer en boucle infinie.

Si un cycle n'a été testé que sur des tâches pouvant être accomplies avec succès, il n'a jamais prouvé sa capacité à échouer avec élégance.

Test 2 : Résultat qui semble raisonnable mais est en réalité erroné

Fournissez aux examinateurs une sortie que vous savez contenir des erreurs subtiles.

Ce résultat devrait se lire très naturellement, mais contient une erreur factuelle ou logique que vous avez intentionnellement intégrée.

Observez si les relecteurs peuvent identifier des problèmes, et non pas simplement approuver parce que le contenu semble raisonnable.

Test 3 : Les constructeurs et les relecteurs partagent les zones aveugles du modèle

Si le constructeur et le réviseur utilisent le même modèle sous-jacent, il est possible d'ajouter intentionnellement une erreur typique que ce modèle commet fréquemment, afin d'observer si le réviseur la laissera passer.

Si les examinateurs et les constructeurs partagent les mêmes lacunes, alors la séparation des rôles conçue à l'étape 6 perd son sens.

Test 4 : Calcul du coût d'exécution dans le pire des cas

Calculate the cost of this loop under the worst-case scenario, using the most expensive model invocation, the maximum number of modifications, and the longest possible output within reasonable limits.

Ensuite, demandez-vous honnêtement :

Si ce chiffre apparaissait sur une facture réelle, seriez-vous inquiet ?

Effectuez ces quatre tests avant de traiter les tâches importantes dans le cycle de confiance pour détecter à l'avance la majorité des problèmes potentiels.

Sinon, ces problèmes apparaîtront très probablement pour la première fois devant les clients ou les gestionnaires, ou se répercuteront directement sur votre facture, et non lors d’un test que vous auriez contrôlé activement.

Une fois que le cycle fonctionne de manière stable, n'utilisez pas le même modèle que vous préférez pour tous les rôles.

Les différents rôles dans le cycle présentent des exigences variées en matière de capacités du modèle.

Builders

Les constructeurs devraient généralement utiliser le modèle le plus puissant.

Car il assume la majeure partie du raisonnement complexe et de la génération de contenu. Si un modèle insuffisamment puissant est utilisé ici, la qualité du résultat initial diminuera, et des rounds de modifications supplémentaires pourraient être nécessaires.

Finalement, le coût de correction d’une première version de mauvaise qualité peut être supérieur au coût d’utilisation dès le départ d’un modèle plus puissant.

Réviseur

Les réviseurs sont chargés d'effectuer des vérifications selon des critères clairs et n'ont généralement pas besoin de grandes capacités créatives.

Dans les cas où les critères sont suffisamment précis, un modèle plus petit, moins coûteux et plus rapide peut également accomplir fiablement la tâche d'examen.

Un petit modèle, s'il fonctionne selon une checklist extrêmement précise, peut atteindre une stabilité proche de celle des grands modèles, tout en présentant des coûts et des délais nettement plus faibles.

Manager

Le gestionnaire effectue simplement le routage selon les règles déjà définies et n'a presque jamais besoin d'utiliser le modèle le plus coûteux.

Son rôle est d'exécuter des logiques déjà définies, et non d'effectuer un raisonnement ouvert.

De plus, quel que soit le niveau de performance des constructeurs et des réviseurs, le gestionnaire s'exécute au moins une fois à chaque itération, ce qui rend son coût par appel particulièrement important à prendre en compte.

Une configuration en couches appropriée est généralement :

• Le modèle puissant est chargé de la construction ;
• Des modèles économiques et stables sont chargés des évaluations régulières ;
• Des modèles ou programmes de règles à faible coût sont responsables du routage et de la gestion.

Les optimisations de coûts significatives dans un système de boucle proviennent généralement de ce type de correspondance de rôles de modèle.

Beaucoup pensent que maîtriser les coûts signifie réduire le nombre de cycles ou de révisions. En réalité, la méthode la plus efficace consiste à faire correspondre le coût du modèle à la difficulté réelle de chaque rôle dans le cycle.

Après le premier cycle réussi, il est facile de vouloir immédiatement construire plusieurs cycles en parallèle pour traiter cinq tâches différentes.

Même si l'architecture actuelle permet déjà cette extension, il convient de maîtriser cette impulsion.

Vous devriez d'abord laisser le premier cycle fonctionner de manière stable suffisamment longtemps jusqu'à ce que vous n'ayez plus besoin de vérifier attentivement chaque sortie.

Il ne s'agit pas d'une démonstration qui réussit par hasard lorsqu'une personne la regarde attentivement, mais plutôt qu'elle continue de passer des vérifications humaines aléatoires après une période d'utilisation réelle.

Seul cet état atteint devrait déclencher la construction du deuxième cycle.

The second cycle should best handle a task that is clearly different from the first cycle.

Cela permet de vérifier si l'architecture sous-jacente possède une véritable universalité, et non pas simplement une optimisation de plus en plus fine pour une même tâche.

Après avoir exécuté plusieurs boucles simultanément, vous devez établir une vue de surveillance unifiée pour suivre de manière centralisée les coûts et les déclenchements des conditions d'arrêt de toutes les boucles, plutôt que de consulter chaque boucle séparément.

Considéré isolément, un budget de tâches cycliques peut être tout à fait raisonnable.

Mais si les dix cycles fonctionnent chacun dans leur budget, leur coût total peut tout de même atteindre un niveau surprenant.

Ce risque est souvent détecté uniquement lors de la génération des factures regroupées, car les données individuelles de chaque cycle semblent normales.

En plus des tâches réussies, chaque déclenchement de condition d'arrêt doit être enregistré de manière spécifique.

Si un cycle touche fréquemment le nombre maximal de modifications, tandis que les autres cycles le font rarement, le signal qu'il envoie n'est peut-être pas « cette tâche est particulièrement difficile », mais :

• Les critères d'évaluation sont mal définis ;
• Les examinateurs sont trop stricts, ce qui empêche tout résultat d'être approuvé ;
• Le système a vérifié les bases objectives erronées ;
• La définition elle-même présente des problèmes.

Si l'on ne suit que les résultats réussis et que chaque mise à niveau manuelle est considérée comme un événement isolé et indépendant, ce modèle au niveau de la conception ne sera pas détecté.

Le signe le plus évident qu’un changement de mentalité est véritablement accompli est que vos indicateurs de référence quotidiens ont changé.

Le prompt operator s'intéresse à :

• Combien de prompts efficaces avez-vous écrits aujourd'hui ?
• Quel prompt fonctionne le mieux ;
• Comment rédiger des instructions plus ingénieuses.

Les concepteurs du système s'intéressent à :

• Combien de cycles sont actuellement en cours ?
• Quelle est la fiabilité de chaque cycle ?
• Combien de temps le système a-t-il libéré pour lui-même ?
• Quels travaux n'exigent plus de supervision humaine ?

Si vous mesurez toujours votre productivité par le nombre de prompts que vous avez entrés, alors le changement de mentalité requis à l'étape 1 n'est pas encore véritablement accompli, peu importe combien de boucles ont été mises en place techniquement.

La dernière étape ne concerne plus entièrement votre propre système.

Il est utilisé pour vérifier si vous avez vraiment compris cette méthode.

Tu dois essayer d'expliquer cinq actions de base à quelqu'un sans recourir à des termes complexes :

Identifier, transférer, vérifier, persister, planifier.

Si tu peux guider une autre personne à construire son premier cycle en te basant uniquement sur ces cinq actions et les étapes précédentes, cela signifie que tu as accompli la véritable transformation décrite dans cette feuille de route.

Vous n'êtes plus la personne qui reste à l'intérieur du cycle et entre continuellement la prochaine commande.

Vous êtes devenu la personne qui se trouve en dehors du cycle, conçoit le système et observe son fonctionnement autonome.

Les quatre coûts qui s'accumulent silencieusement après avoir sauté les étapes

Il est nécessaire de fournir un avertissement à la fin de l'article.

Sauter les étapes de cette feuille de route ne conduit pas toujours immédiatement à un plantage du système.

Son échec est généralement silencieux, voire difficile à détecter pendant une longue période, jusqu'à ce que les problèmes s'accumulent jusqu'à un niveau considérable.

Lorsque vous sautez les étapes 6 et 7, sans établir de réviseurs véritablement indépendants ni fournir de fondements objectifs fiables, la vérification de la dette commence à s’accumuler.

La boucle semble toujours fonctionner normalement, car les résultats générés « ont l'air pas mal ».

Ce n’est qu’au moment où une erreur s’est accumulée pendant des dizaines d’exécutions et a finalement été découverte que vous réalisez que le système n’a jamais véritablement évalué la validité des résultats depuis le départ.

La dégradation de la compréhension peut se produire lorsque vous sautez l'étape 20.

Vous continuez à exécuter le cycle que vous avez autrefois construit, mais vous ne pouvez plus expliquer clairement pourquoi chaque composant existe, ni diagnostiquer efficacement les pannes du système.

La raison en est que vous n'avez jamais véritablement intégré la logique derrière cette architecture.

La reddition cognitive survient si la première étape n'a jamais été véritablement accomplie.

Même si le système de vérification a prouvé sa fiabilité grâce à un fonctionnement prolongé, vous continuez à revoir manuellement chaque sortie par habitude.

Ce comportement semble prudent, mais il annule en réalité toute la signification de la construction du système.

Si l'étape 10 est ignorée et qu'aucune condition d'arrêt réelle n'est définie pour la boucle, une consommation incontrôlée de jetons et des coûts d'appel excessifs peuvent survenir.

Vous ne remarquez généralement pas le problème dès que le système commence à échapper au contrôle, mais seulement lorsque la facture finale arrive, révélant que le cycle a effectué un grand nombre d'appels inutiles.

Tous ces coûts peuvent être évités.

La méthode pour les éviter est toujours la même discipline :

Construisez dans l'ordre, sans sauter les étapes qui semblent moins impressionnantes.

Ce qui fonctionne vraiment, ce sont souvent les parties les plus ennuyeuses :

• Définition claire et complète ;
• Conditions d'arrêt fiables ;
• Preuves objectives vérifiables ;
• Independent review mechanism.

En comparaison, les parties qui semblent plus attrayantes — les prompts astucieux, les schémas d'architecture système complexes — sont bien moins importantes qu'on ne le pense.

Ce qui détermine réellement la qualité du système, c'est si le système que vous avez construit sait :

• Quand êtes-vous vous-même dans le bon ?
• Quand soi-même est à l'erreur ;
• When must you stop?

That is the entire difference between a prompt operator and a system designer.

La différence ne réside pas dans qui est plus intelligent, ni dans qui peut écrire des prompts plus élaborés.

La véritable différence réside dans le fait que vous avez suffisamment de discipline pour construire sérieusement les parties ennuyeuses et facilement ignorées, mais qui déterminent réellement la fiabilité du système.