Что такое Generative UI по определению спикера?

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

Является ли главной целью GenUI избавление от сложных if-ов?

Нет, это лишь приятный побочный эффект; цель — персонализация UX. Верно. Спикер подчёркивает: убирать if-ы не цель, это побочный эффект. Цель — умно компоновать и персонализировать UX.

Зачем у компонентов в каталоге нужны текстовые описания?

Они работают как промпт: по ним модель решает, когда показать компонент. Да, описания фактически являются промптом для модели — дают ей контекст, когда и зачем выбрать компонент.

Чем tool calls мощнее простого выбора компонентов по id?

Модель не только выбирает компонент, но и заполняет его props через input schema. Верно. input schema задаёт форму props, которые модель заполняет (required, placeholder, min/max) — это наполнение, а не только выбор.

Зачем спикер выбрал модель Claude Haiku?

Ради скорости — GenUI добавляет латентность, и быстрая модель важна. Да, Haiku взяли ради скорости. Более продвинутую модель спикер советует брать только если задача правда этого требует.

Какую библиотеку используют для type-safe структурированного вывода модели?

Zod. Верно. Zod описывает type-safe структуру ответа (например, greeting + массив widgets), чтобы формат был стабильным.

Когда, по словам спикера, стоит ОСТАВАТЬСЯ детерминированным, а не брать GenUI?

В критичных, регулируемых, высокорисковых потоках, где важны предсказуемость, латентность и стоимость. Именно. Для критичных/регулируемых потоков, где нужна предсказуемость и тестируемость, лучше детерминированный UI.

Какая область названа самым безопасным стартом для GenUI?

Доступность (accessibility). Верно. Доступность даёт максимум пользы при минимуме риска — например, упрощение интерфейса для слабовидящих.

Почему Jira-подобный дашборд назван плохим кандидатом для GenUI?

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

Как GenUI пересекается с RAG?

Это один пайплайн: кеширование сгенерированного и работа с закрытым internal-контекстом. Да. Спикер видит сильное пересечение: кеширование ранее сгенерированного UI и закрытый внутренний контекст — тот же пайплайн, что в RAG.

Какое главное правило применения GenUI формулирует спикер?

Использовать, когда это улучшает UX, а не потому что можешь. Именно. Как и со всем в AI — применять, когда реально улучшает интерфейс и опыт, а не ради факта, что это возможно.

Разборы · Статья: 18 июня 2026 г. · Видео: 12 июня 2026 г. · 1:00:04

Generative UI: интерфейс, который собирает себя сам под пользователя

Name: Frontend Nation 2026: Generative UI: Building Apps That Compose Themselves
Uploaded: 2026-06-12T00:00:00.000Z
Duration: 1 h 4 s
Description: Воркшоп Alex Garrett-Smith с Frontend Nation 2026: что такое Generative UI, как AI компонует интерфейс из готовых компонентов через widget catalog, Zod и tool calls — и где это уместно, а где вредно.

Воркшоп Alex Garrett-Smith с Frontend Nation 2026: что такое Generative UI, как AI компонует интерфейс из готовых компонентов через widget catalog, Zod и tool calls — и где это уместно, а где вредно.

Программирование ИИ Дизайн

Смотреть на YouTube

Frontend Nation 2026: Generative UI: Building Apps That Compose Themselves

Unlearn (воркшоп Alex Garrett-Smith) · 1:00:04

Главы видео — нажми, чтобы перейти к моменту 9

Коротко

Generative UI — это интерфейс, который AI компонует под конкретного пользователя из готовых компонентов, а не наоборот. Главный поворот: цель не в том, чтобы убить сложные if-ы (это лишь приятный побочный эффект), а в умной персонализации UX — и применять это стоит только там, где оно реально улучшает опыт.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:23

Показать текст выжимки

