Comment relire une PR d’agent IA et supprimer les changements inutiles

Un agent de programmation peut corriger des erreurs ou livrer une fonctionnalité rapidement, tout en reformatant des fichiers sans rapport, en ajoutant des abstractions, en modifiant la configuration ou en réécrivant plus de code que nécessaire. Avant la fusion, l’objectif n’est pas le nombre minimal de lignes. Il faut un ensemble où chaque modification importante correspond à une exigence acceptée, peut être expliquée par la personne responsable et vérifiée par des tests ou d’autres preuves.

Un développeur a décrit sur X une pratique personnelle : après l’ouverture d’une PR par un agent, il lance un second agent avec un contexte neuf et lui demande ce qui peut être retiré. Il a précisé que cette méthode exige du travail et des tokens supplémentaires et qu’elle n’est pas une solution garantie. Un autre utilisateur a indiqué que Codex avait corrigé de nombreuses erreurs tout en modifiant tellement le code qu’il ne le comprenait plus. Ces témoignages définissent un problème ; ils ne prouvent pas qu’un deuxième agent améliore toujours une PR.

Dans le processus ci-dessous, le second agent est un relecteur sceptique, pas une autorité. Le périmètre, les preuves, les risques et la décision de fusion restent humains.

Le processus complet en sept étapes

1. Rédiger un contrat d’acceptation : comportement attendu, éléments à préserver, périmètre autorisé, risques et commandes de validation.
2. Établir l’inventaire réel avec Conversation, Commits, Checks, Files changed et les commandes Git locales.
3. Donner à un agent en contexte neuf une première passe de revue uniquement, sans modification.
4. Classer chaque constat : conserver, simplifier, supprimer, séparer ou escalader, avec une preuve.
5. Appliquer uniquement les réductions validées par une personne, par petits lots réversibles.
6. Exécuter le même ensemble de tests pertinents avant et après la réduction.
7. Relire le diff final depuis le début et fusionner seulement si l’ensemble peut être expliqué.

1. Commencez par le contrat d’acceptation

« Nettoie cette PR » est trop vague et peut déclencher une nouvelle réécriture subjective. Le contrat doit préciser :

• Le problème et le résultat observable : ce que verra l’utilisateur ou l’appelant.
• Le comportement à préserver : interfaces, erreurs, compatibilité et sémantique des données.
• Le périmètre autorisé : modules, API, schémas, configuration et tests attendus.
• Les non-objectifs explicites : pas de mise à jour du framework, formatage global, renommage étranger, abstraction spéculative ou migration non requise.
• Les contraintes de risque : sécurité, permissions, migrations, performances, observabilité, retour arrière et compatibilité.
• La validation : vraies commandes du dépôt pour formatage, lint, types, tests, build, migrations ou E2E.

Si le résultat correct ne peut pas être décrit, il est impossible de décider de manière fiable ce qui est inutile. Clarifiez le contrat avant de supprimer.

2. Établissez le diff complet, pas le résumé de l’agent

GitHub répartit les preuves d’une PR entre plusieurs vues. Conversation contient la description et les échanges, Commits l’évolution de la branche, Checks les validations automatisées, Files changed le diff réel. Le flux officiel permet de commenter des lignes, proposer des modifications, marquer chaque fichier Viewed et terminer par Comment, Approve ou Request changes.

Pour exécuter ou modifier la PR localement, GitHub documente :

gh pr checkout <PR_NUMBER>
git fetch origin

Remplacez origin/main par la branche de base réelle, puis examinez les changements depuis l’ancêtre commun jusqu’à HEAD :

git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git log --oneline origin/main..HEAD

Git définit git diff A...B comme les changements entre le merge base de A et B et B. Après le résumé, lisez le diff complet et les chemins suspects :

git diff origin/main...HEAD
git diff origin/main...HEAD -- path/to/suspicious-file

Ne supprimez encore rien. Classez les fichiers :

Groupe	Question
Implémentation centrale	Répond-elle directement à un point du contrat ?
Support nécessaire	Tests, documentation, migration ou configuration sont-ils réellement nécessaires ?
Extension suspecte	Y a-t-il formatage global, renommages larges, abstraction étrangère ou upgrade ?
Sortie générée	Doit-elle être versionnée avec sa source ou a-t-elle été ajoutée par erreur ?
Risque incertain	Touche-t-elle sécurité, données, compatibilité ou domaine inconnu ?

La complexité ne prouve pas la redondance. Les contrôles défensifs, migrations et chemins de compatibilité peuvent être longs mais indispensables.

3. Utilisez un contexte neuf pour une première passe sans édition

