Bugs du vibe coding : quoi vérifier quand vous ne lisez pas le code

Pourquoi les bugs du vibe coding se regroupent

Un agent optimise le parcours que vous avez décrit. Vous décrivez ce que vous voulez voir se produire : le parcours nominal est donc construit avec soin, et tout ce qui l'entoure est construit de façon plausible. Plausible est le mot qui compte : le code compile, l'écran s'affiche, et les hypothèses n'ont jamais été confrontées à la réalité.

C'est pour cela que les défaillances sont prévisibles. Elles se situent toujours aux frontières de la description.

Les quatre groupes, dans l'ordre où ils frappent

• La persistance. L'écran se met à jour, la base de données non. Un rechargement le révèle instantanément. Rechargez après chaque écriture avant de croire quoi que ce soit.

• Les états vides et les états d'erreur. Zéro résultat, une requête en échec, une saisie refusée. Rien de tout cela ne figurait dans votre prompt. Testez délibérément chacun de ces cas. Ils cassent plus souvent que le parcours nominal.

• Le deuxième compte. La propriété, les permissions et la visibilité sont déduites de l'unique session qui a servi à construire l'application. Connectez-vous en tant qu'un autre utilisateur avant que quelqu'un d'autre ne le fasse.

Le quatrième est plus subtil : les fonctionnalités d'hier. Chaque nouvelle instruction peut défaire discrètement quelque chose qui fonctionnait, et personne ne vérifie l'ancien comportement parce que la conversation est passée à autre chose.

La vérification qui tient le rythme de vos prompts

La vérification manuelle tient un après-midi, puis se dégrade : la surface à couvrir grandit à chaque prompt, pas votre patience. Ce qu'il vous faut, ce sont des vérifications écrites en langage naturel et exécutées automatiquement, pour que les fonctionnalités d'hier soient revérifiées sans que vous ayez à le décider.

La configuration met cela entre les mains de l'agent : la vérification a lieu en même temps que le développement, plutôt que comme une corvée à part.

Rien de tout cela ne nécessite un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage naturel et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter la même chose depuis la ligne de commande s'ils le préfèrent, ce qui se trouve dans le dépôt CLI.

Dix minutes qui en détectent l'essentiel

• Créez un compte, déconnectez-vous, reconnectez-vous. La panne totale la plus fréquente, et la première chose que fait un vrai utilisateur.

• Créez, rechargez, confirmez que ça a tenu. Détecte d'emblée le groupe de la persistance.

• Soumettez quelque chose d'invalide. Vous vérifiez que cela échoue clairement au lieu de réussir en silence.

• Refaites le parcours principal avec un compte tout neuf. Détecte le groupe des permissions.

Aucune de ces vérifications n'exige de lire du code, et ensemble elles trouvent l'essentiel de ce qu'un inconnu découvrirait autrement.

Pourquoi le même bug revient sans cesse

Le reproche le plus courant fait à cette façon de développer n'est pas que les choses cassent, mais qu'en corriger une en casse une autre, encore et encore. Ce n'est pas une défaillance du modèle. C'est une trace écrite qui manque.

Chaque instruction est interprétée à l'aune de l'état actuel du code, et de rien d'autre. Il n'existe aucune liste des comportements qui devaient déjà continuer de fonctionner : l'agent n'a donc aucun moyen de savoir que la modification demandée entre en conflit avec quelque chose que vous avez établi mardi dernier. De son point de vue, il n'y a pas de conflit, parce que mardi dernier n'est pas dans la pièce.

Les vérifications écrites sont cette trace. Elles ne rendent pas l'agent plus intelligent, elles rendent votre intention durable. Concrètement, la troisième et la quatrième série de modifications cessent de défaire les deux premières, et c'est à ce moment-là que développer ainsi devient fiable au lieu d'être épuisant.

Avant que ça n'atteigne de vrais utilisateurs

Dès lors que d'autres personnes vont utiliser l'application, les vérifications doivent s'exécuter à chaque modification, et non quand vous y pensez.

• 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 dans votre propre workflow, configurée depuis le terminal.

Laisser les vérifications s'exécuter d'elles-mêmes

TestSprite fait que les dix minutes de vérification décrites sur cette page cessent d'être un travail manuel. Vous décrivez chaque parcours une fois, en langage naturel, et il les exécute sur votre application après chaque modification.

Cela règle directement ce que l'on trouve le plus frustrant dans cette façon de développer. Les vérifications écrites constituent la trace de ce qui devait déjà continuer de fonctionner : une nouvelle instruction est donc validée par rapport à elles au lieu d'être interprétée isolément. La boucle où corriger une chose en casse une autre cesse d'être la norme.

Rien de tout cela ne nécessite un terminal ni un fichier de test. Créez un projet dans le tableau de bord, pointez-le vers votre application et décrivez les quatre vérifications ci-dessus. Les développeurs de votre équipe peuvent piloter la même chose depuis la ligne de commande s'ils le préfèrent.