Если коротко, это разбор про Generative UI — интерфейс, который ИИ собирает под конкретного человека из готовых компонентов, а не показывает всем один и тот же экран. Знакомый пример — обычный поиск. На запрос «пять плюс пять» вы видите просто число, а на «маршруты для пробежки рядом» — карточки с местами. Один поиск, но интерфейс разный, потому что разный контекст. Самое важное здесь — развеять главное заблуждение. Цель Generative UI не в том, чтобы убрать сложные условия из кода. Меньше ветвлений — это лишь приятный побочный эффект. Настоящая цель — умно персонализировать опыт под пользователя. Как это работает в основе. Мы даём модели набор компонентов, у каждого — текстовое описание, и оно работает как промпт. Дальше просим выбрать несколько штук и расставить по порядку. Получаем структурированный ответ и рендерим его. По сути мы спрашиваем у ИИ: что показать именно этому человеку? Уровень повыше — это tool calls. Здесь модель не просто выбирает компонент, а заполняет его свойства: например, делает поле необязательным или добавляет подсказку. Из одной фразы пользователя может собраться готовая форма под его запрос. Теперь о главном на практике — когда это уместно. Generative UI хорош на открытых, персонализированных поверхностях, где ввод у разных людей сильно отличается: онбординг, доступность, дашборды. А вот в критичных и регулируемых сценариях, где важны предсказуемость, скорость и цена, лучше остаться со статичным интерфейсом. Правило простое: применяй, когда это реально улучшает опыт, а не потому что можешь. И стоит честно держать в голове оговорки. Подход недетерминированный, его трудно тестировать, он дороже и медленнее обычного, и ему нужны ограничители. Технология совсем новая — даже толковых примеров пока почти не найти. И напоследок мысль под другим углом: Generative UI — это не про красивую генерацию экранов, а про новый способ задавать вопрос «что сейчас нужно этому пользователю» и доверять ответ модели.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

Обычно мы делаем один интерфейс на всех и обвешиваем его условиями: «если роль маркетолог — покажи это, если разработчик — то». Чем больше вариантов, тем больше путаницы, и всё равно интерфейс остаётся «тупым». Generative UI переворачивает подход: мы даём AI набор готовых блоков с описаниями, рассказываем контекст (что человек ищет, что мы о нём знаем) и спрашиваем — «что из этого показать и в каком порядке?». Модель сама собирает страницу под человека. Знакомый пример — Google: на запрос «5+5» он покажет просто число, а на «маршруты для пробежки рядом» — карточки с местами. Тот же поиск, но интерфейс ответа разный.

Как ребёнку

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

Аналогия — «это как…»

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

Зачем это мне

Интерфейсы перестают быть «один на всех» и начинают подстраиваться под человека — это меняет онбординг, доступность, дашборды и поиск. Для фронтендера это новый инструмент: вместо лабиринта if-ов модель собирает UI сама, но за гибкость платишь предсказуемостью, скоростью и деньгами, поэтому важно понимать, где это уместно, а где — вред.

Для тех, кто в теме

Паттерн один, но в двух формах: (1) свободный ввод пользователя → tool calls → модель выбирает и наполняет компоненты; (2) известный профиль пользователя (returning, активность вечером, любимая фича) → модель заполняет предопределённую схему UI и упорядочивает виджеты. Базовый уровень — widget catalog с id + описаниями (описание = промпт), system prompt «pick 5-7 widgets in order», Zod-схема структурированного вывода (greeting + widgets[]), Vercel AI SDK, Claude Haiku ради латентности. Продвинутый — tool calls, где input schema = форма props, которые заполняет модель (required:false, slider min/max/step, diet:vegan), плюс стриминг рассуждения. Кеширование результата экономит токены (пересечение с RAG). Спикер не знал термина SDUI — это по сути его близкий родственник. Хранить сгенерированное — как loose JSON; «в GenUI почти нечего хранить, суть в том, что на поверхности».

Оценка видео

Чем выше — тем больше пользы на минуту

4.3

средняя из 5

Актуальность информации 5.0

Тема свежая до предела: спикер честно говорит, что по запросу «GenUI» в Google почти нет хороших примеров. Vercel AI SDK, Zod, tool calls — актуальный стек 2026.

Содержательность 4.0

Плотная польза: два рабочих паттерна, демо на Vue, чёткие критерии «когда применять». Минус — технические сбои со звуком и несколько раз повторённый разбор кода.

Инновационность идей 4.0

Сам GenUI — новый угол, но строится на известных кирпичах (structured output, tool calls). Ценность — в систематизации и честных границах применимости.

Применимость на практике 4.0

Есть репозитории, два упражнения, конкретный стек и явные правила «когда НЕ надо». Можно повторить в выходные. Минус — нет ответа на тесты недетерминированного вывода и хранение.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для фронтенд-разработчиков 5 /5

