Instagram Direct перестроил UI Android под ИИ-нативную архитектуру на 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-тестирование и непрерывное дерево композиции.