Pourquoi les bugs du code généré par GitHub Copilot sont difficiles à attribuer
La complétion en ligne présente un profil de risque différent de celui d'un agent qui réécrit des fichiers. Chaque suggestion est assez petite pour sembler relisable : vous la relisez en une seconde et vous passez à la suite. Cette seconde d'attention est fiable pour la ligne que vous avez sous les yeux, et aveugle au système qui l'entoure.
Conséquence : quand quelque chose casse, la bissection est un cauchemar. Il n'y a pas un commit suspect, seulement une longue traîne de complétions acceptées qui semblaient toutes correctes sur le moment.
Les trois dérives à surveiller
Dérive des conventions
Les complétions reprennent les motifs issus de leur entraînement et du code environnant, qui ne correspondent pas toujours à la convention réelle de votre base de code.
La gestion des erreurs, les vérifications de valeurs nulles et la journalisation divergent lentement d'un module à l'autre.
Logique dupliquée
Accepter une fonction utilitaire générée va plus vite que de retrouver celle qui existe déjà : la même règle finit implémentée à trois endroits.
Plus tard, l'une d'elles est corrigée, les deux autres non.
Valeurs par défaut plausibles
Une valeur par défaut, un délai d'expiration ou un ordre de tri suggéré paraît raisonnable et ne correspond pas à la règle de votre produit.
Rien n'échoue. Le comportement n'est simplement pas celui que quiconque avait prévu.
Ces trois dérives sont invisibles en revue et visibles quand le produit tourne, ce qui détermine où doit se placer la vérification.
Vérifiez le comportement à une cadence régulière, pas à chaque complétion
Vérifier chaque suggestion acceptée n'est ni possible ni utile. La bonne unité, c'est la pull request : à ce stade, un ensemble cohérent de changements existe, et il reste assez réduit pour qu'on puisse raisonner dessus si quelque chose cloche.
Ce que vous voulez faire vérifier, ce n'est pas le nouveau code, c'est le comportement dans lequel ce code s'inscrit. Une pull request qui a touché au module de facturation doit exercer la facturation de bout en bout, y compris les chemins auxquels l'auteur n'a pas pensé, car c'est précisément là que se cache une valeur par défaut plausible.
Installer le skill de vérification permet à l'agent de s'en charger lui-même, plutôt que d'attendre qu'un humain y pense.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même terrain pour qui ne souhaite pas d'installation locale, et l'ensemble des commandes disponibles se trouve dans le dépôt CLI.
La question de régression que personne ne se pose assez tôt
La bonne question à propos d'une base de code nourrie à la complétion n'est pas « ce code est-il bon ? ». C'est « le produit fait-il toujours ce qu'il faisait le mois dernier ? ». Ce sont deux questions différentes, et seule la seconde détecte la dérive.
Y répondre suppose une série de vérifications antérieures au changement, et c'est justement la partie que les équipes repoussent. Dix parcours écrits dès la première semaine valent mieux que cent écrits après le premier incident, car seuls ces dix-là ont été définis avant que quiconque sache lesquels compteraient.
L'habitude de revue qui passe à l'échelle
Relire chaque complétion est impossible, et n'en relire aucune est exactement ce qui laisse la dérive s'installer. L'habitude qui fonctionne consiste à relire par catégorie plutôt que ligne à ligne.
Quand une complétion introduit un chemin d'erreur, vérifiez qu'il correspond à la façon dont le reste du module traite les erreurs, car c'est là que la divergence est la plus fréquente et la plus pénible à démêler ensuite. Quand elle introduit une valeur par défaut, demandez-vous d'où vient cette valeur, car une valeur par défaut plausible est la manière la plus discrète de changer un comportement. Quand elle introduit une fonction utilitaire, prenez dix secondes pour chercher celle qui existe déjà, puisque c'est la logique dupliquée qui rend une correction ultérieure incomplète.
Ces trois vérifications prennent chacune quelques secondes et attrapent l'essentiel de ce qui s'accumule. Tout le reste se détecte mieux en faisant tourner le produit qu'en le lisant.
Automatisez la vérification
La dérive est progressive : la vérification doit donc être d'une régularité ennuyeuse. Tout ce qui repose sur la mémoire de quelqu'un sautera précisément pendant la semaine chargée où le plus de complétions sont acceptées.
Si le pipeline appartient à une autre équipe, la GitHub App est la voie de moindre résistance : c'est un webhook, elle ne change rien dans votre dépôt, et elle se déclenche quand votre build signale la mise en ligne de la nouvelle version. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions s'en charge.
Détecter la dérive sans relire chaque complétion
Relire chaque suggestion acceptée est impossible : TestSprite vérifie donc le comportement dans lequel s'inscrit le code. La couverture est générée à partir de votre produit, s'exécute sur chaque pull request et répond à la question qui compte pour une base de code nourrie à la complétion : est-ce que cela fait toujours ce que cela faisait le mois dernier ?
Cela attrape directement les trois dérives. Une valeur par défaut plausible qui a modifié un ordre de tri apparaît sous la forme d'un parcours qui se comporte autrement. La logique dupliquée apparaît lorsqu'une copie est corrigée et l'autre non. La dérive des conventions dans la gestion des erreurs apparaît sous la forme d'un chemin qui échoue désormais en silence.
La vérification s'exécute là où se trouve le changement, sous forme de commentaire sur la pull request ou de contrôle de commit : une régression désigne alors un seul lot de complétions plutôt qu'un trimestre entier.
Le code généré par Copilot est-il moins bon que le code écrit à la main ?
Ligne par ligne, pas dans la plupart des cas. Le risque est volumétrique : il entre dans le dépôt plus de code par heure que le processus de revue n'a été conçu pour en absorber, si bien qu'un même taux de défauts en laisse passer davantage.
Une revue plus stricte réglerait-elle le problème ?
En partie, et cela va à l'encontre de la raison même pour laquelle on utilise la complétion. Déplacer le contrôle de la lecture vers la vérification comportementale préserve la vitesse et rétablit le filet de sécurité.
Et les tests écrits par Copilot ?
Utiles pour la couverture, faibles comme contrôle indépendant. Un test généré à partir des mêmes hypothèses que le code donne raison au code par construction.
Combien de parcours faut-il couvrir en premier ?
Commencez par la poignée que vous montreriez à un client, plus tout chemin qui touche à l'argent ou aux permissions. Étendez ensuite à partir des incidents plutôt qu'à partir d'un objectif de couverture.
Cela nécessite-t-il un accès au dépôt ?
La vérification s'exécute sur l'application déployée, via son interface. L'accès au dépôt sert uniquement à publier les résultats sur les pull requests et les commits.
Le bug, c'est la dérive, pas la suggestion.
Les bugs du code généré par GitHub Copilot s'accumulent au fil de nombreuses petites complétions acceptées. Vérifiez le comportement à l'échelle de la pull request plutôt qu'à celle de la suggestion, définissez les parcours avant d'en avoir besoin, et laissez la vérification s'exécuter automatiquement.