Ядро аудитории: пошаговый паттерн GenUI на Vue — widget catalog с описаниями-промптами, system prompt, Zod-схема structured output, маппинг id→компоненты, рендер колонок. Прямо переносится в ежедневную работу.

Для full-stack-разработчиков 5 /5

Полный путь от фронта до бэка: API-роут, выбор модели (Claude Haiku), Vercel AI SDK, tool calls с input schema, где модель заполняет props (required/placeholder/min-max), и стриминг вызовов тулов.

Для продуктовых-инженеров 4 /5

Чёткий разбор «когда применять GenUI, а когда остаться детерминированным»: открытые/персонализированные поверхности против критичных, регулируемых и high-stakes флоу, где важны латентность, цена и тестируемость.

Для ML-инженеров 3 /5

Полезны прикладные паттерны structured output через Zod, guardrails в промпте, обсуждение замены foundation-модели маленькой внутренней и пересечение с RAG/кешированием — но без обучения моделей, на уровне интеграции.

Для продакт-менеджеров 3 /5

Сценарии ценности (адаптивный онбординг под цель пользователя, дашборд по роли, переупорядочивание настроек, help-виджет «действие вместо инструкции») и трезвая рамка «использовать, только когда улучшает UX».

Для UX-дизайнеров 3 /5

Концепция «UI адаптируется под пользователя, а не наоборот»: композиция интерфейса из готовых компонентов по профилю/намерению, примеры Google AI mode и travel-booking. Кода много, дизайн-практик мало.

Для специалистов-по-доступности 3 /5

Автор прямо называет доступность самым безопасным и выигрышным применением GenUI: интерфейс упрощается под нужды пользователя (например, при слабом зрении) — то, что трудно покрыть набором if-ов.

Для QA-инженеров 2 /5

Поднимается ключевая боль — как тестировать недетерминированный вывод и оценивать корректность по «намерению пользователя», но конкретной методики тестирования воркшоп не даёт, только направление.

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 GenUI — не про убийство if-ов 2:51

Избавление от сложных условных конструкций — приятный побочный эффект, а не цель. Цель — умно компоновать то, что видит пользователь, и персонализировать UX. Если вы тянетесь к AI просто чтобы убрать if — это неверная мотивация.

02 if-ы лишены интеллекта — в этом их потолок 2:40

Можно навешивать сколько угодно условий, чтобы UI казался спроектированным под человека, но по-настоящему умным он не станет. Интеллект интерфейса возможен только когда решение «что показать» принимает модель.

03 Описание компонента — это и есть промпт 5:44

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

04 Tool calls дают не выбор, а наполнение 10:00

Переход от «модель выбирает id компонента» к «модель заполняет его props через input schema» — это качественный скачок. Теперь AI не просто решает что показать, а задаёт required, placeholder, min/max, diet:vegan — реально интеллектуальная компоновка.

05 В GenUI почти нечего хранить 24:50

Контринтуитивно: вся суть подхода в том, что результат живёт на поверхности, в моменте. Сгенерированную раскладку, если надо, держат как loose JSON, а данные компонента — его собственный изолированный мирок.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«Это интерфейс, который адаптируется под пользователя, а не пользователь под интерфейс.»

Alex Garrett-Smith Определение GenUI 1:48

«Набор if-ов лишён интеллекта. Можно добавлять сколько угодно сложности, но по-настоящему умным интерфейс мы так и не сделаем.»

Alex Garrett-Smith Про потолок условных конструкций 2:49

«GenUI — это не про убийство сложных условий. Это приятный побочный эффект, а не цель.»

Alex Garrett-Smith Главное уточнение о цели подхода 2:51

«По сути мы спрашиваем у AI: что мне показать пользователю?»

Alex Garrett-Smith Суть базового механизма 4:35

«Мы управляем не только тем, какие компоненты показаны, но и тем, какие у них значения.»

Alex Garrett-Smith Про tool calls и props в form-builder 16:44

«Как и со всем в AI: используй это, когда оно улучшает UI и UX, а не просто потому что можешь.»

Alex Garrett-Smith Главное правило применения 18:10

«Если загуглить GenUI, вы почти не найдёте результатов. Это всё ещё очень рано.»

