- À 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) »
10 commentaires
Si les PR sont mortes, j’ai l’impression que c’est moins à cause des PR elles-mêmes qu’à cause de la communication laxiste des vibe coders.
Avec quel flow cela a été implémenté, quelles autres approches existaient et pourquoi elles n’ont pas été retenues, pourquoi
package.lockdoit être modifié : est-ce que ce ne sont pas justement des choses qu’il faudrait d’abord expliquer ?Il vaudrait presque mieux que disparaissent les codeurs qui obligent les autres à poser laborieusement des questions sur ce qui pourrait simplement être écrit dans la description de la PR.
Je suis d’accord. Autrefois, une PR donnait le sentiment que j’assumais la responsabilité de ce que j’avais produit,
mais la PR d’un Vibe coder, c’est plutôt : « Je ne sais même pas vraiment ce que j’ai fabriqué, mais de toute façon il y a bien un résultat, donc à toi de l’évaluer et d’en trouver les problèmes. »
Je suis d’accord.
On évolue vers une forme où l’on parle d’abord, puis où plus personne n’assume la responsabilité ensuite.
Je suis d’accord. C’en est agaçant.
Je suis d'accord.
Sur une seule PR, 500 fichiers sont modifiés, et la personne qui l’a soumise se plaint qu’on ne l’a pas reviewée en moins de 30 minutes. En plus, elle se contente d’écrire cinq ou six lignes dans la description, donc il faudrait juste lui faire confiance et approuver comme ça...?
Tu as bien tout testé ?
Oui
Très bien, faisons ça sérieusement
Pourquoi ils disent toujours que c’est mort ?
À ce rythme, on va tous y passer !
Il y a tellement d’articles au titre du genre « untel est mort » pour un oui ou pour un non
que ça finit par devenir assez fatigant, je trouve.
Moi aussi, j’aimerais bien qu’on arrête un peu de tout tuer.
« Mort ; vive »
Il y a quand même de plus en plus d’articles de ce genre. Mais je reconnais que l’IA est en train de tout changer.