Revue de code par IA : l’auteur peut-il aussi être le relecteur ?

• La question de savoir s’il est pertinent qu’une IA relise du code écrit par une autre IA est particulièrement intéressante
• Des bots comme Devin AI rédigent déjà le plus grand nombre de PR, et les cas où la relecture est également assurée par une IA se multiplient
• Certains soutiennent que les LLM sont sans état (stateless) et que, comme leur structure interne diffère entre l’écriture et la relecture, une séparation des rôles reste possible
• Le code généré par IA provoque des types de bugs différents de ceux des humains, et les IA sont plus efficaces pour détecter ces bugs
• En pratique, la relecture par IA est donc plus avantageuse que la relecture humaine pour repérer les erreurs concrètes, même si le jugement architectural humain et les guides de style restent essentiels

---

Une IA peut-elle relire son propre code ?

• La plupart des entreprises appliquent le principe auteur ≠ relecteur
• Mais les IA basées sur des LLM sont sans état et réévaluent chaque requête à neuf
• Autrement dit, même avec le même moteur, écriture et relecture peuvent être vues comme deux “voitures” différentes

Scaffolding : la structure de la relecture par IA

• Une IA dédiée à la relecture suit un workflow spécifique comme :
  • analyse du diff de code
  • détection de bugs
  • rédaction de commentaires et évaluation de leur gravité
  • consultation de la documentation de la codebase et des fichiers associés
• À l’inverse, une IA de génération de code opère dans un contexte totalement différent : relecture et génération sont donc fonctionnellement distinctes

Les humains aussi sont en réalité le « même moteur »

• Même si l’auteur de la PR et le relecteur sont différents, ils procèdent de la même intelligence humaine
• Ils partagent des connaissances et une expérience proches, acquises dans la même entreprise et avec la même formation
• Au fond, IA comme humains se ressemblent sur ce point : « même moteur, cas d’usage différents »

Le code IA exige une relecture plus précise

• La qualité du code IA est légèrement inférieure

  • Les IA vont vite, mais les limites du prompt rendent souvent la transmission des exigences imprécise
  • Même les bons développeurs ne relisent pas le code IA avec autant de soin que leur propre code
  • Au final, la qualité globale tend à s’aligner vers le bas et à converger vers un niveau moyen

• Les bugs de l’IA sont difficiles à repérer pour les humains

  • Les bugs produits par l’IA sont d’un type que les humains ne créent généralement pas
  • Exemples : modifications inattendues de lignes, erreurs très subtiles dans les conditions, etc.
  • D’après les tests internes de Greptile :
    • l’IA (Sonnet) a détecté 32 bugs sur 209 bugs de niveau « Hard »
    • les développeurs humains n’en trouvent en moyenne que 5 à 7

Conclusion

• Qu’une IA relise son propre code est techniquement possible et pertinent
• Les IA sont meilleures que les humains pour la détection de bugs, et donc réellement utiles en revue de code
• Mais l’interprétation de l’intention, les choix de conception et le jugement sur le style du code restent importants côté humain
• Le critère traditionnel auteur ≠ relecteur doit donc être réinterprété pour les IA

[aer0700]

Je me dis que ça pourrait être intéressant de faire la review en changeant de modèle LLM. Par exemple, faire relire du code écrit avec le modèle A par les modèles B, C et D.

[bungker]

Ah, chez nous, on fait comme ça : quand on ouvre une PR avec du code écrit avec Cursor (Claude), on le fait relire par ChatGPT. En gros, on leur dit de se battre entre eux. À partir de o4-mini, ça suscite déjà l’admiration des gens. On peut aussi le faire directement depuis Cursor en changeant de modèle pour envoyer la demande.

[GN⁺]

Avis sur Hacker News

• Je voudrais insister sur ce point : les ingénieurs n’examinent pas le code généré par l’IA avec autant d’attention que le code qu’ils ont eux-mêmes écrit. La raison, c’est que les LLM produisent du code bien plus vite qu’on ne tape au clavier. Quand on écrit soi-même, on relit naturellement en même temps, mais quand l’IA génère, cette étape est sautée. Fait intéressant, pour un ingénieur moyen, l’IA peut au contraire améliorer la qualité du code. Plus on utilise l’IA, plus les bons et les mauvais ingénieurs vont finir par produire un code d’un niveau similaire. Les façons de penser diffèrent entre la revue de code, la conception et l’écriture, et c’est toujours intéressant

  • Chacun interagit différemment, donc il existe pour chacun une méthode qui lui convient mieux. Pour moi, relire du code est plus facile que l’écrire. Quand j’écris, je dois penser à beaucoup de contexte en plus de la base de code, alors qu’en revue je peux concentrer ce contexte sur la seule base de code et faire du pattern matching plus vite. Malheureusement, comme les LLM sont au niveau d’un ingénieur junior, la revue de PR demande plus d’efforts et d’énergie

  • Un bon ingénieur n’est pas forcément un bon codeur

