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

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

Так между человеком и программой появился слой, который мы сегодня называем интерфейсом. Но с появлением LLM интерфейсы становятся не нужны.

Давайте я вам это покажу. 

Человеку на самом деле не нужен интерфейс

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

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

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

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

Вот бы можно было бы не сообщать системе последовательность действий, а сразу сказать «Переведи Пете 5000» — то есть результат, который я хочу получит? 

Было бы славно, если бы вместо того, чтобы тужиться понять, как авторы программы разложили её возможности по экранам, меню, кнопкам и формам, можно было бы сразу сказать: «Покажи клиентов, которые раньше регулярно покупали, но последние 3 месяца перестали», чтобы система сама разобрала запрос на параметры, сопоставила с доступными данными, превратила в структурированный запрос и выдала результат.

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

Еще 10 лет назад на вопрос «А можно ли так сделать?», я бы услышал фразу из старой рекламы: «Нет, сынок, это фантастика». Но сейчас у нас есть LLM…

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

Запрос не обязан быть текстом, а ответ не должен быть сообщением

Когда мы говорим про LLM-интерфейс, обычно представляем чат: пользователь написал сообщение и получил сообщение в ответ. Это во многом следствие того, как мы сегодня пользуемся ChatGPT и похожими продуктами, но само взаимодействие не обязано выглядеть именно так.

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

А из того, что я задал вопрос голосом, совершенно не следует, что ответ тоже должен быть голосовым. Если я спрашиваю, как менялись расходы по категориям последние полгода, то мне не нужен двухминутный пересказ таблицы. Удобнее услышать: «За полгода потратили миллион рублей, основные категории — аренда, инфраструктура и подрядчики», а на экране получить диаграмму и таблицу с детализацией. Вот так это может выглядеть:

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

У интерфейса в такой модели появляется три независимых параметра: 

• как человек сформулировал запрос, 

• в каком виде лучше представить результат,

• и на каком устройстве его показать.

Сегодня эти вещи чаще всего связаны с одним устройством: если вопрос задан телефону, мы ожидаем ответ на телефоне, если говорим с колонкой, ждём ответа от колонки. 

Но вы же понимаете, что это скорее особенность существующих продуктов, чем техническое ограничение?

Представим простой сценарий. Я спрашиваю умную колонку: «Какие у нас были основные категории затрат за последние полгода?»

А колонка отвечает: «Всего потратили около миллиона рублей. Больше всего — на инфраструктуру, аренду и подрядчиков. Отправил разбивку на телефон».

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

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

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

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

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

Если я говорю: «Хочу тихий отель недалеко от центра, с хорошим завтраком, до 200 евро за ночь», мне удобно сформулировать условия словами. Результат при этом хочется увидеть в виде карточек с фотографиями, ценой, рейтингом и расположением на карте. Последовательное описание десяти отелей текстом будет хуже обычного интерфейса.

Аналогично с данными. «Покажи, как менялись продажи за последние два года и где есть аномалии» — хороший запрос на естественном языке. Ответ лучше показать графиком, а подробности — таблицей.

Поэтому противопоставление «Чат или GUI?» — это неправильная постановка вопроса. Скорее можно убрать обязательную связь между способом задать вопрос и способом получить ответ. Пользователь выбирает удобный способ объяснить задачу, а система — подходящий способ представить результат.

Такой подход уже можно реализовывать вполне обычными средствами.

Как это можно реализовать?

№1. Консервативный вариант — заранее подготовить компоненты интерфейса и разрешить модели выбирать между ними. 

Например, в продукте есть компоненты ExpenseChart, ComparisonTable, HotelCards, Map и Confirmation. Модель сама не рисует экран — она только определяет, что запрос пользователя требует сравнения расходов, вызывает нужный инструмент, получает данные и выбирает ExpenseChart вместе с ComparisonTable.

На фронтенд может приходить примерно такая структура:

{

  "component": "ExpenseBreakdown",
  "period": "6m",
  "data": [...],
  "groupBy": "category"

}

Фронтенд рендерит обычный компонент из UI-kit. Дизайнер и разработчик полностью контролируют внешний вид, поведение, доступность и состояния ошибок, а модель выбирает представление и передаёт ему данные.

Такой подход уже используется в инструментах для генерации интерфейсов. Разработчики заранее создают набор компонентов, например таблицы, графики и карточки, а ИИ выбирает подходящие и отображает их в зависимости от запроса пользователя. Например, в CopilotKit этот подход называется controlled generative UI — управляемая генерация интерфейса. ИИ не создаёт интерфейс с нуля, а собирает его из компонентов, предусмотренных разработчиками.

№2. Следующий вариант — дать модели не готовые экраны, а набор строительных блоков. Например, контейнер, текст, метрику, таблицу, карточку, график, кнопку и форму. Модель возвращает декларативное описание интерфейса, а клиент собирает его из собственного UI-kit.

Такую идею сейчас развивает A2UI от Google. Агент передаёт декларативное описание того, что нужно показать, а клиент отображает это своими компонентами. Один и тот же ответ можно отрисовать средствами веба, мобильного приложения или другого клиента, сохранив его дизайн-систему.

