Outil de débogage Cursor : pourquoi la boucle de correction s'enlise

Pourquoi une session avec l'outil de débogage Cursor s'enlise

Le débogage est une boucle : observer, formuler une hypothèse, modifier, observer à nouveau. Un agent qui travaille à partir de vos fichiers peut accomplir trois de ces quatre étapes. Il ne peut pas observer. Chaque fois que vous collez une trace d'appels ou décrivez ce que vous avez vu à l'écran, vous effectuez manuellement la seule étape dont il est incapable, et la qualité de toute la boucle plafonne au niveau de vos descriptions.

C'est pourquoi le troisième tour est généralement pire que le premier. La fatigue s'installe, votre description raccourcit, et l'agent raisonne désormais sur le résumé d'un résumé.

Les trois descriptions qui égarent un agent

Ce qui referme la boucle

Confiez l'étape d'observation à l'agent au lieu de l'assurer vous-même. Cela suppose que quelque chose pilote l'application déployée comme le ferait une personne, et rende compte de ce qui s'est passé sous forme de preuves plutôt que de prose.

La forme de ces preuves compte plus que leur volume. Ce qui a été tenté, ce que l'application a réellement fait, et l'endroit où les deux divergent. Un agent peut agir directement là-dessus. Une capture d'écran et une trace d'appels exigent encore qu'un humain les interprète, ce qui vous replace dans la boucle que vous cherchiez à quitter.

L'installation ajoute une compétence de vérification directement dans Cursor, qui sait dès lors créer un cas de test, l'exécuter et en lire le résultat sans que vous ayez à réexpliquer le processus à chaque fois.

Vous pouvez faire de même depuis le tableau de bord TestSprite. Tout le reste de ce que fait le CLI se trouve dans le dépôt du CLI.

Une repro que vous pouvez transmettre vaut mieux qu'une description

L'habitude qui rapporte le plus est d'arrêter de décrire le bug pour commencer à le reproduire. Un cas écrit indique quelle page ouvrir, quoi faire et ce qui doit être vrai ensuite. Trois lignes de ce type surpassent trois paragraphes d'explication, parce qu'elles ne laissent aucune ambiguïté et qu'elles peuvent être rejouées.

Cela change aussi la conversation avec l'agent. Au lieu de « le menu déroulant est cassé », l'entrée devient une exécution qui est arrivée à l'étape quatre et a constaté que la mauvaise option était sélectionnée. Il ne reste plus rien à interpréter.

Écrivez le cas avant la première tentative de correction plutôt qu'après la troisième. À ce moment-là, vous vous souvenez encore exactement de ce que vous avez fait pour le déclencher, un savoir qui s'évapore plus vite qu'on ne le croit.

Un exemple concret de boucle qui se referme

Prenons un cas précis. Un utilisateur signale que la modification d'un filtre enregistré est parfois annulée. Vous le décrivez, l'agent trouve une concurrence entre deux mises à jour d'état et propose une garde. Vous l'appliquez, vous essayez une fois, ça fonctionne, vous passez à autre chose. Deux jours plus tard, le signalement revient.

Ce qui a échoué n'est pas la correction. C'est qu'une seule tentative manuelle constitue un échantillon de taille un face à un bug intermittent, et un bug intermittent réussit un essai unique à peu près aussi souvent qu'il échoue. La boucle qui converge vraiment a une autre allure : consignez la séquence sous forme de cas, exécutez-la plusieurs fois et lisez le taux. Quatre échecs sur dix constituent une instruction radicalement différente de « c'est cassé » pour l'agent, parce que cela écarte toute une classe de causes déterministes et désigne le timing.

La deuxième chose qui change, c'est ce qui se passe après la correction. Le même cas est réexécuté dix fois, et soit le taux tombe à zéro, soit il n'y tombe pas. Vous disposez alors d'une preuve et non d'une impression, et le cas reste dans la suite de tests, si bien que le troisième signalement n'arrive jamais.

L'affirmation dont il faut se méfier

« J'ai corrigé le problème » est la phrase la plus coûteuse du débogage assisté par agent. Elle est produite par le raisonnement même qui a produit la modification, et n'apporte donc aucune information indépendante. Une correction est confirmée quand on observe que le comportement est correct, et par définition l'agent qui l'a écrite ne peut pas être celui qui la confirme.

Ce n'est pas une critique du modèle. Un humain qui écrit un correctif puis le déclare valide sans rien exécuter recevrait la même réponse en revue de code.

Faites survivre la vérification à la session

Le cas que vous avez écrit pour reproduire le bug vaut plus après la correction que pendant. Conservez-le et exécutez-le à chaque modification, pour que le même défaut ne puisse pas revenir discrètement trois semaines plus tard.

• La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Elle écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.

• GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.

Ce qui change avec une étape de vérification dans la boucle

TestSprite fournit l'observation qui manque à la boucle. L'installation ajoute une compétence de vérification directement dans Cursor, afin que l'agent puisse créer un cas, l'exécuter sur votre application déployée et en lire le résultat sans que vous ayez à relayer quoi que ce soit.

Concrètement, l'effet sur une session de débogage est que les tours cessent de se répéter. L'agent ne raisonne plus sur votre souvenir de ce que vous avez vu ; il dispose d'un enregistrement de ce qui a été tenté, de ce que l'application a fait et de l'endroit où les deux divergent. Une correction qu'il propose est confirmée par autre chose que le raisonnement qui l'a produite, seule façon pour que « j'ai corrigé le problème » devienne une information.

La reproduction survit elle aussi à la session. Le cas qui a trouvé le bug reste dans la suite de tests et s'exécute à chaque modification, pour que le même défaut ne puisse pas revenir discrètement dans six semaines.