Google, Tambo, and GenUI: three approaches to AI interfaces built on the fly

Generative UI выходит за пределы чат-ботов: модель не только пишет ответ, но и решает, какой интерфейс показать пользователю в конкретный момент. Новый разбор объясняет, где такой подход реально полезен — от аналитики до бронирований — и почему выбор архитектуры здесь важнее моды на агентные системы.

Чем

GenUI отличается В обычном ИИ-чате пользователь получает текст, иногда с таблицей или markdown-разметкой, но логика экрана все равно остается заранее прошитой в продукте. Generative UI двигается дальше: модель может сама выбрать нужный компонент, собрать форму, показать карточку с инсайтом, график или навигацию по результатам. Это особенно полезно там, где интерфейс зависит не от одного сценария, а от контекста запроса, типа данных и следующего шага пользователя.

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

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

Три модели сборки

Автор разбирает три архитектурных подхода, и у каждого свой баланс между свободой модели, качеством UX и рисками для продукта. Самый очевидный путь — дать модели сгенерировать HTML и сразу отрисовать его в браузере. Это быстро для прототипа, но в продакшене такой вариант хрупок: модель легко ломает дизайн-систему, придумывает несуществующие атрибуты и вносит дополнительные вопросы по безопасности.

HTML-генерация — максимум свободы для модели, минимум контроля для команды продукта. Декларативный подход — агент описывает интерфейс через JSON и словарь компонентов, а клиент рендерит его в рамках своего UI-kit. * Выбор готового компонента — агент не верстает интерфейс, а подставляет данные в заранее собранные карточки, графики и формы.

Средний путь здесь — декларативная сборка, где агент не пишет код напрямую, а работает как компоновщик из атомарных элементов. В статье отмечается, что этот подход формализует протокол A2UI от Google, опубликованный в декабре 2025 года. Самый управляемый вариант — библиотека готовых компонентов: свободы у модели меньше, зато интерфейс остается предсказуемым.

Такой подход хуже подходит для бесконечного числа сценариев, но лучше всего работает там, где UX важнее импровизации.

Почему выбрали Tambo Практический кейс в статье связан с ИИ-ассистентом для маркетинговой аналитики.

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

В итоге автор остановилась на Tambo — open source-фреймворке для React, который работает по модели готовых компонентов и добавляет жизненный цикл, состояния и двустороннюю связь между UI и агентом через AG-UI. Компоненты регистрируются с описаниями и Zod-схемами пропсов, после чего агент выбирает, что показать, и может стримить данные в компонент в реальном времени. Рабочая область в этой схеме остается стабильной и заранее собранной, а все генеративные элементы — графики, карточки, быстрые сводки — живут в чате и не ломают основной UX.

Что это значит

Generative UI перестает быть экспериментом для демо и превращается в прикладной слой ИИ-продуктов. Главный вывод простой: выбирать нужно не самый модный фреймворк, а степень свободы, которую ты готов отдать модели без ущерба для интерфейса, безопасности и логики работы пользователя.