Всем привет. Я Михаил Харитончик, лидер продукта GenUI в Цифровом Ассистенте ГигаЧат B2C. Моя команда занимается генеративными интерфейсами: тем, как превращать ответ модели в понятную визуализацию, интерактивные элементы и полноценный пользовательский сценарий. И сегодня я хочу поговорить о будущем приложений. Точнее, о будущем, в котором приложений в привычном виде может вообще не остаться.

Этот текст про горизонт от нескольких месяцев до пары лет. В ИИ-индустрии даже полгода — практически геологическая эпоха: изменения происходят не кварталами, а итерациями длиной в несколько часов. Недавно я увидел, как Сэм Альтман репостит сообщение: кто-то обнаружил, что Grok при работе с агентом отдаёт исходный код. Прошло менее суток — и Grok CLI уже ушёл в open source. За происходящим в индустрии физически сложно успевать.

Визионерствовать на долгий срок в таких условиях сложно, поэтому поговорим о ближайшем будущем. Не абстрактном, а о том, которое начинается с обычного вечера после работы.

Как мы стали API-шлюзом

Мой обычный день: работа, дорога домой, посещение тренажёрного зала в Лужниках. Ничего экзотического, но если посмотреть на этот сценарий с точки зрения цифрового мира, то начинается квест. Сначала я открываю карту и оцениваю дорогу домой. Вариантов два: такси или метро. Появляются переменные:

• Если еду на такси — экономлю время, но трачу больше денег.

• Если еду на метро — добираю дневную норму шагов.

• Чтобы понять, насколько важны шаги, открываю Whoop.

• Чтобы оценить, насколько оправдана цена такси, мысленно сверяюсь с состоянием счёта.

• Чтобы договориться о тренировке — иду в мессенджер.

• Чтобы не забыть выйти вовремя — ставлю таймер или напоминание.

• Чтобы записать подходы и веса — открываю заметки или тренировочный трекер.

Каждая переменная — шаги, усилия, деньги, маршруты, друзья, календарь, тренировки, таймеры — живёт в своём отдельном приложении. И в какой-то момент я становлюсь API-шлюзом между ними. Я вручную вытаскиваю данные из одного интерфейса, удерживаю их в рабочей памяти, сопоставляю с данными из другого интерфейса, принимаю решение и передаю результат в третье приложение. Всё это — ради рутинного действия, которое повторяется почти каждый день.

Вишенка на торте — выбор между такси «Комфорт» и «Комфорт+». Разница, допустим, 120 рублей. И вот на эту развилку я трачу то самое когнитивное топливо, которое к вечеру и так почти закончилось. Накрывает усталость от принятия решений. Пока едет машина, я выбираю, что посмотреть или почитать, — и выбираю что-нибудь максимально простое. Не потому, что оно лучше, а потому, что мозг уже потратил ресурсы на сравнение переменных и переключение контекста.

Затем приезжает водитель, нужно снова открыть приложение и понять, где именно стоит машина; проверить, не сдвинулась ли геолокация на соседнюю улицу; дойти до нужной точки.

Потом — тренировка. Нужно позвать друзей, согласовать время, поставить напоминание. А на месте внезапно выясняется, что в Лужниках проходит концерт, у входа на территорию очередь, и к тренировке добавляется ещё пятнадцать минут логистики.

В конце — снова открываю приложение с заметками: прошлые веса, подходы, план на сегодня.

За один вечер происходит десяток переключений контекста. Я расходую интеллектуальные ресурсы не на саму жизнь, не на тренировку, отдых или общение, а на обслуживание интерфейсов.

Приложения оптимизируют себя, а не вас

Проблема в том, что каждое приложение оптимизирует собственную функцию. Карты хотят, чтобы вы использовали карты, такси — чтобы заказывали такси, сервис доставки — чтобы заказывали доставку. Внутри каждого продукта вас ждут рекомендации, баннеры, дополнительные услуги, акции и попытки продлить сессию.

Но моё реальное намерение находится между приложениями. Я не хочу «использовать такси», я хочу добраться домой к определённому времени, потратить приемлемую сумму, не сорвать тренировку и, возможно, добрать шаги. Это не сценарий одного приложения, это композиция из карт, транспорта, здоровья, финансов, календаря, мессенджера и заметок.

Именно здесь появляются агенты.

Агент вместо набора приложений

Представим, что мы сжали все приложения до их сути — API и Skill-ов. У каждого сервиса есть набор действий:

• карты умеют строить маршруты;

• такси умеет считать цену и создавать заказ;

• Whoop умеет возвращать данные о сне, восстановлении и шагах;

• календарь умеет создавать события;

