Будущее приложений — без приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вместо этого нужен промежуточный декларативный протокол. Например, модель генерирует не 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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• API и доменная логика ^[13];

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

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

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

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

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

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

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

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

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