Là où une boucle de débogage Trae plafonne
Un agent qui débogue à partir du code source sait lire, raisonner et modifier. Il ne sait pas observer. C'est vous qui fournissez l'observation, en prose, de mémoire, et ce canal est étroit. Il transmet ce que vous avez remarqué et laisse de côté ce que vous n'avez pas jugé pertinent, c'est-à-dire souvent ce qui compte vraiment.
Le plateau survient lorsque l'agent a épuisé les hypothèses que votre description permet de formuler. Multiplier les tours n'y change rien, car les informations en entrée n'ont pas progressé.
Trois types de bugs particulièrement touchés
Synchronisation
Un élément s'affiche avant l'arrivée des données, ou une requête se termine après la disparition du composant.
Impossible à repérer dans un diff, évident quand vous le voyez se produire.
État résiduel
La première action fonctionne, la seconde non, parce que quelque chose n'a pas été réinitialisé.
Une reproduction qui repart de zéro ne le montrera jamais.
Écart entre environnements
Le code est correct et c'est l'environnement qui diverge : une variable manquante, un cache obsolète, des données différentes.
L'agent continue de corriger du code qui n'a jamais été défectueux.
Ajoutez l'étape d'observation
Plutôt que de décrire ce que vous avez vu, faites piloter l'application déployée par quelque chose qui rapporte ce qui s'est passé. Ce que reçoit l'agent devient alors un relevé et non un souvenir : ce qui a été tenté, ce qu'a fait l'application, et où les deux ont divergé.
L'installation ajoute cette capacité à l'agent : il peut produire et lire ses propres preuves au lieu d'attendre que vous les lui transmettiez.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même installation est disponible depuis le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes CLI est décrit dans le dépôt du CLI.
Deux questions pour sortir du plateau
Est-ce que cela échoue dès un démarrage à zéro ? Si oui, c'est un problème de logique. Si cela n'échoue qu'à la deuxième tentative, il s'agit d'un état résiduel, et toutes les hypothèses portant sur le code visaient jusqu'ici à côté.
Est-ce que cela échoue dans un autre environnement ? Si le même build se comporte différemment à deux endroits, arrêtez de modifier le code. La différence entre les environnements est le bug.
Les deux coûtent peu à vérifier, et toutes deux réorientent l'ensemble de la session quand la réponse surprend.
Conservez la reproduction après le correctif
Le cas que vous avez construit pour voir le bug est le contrôle qui l'empêche de revenir. Exécutez-le à chaque modification plutôt que de le supprimer avec la conversation.
Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement garantit que chaque modification est vérifiée sans que personne ait à le décider ; la GitHub App s'en charge depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.
Pourquoi l'agent propose-t-il sans cesse des correctifs similaires ?
Parce que les informations en entrée n'ont pas changé. Sans nouvelles observations, il ne peut que réexplorer le même espace d'hypothèses, formulé autrement.
Dois-je coller davantage de logs ?
Plus de signal aide, et les logs décrivent ce que le code a décidé plutôt que ce que l'utilisateur a vécu. Une exécution contre l'application réelle comble l'écart que les logs laissent.
Est-ce propre à Trae ?
Non. Tout agent qui débogue à partir du code source a le même angle mort. Le workflow diffère, l'étape manquante est identique.
Et si je n'arrive pas à le reproduire de façon fiable ?
Alors l'intermittence est le constat. Exécutez plusieurs fois le même cas et comparez. Un parcours qui échoue une fois sur quatre relève d'un problème de synchronisation ou d'état, ce qui restreint considérablement la recherche.
Le correctif doit-il être vérifié séparément ?
Oui. Un correctif proposé et confirmé par le même raisonnement ne repose sur aucune preuve indépendante. Quelque chose doit observer le comportement corrigé.
La boucle a besoin d'une observation, pas d'un tour de plus.
Une session avec l'outil de débogage Trae plafonne lorsque l'agent épuise les hypothèses que votre description peut soutenir. Donnez-lui de vraies observations de l'application en cours d'exécution, demandez-vous si l'échec survit à un démarrage à zéro et à un autre environnement, et conservez la reproduction comme contrôle permanent.