Comment créer une boucle d'IA auto-correctrice qui détecte ses propres erreurs avant que vous ne les voyiez

Il y a un moment précis qui sépare quelqu’un qui utilise l’IA de manière occasionnelle de quelqu’un qui la fait vraiment fonctionner comme un système.

C’est le moment où il cesse d’être celui qui rattrape l’erreur.

Pour la plupart des gens, la boucle ressemble encore à ceci : demander quelque chose à Claude, lire la réponse, remarquer que quelque chose cloche, le signaler, obtenir une version corrigée, relire, remarquer autre chose, le signaler à nouveau. Vous êtes la couche de vérification, manuellement, à chaque fois, pour chaque tâche.

Une boucle d’auto-correction vous retire entièrement de cette position. Le système génère, vérifie son propre travail par rapport à un standard réel, repère ce qu’il a mal fait, le corrige, et ne vous montre le résultat qu’après. Quand vous voyez la sortie, les erreurs évidentes ont déjà été détectées et traitées. Ce qu’il vous reste, c’est un jugement sur les choses qui nécessitent vraiment un humain, pas une relecture du premier jet d’une machine.

Voici la construction complète. À la fin, vous aurez l’architecture exacte, les prompts exacts et les modes d’échec exacts à tester avant de faire confiance à ce système pour quoi que ce soit qui compte.

Pourquoi ce n’est pas la même chose que de simplement demander deux fois

Le premier réflexe évident est de demander au modèle de vérifier son propre travail dans la même conversation. « Relis ce que tu viens d’écrire et corrige les erreurs. » Cela aide un peu. Mais cela ne construit pas une véritable boucle d’auto-correction, et comprendre pourquoi est le fondement de tout ce qui suit.

Un modèle qui révise sa propre production dans le même contexte, avec le même raisonnement qui a produit l’erreur, a tendance à défendre son travail plutôt qu’à l’examiner sincèrement. Ce n’est pas un défaut propre à un modèle particulier. C’est un problème structurel. Le même passage qui a généré une réponse plausible mais fausse n’est pas bien placé pour remarquer qu’elle est fausse, car de l’intérieur, la réponse semble toujours plausible. Demander « Tu es sûr ? » produit plus souvent des assurances qu’un véritable réexamen.

La solution n’est pas de mieux demander. C’est l’architecture. Une véritable boucle d’auto-correction sépare le travail de production d’une réponse du travail de jugement de celle-ci, en utilisant un passage différent, un prompt différent, et idéalement un cadre de référence totalement différent, afin que le jugement ne soit pas contaminé par les mêmes angles morts qui ont créé l’erreur.

Les trois rôles dont toute boucle d’auto-correction a besoin

Tout système d’auto-corction fonctionnel, quelle que soit la tâche spécifique, se réduit à trois rôles distincts. Comprendre clairement ces rôles est plus important que n’importe quel prompt spécifique ci-dessous, car une fois que vous les voyez, vous pouvez construire une boucle pour presque n’importe quelle tâche en remplissant les détails.

Le Constructeur. Produit la sortie réelle. Écrit le code, rédige le contenu, effectue la recherche, exécute la tâche. Ce rôle doit bénéficier de la plus grande latitude créative et du moins de contraintes, car son travail est de produire une première tentative, pas une tentative parfaite.

Le Juge. Ne construit rien. Son seul travail est d’évaluer la sortie du Constructeur par rapport à un standard écrit spécifique, et non pas une vague impression de qualité. Le code passe-t-il ses tests ? Le brouillon correspond-il au brief ? La recherche répond-elle réellement à la question posée ? Le Juge devrait idéalement avoir accès à quelque chose que le Constructeur n’a pas : le matériel source original, la suite de tests, le document d’exigences réel, afin d’avoir une vérité de terrain indépendante à vérifier, plutôt que de simplement relire la même sortie et se faire une nouvelle opinion.

Le Gestionnaire. Lit le verdict du Juge et décide de la suite. Renvoyer au Constructeur avec des retours spécifiques. Escalader vers un humain. Marquer la tâche comme terminée. C’est aussi là que se trouve votre condition d’arrêt, la règle qui empêche la boucle de tourner indéfiniment lorsque quelque chose ne peut pas être corrigé automatiquement.

Le principe de conception critique pour les trois rôles : la vérification doit faire référence à quelque chose d’extérieur au raisonnement du Constructeur. Une suite de tests. Un document source original. Une liste de contrôle écrite. Un second appel IA avec un cadrage réellement différent. Tout ce qui n’est pas simplement « le même modèle, interrogé à nouveau, dans la même foulée ».