• Si l’on utilise des bots et des prompts différents pour la revue de code IA et pour l’écriture du code, on peut détecter bien plus d’erreurs. Même répéter plusieurs fois avec le même outil permet parfois de trouver de nouveaux problèmes. Ni les humains ni l’IA ne produisent un code parfait du premier coup. Les outils d’IA ont beaucoup progressé, au point de tester leur propre code et de faire une pré-revue, mais je suis convaincu que faire relire le code d’une PR à la fois par un humain et par une IA ne peut jamais faire de mal. Même avec un outil que j’ai moi-même créé, appelé Kamara, j’ai souvent trouvé des problèmes dans le code qu’il avait écrit. Il y avait aussi des problèmes comme dans l’exemple de greptile, avec des suggestions pointant vers des emplacements complètement erronés, mais on les maîtrise de mieux en mieux. Aucun outil n’est encore parfait à 100 %, et j’ai l’impression qu’il faudra encore un peu de temps avant que l’IA ne prenne tout en main

• Quand nous avons lancé OpenHands (anciennement OpenDevin), les PR produites par l’IA étaient publiées sous un nom de compte IA. Cela a créé deux problèmes graves : 1) la personne qui avait invoqué l’IA pouvait merger directement sans revue de code, ce qui risquait de déployer du code non vérifié ; 2) il n’y avait pas de responsable clair pour la PR, donc si elle n’était pas mergée ou si un problème survenait, on ne savait pas clairement à qui demander des comptes. Nous avons donc changé de stratégie pour que toutes les PR aient un humain comme owner, et que seul le commit garde un nom lié à l’IA. La PR elle-même relève entièrement de la responsabilité humaine

  • Si du code problématique a été mergé, il est clair qu’au final la responsabilité revient à la personne qui l’a approuvé et mergé

• J’ai trouvé intéressant le passage disant que les LLM détectent bien les bugs. Je me demande combien de faux positifs ont été générés pour obtenir un taux réel de détection élevé. D’après mon expérience, les LLM répondent souvent qu’il y a un bug alors qu’il n’y en a pas

  • Je ressens exactement la même chose. Quand je demande quelque chose à ChatGPT et que sa suggestion ne me plaît pas, si je lui dis « tu n’es pas sûr de cette partie, si ? », il change aussitôt sa réponse. Peut-être que sa première réponse était correcte, mais dès que l’utilisateur manque d’assurance, il vacille facilement. Du coup, il n’est pas simple de bien valider l’outil

  • Dans ce cas précis, il n’y avait qu’un seul bug par fichier et on demandait au bot d’en trouver exactement un. Tous les cas étaient des faux positifs : il a inventé des bugs là où il n’y avait absolument aucun problème

  • La différence entre les divers outils d’IA de revue de code sur le marché se joue justement dans le réglage du ratio signal/bruit. Certains outils sont nettement plus précis et génèrent moins de faux positifs

• La responsabilité la plus importante d’un programmeur est de produire un code fiable et dont il est sûr. Le fait d’avoir utilisé un LLM en soi n’a pas d’importance. L’essentiel, au moment d’ouvrir une PR, c’est de pouvoir dire : « je suis convaincu que ce changement résout le problème et je peux y engager ma réputation ». Par conséquent, qu’il soit humain ou IA, une PR a toujours besoin d’un deuxième relecteur

  • À mon avis, la réputation est au cœur du sujet. Ce n’est pas vrai seulement pour le code, mais aussi pour les textes en langage naturel. Nous entrons dans une époque où la responsabilité incombe non pas à l’auteur, mais à la personne qui publie, autrement dit à l’éditeur. Qu’il y ait 5 % ou 95 % de chatbot dans le texte, si un problème survient, c’est moi qu’il faut blâmer si je l’ai publié. L’excuse du « c’est le chatbot qui l’a fait » ne tient pas

  • Il ne s’agissait que d’un exemple parlant d’un ingénieur entièrement automatisé comme Devin ; c’est donc un cas un peu différent de celui d’un ingénieur classique

  • En ce moment, beaucoup d’ingénieurs balancent sans scrupule du mauvais code généré par l’IA en espérant que d’autres collègues en repèrent les problèmes. Avant, comme générer du code était difficile en soi, cela arrivait moins souvent

  • Je suis tout à fait d’accord avec l’idée que notre responsabilité est de produire un code digne de confiance. Mais même avant l’IA, le bon code n’était déjà pas toujours respecté. Nous avons fini par voir le développement seulement comme un moyen ou une source de revenus. À l’origine, il y avait le plaisir de résoudre des problèmes et de changer le monde. Aujourd’hui, on se concentre davantage sur le fait de gagner vite de l’argent ou de construire des barrières. L’important n’est pas que le code soit beau, mais qu’il résolve le problème avec élégance. L’IA peut détériorer cette culture, mais au final tout dépend de la manière dont on l’utilise

  • J’ai une question. Si une PR résout tous les problèmes mais contient juste des bugs mineurs, j’aimerais voir un exemple permettant de juger si cette PR est une perte de temps ou non

