Faros AI : les agents IA font grimper les pull requests de 98%, mais la revue de code s'allonge de 91%

Les équipes qui travaillent avec des agents IA écrivent du code plus vite, mais ce code n'arrive pas plus vite sur main, et il y arrive parfois plus lentement. Habr a analysé ce paradoxe à partir des données de Faros AI, de CircleCI et de DORA. Le chiffre le plus cité du rapport de Faros AI, fondé sur la télémétrie de plus de 10 mille développeurs : ceux qui utilisent activement l'IA ont 21% de tâches closes en plus et 98% de pull requests fusionnées en plus. Dans le même temps, le temps de revue a augmenté de 91%.

La logique est simple. La génération de code coûte presque zéro, alors que la vérification reste un travail humain. Si le pipeline reçoit deux fois plus de matière en entrée et que le même relecteur se trouve en sortie, la file d'attente s'allonge.

Où le code se bloque

Le problème ne vient pas du nombre de PR, mais de leur taille. D'après Faros AI, le pull request moyen des équipes à fort niveau d'adoption de l'IA a augmenté d'environ 154%. L'agent se lance volontiers dans un gros refactoring, ajoute des tests, touche aux modules voisins. Le relecteur doit garder davantage de contexte en tête, et relire attentivement un diff de 800 lignes ne prend pas du tout le même temps qu'un diff de 300.

Le QA constitue le deuxième point de perte. Faros AI a relevé une hausse d'environ 9% du nombre de bugs par développeur. Chaque défaut supplémentaire renvoie la tâche dans la boucle : commentaires, corrections, nouvelle exécution de la CI, nouvelle revue. La métrique des « tâches closes » progresse, tandis que le lead time jusqu'à la production stagne ou s'allonge.

Les données de DORA montrent le même tableau sous un autre angle. Dans le rapport de 2024, une hausse de 25% de l'adoption de l'IA était corrélée à une baisse de 1,5% du débit de livraison et à une chute de 7,2% de la stabilité. DORA a ensuite décrit l'IA comme un amplificateur : elle accélère les bons processus et met à nu les faibles. CircleCI aborde le problème par les pipelines CI. On y voit où s'accumulent les builds en échec et les exécutions longues, c'est-à-dire où la vitesse d'écriture se heurte à la vitesse de vérification.

Les métriques à suivre

Pour trouver le goulot d'étranglement, les statistiques de commits ne suffisent pas. Il faut une vue de bout en bout, du premier commit jusqu'au déploiement :

• Temps avant la première revue : combien de temps un PR attend avant que quelqu'un le regarde.
• Temps de revue total : de l'ouverture jusqu'à l'approbation.
• Taille des PR en lignes et en fichiers, ainsi que la médiane et le 90e percentile.
• Part des PR renvoyés en reprise après la revue ou le QA.
• Change failure rate et temps de rétablissement après un incident.
• Lead time for changes : du commit à la production.

Si les deux premiers indicateurs augmentent en même temps que le nombre de PR, le problème se situe dans la revue. Si la part de PR renvoyés et le change failure rate augmentent, c'est la qualité du code généré et des tests eux-mêmes qui pose problème.

Que faire pour les équipes

Premièrement : limiter la taille des changements. De nombreuses équipes imposent une limite stricte sur les PR et demandent aux agents de découper le travail en petits blocs atomiques. C'est moins coûteux que d'embaucher deux relecteurs de plus.

Deuxièmement : mobiliser aussi l'IA du côté de la vérification. Revue préliminaire automatique, linters, analyse statique et génération de tests déchargent l'humain des tâches routinières et lui laissent les questions d'architecture. Mais la qualité de cette revue doit elle aussi être mesurée, sinon le goulot d'étranglement ne fera que changer d'endroit.

Troisièmement : revoir les métriques de productivité. À l'ère des agents, le nombre de PR et de tâches closes par personne ne dit presque rien. Le lead time et la stabilité des releases sont plus parlants : ce sont les métriques que DORA utilise depuis de nombreuses années.

Quatrièmement : renforcer les vérifications automatiques en amont de la revue. Plus la CI est fiable et la couverture de tests élevée, moins il reste de travail aux humains. Un test pratique pour tout tech lead : prenez les 100 derniers PR fusionnés et regardez combien de temps chacun a passé à attendre une revue, et non en développement. C'est très probablement là que se trouve le gain que les agents vous avaient promis.