L'IA a fini d'écrire le code à votre place, mais personne ne veut plus y jeter un coup d'œil attentif.

Auteur : The Pragmatic Engineer

Traduction : TechFlow

Note de lecture TechFlow : L'IA écrit du code de plus en plus vite, mais ce sont toujours les humains qui examinent le code. Cette contradiction est en train de se transformer en une crise : les ingénieurs sont submergés par les PR générées par l'IA, soit ils sont trop épuisés pour examiner attentivement, soit ils valident simplement parce que l'IA n'a signalé aucune erreur. Les grandes entreprises construisent leurs propres outils pour y faire face, mais personne n'a encore de réponse standard.

Salut, je suis Gergely, et ceci est un numéro gratuit supplémentaire du Pragmatic Engineer Newsletter. Chaque numéro, je rapporte sur les grandes entreprises technologiques et les startups du point de vue d'ingénieurs seniors et de leaders techniques. Aujourd'hui, nous discutons de l'un des quatre sujets précédents du journal The Pulse. Les abonnés complets ont reçu cet article il y a une semaine. Si cet e-mail vous a été transféré, vous pouvez vous abonner ici.

J'entends dire que l'une des principales préoccupations de nombreux leaders techniques est de savoir comment faire face à la charge croissante de révision de code. Ce sujet existe depuis un certain temps, et ce type de conversation semble maintenant de plus en plus fréquent.

Pour moi, cela a commencé en janvier de cette année, lorsque Opus 4.5 et GPT 5.4 ont commencé à écrire plus de code et de meilleur code dans la plupart des entreprises. À peu près à partir de ce moment-là, les personnes au niveau des directeurs ont commencé à discuter du fait que le goulot d'étranglement du développement logiciel passait de la phase de codage à la phase de révision.

L'essor des outils de révision de code par IA

Depuis février, les outils de révision de code par IA ont connu une croissance explosive pour faire face à l'augmentation de la charge, avec une adoption et des expérimentations explosives d'outils spécialisés de révision de code par IA tels que CodeRabbit, Greptile, Qodo, SonarQube (et maintenant Gitar). Il y a aussi les outils fournis par les outils de codage eux-mêmes, comme Claude Code review, Cursor review, GitHub Copilot review. Ensuite, des outils qui n'étaient pas précédemment impliqués dans la révision de code mais qui avaient un contexte sur la base de code rejoignent également ce domaine, comme les Seer AI reviews de Sentry, Linear code reviews.

Les grandes entreprises construisent leurs propres outils internes : le Code Inbox d'Uber

Les grandes entreprises construisent des outils internes pour améliorer l'expérience de révision de code. Le Code Inbox d'Uber en est un exemple :

L'affectation intelligente est une fonctionnalité dans Code Inbox pour faire avancer le processus de révision :

Figure : Paramètres d'affectation intelligente (Smart assignment) de Code Inbox, utilisés pour faire avancer le processus de révision. Source : The Pragmatic Engineer

Il y a aussi la fonctionnalité de profils de risque, utilisée pour évaluer l'impact des changements et encourager les développeurs à porter une attention particulière aux changements à haut risque :

Figure : Fonctionnalité de profils de risque (Risk Profiles) de Code Inbox, estimant les risques de changement de code et suggérant une attention particulière. Source : The Pragmatic Engineer

Nous avons rapporté comment Uber utilise l'IA pour le développement logiciel, et pas seulement Uber : Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) et de nombreuses autres entreprises ont également construit des outils pour rendre leur processus de révision de code plus fluide, car elles ont constaté que les implémentations internes fonctionnent mieux que les solutions intégrées des fournisseurs.

Passer de la « révision » à la « validation »

Une autre approche consiste à réfléchir à la façon de valider le code, plutôt que de le réviser. C'est plus facile à dire qu'à faire ; en théorie, des tests approfondis devraient pouvoir valider que le code fonctionne comme prévu. Mais combien de tests faut-il pour être « approfondis » ? De quel type de tests parlons-nous ? Les tests d'intégration et de bout en bout sont-ils inclus ? Et le fuzz testing ? Les méthodes formelles ? Comment valider que les nouveaux tests couvrent les fonctionnalités comme prévu ? Comment connectons-nous tout cela à l'observabilité ?

La révision excessive épuise les ingénieurs

Trop de révisions de code approfondies épuisent les ingénieurs et entraînent une baisse de la qualité des révisions. J'entends beaucoup de rumeurs selon lesquelles les développeurs voient que les autres ne sont plus capables d'examiner le code avec attention, et si la révision de code par IA n'a pas d'opinions substantielles, ils valident simplement. Pendant ce temps, les développeurs qui consacrent la même énergie et le même temps à la révision de code qu'avant se sentent submergés par les PR de mauvaise qualité générées par l'IA qui leur sont envoyées.

Le problème existe, les solutions restent expérimentales

Le problème existe, mais les solutions ressemblent plus à des expérimentations.