• La revue de code est l’étape la plus lente en ingénierie. Moi aussi, je peux écrire du code rapidement sans IA, mais la revue de code ne s’accélère pas. Du coup, je fais relire par l’IA avant la revue pour faire gagner du temps à mes collègues, détecter les bugs en amont et réduire parfois de plusieurs jours le délai jusqu’au déploiement. L’IA m’a aidé à trouver aussi bien des bugs évidents que des erreurs plus cachées, et elle a même déjà déniché de vrais bugs profonds. J’utilise un workflow où je copie le diff avec git CLI et xclip, puis je le colle dans un modèle de raisonnement comme o3 pour obtenir une revue

  • Dans ce cas, j’espère vraiment que vous avez un contrat entreprise avec OpenAI

• L’un des avantages de l’IA, c’est qu’elle peut écrire beaucoup de tests unitaires bien plus vite qu’un humain. Et elle peut aussi corriger elle-même les problèmes qu’elle découvre. Le workflow idéal ne se limite pas à la revue de code : l’IA devrait aussi lancer automatiquement ses propres tests et vérifier que tout respecte une spécification donnée. Trop de tests peuvent ensuite compliquer le refactoring (par exemple si les tests dépendent des détails d’implémentation), et quand ils deviennent gênants, on peut aussi jeter séparément les tests écrits par l’IA

  • J’adore le fait de pouvoir régénérer des tests unitaires quand j’en ai besoin. Au moment de soumettre une revue, j’éprouve une grande satisfaction à voir la taille du diff, et j’économise le temps ennuyeux passé à écrire les tests pour pouvoir faire davantage

  • Il reste encore aujourd’hui dans la programmation des tâches pénibles, et idéalement l’IA devrait réduire ces inefficacités pour permettre aux humains de se concentrer sur les aspects créatifs. Mais en pratique, l’IA commence aussi à empiéter sur des travaux créatifs de plus en plus haut niveau

  • En réalité, même sans IA, on peut utiliser un framework de property-based testing pour générer automatiquement des tests avec un très grand nombre de valeurs d’entrée

• J’ai une règle en revue de code : si je ne me sens pas capable d’en assurer moi-même la maintenance plus tard, je n’approuve pas. Si l’on utilise des LLM à la fois pour écrire et pour relire le code, on peut considérer qu’on applique le même principe de responsabilité à l’outil aussi. Mais honnêtement, je ne me vois pas rester longtemps dans une telle situation

• Je me demande si quelqu’un a déjà essayé un pipeline où un LLM génère des scripts Gherkin à partir des exigences, puis un autre LLM produit le code à partir de ces scripts, avant de vérifier le résultat avec Cucumber. Quoi qu’il en soit, les scripts Gherkin comme le code devront être relus, mais j’aimerais savoir quels types de code ne peuvent pas être produits de cette manière. Je considère l’IA comme un développeur à part entière, et j’imagine que, comme les développeurs humains, elle a forcément des domaines où elle est moins bonne

• En fin de compte, l’auteur d’une PR doit assumer la responsabilité de l’impact et des conséquences de son code. Avec la généralisation du codage assisté par l’IA et l’arrivée de plus en plus d’ingénieurs juniors, cette responsabilité est devenue encore plus importante. Il est raisonnable de confier à l’IA une première passe de revue, mais il faut aussi qu’un relecteur humain apporte un regard externe, développe sa compréhension de la base de code et repère des problèmes de niveau plus élevé. En conclusion, l’idéal serait une structure où l’IA fait une première revue, un autre ingénieur effectue une revue de code sur le plan du contexte et de la collaboration, puis l’auteur assume en dernier ressort la responsabilité de tous les résultats