À l’ère de l’IA, comment faut-il faire la revue de code ?

• Un essai qui part de 15 ans d’expérience en tant que CTO et organise le débat sur la revue de code à l’ère de l’IA selon une synthèse thèse-antithèse-synthèse
• La revue de code a toujours été un problème — manque de temps, de personnes et de processus
• L’IA a fait exploser le volume de code produit, mais la capacité de revue est restée la même → le goulet d’étranglement s’est encore aggravé

Thèse — la revue humaine est indispensable

• Simon Willison : « Ne refilez pas à vos collaborateurs du code que vous n’avez pas vérifié »
• Kent Beck : à mesure que le coût de génération se rapproche de 0, la valeur se déplace de la génération vers la vérification
• Addy Osmani : « Le problème non résolu n’est pas la génération, mais la vérification »
• Même si l’IA devient excellente, la responsabilité reste humaine → il faut vérifier → il faut relire

Antithèse — la fin de l’ère de la revue humaine

• Bryan Finster : application du théorème de Nyquist-Shannon — si seule la fréquence de production augmente alors que la fréquence de feedback reste identique, on passe systématiquement à côté de choses
• Données SmartBear : au-delà de 400 lignes, le taux de détection des défauts chute fortement ; l’IA génère 600 lignes d’un coup
• StrongDM, « software factory » : les humains n’écrivent ni ne lisent le code. Ils ne font que définir l’intention et organiser les scénarios
• Stanford CodeX : « Si des agents produisent et testent, en quoi peut-on encore avoir confiance ? »
• Salesforce Prizm : le modèle de revue centré sur les diff lui-même ne fonctionne plus à l’ère de l’IA → reconstruction de l’intention

Synthèse — que faut-il réellement revoir ?

• latent.space : passer de la revue de code à la revue d’intention (Intent Review)
• La spec est la source de vérité, le code n’est qu’un artefact produit
• Construire la confiance en 5 couches (modèle du gruyère suisse)
• Pattern Qodo : contexte d’abord, gravité comme critère prioritaire, revue par agents experts
• Bryan Finster : les seuls blocages humains restants sont les lacunes de connaissance et le parcours réglementaire

En conclusion

• L’auteur ne relit plus directement le code produit par l’IA → il se repositionne en QA
• L’ingénieur AI-native doit assumer lui-même le rôle qu’avait le PM à l’époque précédente
• « Pouvez-vous assumer la responsabilité de votre code ? »

[kgcrom]

https://app.devin.ai/review

Je ne sais pas encore si ce sera une autre méthode éphémère, comme les erreurs du point intermédiaire,
mais je partage un outil qui permet de comprendre le code et de corriger des bugs tout en faisant des PR reviews avec l’IA.

Je l’utilise sur mes side projects quand je ne comprends pas les modifications de code effectuées par l’IA.

[pencil6962]

Erreur du juste milieu (argument to moderation) : lorsqu’il existe deux affirmations extrêmes (A et Z), c’est le raisonnement qui consiste à affirmer que la position intermédiaire (M) est nécessairement vraie ou constitue la meilleure solution.

[overthinker]

D’un point de vue opposé, la relecture humaine finit par devenir un goulot d’étranglement

[vk8520]

À moitié, je trouve encore que la somme reste irréaliste pour l’instant. Le code continue d’être utilisé, et comme les LLM sont probabilistes, il faut (pour l’instant) que les humains lisent tout le code qu’ils ont écrit eux-mêmes. Pour faciliter la revue, il est en revanche nécessaire de faire rédiger automatiquement les PR sous forme de template, ou de les consigner dans des ADR, afin de comprendre le contexte, l’intention, etc.