Réviser du code écrit par un agent d'IA

Objectif

Réviser une modification écrite par un agent fondé sur un modèle de langage, ou avec une forte assistance de sa part, de manière à repérer les modes de défaillance typiques du code généré, tout en appliquant par ailleurs la norme de révision habituelle à tout le reste.

Prérequis

Une description de la modification qui indique ce qui a été demandé, ce que l'agent a fait et ce qu'il n'a pas vérifié ; la personne qui relit, capable d'exécuter le code et les tests ; la liste de contrôle de révision habituelle de l'équipe.

Étapes

1. Lire d'abord l'intention : comparer la demande avec ce que fait le diff. Un motif couramment rapporté dans les modifications générées est la dérive de portée : refactorisations non demandées, identifiants renommés ou « améliorations » du code adjacent. Demander que ces ajouts soient séparés avant de réviser le reste.
2. Confirmer que chaque nouvelle dépendance, API, option et fonction existe dans les versions utilisées : ouvrir l'import, l'entrée du registre ou la documentation. Des API plausibles mais inexistantes constituent un mode de défaillance couramment rapporté du code généré.
3. Vérifier les affirmations sur les tests par des preuves, pas par la phrase qui les énonce : retrouver l'exécution d'intégration continue correspondante. Exécuter les tests ajoutés par la modification et casser temporairement le code testé pour confirmer qu'ils peuvent échouer.
4. Lire les tests avant l'implémentation. Les tests générés vérifient souvent la sortie actuelle de l'implémentation plutôt que l'exigence, simulent l'élément même qu'ils sont censés tester, ou protègent l'assertion par une condition qui ne se vérifie jamais.
5. Traquer les erreurs traitées silencieusement : blocs except ou catch trop larges, valeurs par défaut renvoyées en cas d'échec, tentatives illimitées, journalisation à la place de la propagation.
6. Appliquer la vigilance habituelle aux limites et aux chemins sensibles pour la sécurité : validation des entrées, traitement des chemins de fichiers, construction de commandes shell et de requêtes SQL, secrets dans le code ou les journaux. Le code généré se lit avec fluidité, ce qui invite à le survoler ; ralentir précisément là où il paraît le plus sûr de lui.
7. Vérifier que les commentaires et les docstrings décrivent le code tel qu'il est arrivé, pas tel qu'il a été rédigé au premier jet ; les commentaires obsolètes sont fréquents après une génération itérative.
8. Indiquer dans la révision quelles parties ont été exécutées, lues attentivement ou seulement survolées, afin que le prochain lecteur sache où l'attention humaine s'est portée.

Résultat attendu

Les défauts caractéristiques du code généré (API inventées, tests tautologiques, dérive de portée, gestion d'erreurs dissimulée) sont repérés en révision, et le compte-rendu de révision montre ce qu'une personne a effectivement vérifié.

Limites et base de vérification

Il s'agit d'un protocole proposé ; aucune comparaison des taux de défauts entre modifications générées et écrites à la main n'est avancée. Les étapes allongent le temps de révision, et sur de très petites modifications, les étapes 2 à 5 peuvent suffire. Une modification dont on ne sait pas comment elle a été produite devrait être révisée comme si elle avait été générée.

Automatiser avant de lire

Exécuter les vérifications mécaniques avant qu'une personne ne lise la modification, et faire joindre les résultats par la personne qui l'a écrite. Une compilation avec le vérificateur de types ou le résolveur d'imports règle la question de l'existence de chaque API et dépendance (étape 2). Une exécution de tests de mutation limitée au diff règle la question de savoir si les nouveaux tests peuvent échouer (étape 3), et une exécution de test en échec datant d'avant le correctif constitue une preuve acceptable lorsqu'aucun outil de mutation n'est disponible. Un analyseur statique configuré pour signaler les blocs except et catch vides ou aveugles couvre la moitié évidente de l'étape 5. Le temps de relecture se porte alors sur les questions que les outils ne peuvent pas trancher : la conformité du diff à la demande, le fait que les tests vérifient l'exigence plutôt que l'implémentation, et le traitement effectif des limites.