Examinez le code généré par l’IA

Lisez l’exigence avant le résumé

Commencez par le comportement demandé et les critères d’acceptation. Inspectez ensuite le diff réel. Le résumé de l’agent peut vous guider, mais il peut omettre des changements ou décrire les contrôles de manière inexacte.

Confirmez la branche et le commit examinés. Cherchez les modifications de configuration, de dépendances, d’infrastructure et de tests, en plus du code applicatif. Une petite fonctionnalité visible peut inclure un changement majeur de permissions ou de comportement de déploiement.

Examinez d’abord le comportement aux conséquences les plus importantes. Le formatage et les noms comptent, mais ne doivent pas détourner l’attention d’une limite de données manquante.

Suivez l’identité jusqu’à la ressource

Considérez cet endpoint fictif et incomplet. Il illustre un problème de revue ; ce n’est pas du code de production.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

La fonction obtient un utilisateur authentifié. Elle ne montre pas de décision d’autorisation pour la facture. La personne chargée de la revue doit vérifier si une autre couche applique cette décision. La valeur utilisateur inutilisée justifie une investigation, mais ne prouve pas à elle seule un défaut exploitable.

Suivez la requête dans le système réel. Identifiez l’utilisateur et l’organisation de confiance. Vérifiez comment la requête limite l’accès à l’enregistrement demandé. Inspectez le comportement d’erreur et les tests de requêtes interdites.

Ne supposez pas qu’un bouton masqué protège l’API. Un appelant peut envoyer une requête sans passer par l’interface. Ne supposez pas qu’un ID d’enregistrement valide donne le droit d’y accéder.

Demandez quelles preuves pourraient faire rejeter la modification

Un test réussi peut utiliser une fixture d’administrateur ou une autorisation simulée. Vérifiez s’il teste la limite pertinente. Ajoutez si nécessaire un cas avec une autre organisation et un véritable chemin d’autorisation.

Pour une modification d’interface, inspectez le rendu. Vérifiez l’usage au clavier, les états vides, le chargement et les erreurs. Une vérification des types ne prouve pas qu’une boîte de dialogue est utilisable au clavier.

Pour une modification de dépendance, vérifiez sa nécessité. Examinez la version, la licence et les constats de sécurité. N’acceptez pas une mise à jour sans rapport simplement parce que l’agent l’a générée pendant la tâche.

Gardez la revue indépendante

Un second modèle peut repérer des problèmes utiles. Il peut aussi répéter les hypothèses de l’implémentation. Fournissez l’exigence et le diff à l’outil de revue. Évitez de lui dire que la modification est déjà correcte.

Exigez que chaque constat indique un scénario concret de défaillance et le code concerné. Traitez les avertissements non étayés comme des questions à examiner. Une approbation assurée reste un avis tant que les affirmations importantes n’ont pas de preuves.

La revue humaine reste une décision de responsabilité. La personne qui examine la modification doit la comprendre assez pour expliquer son comportement, ses risques et sa vérification. Si le diff est trop grand, réduisez le périmètre ou divisez-le en modifications qui peuvent être examinées.

Terminez la revue sur la révision finale

Après une correction, relancez les contrôles concernés. Vérifiez qu’elle ne crée pas un autre problème. Assurez-vous que la revue requise s’applique à la révision finale selon la politique du dépôt.

Rédigez la décision d’acceptation en termes de comportement et de preuves. Consignez chaque limite restante avec un responsable et une prochaine action. Ne transformez pas un problème non résolu en affirmation que tous les contrôles ont réussi.

Utilisez l’exercice de revue de code pour apprendre à repérer la décision manquante avant d’examiner une modification réelle.