Как Instagram Direct перестроил UI под ИИ-агентов и сократил расход токенов на 33%
Команда Instagram Direct использовала переход на Jetpack Compose не как обычную замену Android Views, а как возможность перестроить архитектуру интерфейса под работу с ИИ-агентами. На перенесённых участках объём UI-кода сократился примерно на 50%, время работы агентов — на 35%, количество взаимодействий между разработчиком и агентом — на 32%, а расход токенов в расчёте на сессию — на 33%.
Direct относится к ключевым частям Instagram: через него ежедневно проходят миллиарды сообщений. За годы развития инженеры довели старую реализацию на Android Views до высокой степени оптимизации, но поддержка такого интерфейса становилась всё сложнее и дороже. Увеличивались технический долг и количество внутренних правил, которые требовалось учитывать при каждом изменении.
Почему команда выбрала Compose
Jetpack Compose основан на декларативном подходе, благодаря которому интерфейс описывается более компактно и предсказуемо. В коде становится меньше неявного состояния и побочных эффектов, а границы между компонентами выражены яснее. Эти особенности важны не только для разработчиков: ИИ-моделям проще анализировать код, построенный на распространённых и последовательных принципах.
Масштаб миграции был значительным. Отдельный UI-компонент Direct мог отображаться более чем в 160 комбинациях состояний, а один экран переписки поддерживал свыше 200 типов сообщений. При этом переход требовалось выполнять постепенно, не нарушая работу приложения для сотен миллионов пользователей и продолжая выпускать новые функции.
Команда пришла к выводу, что простого добавления Compose-компонентов в существующую иерархию View недостаточно. Такой подход удобен как промежуточный этап, но в долгосрочной перспективе смешение императивной и декларативной моделей создаёт дополнительные риски. ИИ-агент, стремясь выбрать самый простой путь, может связать эти подходы неудачным образом, добавить состояние не в том месте или обойти архитектурные ограничения.
Архитектура, в которой сложнее написать плохой код
Одной из проблем старого подхода были элементы RecyclerView, совмещавшие императивный жизненный цикл с Compose-разметкой. Например, состояние могло храниться в изменяемом поле самого элемента, а не в объекте состояния интерфейса. При повторном использовании элементов RecyclerView такое состояние способно сохраняться между строками и приводить к трудно воспроизводимым ошибкам.
Чтобы снизить риск подобных решений, команда перенесла Compose-код внутрь конструкций, не имеющих доступа к произвольным полям и состоянию класса. Все необходимые данные и обработчики передаются через конструктор, а компонент по сути становится эквивалентом обычной функции @Composable. Такой дизайн не просто описывает желательную архитектуру в документации, а делает правильный путь самым удобным для реализации.
В Instagram сформулировали два принципа разработки кодовой базы, предназначенной для работы с ИИ. Во-первых, следует уменьшать зависимость от уникального контекста конкретного проекта: чем ближе код к распространённым практикам, тем лучше агент понимает задачу. Во-вторых, архитектура должна самостоятельно обеспечивать соблюдение границ. Постоянно компенсировать архитектурные пробелы дополнительными инструкциями для ИИ неэффективно: они занимают место в контексте и плохо масштабируются.
Как проходила миграция
Сотни компонентов долгое время существовали в двух версиях — на Views и на Compose. ИИ-агенты помогли ускорить написание большого объёма повторяющегося кода и сделать параллельную поддержку реализаций возможной. Несколько инженеров могли одновременно запускать собственных агентов, используя общую базу знаний с инструкциями и соглашениями, выработанными во время миграции.
Работу над каждым интерфейсом разделили на два этапа. Сначала с помощью ИИ создавали основную реализацию на Compose. Затем инженеры дорабатывали её: проверяли пограничные случаи, устраняли проблемы производительности и готовили интерфейс к публичному тестированию и дальнейшему использованию в продукте. Благодаря такому разделению один специалист мог быстро пройти весь экран и определить основные архитектурные решения, а остальные — сосредоточиться на качестве и выпуске.
Измеримый эффект для ИИ-разработки
Внутреннее сравнение задач для Compose и Android Views показало устойчивую разницу. В расчёте на один символ кода, попавшего в основную кодовую базу, при работе с Compose требовалось на 32% меньше взаимодействий инженера с агентом, а время работы агента сокращалось на 35%. В типичной сессии общий расход токенов был ниже на 33%.
Команда отдельно анализировала устойчивость этих показателей к сложности и хрупкости кода. Для этого в Meta используют показатель риска изменений, который учитывает качество файла и вероятность того, что правка приведёт к инциденту в продакшене. При двукратном росте накопленного риска эффективность агента в интерфейсах на Android Views снижалась на 30% в пересчёте на символ кода. Для Compose снижение составляло 9%.
Таким образом, преимущество Compose проявлялось не только в меньшем объёме исходного кода. Более структурированная и предсказуемая архитектура помогала агентам эффективнее работать с изменениями даже в сложных участках проекта.
Производительность осталась критическим условием
Переписывание Direct нельзя было проводить за счёт скорости приложения. Пользователи ожидают, что экран сообщений будет открываться быстро и оставаться отзывчивым, поэтому команда продолжала отслеживать сотни показателей производительности. Среди ключевых метрик были время от открытия экрана до готовности к взаимодействию и время полной загрузки.
Вместе с Google инженеры дорабатывали сам Jetpack Compose. В работе использовались Pausable composition и LazyLayoutCacheWindow, был добавлен механизм onVisibilityChanged, а первый запуск оптимизировали с помощью Baseline Profiles. RecyclerView постепенно заменяли на LazyColumn. Эти изменения позволили сохранять требования к производительности во время масштабной миграции и одновременно улучшили инструменты, доступные Android-разработчикам.
Опыт Instagram Direct показывает, что внедрение ИИ в разработку не обязательно сводится к подключению ассистента к существующему проекту. Существенный эффект даёт подготовка самой кодовой базы: компактный декларативный UI, ясные границы компонентов и архитектурные ограничения, которые направляют агента к корректным решениям. Для больших приложений такой подход позволяет одновременно ускорять разработку, контролировать технический долг и не отказываться от требований к производительности.
