Comment supprimer la revue de code
(latent.space)- À mesure que la quantité et l’ampleur du code généré par l’IA augmentent de façon exponentielle, les méthodes traditionnelles de revue de code manuelle ne sont plus viables
- Les équipes avec un fort taux d’adoption de l’IA enregistrent une hausse de 21 % du volume de travail accompli et de 98 % des fusions de PR, mais aussi, paradoxalement, une augmentation de 91 % du temps de revue des PR
- Au lieu d’examiner directement le code, le rôle humain doit se déplacer vers une validation en amont consistant à revoir les spécifications et les critères d’acceptation (Acceptance Criteria)
- Plutôt qu’un portail de validation unique, il faut une structure de confiance multicouche fondée sur le modèle du fromage suisse, avec concurrence entre agents, garde-fous déterministes, BDD, systèmes d’autorisations et validation adverse
- Une nouvelle approche, consistant à déployer vite, tout observer et revenir en arrière encore plus vite, remplace le schéma de revues lentes suivies de débogage en production
Les humains ne parviennent déjà plus à absorber la revue de code
- En pratique, les PR restent en attente pendant des jours, des approbations purement formelles sont données, et les reviewers survolent des diff de 500 lignes
- La revue de code est perçue comme un garde-barrière qualité, mais certaines équipes publient du logiciel depuis des décennies sans revue ligne par ligne, et la généralisation de la revue de code ne date que de 2012 à 2014 environ
- Même avec des revues, les incidents continuent d’arriver, ce qui a conduit à construire des systèmes comme les feature flags, déploiements progressifs et rollbacks immédiats
Il faut renoncer à lire tout le code
- Dans les équipes fortement engagées dans l’IA, le nombre de changements et leur taille augmentent simultanément de façon exponentielle
- D’après l’analyse de Faros, sur des données couvrant plus de 10 000 développeurs et 1 255 équipes
- Les développeurs ont le sentiment que la revue de code généré par l’IA demande plus d’efforts que celle du code écrit par des collègues
- Il est impossible de gagner cette bataille avec de la revue manuelle, et la revue de code est désormais un portail d’approbation hérité du passé qui ne correspond plus à la forme actuelle du travail
La revue de code par l’IA reste malgré tout une « revue »
- Si l’IA écrit le code et que l’IA le relit, il n’y a aucune raison d’afficher une jolie interface de revue
- Les outils de revue de code par l’IA ne font que faire gagner du temps, et ce type de revue va se déplacer vers la gauche du cycle de développement (shift left)
- Il n’y a aucune raison de gaspiller des ressources CI et de gérer des versions entre des cycles de revue
- Dans un environnement où des agents écrivent le code, un « regard neuf » n’est qu’un autre agent partageant les mêmes angles morts ; la vraie valeur se trouve dans la boucle d’itération, pas dans le portail d’approbation
- L’instinct qui consiste à se dire « j’ai déjà vu une IA faire n’importe quoi, donc il faut toujours vérifier » était rationnel quand la validation manuelle était possible, mais à l’échelle actuelle cela devient tout simplement inexécutable
Passer de la revue de code à la revue de l’intention
- Il faut déplacer les checkpoints humains en amont (upstream)
- Il existe déjà un précédent dans l’évolution des checkpoints du développement logiciel : des validations waterfall vers l’intégration continue (CI)
- Le développement piloté par les spécifications (spec-driven development) émerge comme mode principal de collaboration avec l’IA
- Les humains doivent revoir les specs, les plans, les contraintes et les critères d’acceptation, sans avoir besoin de relire des diff de 500 lignes
- Dans ce nouveau paradigme, la spécification devient la source de vérité (source of truth) et le code n’est qu’un produit de cette spécification
- Il ne s’agit plus de revoir le code, mais les étapes (steps), les règles de vérification (verification rules) et le contrat que le code doit respecter
- L’approbation human-in-the-loop passe de « est-ce que cela a été correctement écrit ? » à « est-ce qu’on résout le bon problème avec les bonnes contraintes ? »
- Le jugement humain le plus précieux ne s’exerce pas après la génération du code, mais avant que la première ligne ne soit produite
Construire une confiance multicouche — le modèle du fromage suisse
- Les LLM suivent mal les instructions, s’en écartent fréquemment et sont incapables de s’auto-vérifier de manière fiable (ils répondent avec assurance « ça fonctionne » alors même que le code est en train de brûler)
- La solution n’est pas de demander au LLM de vérifier, mais de lui faire écrire les scripts de vérification — on passe ainsi du jugement à la production d’artefacts
- La confiance se construit par couches, et selon le modèle du fromage suisse, on empile des filtres imparfaits pour éviter que leurs trous ne s’alignent
Couche 1 : comparer plusieurs options
- Au lieu de demander la bonne réponse à un seul agent, on fait en sorte que trois agents essaient chacun une approche différente, puis on choisit le meilleur résultat
- La sélection n’a pas besoin d’être manuelle : on peut classer les options selon des critères comme le plus grand nombre d’étapes de validation franchies, le plus petit diff ou l’absence de nouvelle dépendance
- Le coût de génération d’options est aujourd’hui au plus bas de toute l’histoire du génie logiciel
Couche 2 : des garde-fous déterministes
- Il faut des méthodes déterministes pour valider le travail — tests, vérification de types, validation de contrats — bref, des éléments qui relèvent du fait et non de l’opinion
- Au lieu de demander au LLM « est-ce que c’est bon ? », il faut définir des étapes de validation qui produisent une série d’artefacts pass/fail
- Hiérarchie des garde-fous :
- Règles de codage — pouvant être implémentées via des linters personnalisés
- Règles invariantes à l’échelle de l’organisation — interdiction des identifiants codés en dur, des clés API, des tokens, etc.
- Contrats métier — règles propres à un framework, un service ou une zone du codebase (ex. : dans le domaine des paiements, tous les montants doivent utiliser le type Money)
- Critères d’acceptation (Acceptance Criteria) — critères spécifiques à chaque tâche
- Les étapes de validation doivent être définies avant l’écriture du code, et non construites après coup pour confirmer ce qui existe déjà
- Si l’agent écrit à la fois le code et les tests, on n’a fait que déplacer le problème ; les critères de validation doivent venir de la spécification, pas de l’implémentation
Couche 3 : les humains définissent les critères d’acceptation
- L’endroit où les humains apportent de la valeur, c’est en amont, dans la définition de la réussite
- La BDD (Behavior-Driven Development) retrouve une nouvelle pertinence
- Elle consiste à décrire le comportement attendu en langage naturel, puis à l’automatiser sous forme de tests
- Par le passé, comme il fallait aussi écrire le code, rédiger des specs donnait l’impression d’un travail supplémentaire ; dans un environnement à base d’agents, la spec devient l’artefact principal
- Quand les humains écrivent la spec, les agents implémentent, et le framework BDD valide — tant que ça ne casse pas, il n’est pas nécessaire de lire l’implémentation
- Ce que les humains savent bien faire : définir la « justesse », encoder la logique métier et les edge cases, réfléchir à ce qui peut mal tourner
- Les critères d’acceptation écrits par les humains et validés par la machine deviennent le véritable portail de contrôle important
Couche 4 : faire des systèmes d’autorisations un choix d’architecture
- Ce qu’un agent peut toucher et ce qui nécessite une escalade doit devenir une décision d’architecture
- La plupart des frameworks d’agents gèrent les autorisations de façon tout ou rien (all-or-nothing), alors que la granularité est essentielle
- Un agent qui corrige un bug dans une fonction utilitaire n’a pas besoin d’accéder à la configuration d’infrastructure
- Un agent qui écrit des tests n’a pas besoin d’avoir le droit de modifier le pipeline CI
- Le périmètre doit être aussi étroit que possible, tant qu’il permet à l’agent de faire un travail utile
- Exemple : pour la tâche « corriger un bug de parsing de date dans
utils/dates.py», on ne devrait autoriser l’accès qu’à ce fichier et à ses fichiers de test
- Exemple : pour la tâche « corriger un bug de parsing de date dans
- Les déclencheurs d’escalade sont tout aussi importants : modification de logique d’authentification, changement de schéma de base de données, ajout d’une nouvelle dépendance, etc. Certains motifs doivent déclencher automatiquement une revue humaine, quel que soit le niveau de confiance de l’agent
Couche 5 : validation adverse
- Séparer les responsabilités : un agent exécute la tâche, un autre agent la vérifie — l’essentiel est qu’ils ne se fassent pas mutuellement confiance
- C’est un schéma ancien, comme le fait qu’une équipe QA ne doit pas reporter à un engineering manager, ou qu’un auteur de code ne doit pas être le seul à le relire
- On peut l’imposer architecturalement : l’agent de codage ne sait pas ce que l’agent de validation va vérifier, et l’agent de validation ne peut pas modifier le code — une séparation adverse par conception
- On peut aller plus loin encore avec un troisième agent chargé de tenter de casser ce qu’a produit le premier, en visant les edge cases et les modes d’échec — autrement dit, automatiser une logique red team / blue team sur chaque changement
La signification de « bon code » est en train de changer
- Les incitations d’un système d’agents sont simples : accomplir la tâche demandée et satisfaire la personne qui l’a formulée — la précision à long terme ou les besoins métier ne constituent pas une motivation intrinsèque
- Le rôle humain consiste donc à encoder cela dans les contraintes
- Dans un monde où les agents génèrent le code et où d’autres agents le lisent, la forme du « bon code » va se standardiser davantage, ce qui réduit l’orientation qu’il faut fournir dans un nouveau codebase
- La direction à suivre : « déployer vite, tout observer, et revenir en arrière encore plus vite »
- L’inverse : « relire lentement, rater quand même des bugs, puis déboguer en production »
- On ne gagnera pas en lisant davantage de productions de machines ; il faut dépasser la machine dans la réflexion en amont, là où les décisions comptent vraiment
- Si les agents savent bien traiter le code, le fait que les humains puissent encore le lire ou non cesse d’être important
25 commentaires
C’est assez drôle et original de dire que, puisque les code reviews sont un goulot d’étranglement, il suffit de ne plus en faire mdr
Je me demande si, avant l’IA, les revues de code fonctionnaient vraiment bien partout.
Les organisations qui faisaient des revues de code rapidement et sérieusement étaient en fait très rares.
Même avant l’IA, beaucoup de développeurs faisaient des revues de code de façon négligente, avec du retard et assez bâclée.
D’après mon expérience, les entreprises tech américaines appliquaient les bonnes pratiques, tandis qu’à l’étranger, Corée comprise, c’était le chaos.
Autrement dit, plus les reviews étaient rigoureuses, plus le stress au travail était élevé, et à l’inverse, les reviews bâclées étaient relativement plus tranquilles.
Je pense que la disparition des revues est le résultat des incitations comportementales.
Si ce que l’entreprise exige,
c’est un faible taux d’erreur, elle imposera les revues plus strictement,
et si c’est une mise en ligne rapide des fonctionnalités, les revues seront progressivement omises.
Le fait qu’on dise que les revues disparaissent me donne l’impression que les entreprises privilégient des sorties de fonctionnalités rapides.
Mais bon, si j’étais investisseur, je pense que je demanderais probablement la même chose, haha
Je ne suis pas sûr. Se dire que, parce que la revue est devenue un goulot d’étranglement, il ne faut plus faire de revue, donne l’impression d’oublier l’essentiel. J’ai plutôt l’impression qu’une meilleure approche serait d’allouer obligatoirement du temps de revue à hauteur du temps gagné sur l’implémentation.
On continue d’empiler les boîtes noires ?
Le code est simplement conçu comme une boîte noire, et on ne regarde que le résultat… enfin, l’idée est un peu celle-là… mais est-ce vraiment une direction souhaitable ? Je pense qu’un jour viendra, c’est certain, où il faudra entièrement refaire le code écrit par les IA existantes.
C’est un peu comme dire : « Le FSD est devenu plus intelligent, donc le conducteur peut dormir. »
Techniquement, on a l’impression qu’on se dirige progressivement vers une époque comme celle-là, mais la vraie question sera de savoir comment franchir l’obstacle de la responsabilité.
J’ai l’impression que la revue de code est au moins un minimum de garde-fou.
Pourquoi la validation de l’intention, qui est un concept d’un niveau plus élevé, est-elle faite par un humain..?
En fait, il n’est même pas nécessaire de faire coder en langage de programmation.
Quand on envoie le même prompt à une IA, j’ai l’impression que revoir le résultat revient un peu à tester les performances du modèle, non ?
C’est une idée qui mérite d’être envisagée, mais il semble que l’avis dominant soit qu’il est encore trop tôt.
On dirait qu’il a d’abord décidé de la conclusion, puis demandé à un LLM de l’écrire. Sophisme.
On dirait qu’il n’a absolument aucune expérience de la production
C’est franchement un discours de rêve.
Avec le temps, j’ai plutôt l’impression que la documentation perd aussi de son sens et qu’on finit par faire des reviews de plus en plus strictes ?
Ouiii~ le simple fait d’écrire un texte qui suscite ce genre de débat suffisait déjà à faire passer l’intention.
C’est un article traduit : https://rosetta.page/post/…
C’est un problème qu’on pourrait écarter dès le départ, à l’étape de planification.
Quand les développeurs écrivent du code à la main, ils passent naturellement par la conception fonctionnelle, l’architecture, l’exploration, la compréhension, les tests et l’auto-revue, tout en anticipant implicitement et en parallèle la façon de réagir après coup si un problème survient ; au fil du processus, ces différents aspects s’ajustent donc assez naturellement. C’est sans doute pour cela que, même avec des tests ou des revues insuffisants, tout finissait malgré tout par fonctionner dans une certaine mesure.
En revanche, si l’on supprime le fait d’écrire le code à la main, il faut délimiter explicitement ces processus qui existaient auparavant de manière implicite. Comme l’entité qui rédige le code et celle qui l’examine sont davantage séparées, l’inefficacité de la communication augmente. Et comme la confiance envers l’auteur du code diminue encore, le coût de la revue augmente lui aussi.
J’ai l’impression que c’est assez proche du concept de doorman's fallacy.
C’est aussi un sujet sur lequel je réfléchissais souvent en entreprise, c’est intéressant. J’aimerais aussi essayer de l’introduire dans Harnes, que je développe personnellement.
Je pense qu’on va progressivement évoluer vers des revues de plus en plus légères et des tests beaucoup plus stricts.
Il ne s’agit pas simplement de supprimer la code review, mais plutôt de proposer de faire la review à partir de livrables d’un niveau plus élevé, qui permettent de vérifier explicitement l’intention et si cette intention fonctionne correctement.
À l’heure actuelle, je pense qu’il est souhaitable de conserver comme boîte noire les détails d’implémentation du code, tant qu’on n’est pas au niveau de la conception ou de l’architecture.
Je pense que cette boîte noire peut s’accumuler au point où même l’IA ne pourra plus vraiment y faire quoi que ce soit. J’ai l’impression que tout le monde est trop grisé par la commodité. Je pense qu’un jour, un gros accident finira par se produire.
Je suis également d’accord avec l’avis exprimé plus haut. Et si, un jour, on découvrait soudainement que le modèle a mal appris certaines parties du code humain, puis qu’on réalisait que cela s’est reflété dans le code jusqu’à présent ? Ce jour-là pourrait aussi être celui où tout est remis en cause..
Peu importe à quel point les derniers modèles sont performants, s’ils n’obtiennent pas toujours un score parfait au benchmark SWE (six neuf, 0.999999), je pense que cette possibilité reste ouverte.
Revue d’intention. C’est une belle expression.
Je me demandais comment réagir à cette époque où tout s’accélère grâce à l’IA,
et c’est un excellent article qui offre une nouvelle perspective sur la revue de code !