Instagram Direct a reconstruit l'UI Android selon une architecture native à l'IA sur Jetpack Compose

Instagram Direct est l'une des surfaces les plus importantes d'Instagram : des milliards de messages y transitent chaque jour. Pendant de nombreuses années, l'équipe a tiré des micro-optimisations du système Android View hérité, jusqu'à se heurter à un problème : maintenir et étendre une surface fortement optimisée mais obsolète devenait de plus en plus coûteux — la dette technique et les surcoûts d'ingénierie augmentaient, d'autant plus que l'UI déclarative et les assistants IA d'écriture de code devenaient la norme. Au lieu de considérer l'adoption de Compose comme une énième modernisation de l'interface, Meta s'est fixé un objectif plus ambitieux — reconcevoir la base de code et son architecture pour qu'elle soit pensée nativement pour l'IA, démultipliant ainsi l'effet de l'IA par rapport à ce qu'aurait apporté une simple retouche du code existant.

Les résultats ont été mesurés précisément. Jetpack Compose a permis à Instagram Direct de réduire le volume total de code UI de 50 %, d'accélérer l'exécution des tâches par les agents IA de 35 %, de diminuer de 32 % le nombre d'échanges entre ingénieur et agent et de réduire de 33 % la consommation de tokens par session d'agent. La nature déclarative de Compose joue ici un rôle clé : le code devient concis, prévisible et structurellement plus compréhensible pour les modèles d'IA — moins d'effets de bord, moins d'état implicite, des frontières de composants plus nettes. Ce sont précisément ces propriétés qui permettent à l'IA de produire un résultat de meilleure qualité, et un moindre volume de code généré se traduit directement par une moindre consommation de tokens par tâche.

L'équipe a tiré de dures leçons de ce qui se produit lorsqu'on pointe l'IA sur du code mixte. Dans une base de code riche en RecyclerView, le raccourci tentant consiste à intégrer des composants Compose à l'intérieur de la hiérarchie View existante. En tant qu'étape de migration à court terme, c'est acceptable, mais à long terme les outils d'IA suivent le chemin de moindre résistance : lorsque le code déclaratif et le code impératif sont mélangés, l'IA se met à les fusionner incorrectement, engendrant des bugs subtils, de la dette technique et des régressions de performance. Exemples concrets : un flag de fonctionnalité lu dans du code impératif, puis capturé à l'intérieur d'une lambda Compose ; ou un champ modifiable qui vit sur la classe de l'élément plutôt que dans son état d'interface — et qui survit ainsi au re-binding et au recyclage de RecyclerView entre les rangées, provoquant des bugs pénibles à reproduire. Les garde-fous et les compétences aident, mais ne suffisent pas, car l'IA, face à une résistance, trouve des contournements.

La solution est une paire de règles pratiques. Un élément de liste peut conserver sa propre abstraction, mais tout le code Compose doit se trouver dans le constructeur en tant que content, les arguments du constructeur étant l'unique source de données, sans accès aux membres de la classe ni à l'état modifiable. L'élément devient ainsi équivalent à une simple fonction @Composable, tout en restant dans le cadre de l'architecture existante. La migration a été menée par étapes, en deux temps par écran : d'abord identifier les motifs communs et les cas limites, puis les appliquer systématiquement, en confiant à un ingénieur le soin de stabiliser d'emblée l'architecture et les passages délicats, et aux autres celui de tout mener jusqu'à la production. Plusieurs ingénieurs ont lancé leurs propres agents d'IA au-dessus d'une base de connaissances partagée de compétences et de conventions réutilisables, ce qui a synchronisé les flux de travail et les bonnes pratiques à travers l'équipe et éliminé la redécouverte redondante des décisions déjà prises.

L'échelle était immense. Des composants d'interface individuels peuvent être rendus dans plus de 160 combinaisons d'états distinctes, et un seul écran de conversation gère plus de 200 types de messages différents. L'équipe a progressivement migré vers Compose plusieurs centaines d'éléments de liste au sein de l'architecture RecyclerView existante, et les a déployés en petits groupes indépendants sous tests A/B, sans aucune perturbation visible de l'expérience de messagerie. La performance restait l'objectif numéro un : les métriques étaient suivies en temps réel en production, permettant à l'équipe de lancer des tests A/B comparant l'interface migrée en Compose à l'ancienne.

Une analyse interne a comparé les sessions d'agents d'IA travaillant sur une interface Compose aux mêmes tâches sur Android Views, en utilisant un score de risque qui évalue la qualité du code et la probabilité qu'un changement provoque un incident en production. Lorsque le score de risque accumulé d'un fichier double, Android Views réduisaient l'efficacité en ressources de l'agent — à savoir la consommation de tokens, le temps d'exécution et le nombre d'interactions ingénieur-agent — de 30 % par caractère livré, tandis que l'interface Compose ne chutait que de 9 %. Étape suivante naturelle : l'équipe remplace le cœur basé sur RecyclerView par LazyColumn, en gardant les composants Compose abstraits du framework qui les enveloppe et commutables à l'exécution via des flags de fonctionnalité, afin de préserver les tests A/B et un arbre de composition continu.