Instagram Direct перебудував Android UI під ІІ-нативну архітектуру на Jetpack Compose

Instagram Direct — одна з найважливіших поверхонь Instagram: через неї щодня проходять мільярди повідомлень. Багато років команда вичавлювала мікрооптимізації із застарілої системи Android View, поки не вперлася в проблему: підтримувати й розширювати сильно оптимізовану, але застарілу поверхню ставало дедалі дорожче — зростав технічний борг та інженерні витрати, особливо на тлі того, що декларативний UI та ІІ-помічники в написанні коду стали нормою. Замість того щоб поставитися до впровадження Compose як до чергової модернізації інтерфейсу, Meta поставила амбітнішу мету — перепроєктувати кодову базу та її архітектуру так, щоб вона із самого початку була заточена під ІІ, тим самим багаторазово посиливши ефект від ІІ порівняно з тим, що дала б проста доопрацювання наявного коду.

Результати виміряли точно. Jetpack Compose дав змогу Instagram Direct скоротити загальний обсяг UI-коду на 50%, прискорити виконання завдань ІІ-агентами на 35%, на 32% зменшити кількість обмінів між інженером та агентом і на 33% знизити витрату токенів на одну сесію агента. Ключову роль тут відіграє декларативна природа Compose: код стає лаконічним, передбачуваним і структурно зрозумілішим для ІІ-моделей — менше побічних ефектів, менше неявного стану, чіткіші межі компонентів. Саме ці властивості дають змогу ІІ видавати результат вищої якості, а менший обсяг згенерованого коду напряму позначається на меншій витраті токенів на завдання.

Команда винесла серйозні уроки з того, що відбувається, коли ШІ націлюють на змішаний код. У кодовій базі, де багато RecyclerView, є спокусливий короткий шлях — вбудовувати компоненти Compose всередину наявної ієрархії View. Як короткостроковий крок міграції це допустимо, але в довгостроковій перспективі ШІ-інструменти йдуть шляхом найменшого опору: коли декларативний та імперативний код змішані, ШІ починає об'єднувати їх неправильно, породжуючи ледь помітні баги, технічний борг і регреси продуктивності. Конкретні приклади: прапорець фічі прочитали в імперативному коді, а потім зафіксували всередині лямбди Compose; або змінюване поле лежить на класі елемента, а не в його UI-стані — і через це переживає пере-біндинг і перевикористання RecyclerView між рядками, спричиняючи баги, які болісно відтворювати. Обмежувачі та навички допомагають, але їх недостатньо, бо ШІ, наштовхнувшись на опір, знаходить обхідні шляхи.

Рішення — пара практичних правил. Елемент списку може зберігати власну абстракцію, але весь код на Compose має перебувати в конструкторі як content, а аргументи конструктора — єдине джерело даних, без доступу до членів класу та змінюваного стану. Так елемент стає еквівалентним звичайній функції @Composable, залишаючись при цьому в межах наявної архітектури. Міграцію проводили поетапно, по два кроки на кожен екран: спочатку виявляли загальні патерни та крайні випадки, потім застосовували їх системно, доручивши одному інженеру заздалегідь усталити архітектуру та складні місця, а решті — доводити все до продакшену. Кілька інженерів запускали власних ШІ-агентів поверх спільної бази знань із перевикористовуваними навичками та угодами, що синхронізувало робочі процеси та найкращі практики по всій команді й позбавило від повторного намацування вже ухвалених рішень.

Масштаб був величезним. Окремі UI-компоненти можуть відображатися в понад 160 різних комбінаціях станів, а один екран листування обслуговує понад 200 різних типів повідомлень. Команда поступово перевела на Compose кілька сотень елементів списку всередині наявної архітектури RecyclerView і викочувала їх невеликими незалежними групами під A/B-тестами з нульовим видимим впливом на досвід листування. Продуктивність залишалася ціллю номер один: метрики відстежували в рантаймі на проді, що дозволяло команді запускати A/B-тести, порівнюючи мігрований UI на Compose із застарілим.

Внутрішній аналіз зіставив сесії ШІ-агентів, які працювали над UI на Compose, з тими самими завданнями на Android Views, використовуючи оцінку ризику, яка оцінює якість коду та ймовірність того, що зміна спричинить інцидент у проді. Коли накопичена оцінка ризику файлу подвоюється, Android Views знижували ресурсну ефективність агента — тобто витрату токенів, час виконання та кількість взаємодій інженера з агентом — на 30% на кожен внесений символ, тоді як UI на Compose — лише на 9%. Наступний природний крок: команда замінює ядро на основі RecyclerView на LazyColumn, тримаючи компоненти Compose абстрагованими від обрамляючого фреймворку та перемиканими в рантаймі через прапорці фіч, щоб зберегти A/B-тестування та безперервне дерево композиції.