Construire les transferts

Le vrai travail d’ingénierie dans une boucle d’auto-correction ne réside pas dans des prompts astucieux pour chaque rôle. Il réside dans la structure de ce qui circule entre eux, et c’est la partie que la plupart des gens qui construisent leur première boucle ignorent complètement, avant de se demander pourquoi le système se comporte de manière imprévisible.

Un transfert doit avoir trois propriétés pour fonctionner de manière fiable. Un format défini, pour que le rôle récepteur n’ait pas à analyser un texte vague et deviner ce qui est important. Un déclencheur défini, pour que ce ne soit pas le Constructeur qui décide quand il a terminé. Et un chemin d’échec défini, pour que, lorsque quelque chose ne se passe pas proprement, une prochaine étape soit spécifiée au lieu que le système se casse silencieusement ou boucle à l’infini.

En pratique, cela signifie que le Constructeur doit produire quelque chose de structuré, pas seulement du texte conversationnel. Un livrable clair plus une déclaration explicite de ce dont il n’est pas certain. Le Juge évalue ensuite cette sortie structurée par rapport à un standard écrit et renvoie son propre verdict structuré, pas un paragraphe de prose hésitante, mais un clair succès, échec, ou besoin de révision, avec la raison spécifique attachée. Le Gestionnaire lit ce verdict structuré, pas le contenu brut, et décide de l’action suivante en se basant sur des règles établies à l’avance, et non en improvisant un jugement sur le moment.

Voici une structure de modèle qui fonctionne pour la plupart des tâches, que le travail sous-jacent soit de l’écriture, du code ou de la recherche :

1FORMAT DE SORTIE DU CONSTRUCTEUR
2Livrable : [la sortie réelle]
3Confiance : [élevée / moyenne / faible]
4Incertitudes connues : [tout ce dont vous n’êtes pas sûr, énoncé explicitement]
5Hypothèses faites : [tout ce que vous avez supposé sans vous le faire dire]
6
7FORMAT DU VERDICT DU JUGE
8Verdict : [SUCCÈS / ÉCHEC / BESOIN DE RÉVISION]
9Vérifié par rapport à : [le standard spécifique utilisé, par ex. le brief original,
10la suite de tests, le document source]
11Problèmes spécifiques trouvés : [problèmes exacts, pas une impression générale]
12Confiance dans ce verdict : [élevée / moyenne / faible]
13
14ACTION DU GESTIONNAIRE
15Si SUCCÈS : marquer comme terminé, livrer à l’utilisateur.
16Si ÉCHEC ou BESOIN DE RÉVISION : renvoyer au Constructeur avec les problèmes
17spécifiques du Juge joints. Incrémenter le compteur de révisions.
18Si le compteur de révisions dépasse [N] : arrêter la boucle, escalader vers un humain
19avec l’historique complet de ce qui a été essayé et pourquoi cela a échoué.

Cela semble plus structuré qu’une conversation informelle, et ça l’est. Ce coût initial est ce qui vous achète un système qui se comporte de la même manière à la centième exécution qu’à la première, au lieu de dériver de manière imprévisible à mesure que le contexte s’accumule.

Le Juge a besoin d’une vérité de terrain, pas seulement d’une opinion

C’est le principe le plus important de tout le système, et il mérite sa propre section parce que se tromper sur ce point sape silencieusement tout le reste.

Un Juge qui ne voit que la sortie du Constructeur, sans référence indépendante à vérifier, ne peut évaluer que la cohérence interne, c’est-à-dire si la sortie semble cohérente et bien formatée. Il ne peut pas évaluer l’exactitude, c’est-à-dire si la sortie correspond réellement à ce qui a été demandé ou résout réellement le vrai problème. Une réponse fausse mais confiante, bien formatée et cohérente en interne, passera devant un Juge sans vérité de terrain à chaque fois.

Pour les tâches de code, la vérité de terrain est la suite de tests, la sortie réelle de l’exécution du code, les résultats de lint, l’état de la compilation. Pas « ce code a-t-il l’air correct », mais « a-t-il réellement réussi lorsqu’il a été exécuté ».

Pour les tâches de contenu, la vérité de terrain est le matériel source original et le brief original, côte à côte avec le brouillon. Pas « ce texte se lit-il bien », mais « chaque affirmation spécifique dans ce brouillon remonte-t-elle à quelque chose dans la source, et le texte satisfait-il réellement chaque exigence du brief ».

