Gains :
- Possibilité d'utiliser l'IA comme filtre d'examen initial avec des catégories et des balises de gravité
- Capacité à filtrer les résultats avec l'esprit humain pour vérifier/faux positif/appliquer
- Capacité à appliquer les exigences d'approbation humaine sur les règles métier, l'architecture et les décisions critiques en matière de sécurité
La révision du code se produit lorsqu'une modification écrite par un développeur est révisée par quelqu'un d'autre avant d'être fusionnée. Bonne critique ; Il détecte les bogues rapidement, partage les informations et maintient la cohérence de la base de code. Mais les critiques sont fatigantes, sujettes à distraction et deviennent superficielles sous la pression du temps. L'intelligence artificielle est ici un double assistant : elle vous permet à la fois de pré-nettoyer votre propre code que vous soumettez pour examen et d'examiner le PR (pull request) de quelqu'un d'autre avec un œil plus attentif.
La distinction essentielle est la suivante : l’IA accélère et améliore l’examen, mais elle ne peut pas assumer la responsabilité de l’approbation. La phrase « L’IA a regardé, c’est propre » n’est pas une approbation. La décision finale de « fusion » appartient à un ingénieur qui connaît le code et le contexte.
Examen de ce qui est bon et mauvais de l'IA
Bon pour : échecs de vérification nulle, fuites de ressources (fichier/lien restant ouvert), exceptions non détectées, conditions manifestement erronées (>= au lieu de >), suggestions de renommage, lisibilité, cas extrêmes manquants, odeurs de sécurité simples (comme la concaténation de chaînes SQL), détection de code en double.
Faiblesses : failles profondes qui violent vos règles métier mais nécessitent un contexte et un timing, telles qu'une logique syntaxiquement correcte, une conformité architecturale, de réels goulots d'étranglement en termes de performances, des erreurs de concurrence. L’IA produit également des faux positifs (confondre quelque chose qui n’est pas réellement un problème avec un problème) et des faux négatifs (manquer le vrai bug). Par conséquent, son résultat est une « liste de précautions » et non un verdict définitif.
Attention : Ce n'est pas parce que l'IA dit "pas de problème" que le code est correct. Les faux négatifs sont silencieux ; Les erreurs les plus dangereuses sont celles qui ne sont jamais mentionnées dans la revue.
Étapes d'examen systématique
- Donnez le contexte. Ajoutez l’objectif du changement, le problème concerné et les critères d’acceptation, le cas échéant, à l’invite. Une révision sans but produit une interprétation sans but.
- Divisez-le en catégories. Demandez au modèle de classer les résultats comme « bug/sécurité/performance/lisibilité/style » ; vous séparez donc les critiques du bruit.
- Demandez une étiquette de gravité. Attribuez à chaque constatation une note « élevée/moyenne/faible » et incluez la « cause » et la « correction recommandée ».
- Filtrez-le de vos propres yeux. Évaluez chaque résultat : est-ce réel (vérifiez), est-ce un faux positif (écrivez la justification), y a-t-il quelque chose qui manque (ajoutez vos propres connaissances).
- Vérifiez manuellement les chemins critiques. Lisez et exécutez vous-même des itinéraires impliquant de l'argent, de l'identité, des autorisations et de la suppression de données sans compter sur l'IA.
Trois mini-étuis
Cas 1 — Erreur nulle silencieuse détectée. Une équipe a demandé à l'IA de pré-examiner un PR de 380 lignes. Le modèle a signalé une manière dont une réponse de service externe pourrait être nulle, mais aucune vérification n'a été effectuée à ce sujet dans le code. L'examinateur humain a vérifié ce chemin et ajouté une vérification nulle ; Une erreur similaire a provoqué une interruption de production de 2 heures au cours du trimestre précédent.
Cas 2 — Élimination des faux positifs. L’IA a signalé en boucle un « problème de performances possible ». Le critique a qualifié cela de faux positif, sachant que la boucle ne fonctionne qu'avec un maximum de 5 éléments (elle boucle sur une énumération). Le mannequin, qui ne connaissait pas le contexte, a prévenu ; Celui qui connaissait le contexte a pris la bonne décision.
Cas 3 – L'IA a manqué une erreur de règle métier. Alors qu'un compte de réduction devait être d'un maximum de 30 % selon la règle de la campagne, le code en autorisait 50 %. L'IA n'a jamais remarqué cette erreur logique syntaxiquement parfaite ; parce qu'il ne connaissait pas la règle. Le bug a été détecté lors de l'examen par le propriétaire du produit qui connaissait les critères d'acceptation. Leçon : la validation des règles métier est un travail humain.
Quatre modèles copiables
Examen ciblé et catégorisé :
Rôle : Réviseur de code méticuleux. Objectif du changement : {{Purpose / issue}}Examinez cette différence. Fournissez les résultats dans ces catégories : [Bogue] [Sécurité][Performance] [Lisibilité] [Style]. Pour chaque résultat : fichier : ligne, gravité (élevée/moyenne/faible), cause, correctif recommandé. Marquez "possible" si vous n'êtes pas sûr. Vous ne connaissez pas les règles du commerce ; Interrogez-moi sur les endroits qui nécessitent des règles.{{diff}}
Pour vous préparer à réviser votre propre code :
Vérifiez ce changement avant d'ouvrir un PR. Recherchez : null/bugcheck manquant, fuite de ressources, cas limite, secret, branche non testée. Classer les résultats par ordre de priorité ; suggérer une correction 1 ligne pour chacun.{{code}}
Chasse aux cas extrêmes :
Répertoriez les entrées et les situations dans lesquelles cette fonction pourrait échouer : vide, nul, trop volumineux, négatif, appel simultané, erreur réseau, données partielles. Pour chaque cas, écrivez le comportement attendu et ce que fera le code actuel.{{function}}
Analyse des odeurs de sécurité (pré-sélection) :
Recherchez les odeurs de sécurité courantes dans ce code : concaténation SQL/commande, entrée non validée, secret intégré immuable, désérialisation non sécurisée, manque de vérification des privilèges. Séparez les résultats en « certains / probables / connaissances ». Il s'agit d'une sélection préliminaire ; Ce n'est pas une décision définitive.{{code}}
Invite faible/Invite forte
Faible : « Y a-t-il une erreur dans ce PR ? »
Fort : "Objectif : ajouter le coupon de réduction au total du panier (la remise ne doit pas dépasser 30 % – vous ne pouvez pas vérifier cette règle vous-même, dites-moi simplement si le code impose une limite supérieure). Examinez les différences ; donnez les résultats par catégorie + gravité + correction suggérée, marquez « possible » en cas de doute. [diff]"
La version forte énonce clairement l'intention, la règle métier et les limites de l'IA ; Ainsi, des découvertes utiles arrivent et la zone inconnue du modèle reste claire.
Type de recherche
Fiabilité de l'IA
le rôle de l'homme
Vérification nulle/erreur manquante
haut
Vérifier et postuler
Lisibilité/style
haut
Choisissez par préférence
Une simple odeur de sécurité
moyen
Finaliser, scanner avec le véhicule
Conformité aux règles métier
faible
C'est entièrement humain.
Concurrence/architecture
faible
Un avis d'expert est requis
L’examen par l’IA ne remplace pas l’examen humain
Positionnez l’examen de l’IA comme un « premier filtre » : une passe préliminaire bon marché, rapide et infatigable. Ce filtre libère l'attention de l'examinateur humain des détails sans importance (un espace, un nom) et la dirige vers des endroits qui nécessitent réellement une réflexion : la règle métier, l'architecture, le résultat de sécurité. Mais l’approbation de la fusion est la signature d’une personne responsable au sein de l’équipe. Un examen indépendant par au moins un ingénieur compétent est obligatoire pour les modifications critiques pour la sécurité.
Astuce : lisez la liste des résultats produits par l'IA comme des « choses à vérifier » plutôt que comme des « à faire ». Vérifiez et appliquez chaque élément ou écrivez en une phrase pourquoi vous l'avez réussi ; cette trace rend l'examen auditable.
Erreurs courantes
- Cela signifie "L'IA a regardé, c'est propre". Il s’agit d’un faux sentiment de confiance dû à des faux négatifs.
- Ne pas donner de contexte. Sans objectif ni critères d'acceptation, le modèle ne produit que des interprétations de style superficielles.
- Appliquer aveuglément des faux positifs. La correction de chaque avertissement du modèle pourrait interrompre l'exécution du code.
- Interroger le modèle sur la règle métier. Le modèle ne connaît pas la règle ; C'est à l'homme de le vérifier.
- Ne faites aucune discrimination contre la violence. Mettre une découverte de sécurité critique et une suggestion de nom dans le même sac éclipse ce qui est important.
En résumé
L'IA est un premier filtre infatigable dans la révision de code : elle détecte les erreurs nulles/erreurs, les cas extrêmes et la simple sécurité sent bon ; mais il est faible en ce qui concerne les défauts contextuels tels que les règles métier, l'architecture et la concurrence, et produit à la fois des faux positifs et des faux négatifs. Demandez les résultats par catégorie et gravité, filtrez chacun avec l'intelligence humaine, vérifiez manuellement les chemins critiques. L'approbation est toujours la signature d'un ingénieur responsable.
Tâche de candidature
Sélectionnez un PR/diff réel ou récent. Tout d’abord, demandez à l’IA de l’examiner avec le modèle « examen de catégorie axé sur les objectifs ». Mettez les résultats dans un tableau et décidez pour chacun : vrai (j'ai vérifié), faux positif (voici mon raisonnement), ou à mettre en œuvre. Ensuite, faites un tour vous-même et essayez de trouver au moins une chose (en particulier une règle métier ou un cas limite) qui manque à l'IA et notez-la.
liste de contrôle
- [ ] J'utilise l'examen de l'IA comme premier filtre, pas comme approbation.
- [ ] J'ajoute l'objectif et les critères d'acceptation à l'invite de révision.
- [ ] Je sépare les résultats du bruit par catégorie et je les souhaite vivement.
- [ ] Je filtre consciemment chaque résultat pour confirmer/faux positif/appliquer.
- [ ] En tant qu'humain, je vérifie les règles métier et la conformité architecturale.
- [ ] J'ai besoin de l'approbation d'un ingénieur qualifié pour les modifications critiques pour la sécurité.