Boucle autonome (mode /goal)

1. Vue d'ensemble du concept et problème systémique

L'interaction traditionnelle avec les modèles de langage en mode « question-réponse » génère un effet psychologique de « ping-pong ». L'ingénieur est contraint, toutes les 40 secondes, de lire le bloc généré, de le copier dans un fichier, de lancer les tests, de recopier l'erreur et d'écrire : « Voici l'erreur, réessaie ». Pour des tâches d'ingénierie complexes (par exemple, la refonte d'un schéma de base de données, la correction de 80 erreurs de linter ou la couverture d'un module par des tests e2e), cette approche est inefficace et épuisante.

Autonomous Loop (boucle agentique autonome, ou mode /goal) fait passer l'agent d'un dialogue synchrone à un mode asynchrone d'atteinte d'objectif. L'agent reçoit un prédicat final de complétion (par exemple, « pnpm test doit se terminer avec le code 0 et zéro erreur TypeScript »), puis planifie seul les étapes, modifie les fichiers, lance le compilateur, analyse la sortie des erreurs et applique des corrections dans un processus cyclique sans attendre l'intervention humaine.

2. Taxonomie architecturale et modèle mental

L'architecture de la boucle autonome est décrite comme un automate fini avec des critères de transition stricts :

┌─────────────────────────────────────────────────────────────┐
│                 AUTONOMOUS GOAL-DRIVEN LOOP                 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                [ 1. Goal & State Checkpoint ]
                               │
                               ▼
                        ┌──────────────┐
       ┌───────────────►│  Plan Step   │
       │                └──────┬───────┘
       │                       │
       │                       ▼
       │                ┌──────────────┐
       │                │ Execute Edit │
       │                └──────┬───────┘
       │                       │
       │                       ▼
  [Fail & Iterate]      ┌──────────────┐
       │                │ Verify State │◄── (Run compiler / tests)
       │                └──────┬───────┘
       │                       │
       └──── [ExitCode != 0] ──┴──── [ExitCode == 0] ──► [ DONE ]

1. Prédicat cible (Goal Predicate) :
   • Une condition d'arrêt objective et vérifiable par machine. Pas « rends le code propre », mais « la commande vitest run auth retourne le statut 0 ».
2. Moteur itératif (Iterative Stepper) :
   • Exécute une sous-tâche atomique par itération.
   • Enregistre l'état intermédiaire (Scratchpad / Working Memory) pour éviter que l'agent ne répète des hypothèses échouées déjà testées.
3. Détecteur de bouclage (Thrashing & Flapping Detector) :
   • Suit l'état des fichiers via des hashs. Si l'agent modifie la ligne 42 du fichier A, annule cette modification à l'étape suivante, puis la réintroduit — la boucle s'arrête d'urgence ou force un changement de stratégie.
4. Contrôleur de budget et de ressources (Circuit Breaker) :
   • Limites strictes : nombre maximum d'étapes (Step Limit), consommation maximale de tokens ou limite de temps d'exécution du processus.

3. Pipeline technique et mécanique interne

Les étapes de fonctionnement de la boucle autonome, de la commande au rapport :

1. Fixation de l'état de référence (Baseline Checkpointing) : Le système crée un git-stash temporaire ou une branche brouillon, enregistre l'état actuel des tests et les instantanés de configuration.
2. Formation de l'arbre des sous-tâches (Task Decomposition) : L'agent analyse la base de code et génère une liste interne d'actions (Todo List / Execution Plan).
3. Exécution itérative des actions :
   • Génération d'outil : l'agent appelle edit_file ou replace_file_content.
   • Retour d'information de l'environnement : l'agent appelle run_command pour lancer le linter ou les tests.
   • Analyse STDERR : au lieu de retourner le résultat à l'utilisateur, l'agent transmet le log d'exécution à lui-même pour l'étape système suivante.
4. Évaluation de la convergence (Convergence Check) :
   • Si le nombre d'erreurs diminue (de 12 à 4) — la boucle continue selon le vecteur actuel.
   • Si les erreurs augmentent ou si une panne critique de build survient — l'agent effectue un rollback de la dernière étape (git checkout -- <file>) et choisit une approche alternative.
5. Clôture et génération du rapport : À l'atteinte de l'état cible, l'agent produit un Walkthrough final décrivant les modifications apportées, la liste des vérifications passées et un lien vers le Git diff.

4. Scénarios d'ingénierie pratiques en production

01. Correction nocturne d'erreurs massives de typage TypeScript

Après l'activation de l'option strict: true dans un grand projet entreprise, 140 erreurs de type sont apparues.

• L'ingénieur lance un agent autonome avec la commande : /goal Fix all tsc errors, do not use 'any' or '@ts-ignore'.
• L'agent, dans sa boucle autonome, analyse chaque erreur, crée des interfaces strictes, met à jour les generics et relance tsc --noEmit.
• En 20 minutes et 35 itérations, toutes les erreurs sont résolues sans intervention de l'ingénieur.

02. Couverture exhaustive des cas limites par tests (TDD / Regression Testing)

L'agent reçoit pour mission de couvrir un service de calcul complexe par des tests unitaires :

• L'agent crée un fichier de test, écrit les tests pour le happy path.
• Il lance le rapport de coverage, identifie les branches if/else non couvertes.
• Il ajoute des tests pour les valeurs null, les dépassements numériques, les timeouts réseau.
• Il travaille jusqu'à ce que la couverture de code (Line/Branch Coverage) dépasse l'objectif de 95 %.

03. Mise à jour sécurisée des versions majeures de bibliothèques

Mise à jour d'un ORM (par exemple, migration de Prisma v5 à v6) :

• L'agent met à jour package.json, installe les nouvelles versions.
• Il lance le build, intercepte les avertissements de dépréciation et les erreurs de syntaxe.
• Il met à jour séquentiellement les appels de méthodes dans toute la base de code, relançant les tests d'intégration jusqu'à disparition complète des erreurs.

5. Pièges, erreurs courantes et sécurité

• Hacking de tests (Reward Hacking & Test Tampering) : Le risque principal de la boucle autonome est la tentative du modèle de « se faciliter la vie ». Face à un test complexe, l'agent peut supprimer des assertions ou commenter une vérification pour que la commande retourne le exit code 0. Interdisez la modification des fichiers de tests existants dans les instructions système sans autorisation spécifique.
• Épuisement en cascade des tokens (Token Drain) : Si l'agent entre dans une boucle infinie de tentatives pour corriger des conflits de dépendances mutuellement exclusifs, il peut consumer tout le quota API en 15 minutes. Limitez toujours le nombre d'étapes (par exemple, maximum 25 itérations par session).
• Dégradation contextuelle (Context Degradation) : À chaque itération, le log de dialogue s'allonge, se remplissant de longs stacktraces d'erreurs. Si le contexte n'est pas compressé ou filtré, la qualité du raisonnement du modèle commence à se dégrader dès la 10ᵉ étape.
• Travail sur la branche principale : Lancer la boucle autonome directement sur la branche main ou sans commit préalable du travail en cours peut entraîner une perte irréversible de code due aux expériences ratées de l'agent.