Pour les tâches de recherche, la vérité de terrain est les résultats de recherche réels et les documents sources sur lesquels la recherche était censée se baser. Pas « ce résumé a-t-il l’air autoritaire », mais « chaque affirmation peut-elle être attribuée à une source spécifique, et les sources qui ont été recherchées étaient-elles réellement les bonnes ».

Si vous ne pouvez pas articuler quelle est la vérité de terrain du Juge pour votre tâche spécifique, vous n’avez pas encore de boucle d’auto-correction. Vous avez une boucle de reformulation, où l’erreur confiante du Constructeur est reformulée avec confiance par le Juge au lieu d’être réellement détectée.

La condition d’arrêt n’est pas optionnelle

La façon la plus courante pour qu’une boucle d’auto-corction devienne un désordre coûteux et incontrôlable est l’absence d’une condition d’arrêt explicite et ferme. Sans elle, un Constructeur et un Juge peuvent boucler indéfiniment, chaque révision déclenchant une autre évaluation, chaque évaluation déclenchant une autre révision, tandis que le coût grimpe et que personne ne s’en aperçoit jusqu’à l’arrivée de la facture.

Une vraie condition d’arrêt nécessite trois composants, et les trois doivent être appliqués comme une logique explicite, et non laissés à l’appréciation du modèle sur le moment.

Un nombre maximum d’itérations. Un plafond dur sur les cycles de révision, après lequel le Gestionnaire est obligé d’escalader vers un humain, que le Juge soit satisfait ou non.

Un seuil de qualité qui est réellement mesurable, pas seulement aspirationnel. « Assez bien » en tant qu’instruction dans un prompt n’est pas une condition d’arrêt, car c’est une suggestion que le modèle peut et va éventuellement ignorer sous la bonne pression. Une barre spécifique et vérifiable, les onze cas de test passent, ou le brouillon correspond aux cinq exigences énoncées du brief, est une condition d’arrêt, car elle peut être vérifiée mécaniquement plutôt que jugée subjectivement à chaque fois.

Un plafond de coût ou de temps. Un budget absolu que la tâche ne peut pas dépasser, quel que soit son état lorsque ce plafond est atteint. C’est la barrière de protection qui vous protège spécifiquement du pire scénario : une tâche vraiment insoluble qui boucle jusqu’à ce que quelqu’un remarque la facture.

CONDITIONS D’ARRÊT

Révisions maximales : 3. Au 3ème verdict échoué, arrêter et escalader

vers un humain avec l’historique complet des révisions, ne pas tenter

un 4ème cycle automatiquement.

Seuil de qualité : tous les éléments de la liste de contrôle du Juge doivent

être SUCCÈS, pas « en grande partie réussi » ou « assez proche ».

Plafond budgétaire : si cette tâche a consommé plus de [X] tokens ou

[Y] minutes, arrêter immédiatement quel que soit l’état actuel et signaler

ce qui a été accompli par rapport à ce qui reste.

Écrivez-les dans la logique réelle du Gestionnaire, pas dans une instruction molle à l’intérieur d’un long prompt que le modèle pourrait contourner sous pression.

Un exemple concret : production de contenu auto-corrective

Pour rendre cela concret, voici exactement comment les trois rôles et la condition d’arrêt se combinent pour une tâche réelle et courante : transformer un document source en un contenu fini sans qu’un humain ne relise manuellement chaque brouillon.

Le Constructeur reçoit le matériel source et le brief, et produit un brouillon. Sa sortie inclut le brouillon lui-même, plus une déclaration de confiance explicite et une liste de tout ce dont il n’était pas certain en écrivant, un chiffre spécifique dont il n’était pas entièrement sûr qu’il était dans la source, une affirmation qu’il a déduite plutôt que trouvée énoncée directement.

Le Juge reçoit le brouillon et la source originale côte à côte, jamais le brouillon seul. Il vérifie trois choses spécifiques, chacune avec son propre succès ou échec. Chaque affirmation factuelle dans le brouillon remonte-t-elle à quelque chose de réellement présent dans la source. Le brouillon satisfait-il chaque exigence spécifique du brief, longueur, ton, sections requises. L’argument ou l’accroche principal est-il réellement présent et non dilué par du remplissage. Le Juge renvoie un verdict structuré avec un succès ou un échec pour chacun des trois contrôles séparément, car fusionner cela en un seul score global cache exactement quelle dimension a échoué.

