Vérifie les modifications de code de l’IA avant de les accepter
Contrôle le périmètre, les différences, les changements indexés et les preuves de test dans Mono Code, avec une fiche de revue et des commandes Git de lecture.
Vérifie le code présent dans le dépôt, pas seulement le résumé de l’agent. Une explication convaincante peut accompagner une correction incomplète, un test jamais exécuté ou des changements sans rapport. Distingue le comportement demandé, les modifications réelles et les preuves de vérification avant d’accepter le résultat.
Mono Code te permet d’ouvrir les fichiers du projet, de travailler avec des agents de code et de voir les changements Git directement dans l’éditeur. Ce guide porte sur la revue d’une petite modification terminée ; le guide du code à distance explique comment te connecter. Le dépôt et les commandes restent toujours sur ton propre ordinateur, l’hôte. Mono n’est pas encore disponible ; tu peux rejoindre la liste d’attente.
1. Reformule le critère d’acceptation
Prends un exemple concret : un formulaire fictif accepte un titre de tâche composé uniquement d’espaces. La correction demandée doit refuser cette saisie tout en préservant les titres ordinaires. Avant de lire le correctif, note les conditions :
- Aucun titre vide ou composé uniquement d’espaces ne peut être envoyé.
- Un titre ordinaire s’envoie toujours correctement.
- Un message de validation utile apparaît.
- Le reste du formulaire respecte le périmètre convenu.
Garde cette liste près du diff. Elle te donne une base d’évaluation indépendante de l’explication de l’agent. Si la demande initiale était ambiguë, clarifie le comportement avant d’accepter une réalisation plus large.
2. Établis l’état du dépôt
Confirme l’hôte, le dossier du projet et la branche. Compare les fichiers modifiés à l’état initial relevé avant le travail de l’agent. Les changements préexistants de l’utilisateur ne deviennent pas ceux de l’agent parce qu’ils se trouvent dans le même fichier.
Dans un terminal du bon hôte, ces commandes en lecture peuvent aider :
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileRemplace le chemin d’exemple. git diff montre les modifications non indexées ; --cached compare celles de l’index au commit. Les fichiers non suivis doivent être examinés séparément. La documentation de Git diff explique ces comparaisons. Un arbre de travail propre ne révèle pas si l’agent a déjà créé un commit : consulte l’historique pertinent si c’est le cas.
3. Lis le correctif et le code environnant
Dans l’éditeur de Mono, la marge signale les lignes ajoutées et modifiées, et toucher un repère ouvre le diff de ce passage. C’est pratique pour regarder un changement, mais ça ne prouve pas que tu les as tous relus. Un repère absent ou périmé ne veut pas dire que le fichier n’a pas changé.
Pour le titre, repère la condition de validation et suis la suite du traitement. Vérifie-t-elle la valeur normalisée ? L’erreur est-elle visible ? L’envoi s’arrête-t-il ? Examine le code environnant au lieu de valider une condition isolée sans son appelant.
Contrôle les nouveaux fichiers, le code supprimé, les dépendances et le reformatage hors sujet. Une courte explication ne justifie pas un grand diff inexpliqué. Passe sur l’hôte ou un écran plus grand si les lignes sont tronquées ou la modification trop large pour être lue correctement.
4. Relie les tests au comportement
Demande la commande réellement exécutée, son résultat et les contrôles omis. « Les tests devraient passer » est une prévision, pas un résultat observé. Même une suite réussie doit couvrir le défaut signalé.
| Cas | Observation attendue |
|---|---|
| Titre vide | Envoi arrêté avec le retour prévu |
| Espaces uniquement | Même refus, sans création d’élément |
| Titre ordinaire | Envoi toujours fonctionnel |
| Comportement existant hors modification | Contrôles pertinents toujours réussis |
Un contrôle manuel peut convenir au retour visuel ; un test de régression automatisé peut protéger la règle de validation. Choisis des preuves qui démontrent le changement, plutôt que des tests répétant son implémentation. Si l’environnement empêche les tests, note explicitement la limite et décide où réaliser la vérification manquante.
5. Corrige les problèmes sans perdre les autres travaux
Donne un retour précis : « Le titre composé d’espaces est refusé, mais le message d’erreur n’apparaît jamais » ou « Explique le changement du fichier de dépendances pour cette validation ». Désigne le comportement et le fichier, au lieu de dire seulement « recommence ».
Évite les réinitialisations ou restaurations globales pour retirer une petite modification lorsque d’autres travaux sont présents. Demande une correction ciblée et inspecte le nouveau diff. Relance les contrôles concernés : un ancien succès ne vérifie pas les changements ultérieurs.
Autoriser une commande et accepter le code sont deux décisions distinctes. Approuver une commande de test n’autorise pas un commit, une fusion ou un déploiement. Le guide des permissions aide à examiner l’opération elle-même.
6. Laisse une transmission vérifiable
Note la conclusion brièvement :
Comportement demandé : Refuser les titres de tâches vides.
Fichiers examinés : Indiquer les chemins réels.
Preuves : Commandes, résultats et contrôles manuels pertinents.
Questions ouvertes : Ce qui reste à vérifier.
Prochaine décision : Accepter, demander une correction ou différer.Garde les commits et les mises en production explicites. Pour conserver la discussion, exporte-la en Markdown, mais conserve aussi les vrais fichiers du projet. La transcription témoigne de l’échange ; le dépôt et les contrôles vérifiés établissent ce qui a changé.