• мессенджер умеет писать друзьям;

• заметки умеют хранить тренировочные планы.

Не обязательно, что все эти API публичны. Не обязательно, что интеграция будет простой. Но на уровне концепции сервис превращается в «способность выполнить конкретное действие».

И над такими «способностями» появляется агент. Современный агент — будь то OpenClaw, Hermes Agent или альтернативное решение — обычно состоит из нескольких ключевых частей:

• Память. Набор фактов о пользователе, его предпочтениях, привычках и истории взаимодействия. На практике это может быть и набор Markdown-файлов, и векторное хранилище, и более сложная система.

• Инструменты и навыки. Интерфейсы к API, сервисам, данным и действиям.

• Контекст. Текущая задача, история диалога, ограничения, разрешения и состояние мира.

• Heartbeat. Регулярный запуск агента по таймеру.

• Вебхуки и события. Возможность реагировать на внешние изменения: концерт рядом с тренировкой, отмену брони, пробки, изменение погоды или опоздание друга.

Агент может работать реактивно — отвечать на запрос пользователя. Но гораздо интереснее, когда он становится инициативным. Например, он знает, что я обычно выхожу из офиса около 19 часов. За полчаса до этого он может проверить пробки, цены на такси, расписание транспорта, загруженность спортивного комплекса и события рядом с ним — это heartbeat.

Необязательно каждый запуск heartbeat должен заканчиваться сообщением пользователю. Агент может просто обновить память — это не векторная база, а файлы: долгосрочные курируемые факты, дневник дня и так далее.

Постепенно система начнёт понимать, что для меня действительно важно: в картах мне не нужны все функции картографического сервиса; в Whoop меня могут интересовать всего две метрики: сон и шаги. Агент учитывает именно этот контекст, а не предлагает весь каталог возможностей каждого продукта.

Но текстовый агент — это ещё не интерфейс

Казалось бы, задача решена. Я пишу агенту: «Хочу после работы попасть домой, сходить на тренировку и не забыть форму». Он собирает данные из всех сервисов, строит план и возвращает ответ.

Например:

До дома быстрее всего на такси: Комфорт — 570 ₽, Комфорт+ — 690 ₽. Разница 120 ₽. Вы не торопитесь, а Whoop показывает низкую активность — можно пройти часть пути пешком и добрать шаги. После дома нужно выйти в 21:40, чтобы успеть на Спортивную к 22:00. У Воробьёвых гор сегодня концерт — возможна очередь на вход. Могу вызвать такси, поставить будильник, написать друзьям и предложить видео на дорогу.

Формально всё хорошо: агент избавил меня от переключения между приложениями. Но теперь я стал текстовым парсером. Агенты любят объяснять, и это естественно: модель «думает» через последовательность токенов и часто стремится выдать развёрнутый ответ. Но человеку неудобно читать полотно текста, когда нужно быстро принять решение.

Некоторые вещи вообще плохо выражаются текстом:

• Где именно стоит приехавшее такси?

• Как соотносятся цены нескольких тарифов?

• Сколько времени осталось до выхода?

• Как выглядит мой бюджет или динамика расходов?

• Какой из двух маршрутов быстрее, дешевле и полезнее с точки зрения шагов?

• Какие подходы и веса делать на тренировке?

Поэтому нужен визуальный интерфейс. Не заранее спроектированный экран конкретного приложения, а интерфейс, который агент собирает под текущее намерение пользователя.

Так мы и пришли к идее генеративного интерфейса — GenUI.

GenUI: интерфейс как ответ на намерение

В генеративном интерфейсе агент не просто пишет: «Есть два варианта», а создаёт компактный экран:

• карточку с планом вечера;

• кнопку «Выйти через 15 минут»;

• блок согласования времени с друзьями;

• таблицу выбора транспорта;

• индикатор шагов, которые нужно пройти;

• таймер до выхода;

• кнопку подтверждения заказа такси;

• предупреждение об очереди;

• альтернативный маршрут к нужному входу.

В одном виджете можно объединить информацию, которая раньше была жёстко разделена между несколькими приложениями. Например, агент показывает:

Такой экран невозможно собрать в рамках классической модели мобильных приложений. Такси не будет нативно учитывать вашу активность в Whoop, а фитнес-трекер — стоимость маршрута и загруженность конкретного входа в спортивный комплекс. Даже супераппы редко доходят до такой глубины персонализации, потому что их задача — удержать пользователя внутри собственной экосистемы, а задача агента — насквозь оптимизировать намерение пользователя.