Alex Garrett-Smith О зрелости технологии 18:23

«В GenUI почти нечего хранить, потому что весь его смысл — в том, что на поверхности.»

Alex Garrett-Smith Ответ на вопрос про хранение в БД 24:50

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

Начни с доступности — самый безопасный вход в GenUI

вечер получишь реальную пользу от GenUI без риска сломать критичные сценарии

По словам спикера, доступность (accessibility) — область, где GenUI приносит максимум пользы при минимуме риска: например, упрощение интерфейса для людей со слабым зрением. Это безопаснее, чем переставлять критичные потоки.

Опиши компоненты так, будто пишешь промпт

1 час модель чаще выбирает правильные блоки, меньше промахов

Каталог виджетов модель читает как инструкцию. Не ограничивайся именем CampaignPerformance — добавь внятное описание «когда и зачем» показывать этот блок. Это напрямую влияет на качество выбора.

Что делать

1 Выпиши все компоненты, которые модель может показать.
2 Каждому дай уникальный id.
3 К каждому добавь описание-промпт: в какой ситуации его уместно показать.
4 Передай весь каталог в system prompt модели.

Возьми Zod-схему для type-safe вывода

30 минут перестанешь парсить непредсказуемый JSON руками

Чтобы получать от модели стабильный формат, опиши структуру ответа Zod-объектом (например, greeting + массив widgets с id). Тогда ответ приходит в одном и том же виде каждый раз и его можно безопасно рендерить.

Выбери быструю модель ради латентности

5 минут интерфейс собирается заметно быстрее, меньше раздражения у пользователя

Спикер сознательно взял Claude Haiku — он очень быстрый. GenUI и так добавляет задержку относительно статики, поэтому скорость модели критична. Более умную модель бери только если задача правда требует.

Кешируй сгенерированный UI, чтобы экономить токены

пара часов перестанешь платить за повторную генерацию того же самого

Если раскладка зависит от профиля пользователя, не дёргай AI на каждый заход. Сгенерировал — закешировал — переиспользуешь. Это прямое пересечение с RAG-подходом.

Используй низкоприоритетные tool calls для «приятностей»

20 минут интерфейс выглядит богаче, но не ломается, если второстепенный блок не пришёл

Не всё в UI одинаково важно. В примере с путешествием погода добавляется последним tool call'ом как украшение. Помечай такие блоки как необязательные — они дополняют экран, но не определяют его суть.

Управляй полями через props, а не плодя компоненты

час одна форма подстраивается под любой запрос без десятка вариантов компонента

