Представьте: пользователь открывает ваш продукт, и интерфейс не просто отображает заранее заготовленные экраны — он собирается в реальном времени, под конкретного пользователя и его контекст. А продакт не сидит с веревкой и мылом в углу :)
Меня зовут Мария Мошкович, я продакт менеджер ИИ продуктов. GenUI появился в моей практике как решение конкретной задачи — и в этой статье я расскажу что из этого вышло. Статья предназначена для продактов и UX-дизайнеров, которые слышали про генеративные интерфейсы, но ещё не разобрались: что это такое на самом деле, чем отличается от обычного чат бота и когда это нужно.
В чем принципиальное отличие
Как выглядит классический чат с ИИ-агентом: пользователь пишет текст -> модель отвечает тоже текстом, возможно с красивым стримингом и markdown-форматированием. Бывает, что поведение интерфейса заложено в конкретные сценарии этого чата, но юзкейсы в таком случае должны быть весьма конкретны и физически исчисляемы.
GenUI — это когда модель не только отвечает текстом, но и принимает решение о том, какой компонент показать. Например собирает интерактивные графики по вашим данным, или достаточно сильно распространившиеся виджеты для апрува в вайб-кодинг приложениях, которые появляются прямо посреди генерации.
Когда это вообще нужно
Прежде чем бежать переделывать продукт — разберемся, когда такое уместно.
GenUI решает конкретную задачу: ваш интерфейс слишком вариативен, чтобы захардкодить все состояния. И вы хотите снять часть когнитивной нагрузки с пользователя, сделав его опыт в продукте приятнее. Несколько кейсов в качестве примера, когда это могло бы быть применимо:
Когда результат генерации — живой артефакт. Агент сгенерировал что-то и показывает это как интерактивный компонент. Пользователь редактирует поля, меняет параметры — агент видит изменения в реальном времени и может менять сам: переставляет, предлагает правки, предупреждает о противоречиях. Т.е. совместная работа пользователя и агента над объектом внутри диалога.
Когда нужно собрать структурированные данные. Агент понимает что пользователю нужно заполнить несколько полей, и рендерит форму, под конкретный контекст, например, бронирование отеля.
Когда ответ проще и лучше показать визуально. Данные, сравнения, сложные схемы работы. График или карточки дадут быстрое понимание там, где текст создал бы когнитивную нагрузку.
Когда нужна навигация по результатам. Агент нашёл 10 вариантов, и пользователю нужно между ними перемещаться, фильтровать или сравнивать
Три подхода к GenUI
Подойти к вопросу генерации UI можно по-разному, и выбор подхода сильно влияет на то, что вы получите в итоге.
Подход 1: HTML-генерация
Самый очевидный и самый хрупкий вариант. Логика достаточно проста: даёте модели задачу -> модель генерирует HTML-разметку -> браузер её рендерит. Все.
Плюсы: быстро реализуется, может сгенерировать все что угодно и модель ничем не ограничена в своих дизайнерских соображениях.
Минусы: дизайнерские соображения модели и генерация чего угодно)
Модель генерирует HTML так, как считает нужным, а это значит, что ваша дизайн-система перестает иметь смысл: кнопки могут выглядеть по-разному от запроса к запросу, цвета могут не совпадать с общим интерфейсом. Да, современные модели глобально лучше справляются с правилами и реализацией HTML, Claude хороший тому пример, но даже Claude может ошибиться. А ещё — это потенциальная дыра в безопасности: исполняемый код от модели в вашем интерфейсе.
Плюс есть технический момент, о котором часто забывают: модель может галлюцинировать несуществующие HTML-атрибуты или генерировать разметку, которая ломается в конкретном браузере. В общем, в продакшене от такого подхода сейчас стараются отказываться.
Когда подходит: быстрые прототипы, внутренние инструменты без строгих требований к дизайну, либо вы готовы идти на риск и серьезно посидеть над скиллом фронтендера
Подход 2: Декларативный подход
Здесь агент не пишет код и не выбирает из полностью готовых блоков — он описывает что-то вроде ТЗ: что должно появиться на экране и из чего это собрать.
Разработчики заранее создают каталог атомарных компонентов — строка, столбец, кнопка, инпут. Агент оперирует этим словарем: решает какие элементы нужны, в каком порядке, с какими параметрами. По сути, агент здесь выступает своего рода верстальщиком.
Этот подход стандартизирует протокол A2UI от Google, вышедший в декабре 2025 — агент отправляет JSON с описанием компонентов, клиент рендерит через свой фреймворк.
Плюсы: стиль компонентов остается вашим — кнопка всегда выглядит как ваша кнопка. Поддерживает большое количество юзкейсов, при этом не надо делать отдельный компонент под каждый сценарий.
Минусы: агент все еще свободен в композиции, поэтому результат может быть немного разным по структуре. Качество, как и в первом подходе, напрямую зависит от модели и проработанности скилла.
Когда подходит: когда вариаций того, что нужно визуализировать, слишком много, чтобы собрать готовые компоненты под каждый случай, но все таки консистентность дизайна нам важна
Подход 3: Агент выбирает готовый компонент
Это наиболее управляемый подход. Разработчики заранее создают полноценные компоненты — готовый график, карточку товара, форму бронирования. Агент не верстает и не описывает структуру, он просто решает какой компонент показать и заполняет его данными.
Когда мы начали искать готовую реализацию этого паттерна, наткнулись на Tambo — небольшой опенсорсный фреймворк, про который в русском комьюнити еще не было никакой информации. Концептуально он работает на базе этого, третьего подхода, но добавляет слой: состояния, жизненный цикл компонента и двусторонняя коммуникация между UI и агентом (AG-UI протокол). Ниже я расскажу про него немного подробнее.
Плюсы: максимальный контроль над визуалом — агент не может сгенерировать ничего не предусмотренного
Минусы: требует понимания, какие компоненты могут понадобиться. Не подойдет для универсальных агентных систем
Когда подходит: когда важен точный контроль над UX, а количество кейсов не стремится к бесконечности
Сравнительная таблица подходов
HTML | Декларативный | Статичный / Tambo | |
Контроль над визуалом | Низкий | Средний | Высокий |
Свобода агента | Максимальная | Высокая | Ограничена библиотекой и типами |
Сложность реализации | Скорее низкая, но +10 к сложности, если захотите научить его генерировать по вашему UI-kit и всем канонам дизайна | Средняя, время на описание работы и принципа сборки сложных компонентов | Средняя, время на реализацию всех нужных компонентов |
Безопасность | 50/50 | Безопасно | Безопасно |
Как мы пришли к Tambo
Продукт, о котором пойдёт речь — ИИ-ассистент для маркетинговой аналитики. Интерфейс состоит из двух основных частей — рабочая область с таблицами данных, по которым пользователь работает: смотрит срезы, сравнивает группы, строит выводы; и чат с агентом, который помогает с этим всем разобраться.
Когда мы проектировали взаимодействие агента с интерфейсом, сразу стало понятно: какие-то генеративные компоненты будут очень полезны для аналитика при работе с выводами, особенно когда надо получить их быстро. Вместо текстового ответа агент может показать инсайт-карточку с ключевой цифрой, мини-график для сравнения групп или сводную таблицу.
Но встал вопрос: а что делать с рабочей областью? Если агент мог бы менять её как хочет — таблицы и срезы с которыми работает пользователь начнут жить своей жизнью, а это самый ценный артефакт нашего продукта, в нем не должно быть ничего лишнего. Спустя два дня беспрерывного ресерча был найден Tambo на просторах гитхаба.
Tambo поддерживает два типа компонентов. Первый — генеративные: работают как раз с библиотекой компонентов, рендерятся один раз в ответ на сообщение в чате, то, что прямо сейчас впишется в контекст, например график. Второй — интерактивные: это обычные React-компоненты, которые вы размещаете в любом месте интерфейса, не обязательно в чате, та же таблица в рабочей области. Пользователь взаимодействует с ней напрямую, а Tambo наблюдает за ее состоянием.
Сама реализация не сложная: компоненты регистрируются с описаниями и Zod-схемами пропсов — это становится словарем агента. Дальше он сам решает что показать исходя из контекста диалога и стримит пропсы прямо в компонент в реальном времени.
К этому подходу мы в итоге и пришли:
Рабочая область — для основного контента: здесь живут Interactable-компоненты. Они размещены заранее, всегда видны на нужном этапе, и агент может менять только их содержимое, но не структуру.
Чат — для всего что “сверх” основного: Generative-компоненты, как графики, карточки и т.п., генерируются только в чате, не мешая работе с основным материалом.
Какой подход подойдёт, зависит не от стека и не от того что сейчас модно — а от того, как вы видите взаимодействие пользователя с вашим продуктом. Что для него важнее: предсказуемость и контроль над тем что он видит, или богатый и неожиданный вывод от агента? Где в вашем продукте есть место для свободы модели, а где она будет только мешать? Ответы на эти вопросы и определяют выбор подхода.
Полезные ссылки для изучения
A2UI — протокол от Google, документация и примеры
Tambo — фреймворк для React
AG-UI — протокол для двусторонней коммуникации агент-приложение, работает поверх A2UI и других спеков
GenUI активно развивается — A2UI вышел в декабре 2025, Tambo выпустили v1.0 в феврале 2026, и это далеко не последние инструменты в этом направлении. Но какими бы ни были новые фреймворки и протоколы, логика выбора остается той же: опирайтесь на то, что нужно вашему продукту и пользователю, а не на то, что появилось последним.
Если у вас был опыт с GenUI в продакшне — интересно услышать в комментариях, какой подход выбрали и почему?