Le Gestionnaire lit ce verdict structuré. Un succès complet sur les trois envoie le brouillon dans une file d’attente de sortie finale. Un échec sur la dimension de vérification des faits le renvoie au Constructeur avec l’affirmation non vérifiée spécifique signalée directement, et non une instruction vague de « revérifier l’exactitude ». Un échec sur la conformité au brief le renvoie avec l’exigence manquante spécifique nommée. Après trois cycles échoués sur le même contrôle spécifique, le Gestionnaire arrête complètement la boucle et escalade vers un humain avec l’historique complet de ce qui a été essayé, plutôt que de continuer à réessayer un problème que le système a déjà montré qu’il ne pouvait pas résoudre seul.

C’est un petit système. Trois rôles, un format de transfert structuré, une condition d’arrêt explicite. C’est aussi un système que vous pourriez vraiment faire fonctionner sans surveillance et dont vous pourriez faire confiance à la sortie, car chaque mode d’échec a un chemin défini plutôt qu’indéfini.

Tester la boucle avant de lui faire confiance

Avant de vous fier à un système d’auto-correction pour quelque chose qui compte vraiment, passez-le délibérément par ces tests de stress spécifiques. La plupart des boucles qui échouent en utilisation réelle auraient échoué immédiatement à l’un de ces tests, si quelqu’un avait pris la peine de vérifier d’abord.

Le test de la tâche insoluble. Donnez délibérément au Constructeur une tâche qu’il ne peut pas accomplir selon le standard du Juge. Le Gestionnaire atteint-il correctement le plafond d’itérations et escalade-t-il vers un humain, ou tourne-t-il indéfiniment, brûlant du budget sur une tâche qui n’allait jamais réussir ?

Le test de l’erreur confiante. Donnez au Juge une sortie dont vous savez déjà qu’elle est subtilement fausse, quelque chose qui se lit bien mais contient une erreur factuelle ou logique spécifique. Le Juge, avec sa référence de vérité de terrain, la détecte-t-il correctement ? Si le Juge approuve quelque chose que vous savez être cassé, votre référence de vérité de terrain n’est pas réellement vérifiée, ou la vérification est trop superficielle.

Le test de l’angle mort du même modèle. Si votre Constructeur et votre Juge fonctionnent sur le même modèle sous-jacent, cela vaut la peine d’être vérifié directement. Donnez au Juge une sortie contenant exactement le type d’erreur que ce modèle a tendance à commettre de manière caractéristique. Si le Juge la laisse passer, vous avez construit une boucle qui partage ses angles morts entre les rôles, ce qui défait le but même de la séparation. Envisagez d’utiliser un modèle vraiment différent, ou au minimum un cadrage de prompt significativement différent, pour le rôle du Juge spécifiquement.

Le test de la dérive des coûts. Calculez le pire chemin possible à travers votre système : révisions maximales, appels de modèle les plus coûteux impliqués, longueur de contenu la plus longue raisonnable, et déterminez ce que cela coûterait réellement en dollars réels et en temps réel. Si ce chiffre vous alarmerait en apparaissant sur une facture réelle, vos conditions d’arrêt ne sont pas encore assez strictes.

Effectuer ces quatre tests avant de faire confiance à une boucle d’auto-correction pour quoi que ce soit de réel permet de rattraper la grande majorité des échecs qui apparaîtraient autrement pour la première fois devant un client, un patron ou votre propre relevé bancaire.

Erreurs courantes qui cassent silencieusement une bonne conception

Même avec la bonne architecture à trois rôles, quelques erreurs d’implémentation spécifiques reviennent régulièrement dans des domaines complètement différents, et les connaître à l’avance vous évite de les redécouvrir chacune à vos dépens.

Laisser le Juge ne voir que la sortie du Constructeur, sans référence indépendante. C’est l’erreur la plus courante, et elle transforme silencieusement votre système d’un contrôle d’exactitude en un contrôle de cohérence. Un Juge sans rien à comparer ne peut vous dire que si la sortie semble cohérente en interne, jamais si elle est réellement correcte.

Donner à chaque rôle le même modèle avec seulement une fine différence d’instruction par-dessus. Si le Juge utilise le même modèle sous-jacent que le Constructeur, avec juste un prompt différent lui disant d’être « critique », il hérite souvent des mêmes angles morts que le Constructeur, car il s’agit fondamentalement du même processus de raisonnement sous un chapeau différent. Lorsque le budget le permet, un modèle réellement différent pour le rôle du Juge produit une véritable indépendance plutôt qu’une indépendance théâtrale.

