Revue du code IA : vérifier l'intention plutôt que lire les diffs

Les ingénieurs d'Aviator ont restructuré leur processus de revue de code pour gérer une augmentation quadruple des pull requests générées par l'IA. En passant d'une lecture systématique de chaque ligne de code à une vérification de l'intention, des critères d'acceptation et des invariants système, l'équipe a réduit le temps médian de fusion de 2,1 jours à 3,4 heures. Cette approche maintient la supervision humaine tout en automatisant les contrôles de routine, permettant à neuf ingénieurs de gérer plus de 400 PR fusionnées par semaine.

Ce qui s'est passé

Alors que le flux de travail de développement d'Aviator est passé d'un code écrit par des humains avec assistance IA à un code généré par l'IA sous guidance humaine, le volume de modifications a explosé. Le nombre hebdomadaire de pull requests fusionnées est passé d'environ 100 à plus de 400, avec une taille médiane de PR atteignant 640 lignes. Cela dépassait le seuil de 400 lignes où la détection de bugs diminue généralement. Les méthodes traditionnelles de revue n'ont pas réussi à suivre la cadence : ajouter un relecteur IA noyait les décisions de conception critiques sous des remarques triviales, tandis qu'imposer un SLA de revue de quatre heures conduisait à des approbations vides, les ingénieurs survolant les changements pour respecter les délais.

L'équipe a réalisé que détecter les bugs n'a jamais été l'objectif principal de la revue de code. Citant une étude Microsoft de 2013, ils ont noté que seuls 14 % des commentaires de revue concernent des défauts. La valeur fondamentale de la revue réside dans le partage de connaissances et le maintien d'un modèle mental actuel du système. Avec des agents IA écrivant la majeure partie du code, cette fonction de transfert de connaissances était menacée. Au lieu d'essayer de mieux lire le diff, qui montre ce qui a changé mais pas pourquoi, l'équipe a cessé de revoir le diff entièrement.

Comment cela fonctionne

Le nouveau flux de travail divise les tâches de la revue de code en étapes distinctes gérées par différents mécanismes. Premièrement, les agents de revue se confrontent mutuellement avant même qu'une PR existe, débattant des détails d'implémentation et enregistrant les désaccords. Seuls les problèmes non résolus, tels que les conventions de nommage, sont escaladés aux humains. Deuxièmement, le système capture l'intention et les critères d'acceptation directement depuis la session de codage. Chaque fois qu'un ingénieur corrige un agent ou répond à ses questions, ces interactions deviennent des critères vérifiables. L'intention explique pourquoi un changement est effectué, tandis que les critères d'acceptation définissent comment il doit se comporter.

Troisièmement, l'équipe a codifié les commentaires de revue répétés en invariants système. En analysant un an d'historique de revues, ils ont distillé 11 400 commentaires en 64 invariants approuvés, tels que l'exigence d'entrées dans le journal d'audit pour les modifications de configuration. Ces invariants sont compilés en règles déterministes utilisant des outils comme ast-grep, qui s'exécutent en secondes parallèlement aux vérifications probabilistes des modèles. Enfin, chaque critère d'acceptation est prouvé par des éléments concrets. Les agents lancent des environnements de prévisualisation pour simuler des scénarios utilisateurs, enregistrant captures d'écran et logs pour vérifier le comportement. Cela fournit une preuve concrète qu'une fonctionnalité fonctionne comme prévu, plutôt que de simplement passer un contrôle CI.

Détails clés

• Augmentation du débit : Les mêmes neuf ingénieurs fusionnent désormais 4x plus de pull requests par semaine, passant de ~100 à >400.
• Amélioration de la vitesse : Le temps médian de fusion a chuté de 2,1 jours à 3,4 heures.
• Métrique de qualité : Les annulations (reverts) pour 100 PR ont diminué de 40 %, indiquant une meilleure qualité initiale du code.
• Efficacité de la revue : Les fils de commentaires humains par PR sont passés de 6,2 à 1,3, se concentrant uniquement sur les décisions de haut niveau.
• Création d'invariants : 11 400 commentaires historiques ont été analysés pour créer 64 invariants approuvés et 212 règles candidates.
• Vitesse de vérification : Dix-neuf invariants clés s'exécutent de manière déterministe en 0,3 seconde, offrant un retour rapide sans latence de modèle.

Pourquoi c'est important

Pour les équipes d'ingénierie adoptant des agents de codage IA, cette étude de cas démontre que les goulets d'étranglement traditionnels de la revue peuvent être résolus en changeant ce que les humains évaluent. À mesure que la taille des PR dépasse les limites cognitives humaines pour une inspection détaillée, se fier aux diffs devient inefficace. En automatisant la vérification des règles et des comportements, les ingénieurs peuvent se concentrer sur les décisions architecturales et la compréhension du système. Ce changement protège l'aspect partage de connaissances de la revue, crucial pour la maintenabilité à long terme, tout en laissant les machines gérer la validation répétitive des contraintes.

Cette approche souligne également l'importance de capturer l'intention tôt dans le cycle de développement. Lorsque les critères d'acceptation sont dérivés d'interactions en temps réel entre ingénieurs et agents IA, ils reflètent les exigences réelles plus précisément que la rédaction de tests a posteriori. Cela garantit que le processus de vérification teste ce qui compte pour la logique métier, et non seulement ce qui est facile à automatiser. Les équipes construisant des flux de travail natifs IA devraient envisager de séparer l'application des règles de la prise de décision pour maintenir la vélocité sans sacrifier la qualité.

Ce que vous pouvez faire

• Auditer vos commentaires de revue : Catégorisez les anciens commentaires de PR en règles, décisions et corrections ponctuelles pour identifier les candidats à l'automatisation.
• Définir des invariants système : Extrayez les contraintes récurrentes de votre base de code et encodez-les comme des vérifications déterministes en utilisant des outils comme ast-grep.
• Capturer l'intention pendant le codage : Sauvegardez le dialogue entre ingénieurs et agents IA pour générer automatiquement des critères d'acceptation.
• Implémenter une vérification basée sur les preuves : Utilisez des agents automatisés pour exécuter des scénarios utilisateurs dans des environnements de prévisualisation et enregistrer les logs comme preuve.
• Déplacer le focus de la revue humaine : Formez les relecteurs à ignorer les diffs ligne par ligne et à évaluer plutôt l'intention, les preuves et les décisions de conception non résolues.
• Débat d'agents pré-PR : Configurez les agents IA pour qu'ils débattent des détails d'implémentation avant la création d'une PR, résolvant automatiquement les problèmes triviaux.