Для большинства продуктовых систем этот вариант мне кажется особенно интересным. Мы по-прежнему контролируем набор допустимых компонентов и их поведение, но перестаём заранее проектировать все возможные комбинации этих компонентов в виде отдельных экранов.

№3. Передавать вместе с инструментом готовый небольшой веб-интерфейс. Например, MCP Apps позволяет инструменту вернуть интерактивный интерфейс, который клиент показывает внутри iframe в песочнице. Там можно использовать обычные веб-технологии и делать формы, графики, карты, панели и многошаговые сценарии. Такой подход уже поддерживают разные MCP-клиенты; на нём же основана возможность приложений внутри ChatGPT.

Здесь есть важное отличие от варианта с UI-kit. В декларативном подходе внешний вид в основном контролирует клиент. В MCP App интерфейс сильнее контролирует поставщик конкретного инструмента. Если я подключаю сервис бронирования, он может принести с собой собственный интерфейс выбора отелей. Если строю внутреннюю аналитику в единой корпоративной системе, вероятно, удобнее отдавать описание интерфейса и собирать его из корпоративной дизайн-системы.

№4. Наконец, можно разрешить модели генерировать HTML, CSS и JavaScript полностью на лету. Такие реализации тоже существуют. Это даёт максимальную свободу, но вместе с ней появляется больше вопросов к качеству, безопасности, стабильности поведения и визуальной целостности. Для прототипа или редкой задачи это может быть удобно, но делать такой режим основой критичной корпоративной системы я бы не стал.

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

Как изменится разработка продукта?

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

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

Если точкой входа становится намерение, структуру можно строить иначе. Бэкенд предоставляет операции над данными, UI-kit — способы показать результат, а LLM связывает пользовательский запрос с нужной операцией и подходящим представлением.

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

Система получает данные и показывает таблицу с динамикой. Пользователь выбирает одну команду и спрашивает, из-за чего произошло ухудшение. Появляется детализация по этапам. Затем он говорит: «Убери команды, где был большой реорг», и текущее представление обновляется.

Для такого сценария необязательно заранее проектировать отдельные страницы «Сравнение команд», «Динамика поставки», «Причины ухудшения» и «Фильтрация по оргизменениям». Нужны операции с данными и компоненты, способные показать их результат.

Это может заметно влиять на T2M (time to market). Но не потому, что фронтенд больше не нужен, а потому, что команде не требуется заранее реализовывать интерфейс для каждой возможной комбинации пользовательских действий. Инвестиции смещаются в API, семантику инструментов, качественный UI-kit и несколько универсальных способов отображения данных.

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

Есть сценарии, где результатом запроса является действие, а не информация

Например: «Если подрядчик пришлёт новую версию договора, сохрани её в папку проекта и сообщи, если сумма изменилась».

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

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

Свободная формулировка запроса не означает, что такой же свободной должна стать внутренняя система

Возьмём фразу «переведи Пете пять тысяч». Модель может определить, что речь идёт о переводе, извлечь сумму и найти подходящего получателя. Если получателей два, нужно попросить выбрать одного. Затем можно показать обычную форму подтверждения: Пётр Иванов, 5 000 рублей, такой-то счёт списания.

После подтверждения перевод должен выполнять обычный платёжный сервис со своими лимитами, проверками, журналом операций и правилами доступа. LLM здесь не должна решать, можно ли списывать деньги, и тем более самостоятельно менять правила операции.

То же относится к корпоративным системам. Если пользователь спрашивает «покажи проблемные проекты», модель должна иметь формальное описание доступных метрик или использовать инструмент, в котором понятие «проблемный» определено. Если запрос неоднозначный, лучше уточнить критерий, чем позволить модели самой придумать бизнес-определение.

Поэтому архитектурно мне нравится довольно скучное разделение. LLM работает с неоднозначностью человеческого языка. Бизнес-система остаётся детерминированной там, где это возможно.

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

Если интерфейс собирается в зависимости от запроса, UI-kit уже недостаточно быть каталогом кнопок, полей и цветов

Нужно описывать более крупные смысловые конструкции.

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

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

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

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

То есть проектирование смещается от конкретной страницы к правилам сборки интерфейса.

Обычные приложения всё равно останутся

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

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

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

Для новых продуктов можно идти ещё дальше и не строить большую структуру экранов заранее. Сначала определить доменные возможности, API и UI-kit, а уже затем смотреть, какие устойчивые интерфейсы появятся из реального поведения пользователей.

От экранов к намерениям

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

LLM позволяют начать «с конца»:

• Пользователь сообщает, что он хочет получить или сделать. 

• Запрос может быть текстовым или голосовым, а ответ — текстом, голосом, таблицей, графиком, картой или небольшим интерактивным интерфейсом. 

• При необходимости этот интерфейс может появиться вообще на другом устройстве.

Дальше продукт всё равно состоит из вполне знакомых частей: API, бизнес-логики, прав доступа, UI-kit и клиентов на разных устройствах, но добавляется слой, который умеет сопоставить свободно сформулированное намерение пользователя с этими возможностями.

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

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