Les agents d'IA tuent la revue de code — Le problème principal-agent expliqué

Le processus standard de revue de code de l'industrie — revue puis validation, popularisé par les PRs GitHub — a été conçu pour la collaboration à faible confiance. Un humain fait une modification, un autre humain la révise, des itérations ont lieu, et la modification est intégrée. Cela fonctionnait car les relecteurs pouvaient facilement inférer l'effort et la compréhension en lisant le code. Les agents d'IA brisent complètement cela.

La catastrophe de l'agent intermédiaire

Le meilleur cas avec les agents d'IA : un humain demande à une machine d'écrire du code, l'humain le révise, puis l'envoie à un deuxième humain pour une revue traditionnelle. Cela double la charge de revue. Pire, les agents augmentent le volume total de changements. Résultat : la bande passante de revue est épuisée avant même qu'une fraction des gains de productivité des agents ne se matérialise.

Mais la réalité est pire. Le modèle réel est : un humain tape une courte requête, valide légèrement le résultat, le conditionne en PR, puis renvoie les commentaires du relecteur à l'agent pour corrections. C'est un exemple classique de problème principal-agent : le relecteur (principal) ne peut plus inférer l'effort ou la compréhension à partir du code, car le code a été généré par une machine. L'humain qui pilote l'agent n'a aucune incitation à réellement lire le code ou à réfléchir de manière critique aux retours du relecteur. Il passe 5 minutes et génère une charge de revue importante pour un autre ingénieur.

C'est ce qui tue l'open source — les « PRs bâclées » de personnes qui n'ont aucune compréhension du projet, de ses contraintes ou de ses outils.

Une voie à suivre pour les petites équipes

Pour les petites équipes à haute confiance, il existe un processus plus simple : humain interroge agent → humain révise le code → humain déploie directement (pas de second relecteur). L'humain qui pilote la machine assume l'entière responsabilité en possédant le déploiement. Le problème principal-agent disparaît car l'humain est à la fois le pilote et le déployeur.

Chez exe.dev, une équipe de neuf personnes utilise cette approche avec succès. Pratiques clés : écrire beaucoup plus de tests d'intégration et de bout en bout, créer des workflows basés sur des agents pour analyser les commits en termes de sécurité/performance/ergonomie, et s'assurer qu'un humain est toujours responsable du déploiement final.

Le modèle traditionnel de revue de code n'est pas viable avec les agents. Les petites équipes peuvent s'adapter ; les grandes organisations et les projets open source font face à un problème structurel plus difficile.