- À l’ère où l’IA écrit du code, la méthode de revue des pull requests (PR) doit être fondamentalement repensée, et le processus de revue actuel n’est pas adapté aux workflows de coding avec IA
- Quand un reviewer demande « pourquoi cela a été fait ainsi ? », le développeur redemande à l’IA puis colle la réponse, ce qui crée une inefficacité où l’humain reste cantonné à un rôle d’intermédiaire (middleman)
- Il faut inclure dans le contrôle de source le journal de décision (decision log) de l’IA avec le code, afin que le reviewer puisse vérifier directement le contexte
- Un workflow où l’IA reçoit directement les commentaires du reviewer et génère automatiquement un patch et une réponse est déjà possible grâce à la combinaison de webhooks GitHub/GitLab et d’un serveur MCP
- Les documents de conception et les diagrammes d’architecture doivent eux aussi être inclus dans le contrôle de source dans des formats analysables par les LLM comme Markdown ou Mermaid, car « le contexte est roi »
Les problèmes de la revue de code à l’ère de l’IA
- Lors d’une revue de PR, on pose une question et on reçoit en retour une réponse qui semble générée par l’IA, car c’est effectivement l’IA qui a écrit le code
- À la question « pourquoi avoir choisi cette bibliothèque ? », le développeur humain ne peut pas répondre, et doit reposer la question à l’IA puis copier sa réponse
- Avant l’IA, on demandait directement au développeur qui avait écrit le code, pas à son manager ; il faut donc supprimer l’intermédiaire
- Tous les auteurs du code doivent participer à la revue, et faire appel après coup à un agent IA séparé pour rétro-inférer les raisons d’une décision est une approche totalement erronée
Pourquoi un journal de décision est nécessaire
- Quand on demande « pourquoi ? » à un humain, on l’interroge sur un processus de réflexion interne qui n’est pas inclus dans la PR
- Le chain-of-thought de l’IA est auditable de l’extérieur (externally auditable), et l’historique des interactions avec l’IA l’est aussi ; ce contexte doit donc être intégré à la revue et au contrôle de source
- Il n’est pas nécessaire de commit tous les tokens générés pendant la création de la PR ; en s’inspirant du concept d’episodes de Random Labs, il suffit d’inclure les transcriptions des appels d’outils réussis et les conclusions
- Cela peut aussi s’étendre à un environnement d’agent swarm, en chaînant les journaux de décision avant l’étape PR puis en appliquant le formatage final
Les limites des commentaires inline
- Modifier les fichiers source impose de relancer le pipeline de build (linting, compilation, tests), même si l’on ne change qu’un commentaire
- Les transcriptions de décisions sont bien plus volumineuses que ce qu’autorisent généralement les commentaires inline
- Les commentaires existants expliquent le fonctionnement actuel du code, mais pas le cheminement qui a conduit à cette décision
Workflow de revue intégré à l’IA
- Quand un reviewer laisse un commentaire, l’IA du développeur doit pouvoir le recevoir directement et générer automatiquement un patch et une réponse
- C’est déjà réalisable aujourd’hui avec la combinaison de webhooks GitHub/GitLab et d’un serveur MCP
- D’une manière similaire à Devin AI ou à Claude Code via GitLab Duo
- Il est possible de configurer le système pour que le développeur doive d’abord donner son autorisation à l’IA, ou pour que l’IA prenne elle-même la décision d’agir immédiatement
- Le développeur humain peut toujours continuer à écrire lui-même des commentaires et des modifications
- Cela peut réduire fortement les cas où les commentaires de revue ne sont pris en compte que plusieurs heures ou jours plus tard, voire jamais
Exigences d’outillage pour les reviewers
- Les reviewers doivent eux aussi pouvoir examiner la PR en posant directement des questions à une IA, comme ils explorent une codebase
- Le fait que le journal de décision soit check-in avec le code est essentiel à cet objectif
- Il faut conserver l’interface de PR existante tout en y intégrant, à côté, une fenêtre de dialogue avec Codex ou Claude, comme dans un environnement de développement IDE
- Il n’existe pas encore d’outil vraiment propre pour cela, donc ce serait bien que quelqu’un le construise
- Dans un diff, on doit pouvoir poser en privé des questions à l’IA sur une bibliothèque inconnue, un langage peu familier ou des best practices, puis décider si un commentaire de revue est nécessaire
- Si un commentaire est nécessaire, c’est le signe qu’il existe un manque (gap) dans le journal de décision ; il faut alors mettre à jour le journal avant d’approuver la PR
L’importance des documents de conception et du contexte
- Dans une revue intégrée à l’IA, il devient aussi beaucoup plus facile pour le reviewer de proposer directement des patchs
- Il faut ajouter au contrôle de source les documents de conception, les decision records et les diagrammes d’architecture dans des formats analysables par les LLM comme Markdown ou Mermaid
- « Le contexte est roi (Context is king) »
Aucun commentaire pour le moment.