- Pour devenir compétent dans l’utilisation des agents IA, il est essentiel d’avoir de solides compétences en revue de code
- Les grands modèles de langage excellent dans la génération de code, mais manquent souvent de jugement approfondi, ce qui les conduit à perdre du temps dans de mauvaises directions
- Les revues tatillonnes qui ne signalent que des détails de syntaxe, comme les revues coup de tampon qui approuvent sans esprit critique, n’aident pas à bien exploiter l’IA
- Une bonne revue de code intègre une vision structurelle, examine s’il existe une meilleure approche et aide à éviter des conceptions inutilement complexes
- Au final, le codage avec l’IA ressemble au « centaur chess » : un modèle qui combine le jugement humain et la productivité de la machine, et la capacité à faire de bonnes revues de code se traduit directement par une meilleure utilisation de l’IA
Relation entre les agents IA et la revue de code
- Bien utiliser un agent IA revient en pratique à suivre un véritable processus de revue de code
- Les personnes qui sont bonnes en revue de code exploitent aussi plus efficacement les outils de code IA comme Claude Code, Codex et Copilot
Pourquoi les compétences en revue de code sont importantes
- Les grands modèles de langage savent générer beaucoup de code, mais ils restent en retrait sur le jugement d’un ingénieur logiciel expérimenté
- Sans supervision, ils ont donc tendance à gaspiller beaucoup de ressources dans des conceptions inutiles ou médiocres
Limites des agents IA et erreurs de conception
- Par exemple, pendant le développement du projet VicFlora Offline, Codex a consacré beaucoup d’efforts à rétroconcevoir le code frontend
- Alors qu’il existait en réalité une approche d’accès aux données beaucoup plus simple
- Lorsqu’on utilise un agent IA, on constate en moyenne environ une fois par heure qu’il se lance dans une tâche suspecte
- Repérer ce type de problème et corriger soi-même la direction permet de gagner plusieurs heures de travail
- Dans une autre expérience de développement d’application, l’IA a proposé de mettre en place une infrastructure de fond excessive pour une simple tâche de traitement parallèle
- Alors qu’un simple traitement non bloquant côté frontend suffisait, elle cherchait à introduire une architecture complexe
- Il est important de continuer à contrôler l’IA afin de préserver la simplicité
- Quand des non-spécialistes développent en faisant confiance uniquement à l’IA, la complexité et les inefficacités s’accumulent dans la base de code, au point de dégrader fortement leur capacité à résoudre les problèmes
Nature et effet de la revue de code
- Collaborer avec l’IA ressemble à travailler avec un développeur junior enthousiaste mais peu expérimenté
- Comme l’IA ne voit pas son jugement progresser avec le temps, une observation continue reste nécessaire
- La plus grande erreur en revue de code consiste à ne regarder que le code produit, sans se demander s’il existe une meilleure alternative
- La revue de code idéale adopte une perspective structurelle et prend en compte l’ensemble du contexte système
- Avant de créer un nouveau système inutile, il faut d’abord chercher à réutiliser les systèmes existants
- Les reviewers trop focalisés sur le style de code, de façon 'nitpicky', risquent de passer à côté du véritable potentiel des outils IA
- À l’inverse, un reviewer de type 'rubber-stamp' qui laisse passer sans esprit critique aura du mal à collaborer efficacement avec l’IA ou avec un développeur junior
Réflexions sur les compétences d’utilisation des outils IA
- Les outils traditionnels comme git ont une structure et un mode d’utilisation clairs, alors que la structure fondamentale de l’IA reste opaque
- L’IA peut effectuer presque tous les types d’opérations
- Certains estiment que savoir mobiliser les outils IA dans toutes les directions constitue en soi une compétence d’usage de l’IA
- En pratique, les utilisateurs expérimentés sont capables d’en extraire davantage de possibilités
- À ce jour, les agents IA de code peuvent aider sur des tâches variées, mais ils exigent une supervision étroite
- Comme dans le modèle du « centaur chess », la meilleure productivité est atteinte quand l’orientation d’un humain expérimenté se combine avec les propositions de l’IA
- La qualité de l’utilisation de l’IA dépend au fond des compétences en revue de code et du jugement critique sur la conception
- Plus les compétences en revue de code sont élevées, plus l’efficacité des outils d’agentic AI est maximisée
Réflexions finales et perspectives
- Les agents IA peuvent donner l’impression de devenir progressivement plus proches d’ingénieurs expérimentés avec le temps
- Dans les prochaines années, collaborer avec l’IA pourrait évoluer jusqu’à se rapprocher d’une collaboration avec un ingénieur confirmé
- Pour l’instant, il est souhaitable d’expérimenter avec différents outils IA (Codex, Claude Code, Copilot, etc.), mais la capacité de supervision critique reste le principal facteur de différenciation
Avis supplémentaires
- Des discussions ont eu lieu sur Hacker News et ailleurs autour de la question : « jusqu’à quel niveau les agents IA sont-ils réellement utiles ? »
- L’auteur ne pense pas qu’une simple revue de code suffise pour permettre à l’IA de contribuer à un niveau comparable au noyau Linux
- Certains estiment aussi que les méthodes de revue de code centrées sur le style et le choix des noms ont leur importance
- Il existe un regard critique sur le fait d’intégrer les discussions de design dans la revue de code, mais l’auteur n’y voit pas quelque chose de négatif
1 commentaires
Avis Hacker News
L’idée qu’on peut obtenir de bons résultats avec un mauvais processus simplement en faisant bien le contrôle qualité me paraît très douteuse ; c’est un peu le raisonnement « ce n’est pas grave si ça crache du n’importe quoi tant que quelqu’un vérifie », et dans la réalité je n’ai jamais vu ça bien fonctionner. L’industrie automobile américaine a déjà essayé ce genre d’approche, mais aucun exemple de réussite ne me vient à l’esprit. Si j’imagine mon supérieur me dire, à moi chef d’équipe : « au lieu de 5 personnes compétentes, je vais te donner 25 parfaits débutants et attendre qu’un résultat correct sorte par hasard ; à toi de tout relire », ce serait absurde. Et pourtant, dès qu’on remplace ce scénario par de l’IA, beaucoup de gens se disent : « hmm ? peut-être que ça pourrait marcher ? », ce qui est fascinant.
Relire le code de personnes peu expérimentées ou peu motivées est aussi extrêmement fatigant. Ça consomme énormément d’énergie mentale et émotionnelle. Quand on revoit la même fonctionnalité quatre fois, on finit par se lasser et par abandonner à un stade où la qualité ne peut plus vraiment progresser.
C’est exactement l’inverse du modèle de gestion de la qualité développé par Deming (Edward Deming) au Japon puis diffusé en Occident. La qualité ne vient pas des personnes mais du processus. Si on choisit un procédé qui produit beaucoup de défauts et qu’on espère qu’un humain attrapera les erreurs, ce n’est pas du tout une bonne méthode si l’objectif est la qualité. Les LLM peuvent être utilisés de nombreuses façons, mais seules certaines sont réellement avantageuses. Les dirigeants semblent fascinés par l’idée que l’IA peut résoudre tous les problèmes, sans bien comprendre ses forces et ses limites, ou alors en oubliant les leçons de Deming.
L’évolution repose sur des mutations aléatoires et de la sélection ; l’existence même de toute vie complexe en est un exemple. Ce n’est pas mon approche préférée, mais les gens ont tendance à s’enthousiasmer pour les buzzwords du moment et à les essayer de façon indiscriminée là où ils ne conviennent pas. Dans la production de certaines pièces plastiques d’ustensiles de cuisine, on continue à mouler des pièces de mauvaise qualité puis à faire corriger manuellement au couteau par des journaliers avant emballage. J’ai moi-même déjà eu ce type de boulot temporaire. Le chip binning et la gestion du rendement dans les semi-conducteurs peuvent aussi être vus comme des cas à très fort taux d’échec. Il suffit d’observer la réalité autour de soi pour voir que les processus douteux ne sont pas l’exception mais presque la norme.
Dès qu’on commence à se dire qu’on « sait bien manier l’IA », on tombe facilement dans l’illusion que « l’éventail des problèmes que je peux résoudre s’est énormément élargi ». On observe ce phénomène avec toutes les technologies généralistes. À l’époque du boom des algorithmes génétiques, c’était similaire. Tout le monde cherche un outil « généraliste » puis se persuade qu’il permet de tout faire. En pratique, on essaie d’optimiser sans aucun contexte. L’IA est un exemple où ce phénomène est poussé à l’extrême.
Même avec un très bon processus, on n’apprend pas pour autant à construire des systèmes qui fonctionnent réellement. Le schéma qu’on voit sans cesse, c’est une équipe qui tâtonne longtemps avant qu’un ingénieur connaissant réellement la solution prenne la main et remette enfin les choses sur les bons rails.
Il est vraiment difficile de faire respecter à l’IA les paramètres demandés. Elle part toujours aléatoirement dans une direction absurde. Quand je travaillais sur la coloration syntaxique pour
nftables, il y avait 230 tokens, 2 500 états et plus de 50 000 transitions d’état. Même en donnant à l’IA cinq règles parfaitement claires, elle finit toujours par dévier à des points aléatoires. Elle ne rate pas seulement le code : elle n’arrive même pas à produire correctement un Vimscript très simple. Du coup, je ne l’utilise plus que pour la documentation. Cela dit, elle commence à être assez bonne pour expliquer des éléments découpés commerule,chain_block stmt,map_stmt_expr. Il suffit ensuite de copier-coller uniquement les motifs syntaxiques que je veux.La génération de code par IA est assez utile au début d’un projet, mais il y a des points inquiétants sur les projets matures. J’ai récemment fusionné un parseur Postgres de plus de 280k+ LOC dans Multigres, sans revue publique. Dans l’écosystème open source, c’est quelque chose dont il faut se méfier. Beaucoup de gens s’appuient sur ce type de projet pour apprendre ou comme référence ; si du code IA y entre sans vraie revue, on affaiblit à la fois sa valeur pédagogique et la confiance qu’on peut lui accorder comme dépendance. La code review ne sert pas seulement à attraper des bugs : c’est aussi le mécanisme central par lequel les collaborateurs apprennent, comprennent les raisons de conception et accumulent de la connaissance collective. Le problème n’est pas la vitesse mais le processus de transmission du savoir. Pour le délai avant publication de la PR, voir aussi ce lien.
Mon processus ressemble à peu près à ça
Je prends aussi des snapshots en cours de route pour pouvoir revenir en arrière.
Comme ça, sans atteindre un niveau excellent, j’arrive au moins à obtenir un résultat qui sert de référence pour ma propre implémentation.
L’inconvénient, c’est que ça prend énormément de temps, et dans 80 % des cas j’ai l’impression qu’il aurait été plus rapide de tout faire moi-même depuis le début.
Ça semble plus lent que de le faire seul. Quand on code avec l’IA, on a l’impression de regarder le travail d’un développeur intermédiaire qui dirait : « J’ai bricolé ça ce week-end à partir de tes notes, en buvant un verre, t’en penses quoi ? » Il suffit de répondre « NON, ça ne me convient pas », et si la direction générale était à peu près correcte, on a quand même l’impression de gagner un peu de temps en refactorant à partir de là plutôt qu’en recommençant de zéro le lundi matin.
À chaque fois que je vois ces guides étape par étape, j’ai l’impression qu’on ajoute finalement une énorme couche de friction qui annule toute l’efficacité qu’on espérait tirer de l’IA. Dans mon expérience, c’est presque vrai. Bien sûr, il y a des moments où l’IA aide, mais savoir quand et où elle est utile est aussi, à mon avis, une compétence importante.
Je travaille à un niveau un peu plus bas, et en général je fais plutôt comme ça :
En général, quand on donne d’un coup un objectif trop large et trop long, l’agent se trompe souvent sur le moment où le travail est réellement terminé.
J’utilise un processus similaire mais un peu plus simple. Je donne aussi un PRD, j’indique l’architecture générale, puis je demande l’implémentation de chaque composant comme je le souhaite. Ça prend toujours beaucoup de temps, et ce serait encore plus rapide de le faire moi-même, mais maintenant coder à la main ligne par ligne me fatigue un peu, donc j’envisage de laisser le LLM s’occuper au moins du niveau fonction.
Si j’avais seulement utilisé l’IA pour me suggérer une approche générale, des bibliothèques ou des spécificités du langage, puis fait le travail principal moi-même, j’aurais probablement été bien plus rapide.
Si on est bon en code review, il vaut peut-être mieux ne pas utiliser d’agents IA du tout.
En relisant et en corrigeant les bugs du code de collègues tombés amoureux d’agents comme Claude Code, j’ai souvent eu l’impression que leur code avait été écrit en plein délire, et que les auteurs étaient incapables d’expliquer quoi que ce soit à son sujet. Je veux bien croire que certaines personnes arrivent à produire du très bon code ainsi, mais tout ce que j’ai vu moi-même a été décevant. Heureusement, certains s’en sont rendu compte d’eux-mêmes et sont revenus à des méthodes plus solides. Si on regarde de manière critique ce qui sort aujourd’hui des workflows à base d’agents, la réponse me semble évidente. Quelqu’un de bon en code review arrivera à cette conclusion encore plus vite.
Si j’étais bon en code review, j’aurais surtout envie de continuer à progresser dans cette compétence.
La code review fait certes partie du travail, mais c’est la partie la moins plaisante. Les développeurs tirent leur satisfaction du moment où ils écrivent eux-mêmes le code. Les outils d’IA aident, certes, mais comme ils sont imprévisibles tout en restant convaincants en apparence, il faut les relire encore plus soigneusement, ce qui augmente au contraire la charge. Pourquoi avons-nous créé des outils qui nous retirent la partie amusante pour ne laisser que l’aspect pénible ? Où est l’agent spécialisé « code review » ?
En réalité, je ne trouve pas l’« écriture » du code particulièrement amusante en soi. Ce qui m’amuse davantage, c’est résoudre des problèmes, créer quelque chose de nouveau, décomposer un système puis le réassembler dans une meilleure structure. Avec les LLM, j’ai l’impression de transformer bien plus vite une idée en résultat concret manipulable. Le code existant devient aussi plus sûr au niveau du typage, mieux documenté, et les refactorings complexes deviennent plus faciles. Je n’attends pas des LLM qu’ils résolvent les problèmes à ma place, mais qu’ils m’aident à rassembler du contexte, réappliquer des patterns, automatiser le code répétitif, etc. En particulier, quand le code est dispersé sur plusieurs fichiers, le fait que l’IA génère automatiquement les morceaux au lieu que je les écrive un par un est extrêmement pratique, parce qu’il ne me reste plus qu’à vérifier chaque changement.
OpenAI Codex Cloud a ajouté une fonction de code review, et le nouveau modèle GPT-5-Codex a été entraîné spécifiquement pour la review de code [présentation des mises à niveau de Codex]. Gemini et Claude ont eux aussi ajouté des fonctionnalités de code review via l’intégration GitHub Actions ou l’intégration GitHub de Claude. GitHub a également lancé sa propre fonctionnalité Copilot Code Review. Il existe aussi de nombreuses startups spécialisées comme CodeRabbit, Greptile ou Qodo Merge.
Le moment où je ressens vraiment une forme d’euphorie, c’est quand, en implémentant quelque chose, je découvre en dessous une structure d’une grande élégance qui change ma façon de programmer, voire ma façon de vivre (même si ce genre de chose n’arrive que très rarement).
Plus un développeur est junior, plus il aime écrire directement du code ; les seniors, eux, aiment plutôt en supprimer. Personnellement, la code review est la partie la plus amusante de mon travail (quand je ne suis pas pressé par une deadline). Je ne suis donc pas d’accord avec l’idée que la code review ne serait pas amusante.
Au début, il était dit que « la plupart des développeurs aiment créer du neuf », mais en réalité beaucoup préfèrent travailler sur une base de code existante, en comprendre les patterns et la structure, puis l’améliorer. Il faut aussi tenir compte du fait que certaines personnes trouvent le processus de création totalement neuf — conception initiale puis itérations sans fin — plus difficile. Quant à la question « pourquoi enlever le fun pour ne garder que le pénible ? », c’est probablement parce que les gains de productivité les plus visibles se trouvent là. Pour la review par IA, il existe déjà plusieurs options comme CodeRabbit ou GitLab Duo, et rien n’empêche non plus de faire faire une review à partir d’un diff Git avec un outil comme RooCode.
Le titre de cet article me paraît trop simpliste. La code review et la design review sont différentes, et ce qu’on tente avec l’IA ne se limite pas à ces deux aspects. Pour utiliser l’IA, il faut une expertise dans le domaine concerné ; même en se limitant au code, la simple capacité de review ne suffit pas, il faut pouvoir valider le travail confié à l’IA quel que soit le domaine. En réalité, l’IA est souvent plus utile quand j’aborde un langage ou un framework que je maîtrise mal, mais dans ce cas ma capacité de code review est justement moins profonde. C’est d’ailleurs amusant de voir le mot « coding » redevenir à la mode à l’ère de l’IA et des LLM. Aujourd’hui, on dirait que les entreprises préfèrent des ingénieurs capables de tout faire — architecture, analyse des exigences, full stack, opérations — plutôt que de simples codeurs.
Mon intitulé de poste officiel est « Software Engineer », mais au cours des cinq dernières années j’ai surtout :
J’aime énormément l’idée que la code review avec les collègues améliore la connaissance partagée et les standards communs. Mais rien que l’idée de relire le code d’une IA têtue et peu coopérative me donne l’impression que je vais finir en burn-out.
Quand je deviens bon dans la partie la plus ennuyeuse de mon travail, je me demande parfois si je vais devoir faire uniquement ça toute ma vie. Honnêtement, ça ne me plaît pas. Et comme le dit le texte, mieux vaut toujours éviter qu’un bug entre dans le système ; le détecter après coup reste une prise de risque.