Contexte et objectifs
Spotify a constaté que le nombre de changements fusionnés a plus que doublé d’une année sur l’autre, atteignant environ 17 000 en août. Malgré ce volume, l’entreprise n’a pas observé d’augmentation proportionnelle du rework ni d’incidents majeurs liés au code généré par l’IA. Cette situation a déplacé la pression vers la capacité de vérification : il a fallu renforcer les revues, le monitoring, les rollbacks et les métriques de qualité pour gérer des pull requests plus gros et plus complexes.
Architecture du flux agentique sur Expo
Le processus repose sur des agents capables d’ouvrir des pull request de correction (fix PR) qui sont ensuite approuvées par un humain avant d’être déployées. Expo, plateforme de développement mobile sponsorisée, fournit un environnement d’exécution où les agents peuvent exécuter des tests automatisés et simuler des appareils. Expo travaille actuellement sur des simulateurs dédiés aux agents, accessibles via une liste d’attente, afin de réduire les temps d’itération. Le monitoring de performance, intégré à chaque version, associe les métriques d’exécution aux releases, permettant d’identifier rapidement les régressions et de les renvoyer aux agents pour un nouveau cycle.
Analyse des impacts sur la vélocité et la vérification
Le doublement du nombre de merges sans hausse du rework indique que les agents automatisent efficacement la rédaction et le test du code. Cependant, la charge de vérification a augmenté, poussant Spotify à mettre en place des revues plus strictes, des priorisations de services et des indicateurs de complexité des PR. Un autre article du même TLDR montre que, dans des expériences sur des applications React identiques, une modification simple d’une feuille de style coûte cinq fois plus dans une version sur‑abstraite et trois fois plus même après égalisation de la taille du code. Ces résultats soulignent que l’abstraction excessive augmente le coût de navigation inter‑fichiers et les allers‑retours, ce qui peut ralentir les boucles d’agent même si le code généré est correct.
Limites et considérations
Le principal risque identifié est le provenance gap : les agents peuvent produire un commit vert tout en effaçant les tentatives échouées et les réparations, rendant difficile la reconstruction du chemin de décision en cas d’incident. La proposition d’un enregistrement de provenance, liant chaque entrée, sortie, diff, configuration de modèle et tentative de retry, vise à combler ce vide, mais nécessite un stockage supplémentaire et une discipline de suivi. De plus, la dépendance à des simulateurs spécifiques à Expo peut créer un point de défaillance si ces environnements ne reflètent pas fidèlement le matériel réel. Enfin, la charge humaine de validation reste un goulot d’étranglement : même avec des agents, chaque PR doit être approuvée, ce qui limite la vitesse maximale atteignable sans augmenter les équipes de revue.