Le contexte neuf n’est pas utile parce que le second agent serait naturellement plus juste. Il permet de lui donner un objectif différent : contester le périmètre et les preuves au lieu de terminer l’implémentation. C’est une technique raisonnée et un retour d’expérience, pas une exigence GitHub ni une garantie mesurée.

Fournissez le contrat, le diff complet, les appelants pertinents, les tests et les règles du dépôt. Exemple :

Vous êtes la personne chargée de la seconde revue de cette pull request. Votre objectif n’est pas de réécrire le code, mais de trouver le plus petit ensemble explicable qui respecte le contrat d’acceptation.

Première passe : revue uniquement. Ne modifiez aucun fichier.
Lisez l’objectif, le diff complet, les appelants, les tests et les contraintes du dépôt.

Pour chaque constat, fournissez :
1. fichier et hunk ou symbole exact ;
2. exigence servie ;
3. preuve : appelant, test, contrat d’interface, documentation ou absence de preuve ;
4. risque de suppression ou simplification ;
5. action : CONSERVER / SIMPLIFIER / SUPPRIMER / SÉPARER / DÉCISION HUMAINE ;
6. validation exacte à exécuter.

Règles :
- ne proposez pas une suppression uniquement parce que le code est long ou d’un autre style ;
- des tests verts ne sont pas la seule preuve d’exigences correctes ;
- examinez en priorité formatage étranger, abstractions dupliquées, helpers inutilisés, refactors hors périmètre et changements de dépendance/configuration inexpliqués ;
- préservez sécurité, compatibilité, migrations, gestion des erreurs et observabilité sans preuve contraire ;
- indiquez l’incertitude, n’inventez pas de règles métier ;
- terminez par un plan du risque faible au risque élevé. N’écrivez pas encore de code.

Un rapport avant édition évite une nouvelle grande réécriture sous prétexte de réduction. Chaque recommandation doit pointer vers un fichier, un hunk et une preuve.

4. Une personne classe chaque constat selon les preuves

Décision	Quand l’utiliser	Preuve à confirmer
Conserver	Le code implémente le contrat ou une obligation de sécurité, compatibilité, migration ou exploitation	Exigence, chemin d’appel, test, interface ou contrainte documentée
Simplifier	Le comportement est nécessaire, mais branches, wrappers ou couches sont dupliqués	Équivalence du comportement et couverture des limites importantes
Supprimer	Changement étranger, inutilisé, sans contrat ou simple formatage/renommage accidentel	Recherche, build et tests pertinents ne révèlent aucune dépendance
Séparer	Travail utile mais extérieur au contrat actuel	Peut être décrit, testé, revu et annulé indépendamment
Escalader	Domaine inconnu, limite de sécurité, migration ou règle implicite	Code owner, spécialiste ou test de caractérisation requis

À examiner sans supprimer automatiquement : plusieurs couches génériques pour un seul appel ; ancien et nouveau chemins sans période de compatibilité ; formatage, imports, noms ou déplacements sans rapport ; dépendance, lockfile ou configuration inexpliqués ; tests de la forme interne plutôt que du comportement ; exceptions toutes capturées silencieusement ; helpers sans appelant ; code « pour plus tard ».

L’absence de test ne prouve pas l’absence d’usage. Elle peut signaler un manque de couverture. Ajoutez un test de caractérisation ou consultez le responsable avant de supprimer un comportement incertain.

5. Réduisez par petits lots et gardez un point de récupération

Avant l’édition, contrôlez le working tree et créez une référence locale :

git status --short
git branch backup/ai-pr-before-trim

Pour restaurer un fichier entier à la base :

BASE=$(git merge-base origin/main HEAD)
git restore --source="$BASE" -- path/to/unrelated-file

Pour certains hunks :

git restore -p --source="$BASE" -- path/to/file

La documentation Git indique que si un chemin suivi n’existe pas dans la source, la restauration le supprime pour correspondre à cette source. Vérifiez $BASE et le chemin, puis inspectez immédiatement le diff. Une édition manuelle convient aussi ; évitez simplement un nouveau refactor hors périmètre.

Traitez un groupe approuvé à la fois :

git diff
git add -p
git diff --cached
git commit -m "Remove unrelated changes from AI-generated PR"

De petits commits montrent ce qui a été retiré, pourquoi et avec quelle validation. Ne masquez pas le processus par une réécriture destructive de l’historique pendant la revue.

6. Exécutez des validations comparables avant et après

Les tests doivent montrer que le comportement accepté a survécu, pas que le diff est plus court. Enregistrez si possible la référence du PR original, puis répétez les mêmes contrôles après chaque lot :

<format-check-command>
<lint-command>
<typecheck-command>
<targeted-unit-test-command>
<relevant-integration-test-command>
<build-or-e2e-command>

