Зачем нужны интерфейсы, если есть LLM

От командной строки к интерфейсу — и снова назад

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

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

Способ спросить и способ получить ответ — две разные задачи

Когда говорят про LLM-интерфейс, представляют чат: текст → ответ-текст. На самом деле это два независимых параметра. Запрос может быть произнесён голосом — длинные фразы с несколькими условиями быстрее сказать, чем напечатать с телефона. Фразу «покажи проекты моего блока, где за последний месяц вырос срок поставки, но при этом не менялся скоуп» можно сказать практически без остановки.

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

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

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

Четыре способа реализовать это

№1. Controlled generative UI

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

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

Дизайнер и разработчик полностью контролируют внешний вид, поведение, доступность и состояния ошибок. Модель только выбирает представление и передаёт ему данные. Этот подход реализован в CopilotKit.

№2. Декларативное описание из строительных блоков

Модель получает не готовые экраны, а базовые элементы: контейнер, текст, метрику, таблицу, карточку, график, кнопку, форму. Возвращает декларативное описание интерфейса, клиент собирает его из своего UI-kit, сохраняя дизайн-систему везде: веб, мобильное приложение, другие клиенты. Один и тот же ответ можно отрисовать в разных средах. Этот подход развивает A2UI от Google.

№3. MCP Apps с готовым интерфейсом

Инструмент возвращает интерактивный интерфейс, который клиент показывает внутри iframe в песочнице. Можно использовать обычные веб-технологии: HTML, CSS, JavaScript, делать формы, графики, карты, многошаговые сценарии. Это поддерживают разные MCP-клиенты и приложения внутри ChatGPT. Здесь внешний вид сильнее контролирует поставщик инструмента, а не клиент.

№4. Полная генерация HTML/CSS/JavaScript

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

Как изменится разработка

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

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