При этом агент не должен бесконтрольно принимать решения за человека. Заказать такси и списать деньги — действие с последствиями. Модель может ошибиться, повторно выполнить запрос или неверно интерпретировать контекст. Поэтому такие операции нужно завершать явным подтверждением: кнопкой, чекбоксом, выбором тарифа или другим понятным механическим действием. Не текстовым /approve в чате, а нормальным интерфейсом.

Персонализация — не рекомендация

Настоящая персонализация начинается не с фразы «вам может понравиться». Она начинается с того, что агент помнит контекст и умеет использовать его осознанно. Например, в YouTube легко случайно посмотреть что-то, что потом совсем не хочется видеть в рекомендациях. Удаление ролика из истории не всегда быстро исправляет ситуацию: система продолжает подсовывать похожий контент. Агенту можно сказать напрямую: «Не предлагай мне такой контент, это был случайный просмотр», и он сохранит это как явное предпочтение, а не как косвенный сигнал, который алгоритм должен интерпретировать.

То же самое относится к транспорту, тренировкам, питанию, планированию и любым бытовым сценариям. Агент знает, что пользователь предпочитает, чего избегает, какие компромиссы готов принимать и какие действия требуют обязательного подтверждения. Например, если пользователь не добрал шаги, то агент может мягко вмешаться в привычный сценарий: предложить пройти часть пути пешком, подсветить маршрут через парк, поставить менее удобный вариант такси ниже в списке. Не запрещать, не манипулировать, а помогать придерживаться целей, которые человек сам для себя задал.

Из чего строится такая система

Чтобы собрать подобный опыт, нужны три базовых слоя:

1. Фронтенд. Телефон, очки, компьютер, голосовой интерфейс или любое другое устройство, на котором пользователь видит результат.

2. Agent harness на бэкенде. Система, которая хранит контекст, память, настройки, разрешения и историю и управляет инструментами.

3. Модель, умеющая работать с интерфейсом. Она должна понимать намерение пользователя и выбирать не только текстовый ответ, но и подходящее представление: кнопку, таблицу, график, карту, форму или таймер.

Ключевой момент: модель не должна генерировать интерфейсный код с нуля. Она описывает интерфейс на языке, который фронтенд умеет интерпретировать.

Наивный подход выглядит так: дать модели HTML, CSS и JavaScript, подключить дизайн-систему, попросить соблюдать руководства — и позволить на лету собирать любые экраны. Технически это возможно, а практически получается дорого, нестабильно и несогласованно. Модель будет тратить много токенов на рутину. Интерфейсы начнут отличаться друг от друга. Появятся ошибки в доступности, поведении, адаптивности и визуальной иерархии. А при добавлении каждого нового навыка придётся снова думать, как заставить модель корректно использовать дизайн-систему.

Вместо этого нужен промежуточный декларативный протокол. Например, модель генерирует не HTML, а структуру такого рода:

screen:
  title: "План на вечер"
  blocks:
    - type: transport_comparison
      options:
        - label: "Метро"
          duration: "52 мин"
          price: "75 ₽"
          steps: "+4 200"
        - label: "Такси"
          duration: "35 мин"
          price: "560 ₽"
          steps: "+300"
    - type: reminder
      text: "Выйти через 15 минут"
      action: create_timer
    - type: confirmation
      text: "Заказать такси?"
      primary_action: order_taxi

Дальше парсер преобразует эту структуру в JSON, а фронтенд — в реальные компоненты интерфейса. То есть модель получает не код, а контракт, на основе которого собирает интерфейс из компонентов — «атомов»: текст, кнопка, поле ввода, карточка, график, таблица, список, таймер, карта. 

При этом модель не получает бесконтрольную возможность собрать произвольный веб-сайт. Это важно сразу по нескольким причинам:

• сохраняется согласованность дизайн-системы;

• интерфейс остаётся предсказуемым;

• снижается количество токенов;

• можно встроить правила безопасности и permissions;

• можно ограничить набор допустимых действий;

• сложную бизнес-логику берут на себя компоненты, а не модель.

Можно пойти другим путём: для каждого навыка заранее создать отдельный виджет. Но пользовательские сценарии не живут в границах продуктов. Сегодня человеку нужен виджет тренировки, завтра — планировщик встреч, в выходные — подбор маршрута по паркам, через неделю — объединённый сценарий «забрать заказ, встретиться с другом и успеть в кино». Если заранее проектировать экран под каждый из этих вариантов, то мы снова возвращаемся к миру приложений: набору изолированных процессов.

Поэтому нужна способность собирать новый интерфейс из базовых атомов под конкретную ситуацию. Безусловно, в соответствии с:

• требованиями платформы: общие правила, дизайн-система, паттерны подтверждения, безопасность, базовые компоненты;

