Comment supprimer la revue de code

• À 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
• 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