La relecture du code généré par l'IA repose sur les mêmes principes que la relecture de tout code, mais certains modes d'échec apparaissent plus fréquemment et nécessitent une attention particulière. Les erreurs confiantes et d'apparence plausible sont plus courantes ; le rôle du relecteur est de ralentir là où les relecteurs humains ont instinctivement tendance à accélérer.
Pourquoi le code généré par l'IA semble plus facile à approuver
Le code généré par l'IA est généralement bien formaté, nommé de façon cohérente et accompagné de commentaires en ligne. Cette qualité de surface peut diminuer la vigilance d'un relecteur. Le code donne l'impression d'avoir été écrit par quelqu'un de compétent, ce qui crée une pression à approuver rapidement. Résister à cette pression est la première chose à faire.
Le problème de fond est qu'un modèle de langage optimise pour la vraisemblance, non pour la correction. Il n'a aucun intérêt dans le résultat. Il ne peut pas exécuter le code avant de le proposer, et il ne sait pas ce qui a changé dans votre base de code mardi dernier.
Ce qui change dans la revue
Présumez moins quant à l'intention. Quand un collègue écrit une fonction, vous pouvez lui demander pourquoi il a fait un choix particulier. Le code généré par l'IA n'a pas d'auteur à interroger. Si l'intention ne ressort pas clairement du code et de son contexte, c'est un manque à combler avant d'approuver, pas après.
Vérifiez les points de jonction. Les outils d'IA travaillent sur une fenêtre de contexte. Ils voient ce qui leur a été transmis, rien d'autre. Les erreurs se concentrent aux frontières : là où le code généré rencontre le reste du système, là où les types sont supposés plutôt qu'importés, là où un appel d'API correspond aux données d'entraînement du modèle plutôt qu'à la version que vous utilisez réellement. Voir what is a context window pour en savoir plus sur cette limitation.
Traitez les tests avec un scepticisme particulier. Les modèles génèrent des tests qui passent contre le code qu'ils viennent d'écrire. Ce n'est pas la même chose que des tests capables de détecter une régression. Vérifiez si les tests exercent le comportement qui vous importe, ou s'ils confirment simplement que la fonction retourne quelque chose.
Soyez attentif aux dépendances hallucinations. Les modèles font parfois référence à des bibliothèques, des méthodes ou des clés de configuration qui n'existent pas, ou qui existent dans une version différente de celle que vous utilisez. Une vérification rapide des imports et des versions de dépendances ne coûte pas cher. Découvrir le problème en production, si.
Lisez attentivement la gestion des erreurs. La gestion des erreurs générée par l'IA tend à être générique. Des catches silencieux, des blocs except nus, des erreurs avalées dans une ligne de log que personne ne surveille. Ces éléments passent une revue superficielle car ils ressemblent à de la gestion d'erreurs. Lisez chacun d'eux et demandez-vous ce qui se passe réellement quand ce chemin est emprunté.
Ce qui ne change pas
La liste de contrôle standard s'applique toujours : correction, sécurité, performance, lisibilité, couverture de tests, adéquation avec l'architecture existante. La génération par IA ne rend pas ces considérations moins pertinentes. Elle change l'endroit où les erreurs ont tendance à se cacher, pas leur existence.
La revue de sécurité en particulier ne doit pas être abrégée. L'injection de prompt est une catégorie de risque propre aux systèmes assistés par l'IA, mais l'ensemble plus large des préoccupations, injection, paramètres par défaut non sécurisés, contrôle d'accès inapproprié, s'applique au code généré par l'IA autant qu'à n'importe quel autre.
Bonnes pratiques au quotidien
- Lisez le diff comme du code, pas comme un résumé. Résistez à l'envie de parcourir en diagonale parce que cela semble propre.
- Si un bloc est long, décomposez la revue en plusieurs passages : un pour la logique, un pour la gestion des erreurs, un pour les tests.
- Quand quelque chose semble plus astucieux que nécessaire, cela mérite un second regard. Les modèles produisent parfois des solutions trop complexes.
- Notez les cas où le code généré par l'IA a causé des problèmes. Les schémas émergent rapidement et permettent de savoir quoi vérifier la prochaine fois.
Pour une vue d'ensemble de l'évolution des pratiques de revue de code, voir what changed about code review.
Ce que nous évaluons
La relecture du code généré par l'IA fait partie des compétences que nous évaluons directement pendant la sélection. Dans l'évaluation AI-native, la vérification des productions de l'IA est notée de façon explicite : l'ingénieur sait-il repérer, avant la mise en production, des API hallucinées, une logique subtilement fausse ou des failles de sécurité dans le code généré, au lieu de lui faire confiance parce qu'il compile ? Le jugement selon le risque est noté dans les deux évaluations, car un agent produit une modification de texte et une migration de paiement à la même vitesse et avec la même assurance. Le déroulé des deux évaluations est détaillé dans notre processus de sélection.
Réponses courtes
La revue du code généré par l'IA est-elle fondamentalement différente de la revue du code écrit par un humain ?
Les principes sont les mêmes, mais les modes d'échec changent. Le code généré par l'IA a tendance à paraître plus propre qu'il ne l'est, les erreurs se concentrent aux frontières de contexte, et les tests ne font souvent que confirmer ce que le modèle vient d'écrire plutôt que de détecter de futures régressions.
Le code généré par l'IA doit-il être identifié comme tel dans une pull request ?
De nombreuses équipes trouvent cela utile, car cela incite les relecteurs à appliquer les vérifications spécifiques qui comptent. Cela aide également à suivre l'origine des problèmes. Il n'existe pas encore de standard universel, mais la transparence tend à améliorer la qualité de la revue.
Comment relire efficacement des tests générés par l'IA ?
Vérifiez si chaque test exercice un comportement que la base de code doit réellement protéger, pas seulement s'il passe. Les modèles écrivent des tests qui confirment leur propre sortie. Demandez-vous quelle régression le test détecterait, pas seulement s'il passe actuellement.