Traiter le Gestionnaire comme un simple relais sans lui donner une véritable mémoire des tentatives précédentes. Un Gestionnaire sans visibilité sur ce qui a déjà été essayé pour cette tâche spécifique renverra volontiers le même retour d’échec au Constructeur une deuxième et une troisième fois, produisant le même résultat échoué identique à chaque fois, car rien dans le système ne se souvient que cette approche exacte a déjà échoué une fois.

Sauter les quatre tests de stress parce que le système a bien fonctionné lors de la seule démo que tout le monde a suivie de près. Un système qui se comporte correctement lorsque vous le surveillez de près et un système qui se comporte correctement lorsqu’il fonctionne sans surveillance sont des affirmations différentes. Seule la seconde est le véritable objectif de la construction d’une boucle d’auto-correction. Si vous n’avez pas testé les modes d’échec délibérément, vous ne savez pas réellement laquelle des deux affirmations est vraie pour votre système.

Écrire la condition d’arrêt comme une instruction molle au lieu d’une logique dure. « Arrêter quand c’est assez bien » dans un prompt n’est pas une condition d’arrêt, c’est une suggestion que le modèle peut et finira par contourner sous la bonne pression. Un compteur d’itérations dur que le Gestionnaire vérifie mécaniquement avant d’autoriser un autre cycle est une condition d’arrêt. La différence entre les deux importe énormément la première fois qu’une tâche se révèle réellement insoluble.

Un deuxième exemple concret : code auto-correctif

Le même squelette a une apparence différente mais suit une logique identique lorsque la tâche est du code plutôt que du contenu, et parcourir les deux côte à côte montre clairement à quel point peu de choses changent entre les domaines.

Le Constructeur ici est un agent de codage travaillant sur une tâche définie : un correctif de bug, une fonctionnalité, un refactor. Sa sortie structurée n’est pas seulement le diff de code, mais aussi la sortie réelle de la commande après tentative d’exécution, les résultats des tests, la sortie du lint, l’état de la compilation, le tout regroupé dans le transfert. Un Constructeur qui produit du code mais ne l’exécute jamais ne remplit pas vraiment correctement le rôle de Constructeur, car un code syntaxiquement plausible qui échoue à sa propre suite de tests est pire que pas de code du tout, puisqu’il a l’air terminé sans l’être.

Le Juge vérifie trois choses spécifiques et vérifiables. Le changement a-t-il passé la suite de tests existante sans que les tests eux-mêmes aient été modifiés, car un Constructeur qui modifie silencieusement un test pour le faire passer est un échec spécifique et étonnamment courant qui mérite d’être vérifié directement. L’analyse statique et le lint sont-ils revenus propres. Le diff répond-il réellement à la tâche assignée, et non à un problème différent mais connexe que le Constructeur a décidé qu’il était plus intéressant de résoudre en cours de route. Chacun de ces points obtient son propre succès ou échec explicite dans le verdict structuré.

Le Gestionnaire achemine en fonction du contrôle spécifique qui a échoué. Une suite de tests échouée renvoie au Constructeur avec la sortie exacte du test échoué directement attachée, et non une instruction générique de « corriger les tests ». Un décalage de périmètre, où le diff a résolu un problème différent de celui assigné, escalade immédiatement vers un humain plutôt que de boucler, car c’est un échec de jugement sur ce qu’était réellement la tâche, et non un défaut mécanique que le Constructeur pourrait simplement itérer tout seul.

Remarquez que le squelette sous-jacent ici, le Constructeur produit et soumet avec des preuves, le Juge vérifie par rapport à des critères nommés spécifiques avec un verdict par contrôle, le Gestionnaire achemine en fonction du contrôle exact qui a échoué, est identique à l’exemple de production de contenu ci-dessus. C’est la véritable leçon à retenir en voyant deux domaines différents côte à côte. Une fois que vous avez le squelette correct, l’appliquer à un nouveau type de tâche consiste principalement à écrire une nouvelle liste de contrôle spécifique pour le Juge, et non à reconcevoir toute l’architecture à partir de premiers principes à chaque fois.

Passer à l’échelle avec plusieurs boucles concurrentes

Lorsqu’une seule boucle d’auto-correction est vraiment fiable, la vraie question suivante est de savoir comment en exécuter plusieurs à la fois sans que le système ne devienne ingérable, car c’est exactement là que la plupart des gens échouent lors de leur deuxième tentative de mise à l’échelle.