Prenez les commandes dans la documentation ou le CI, pas dans une supposition de l’agent. Couvrez chemin normal, limites, échecs, permissions, valeurs vides, concurrence, timeout, retry, interfaces publiques, formats sérialisés, migrations, build, types, lint, sécurité et Checks requis du dernier commit.

Si une réduction casse un test, annulez ce lot ou restaurez-le depuis la sauvegarde, puis cherchez la cause. Ne changez pas test et implémentation ensemble uniquement pour obtenir du vert, sauf si le contrat indique explicitement que l’ancienne attente est fausse et qu’une personne approuve la nouvelle.

Les tests verts sont une preuve nécessaire, mais la suite peut être incomplète. La compréhension humaine reste obligatoire.

7. Relisez le diff final et prenez une décision explicite

Après la réduction, rouvrez Files changed et relisez tous les fichiers. GitHub retire la marque Viewed lorsqu’un fichier déjà vu change, ce qui signale les fichiers à revoir. Contrôlez de nouveau Commits et Checks pour vérifier qu’ils concernent la dernière révision.

Une dernière revue en contexte neuf peut porter uniquement sur le contrat et le diff final, avec une condition d’arrêt : seulement des problèmes étayés, pas une boucle infinie de style. Ensuite, une personne soumet :

• Approve : contrat satisfait, changements explicables, risques traités, validations requises réussies.
• Request changes : périmètre étranger, logique opaque ou checks en échec persistent. Le blocage dépend des règles du dépôt et de la protection de branche.
• Comment : retour utile sans approbation ni demande formelle de modification.

Checklist avant fusion

• Chaque fichier modifié correspond au besoin, à un test nécessaire ou à un support explicite.
• La personne responsable explique chaque hunk important sans répéter le résumé de l’agent.
• Dépendances, configuration, permissions, migrations et fichiers générés inexpliqués ont été supprimés, séparés ou escaladés.
• PR original et PR réduit ont reçu des validations comparables.
• Tests locaux, build et checks du dernier commit répondent au projet.
• Incertitudes de sécurité, données et compatibilité ont été vues par la bonne personne.
• Si le diff reste large, le travail indépendant a été séparé.
• Décision de revue et suites ont été enregistrées.

Échecs fréquents et récupération

Le second agent réécrit encore le module

Arrêtez l’exécution. Revenez à un rapport sans édition, limitez les fichiers et exigez hunk, exigence et validation pour chaque proposition. Refusez les refactors esthétiques sans preuve.

Les agents ne sont pas d’accord

Ne votez pas. Comparez appelants, contrats, chemins d’échec, tests et contraintes historiques. Si les preuves restent faibles, conservez temporairement, ajoutez une couverture ou consultez le responsable du domaine.

Les tests passent mais le code reste opaque

La couverture n’est pas un design compréhensible. Séparez la PR, documentez ou demandez une explication du chemin critique. Ne fusionnez pas un code opaque uniquement parce que le CI est vert.

Il n’existe pas de tests fiables

Ajoutez un test minimal de caractérisation ou une vérification manuelle répétable avec résultat enregistré. Pour un code risqué, l’absence de preuve impose une pause, pas une supposition.

La PR est trop grande

Séparez comportement central, refactor, upgrades, formatage et migrations en changements indépendants. Les petites unités sont plus faciles à vérifier et annuler.

Prompt d’exécution pour les constats approuvés

Implémentez uniquement ces IDs approuvés : [LISTE].
Ne modifiez aucun fichier hors liste et ne faites aucun refactor opportuniste.
Pour chaque groupe logique :
1. montrez le diff réel ;
2. exécutez les commandes assignées ;
3. rapportez commande, code de sortie et résumé des échecs ;
4. listez les incertitudes restantes.
Arrêtez-vous et demandez une décision humaine si un point change le contrat, une interface publique, la sécurité ou une migration.

L’idée centrale n’est pas « davantage d’agents ». Il faut séparer génération et revue : un contexte propose l’implémentation, un autre conteste le périmètre et les preuves, et une personne possède la décision. Le bon résultat n’est pas le diff le plus court, mais la plus petite modification explicable et vérifiée qui résout la tâche.

Sources et limites

• Retour d’expérience : publication et réponses d’Arnav Gupta sur X sur une revue de réduction en contexte neuf ; il s’agit d’un témoignage.
• Rapport utilisateur : un développeur a dit ne plus comprendre le code après une modification large de Codex ; l’original ne contient ni dépôt, ni diff, ni résultats de tests.
• Documentation GitHub : reviewing proposed changes, checking out PRs locally, référence des pull requests.
• Documentation Git : git diff et git restore.