• и продуктовыми требованиями: сценарии продукта, доменные виджеты, бизнес-правила, доступные действия, настройки поведения.

Иначе мы получим интерфейсы, которые выглядят так, будто их сгенерировала модель без присмотра.

Как это выглядит на очках виртуальной реальности

Поясню идею на примере примере моего сетапа с очками Even Realities G2. У них небольшой монохромный дисплей 576 × 288 пикселей. Места мало, цветов нет, интерфейс крайне ограничен. С одной стороны, это усложняет задачу. С другой — заставляет оставить только действительно важную информацию.

Допустим, агент получает запрос: «Нужно добраться домой, успеть на тренировку и не забыть форму».

Модель собирает компактный интерфейс:

Технический конвейер выглядит так:

1. Модель генерирует YAML-подобное описание интерфейса.

2. Парсер преобразует его в структурированный JSON.

3. JSON рендерится в web view на смартфоне.

4. Изображение передаётся на очки в адаптированном монохромном виде.

5. Пользователь взаимодействует с элементами через управление на устройстве.

Таким образом, один и тот же набор компонентов может отображать маршрут, стоимость такси, тренировочный план, шаги, карту или таймер. Но здесь есть важная граница: таймер — это не просто текст с числом, он требует бизнес-логики: отсчёта времени, обновления состояния, обработки паузы, фонового выполнения. Поэтому компонентный подход не означает, что модель заменяет всю разработку. Модель собирает интерфейс и определяет, когда показать конкретный компонент. Но сама сложная механика остаётся внутри проверенных компонентов и сервисов.

Две модели вместо одной

Чтобы упростить и удешевить расчёты, мы придерживаемся архитектуры из двух моделей. 

Первая — быстрая, «интерактивная», отвечает пользователю в реальном времени: принимает голосовой запрос, уточняет подробности, показывает интерфейс, обрабатывает выбор. Пользователь скорее простит неидеальный ответ, чем задержку ответа в 10-20 секунд. Если заставить человека ждать, он просто вернётся к привычному способу: откроет карты, затем такси, календарь, мессенджер...

Вторая модель — медленная и фоновая. Она может:

• анализировать историю взаимодействий;

• обновлять память;

• находить новые паттерны;

• создавать или улучшать композиции интерфейсов;

• готовить сценарии заранее;

• выполнять более дорогие рассуждения;

• проверять данные из нескольких источников.

Это похоже на архитектуру современных voice mode-систем. Интерактивная модель должна быстро поддерживать разговор, поэтому часто уступает большой чат-модели в глубине рассуждений. Более тяжёлая модель работает в фоне, возвращает результаты быстрой модели, а та уже использует их во время общения с пользователем.

Инициативность и проактивность здесь важна не только для «угадывания желания», она помогает скрывать задержку реакции системы: система видит контекст, большая модель готовит варианты, пользователь выражает намерение, быстрая модель показывает заранее подготовленные варианты. Например, если агент знает, что я обычно выхожу из офиса около 19 часов, то он может начать составлять план в 18:50: проверить маршруты, цены на такси, события, очереди, тренировочный календарь. На это можно потратить больше времени, применив более сильную модель и задействовав больше вычислительных ресурсов — ещё до того, как я открою интерфейс. И в итоге я почти мгновенно получу готовое предложение.

Что останется от приложений?

В будущем не исчезнут ни API, ни сервисы, ни сложная бизнес-логика, ни дизайн-системы. Исчезнет необходимость заходить в отдельное приложение для каждого действия. От привычных приложений останутся:

• API и доменная логика;

• данные и разрешения;

• надёжные интерактивные компоненты;

• карты, графики, формы, списки, кнопки;

• механизмы оплаты и подтверждения;

• брендовые и юридические ограничения.

Но финальный пользовательский сценарий будет собирать не продуктовая команда в рамках одного экрана, а агент под конкретное намерение конкретного человека.

Конечно, не всё можно свести к простым атомам. Графики, карты, таймеры, платежи, навигация и сложные интерактивные сценарии потребуют большого количества кода под капотом. Но интерфейс верхнего уровня — то, как эти части собираются в решение задачи, — сможет появляться динамически.

Приложения почти никогда не будут оптимизировать ваш путь целиком. Они оптимизируют собственную воронку, метрики и набор услуг. Агентский harness может занять другое место в этой системе. Он будет оптимизировать не экран приложения, а намерение пользователя.

И да — кнопки подтверждения никуда не денутся. Если агент хочет вызвать такси, списать деньги или отправить сообщение, то последнее слово должно оставаться за человеком.