La tentation est de lancer plusieurs boucles simultanément dès que la première fonctionne, en s’attaquant à cinq tâches différentes en parallèle parce que l’architecture le supporte techniquement. Résistez plus longtemps que nécessaire. Chaque boucle concurrente supplémentaire est un endroit de plus où une condition d’arrêt peut échouer silencieusement, un endroit de plus où le coût peut s’emballer inaperçu, un endroit de plus où la référence de vérité de terrain d’un Juge peut être subtilement erronée d’une manière qui ne se révèle que sous un volume réel plutôt que lors d’un seul test.

La voie de mise à l’échelle la plus sûre est l’expansion séquentielle avec un véritable seuil de confiance à chaque étape. Faites fonctionner une boucle de manière suffisamment fiable pour que vous ayez cessé de vérifier attentivement sa sortie, ce qui signifie qu’elle réussit constamment vos vérifications ponctuelles manuelles sur une période réelle, et non une seule démo réussie. Ce n’est qu’alors que vous ajoutez une deuxième boucle pour une tâche différente. Suivez le taux d’échec réel de chaque boucle au fil du temps, pas seulement si elle a semblé fonctionner sur les exécutions que vous avez observées.

Lorsque vous exécutez plusieurs boucles en parallèle, réfléchissez sérieusement à un tableau de bord de coûts partagé pour toutes, et non à un suivi par boucle isolé. Une seule boucle avec un budget raisonnable par tâche semble parfaitement correcte isolément. Dix boucles chacune individuellement dans le budget peuvent toujours s’additionner pour former un total vraiment alarmant que personne ne remarque jusqu’à l’arrivée de la facture agrégée, précisément parce que le suivi de chaque boucle individuelle semblait correct en soi.

La seule habitude qui empêche les problèmes de mise à l’échelle avant qu’ils ne commencent : enregistrez chaque déclenchement de condition d’arrêt dans chaque boucle, pas seulement les achèvements réussis. Une boucle qui atteint son plafond maximum d’itérations et escalade vers un humain fait exactement ce qu’elle est censée faire, mais si une boucle spécifique atteint ce plafond constamment alors que d’autres le font rarement, c’est un signal que le standard du Juge pour cette tâche particulière est soit mal calibré, trop strict pour jamais réussir, soit vérifie par rapport à une vérité de terrain erronée. Ce motif est invisible si vous ne suivez que les succès et traitez chaque escalade comme un événement isolé et sans intérêt plutôt que comme un point de données sur la conception de cette boucle spécifique.

Par où commencer cette semaine

N’essayez pas de construire un système d’auto-correction entièrement général lors de votre première tentative. Choisissez une tâche spécifique, étroite, bien définie que vous faites déjà régulièrement, quelque chose avec un standard clair que vous pourriez écrire si on vous le demandait, et construisez la boucle à trois rôles autour de cette seule tâche d’abord.

Écrivez la liste de contrôle du Juge explicitement avant d’écrire une seule ligne du prompt du Constructeur. Le standard que vous vérifiez doit façonner ce que vous demandez au Constructeur de produire, et non l’inverse. Si vous ne pouvez pas encore écrire la liste de contrôle, vous ne savez pas encore ce que « correct » signifie pour cette tâche suffisamment bien pour automatiser sa vérification, et cela vaut la peine d’être découvert avant de construire quoi que ce soit.

Exécutez les quatre tests de stress ci-dessus avant de faire confiance à la boucle pour quoi que ce soit qui compte vraiment, et non après que quelque chose a déjà mal tourné devant quelqu’un. Ajoutez la condition d’arrêt comme une logique réelle et dure dès la toute première version, et non comme une réflexion après coup une fois que vous avez déjà été brûlé par une boucle incontrôlée.

Une fois qu’une boucle est vraiment fiable, fonctionne sans surveillance, détecte les vraies erreurs, s’arrête proprement quand elle le doit, la seconde va beaucoup plus vite. Pas parce que les prompts se transfèrent directement, ils doivent généralement être réécrits pour la nouvelle tâche, mais parce que vous comprenez déjà la forme réelle du problème. Séparez la construction du jugement. Donnez au jugement quelque chose de réel à vérifier. Écrivez la condition d’arrêt comme une logique, pas comme un espoir.

Cette forme est toute la discipline. Tout le reste n’est que l’appliquer à la tâche qui se présente à vous.

Suivez @cyrilXBT pour les modèles de boucle exacts et les configurations Constructeur-Juge-Gestionnaire derrière tout ce qui se trouve dans cet article.