Input в форме — это не просто input: он может быть required или нет, иметь maxLength, placeholder. Через input schema модель сама заполняет эти props по запросу («don't require phone number» → required:false).

Заложи guardrails прямо в промпт

вечер снизишь шанс, что модель покажет что-то некорректное или юридически опасное

GenUI недетерминирован, поэтому защита нужна с самого начала: правила в промпте для конкретных компонентов, предупреждение пользователя «это сгенерировано AI», бэкап-вариант и мониторинг фидбэка. Warning-компонент (например, на запрос marital status) — пример встроенного guardrail.

Сценарии применения

Как разные люди применяют это на практике

Я как фронтенд-разработчик

Проблема: дашборд оброс десятками вложенных if-ов под роли и условия, поддерживать невозможно

Хочу: собирать интерфейс умнее, без лабиринта условий

Поможет: понять, как отдать компоновку модели через widget catalog + Zod и где это оправдано

Я как продуктовый дизайнер

Проблема: один интерфейс на всех не учитывает разные цели пользователей

Хочу: персонализировать UX, не рисуя сто статичных вариантов

Поможет: увидеть паттерны GenUI и понять, какие поверхности (онбординг, настройки) стоит адаптировать

Я как специалист по доступности

Проблема: адаптация интерфейса под слабовидящих традиционными средствами громоздка

Хочу: автоматически упрощать UI под нужды пользователя

Поможет: узнать, что доступность — самый безопасный и полезный старт для GenUI

Я как основатель SaaS-стартапа

Проблема: новые пользователи теряются в сложном продукте на онбординге

Хочу: онбординг, подстраивающийся под цель конкретного пользователя

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

Я как тимлид, отвечающий за бюджет на AI

Проблема: боюсь, что генерация UI на каждый заход разорит на токенах и замедлит приложение

Хочу: понять реальную цену и когда оно того стоит

Поможет: получить критерии «когда оставаться детерминированным» и приём кеширования результата

Я как QA-инженер

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

Хочу: оценивать корректность недетерминированного вывода

Поможет: услышать честный разбор: guardrails в промпте, предупреждение пользователя, бэкап и мониторинг фидбэка

Я как разработчик, знакомый с RAG

Проблема: не вижу, как новые AI-паттерны связаны с тем, что уже умею

Хочу: понять пересечение GenUI и RAG

Поможет: увидеть, что кеширование сгенерированного UI и закрытый internal-контекст — тот же пайплайн, что в RAG

Я как разработчик travel/booking-сервиса

Проблема: набор экранов одинаковый, но данные и порядок всё время разные

Хочу: менять порядок и наполнение карточек под запрос пользователя

Поможет: узнать, что приложения со стабильным набором компонентов — идеальный готовый кейс для GenUI

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод

Предпосылка Статичный UI обвешивается условиями 2:10

Любой нетривиальный дашборд или планировщик поездки быстро обрастает вложенными if-ами: погода, бюджет, дети, диеты — и превращается в неуправляемую кашу.
Аргумент if-ы лишены интеллекта 2:38

Сколько сложности ни добавляй, условные конструкции не сделают интерфейс по-настоящему умным — это их фундаментальный потолок.
Аргумент Цель GenUI — не убрать if-ы, а персонализировать UX 2:51

Избавление от условий — приятный побочный эффект. Настоящая цель — умно компоновать то, что видит пользователь, силами AI.
Пример Пример: Google AI mode 3:05

На «5+5» показывает простой ответ, на «маршруты для пробежки» или «лучшие камеры» — карточки-компоненты. Один поиск, разный UI под контекст.
Аргумент Базовый механизм: prompt + каталог → выбор компонентов 4:23

Передаём модели контекст и набор компонентов с описаниями, получаем через Zod упорядоченный список id и рендерим. Суть — «спрашиваем AI: что показать пользователю?».
Аргумент Продвинутый уровень: tool calls + props 9:57

Регистрируем tools с input schema; модель не только выбирает компонент, но и заполняет его props (required, diet:vegan, min/max). Интеллект сидит на верхнем уровне.
Вывод Применять только когда улучшает UX 17:38

Брать GenUI на открытых/персонализированных поверхностях с разным вводом; оставаться детерминированным на критичных, регулируемых, латентно- и стоимостно-чувствительных потоках.
Вывод Технология очень ранняя 18:21

Паттерны и инструменты ещё эволюционируют, материалов мало; хорошие примеры есть у Google и Flutter. Это вкус возможного, а не зрелый стандарт.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

О чём это

Это воркшоп Alex Garrett-Smith (technical education lead в Bitterbrains, проект Unlearn) с конференции Frontend Nation 2026 про Generative UI (он же GenUI) — интерфейс, который адаптируется под пользователя, а не пользователь под интерфейс.

Главная идея: вместо одного статичного UI на всех, обвешанного вложенными if-ами, мы даём AI набор готовых компонентов с описаниями + контекст (что человек ищет, что мы о нём знаем) и спрашиваем — «что показать и в каком порядке?». Знакомый пример — Google AI mode: на «5+5» он покажет простой ответ, на «маршруты для пробежки» — карточки-компоненты. Один поиск, разный UI.

Воркшоп разбирает два уровня на живом коде (Vue):

Базовый — widget catalog с id и описаниями-промптами, system prompt «выбери 5–7 виджетов по порядку», Zod-схема для type-safe вывода, Vercel AI SDK + Claude Haiku. Модель возвращает упорядоченные id → маппинг на компоненты → рендер.
Продвинутый — tool calls + props: модель не просто выбирает компонент, а заполняет его свойства через input schema (required, placeholder, min/max). Примеры: travel-booking, form-builder, warning-компонент.

Важная честность автора: GenUI не про убийство if-ов (это побочный эффект), а про персонализацию UX; применять стоит только там, где это улучшает опыт. В критичных/регулируемых потоках лучше остаться детерминированным. Подход недетерминированный, дороже, медленнее, трудно тестируется и требует guardrails — технология очень новая.

⚠️ Критический разбор спорных мест (доступность как «безопасный старт», prompt injection, «консистентный формат») — в блоке ниже.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 7

Шаг 1. Выбери подходящую поверхность Возьми область, где ввод сильно варьируется между пользователями и UI собирается из многих кусков (онбординг, дашборд, поиск). Для старта — доступность как самый безопасный кейс.
Шаг 2. Собери каталог компонентов с описаниями Каждому компоненту — уникальный id и описание-промпт «когда и зачем показывать». Описания напрямую управляют выбором модели.
Шаг 3. Опиши структуру ответа через Zod Зафиксируй type-safe схему вывода (например, greeting + массив widgets), чтобы ответ модели всегда приходил в одинаковом формате.
Шаг 4. Подключи Vercel AI SDK и быструю модель Передай system prompt («pick 5-7 widgets in order») и каталог; для латентности возьми быструю модель вроде Claude Haiku.
Шаг 5. Перейди к tool calls, если нужны props Зарегистрируй tools с input schema, чтобы модель не только выбирала, но и наполняла компоненты (required, placeholder, slider min/max/step).
Шаг 6. Добавь guardrails и предупреждения Заложи правила в промпт, warning-компоненты для опасных запросов, пометку «сгенерировано AI» и бэкап-вариант.
Шаг 7. Закешируй результат и мониторь фидбэк Не дёргай AI на каждый заход — кешируй раскладку под профиль (пересечение с RAG). Следи за обратной связью пользователей, чтобы ловить промахи.

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 11 Верно: 0

1. Что такое Generative UI по определению спикера?
2. Является ли главной целью GenUI избавление от сложных if-ов?
3. Зачем у компонентов в каталоге нужны текстовые описания?
4. Чем tool calls мощнее простого выбора компонентов по id?
5. Зачем спикер выбрал модель Claude Haiku?
6. Какую библиотеку используют для type-safe структурированного вывода модели?
7. Когда, по словам спикера, стоит ОСТАВАТЬСЯ детерминированным, а не брать GenUI?
8. Какая область названа самым безопасным стартом для GenUI?
9. Почему Jira-подобный дашборд назван плохим кандидатом для GenUI?
10. Как GenUI пересекается с RAG?
11. Какое главное правило применения GenUI формулирует спикер?

Словарь терминов

Понять незнакомое простым языком

Показать 12 терминов

Generative UI (GenUI): Подход, при котором интерфейс собирается AI под конкретного пользователя из готовых компонентов, вместо одного статичного UI на всех.
Tool calls: Заранее зарегистрированные «инструменты» с описанием и схемой входа; модель вызывает нужные и заполняет их данными — так она не только выбирает компонент, но и наполняет его.
Props: Параметры компонента (например, required, placeholder, min/max). В GenUI их заполняет модель через input schema по контексту запроса.
Input schema: Описание формы данных (props), которые модель должна заполнить при вызове tool. Задаёт, какие значения и какого типа компонент ожидает.
Zod: Библиотека для описания type-safe структур данных. В GenUI ею фиксируют формат ответа модели, чтобы он всегда приходил предсказуемым.
Vercel AI SDK: Инструментарий для интеграции AI в приложения: упрощает отправку запросов модели, structured output и tool calls.
Schema (схема вывода): Заданная заранее структура ответа модели (например, greeting + массив виджетов), благодаря которой результат можно безопасно рендерить.
Widget catalog: Набор доступных компонентов с id и описаниями, который передаётся модели; описания работают как промпт для выбора.
Guardrails: Ограничения и защита для недетерминированного вывода: правила в промпте, предупреждения пользователю, бэкап-варианты, мониторинг фидбэка.
SDUI (Server-Driven UI): Подход, где структуру интерфейса задаёт сервер. Близкий родственник GenUI; спикер на воркшопе сам признался, что не знал этого термина.
RAG: Retrieval-Augmented Generation — подтягивание релевантных данных из базы/документов к запросу модели. Сильно пересекается с GenUI в части кеширования и закрытого контекста.
Structured output: Получение от модели ответа в заранее заданном машиночитаемом формате (по схеме), а не свободным текстом.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Спорно

GenUI назван «самым безопасным стартом» именно для доступности

Это спорно: динамический UI, который перестраивается AI, ломает предсказуемость и навигацию для скринридеров — для слепого пользователя «минута латентности и перестановка элементов» это регресс, а не помощь. Исследования (W3C AI Accessibility) отмечают, что подстройка под предполагаемую инвалидность часто ухудшает опыт, потому что потребность нельзя надёжно определить по данным. Спикер берёт самый рискованный кейс и называет его самым безопасным.

Преувеличение

«Очень сложно, чтобы это пошло сильно не так; пользователи не могут изменить твой промпт»

Преуменьшение. В demo вход формирует сам пользователь («include marital status», «I want a burger»), а это и есть канал prompt injection — вход и инструкции для модели смешиваются. OWASP ставит prompt injection на 1-е место среди LLM-рисков 2025, и его, в отличие от SQL-инъекций, нельзя надёжно закрыть валидацией схемы. Guardrails в системном промпте — не гарантия.

Упрощение

Zod structured output даёт «консистентный формат каждый раз»

Верно про синтаксис, но не про смысл. Валидная схема не значит корректный выбор компонента или адекватные props: когда хорошего значения нет, модель уверенно галлюцинирует (выдаёт «required: false» или min/max наугад). Структурная и семантическая корректность — разные свойства, и их смешение — дорогая ошибка в продакшене.

Спорно

Кэширование снимает проблему цены и латентности GenUI

Частично. Кэш работает только там, где набор входов конечен и повторяется; в по-настоящему персонализированных/open-ended сценариях (ровно те, для которых спикер и советует GenUI) каждый рендер уникален и кэш почти не помогает. Рекомендации «применяй на open-ended поверхностях» и «кэшируй» отчасти противоречат друг другу.

Упрощение

Ответы на ключевые вопросы (тестирование, оценка корректности, хранение) сведены к «это очень ново, я бы экспериментировал»

Честно, но это и слабое место материала: тестируемость недетерминированного UI, eval-метрики и персистентность — не побочные детали, а то, что решает, поедет ли GenUI в продакшен. Производственная практика уже даёт конкретику (step-level трейсы, correct tool selection rate, schema-валидация), и без неё блок про продакшен остаётся на уровне намерений.

Однобоко

GenUI противопоставляется if-ам как «интеллект против отсутствия интеллекта»

Риторически сильно, но однобоко. If-statement детерминирован, бесплатен, мгновенен, тестируем и не ломает мышечную память — это не «отсутствие интеллекта», а другой профиль гарантий. Спикер сам это признаёт ниже (детерминизм в критичных потоках), но исходная рамка «if-ы тупые» завышает контраст.

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

Недетерминизм UI — это не баг, а новый класс A/B-тестов

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

Другой угол

А что если консистентность ценнее персонализации

Спикер оптимизирует под «UI под каждого». Но мышечная память, предсказуемость и узнаваемость бренда — тоже UX-ценности, которые ломаются при перестановке элементов. Возможно, сильнейший кейс GenUI не там, где интерфейс меняется максимально, а там, где он меняется минимально и незаметно — подбор дефолтов и порядок, а не пересборка экрана.

Смежная область

Тот же паттерн — это движок прогрессивного раскрытия в обучении

Widget catalog + модель, выбирающая что показать под контекст, — это ровно механика адаптивных образовательных систем и онбординга: показать следующий шаг по уровню ученика. GenUI-стек из воркшопа можно один-в-один переложить на тьюторы, чек-листы и интерактивные доки, где «компонент» — это учебный блок.

Смежная область

GenUI как фронтенд для observability и алертинга

Дашборды мониторинга страдают ровно от проблемы из воркшопа: десятки панелей, релевантна сейчас одна. Модель, собирающая дашборд под текущий инцидент (всплыли ошибки БД → наверх метрики БД и недавние деплои), — это adjacent-применение, где цена ошибки ниже, чем в регулируемых потоках, а выигрыш во времени реакции выше.

На стыке областей

На стыке GenUI и формальной верификации

Главная боль — недетерминизм и тестируемость. Решение может прийти не из ML, а из типов и контрактов: модель выбирает только из множества заранее верифицированных компонент-состояний, а property-based/snapshot-тесты покрывают комбинаторику, а не конкретный рендер. GenUI становится управляемым, когда AI работает в песочнице, чьи границы доказаны статически.