Transcription
[музыка] >> Всем привет. Итак, я знаю, что я тот человек, который стоит между вами и вашим обедом. И, но это будет очень интересный разговор, который объединит предыдущие два доклада с будущим. И именно об этом я хочу поговорить сегодня. Итак, в ноябре 2022 года мы обычно шли в ChatGPT и просили ChatGPT создать компонент. И мы просто копировали и вставляли. Вам приходилось отвечать в блоках кода. Затем, знаете, снова исправляли, повторяли. И это то, что я называю кодированием бедняка. И мы прошли долгий путь. Это как бы работало. Это было очень захватывающе. Вы могли заставить модели фактически создавать для вас какой-то пользовательский интерфейс. И я уверен, что они не напишут код лучше меня, верно? И затем вещи улучшились очень, очень быстро, очень, очень быстро. То, что произошло в прошлом году, и если вы осведомлены о том, что произошло в последние месяцы 2025 года, это было это ускорение, невероятная точка перегиба, где все изменилось. И это войдет в учебники истории как то, что все изменилось очень быстро и сразу. И это отчасти связано с выпуском двух очень важных моделей, которые были 5.2 ChatGPT, извините. Это было, да, GPT 5.2 и Opus 4.5. И они были не просто очень хороши в большинстве задач, долгосрочных задачах. Они также были очень хороши в генерации пользовательского интерфейса с высокой точностью. И они создавали очень хороший рабочий пользовательский интерфейс. Иногда продуманный, иногда действительно, действительно хороший. И также очень быстрый. Теперь я испытал это, когда попробовал одну из этих моделей, попытался переписать свой блог. Я знаю, что люди использовали это более творческими способами, но я просто попробовал, знаете ли, один запрос, перепиши мой блог. И тогда он сделал это, чего я не просил. Он создал приятную, приятную поисковую строку с анимацией размытия, с доступностью из коробки. И тогда я понял, что за 3 года с момента выпуска ChatGPT до сегодняшнего дня мы прошли путь от, знаете ли, нескольких строк кода — это здорово. Это работает. О. И теперь он может писать фронтенд-код лучше меня. И, знаете, я не возражаю. Никакого эго. Это просто реальность. Итак, вот вопрос. Если эти модели так хороши в написании кода пользовательского интерфейса, почему мы все еще застряли в этой в основном старой парадигме в основном статических пользовательских интерфейсов? И где, где тот момент с Джарвисом, о котором мы говорили раньше? Где мои плавающие окна пользовательского интерфейса, которые появляются и исчезают? И почему мы еще не там? Итак, меня зовут Рубен Касас. Я старший инженер в Postman. И я изучаю пользовательский интерфейс и генеративный пользовательский интерфейс в течение последнего года, и я также работал с MCP-приложениями. И сегодня я хочу показать вам, что мы делаем сегодня и куда мы движемся в будущем. Итак, новость в том, что у нас есть новый компьютер. И, как сказал Андрей Карпатый, взаимодействие с этим новым компьютером похоже на разговор с терминалом. У вас есть прямой доступ к этой операционной системе. И графический интерфейс еще не изобретен. Это как будто мы в 70-х, когда все было просто текстом. И у нас есть супер-интеллект, но у нас нет зрелого языка интерфейса. И сегодня мы все еще пытаемся понять, что это за новый интерфейс для этого компьютера. И люди спрашивают, это чат? Я покажу вам, что мы делаем сегодня. И на самом деле это был очень недавний твит на прошлой неделе, где люди жаловались, что большинство SaaS-компаний добавляют чат на свои домашние страницы, и все просто размещают чат везде. И это нормально. У меня нет проблем с чатом. Это не окончательный пользовательский интерфейс. Пока что это нормально. Но вопрос в том, если это не чат, то что тогда является интерфейсом для этого компьютера? С другой стороны, как мы видели с MCP-приложениями, есть [кашляет] еще одна мысль, которая заключается в том, что у нас будет одно приложение или супер-приложение, которое будет править всеми. И вот здесь и появляются MCP-приложения, где вместо того, чтобы размещать все эти окна чата на ваших домашних страницах и в каждом приложении, которое вы используете, у нас будет супер-приложение, такое как ChatGPT или Claude или Gemini, где вы будете взаимодействовать с большей частью пользовательского интерфейса и веб-сайтов, которые у нас есть сегодня. И это хорошо. Это то, как мы используем MCP-приложения сегодня для рендеринга стороннего пользовательского интерфейса внутри одной агентской среды. Теперь эти два варианта могут быть действительными. И я считаю, что это часть эволюции в поиске того, что представляет собой новый интерфейс для этого компьютера. И, честно говоря, я не знаю, какой из них будет окончательным. Потребители нам скажут. Но одно ясно: это два разных вопроса. Вопрос в том, где выполняется пользовательский интерфейс? В этом случае, это сторонний пользовательский интерфейс, супер-приложение или, в данном случае, чат везде? Но самое интересное — это то, что генерирует модель. И именно об этом я хочу поговорить сегодня в плане того, как мы генерируем этот пользовательский интерфейс. И мы видели это. У нас в основном статический, декларативный и генеративный пользовательский интерфейс. И я кратко опишу этот. Итак, начнем с подхода к запуску пользовательского интерфейса с использованием статических компонентов, который сегодня используют большинство агентов. Агент — это просто оркестратор. Агент совершает вызов инструмента через MCP-приложения или прямой вызов инструмента агента. Затем у нас будут некоторые параметры и данные, передаваемые предопределенным статическим компонентам, созданным разработчиками. И это очень похоже на то, что мы делали последние 20 лет с пользовательским интерфейсом. И затем клиент отображает компонент. И если вы посмотрите сюда, это очень похоже на то, как сервер отправляет некоторые данные, а затем пользовательский интерфейс будет отображаться клиентом. Но в этом случае агент будет генерировать эти данные и свойства для этого. И некоторые примеры, которые у нас есть сегодня, — это протокол AGUI. У них есть SDK, где вы можете зарегистрировать клиентский инструмент, который соответствует компоненту React. Вызов инструмента получит некоторые свойства. Эти свойства будут сопоставлены со статическим компонентом, который затем будет отображен пользователю. Другой пример — Goose. Goose — это клиент MCP, где вы можете попробовать большинство функций MCP. И Goose имеет эту действительно интересную функцию под названием Goose Auto Visualizer, где вы можете просто передать любой тип данных в Goose, и Goose попытается сопоставить эти данные, организовать их, а затем передать набору предопределенных компонентов, которые команда Goose создала. В этом случае у нас есть несколько интересных компонентов, которые вы можете использовать для визуализации ваших данных. Итак, это статический способ. Это самый распространенный способ генерации пользовательского интерфейса сегодня. Но я видел эволюцию в последнее время, которую мы теперь называем декларативным пользовательским интерфейсом. И декларативный пользовательский интерфейс выводит это на новый уровень. Итак, у нас по-прежнему будут некоторые предопределенные статические компоненты, которые создают разработчики, и они содержат вашу систему дизайна и все эти компоненты, которые у вас есть. Но вместо того, чтобы агент просто передавал свойства и данные, агент использует дескриптор, который может быть либо JSON, либо YAML. Или я также видел Python с быстрыми MCP, где у них есть дескриптор на Python, который сопоставляется с этими предопределенными статическими компонентами. И затем у вас есть этот движок трансляции и рендеринга, который берет эти дескрипторы и преобразует их в окончательный пользовательский интерфейс. Чем это отличается? Ну, в этом случае это более динамично. Это все еще статические компоненты, но это более персонализированно. И если вы посмотрите на это и подумаете, что это может выглядеть знакомо, это потому, что это не ново. Netflix делает это уже давно с эпохи персонализации и серверного рендеринга пользовательского интерфейса, когда вы заходите на домашнюю страницу Netflix, вы получаете пользовательский интерфейс, который полностью персонализирован для вас. Но это все еще сопоставлено с компонентами и элементами пользовательского интерфейса Netflix. Еще один очень хороший инструмент, который я видел недавно, — это JSON Render. JSON Render разрабатывается Vercel. И это способ сопоставления ваших компонентов с использованием JSON, а также YAML. Они недавно добавили поддержку YAML. И создают все эти очень динамичные, очень хорошие интерактивные элементы пользовательского интерфейса, которые вы можете использовать сегодня. Но теперь JSON Render по-прежнему, как они говорят, ограничен вашими статическими компонентами. И да, это все еще статические компоненты. LLM не генерирует эти компоненты. LLM генерирует JSON. Однако я думаю, что на данном этапе декларативный генеративный пользовательский интерфейс, вероятно, является идеальным балансом сегодня с точки зрения гибкости и согласованности. Потому что вы все равно хотите иметь свою систему дизайна. Вы все равно хотите иметь предсказуемость того, какой пользовательский интерфейс будет сгенерирован, также быстрее и, возможно, дешевле на данном этапе. Вы не создаете и не используете много токенов для создания пользовательского интерфейса. Но, как я упомянул в начале, почему мы все еще застряли здесь? И какой следующий уровень? Я думаю, что следующий уровень будет генеративные компоненты. И генеративные компоненты идут в соответствии с предпосылкой, которую я изложил в начале, где модели хороши в написании фронтенд-кода. Они хороши в написании React. Они хороши в создании React на JavaScript, CSS. И вопрос в том, почему мы не позволяем им просто писать это по запросу во время выполнения. Что может пойти не так? Эта модель генерации пользовательского интерфейса использует возможности агента. И в этом случае вы также можете использовать вызов инструмента, но вместо вызова этого движка рендеринга макета вы можете вызвать ту же модель с обратной выборкой или вызвать другую модель, которая будет генерировать HTML, CSS, JavaScript по запросу, а затем это будет передано клиенту. Я провел этот эксперимент, я работаю в Postman над этим экспериментом, где я создал погодный агент, который обращается к API, погодному API. Он создает шутку. Он создает HTML, CSS, JavaScript, все в одном вызове инструмента. И вам представляется этот случайный, но очень образный пользовательский интерфейс, где все создано агентом. Нет компонента. Нет трансляции. Конечно, есть проблема с этим подходом. И проблема с этим подходом заключается в том, что если мы не доверяем стороннему коду, то мы не должны доверять коду, который был сгенерирован LLM, а затем просто представлен пользователю. Генеративный пользовательский интерфейс и этот уровень генеративного пользовательского интерфейса нуждаются в модели распространения. И эта модель распространения требует границы, требует изоляции и требует песочницы, о чем мы говорили ранее. Вот почему MCP-приложения так важны, потому что MCP-приложения являются лучшим механизмом доставки для генеративного пользовательского интерфейса. У нас есть функции, предоставляемые MCP, включая аутентификацию, вызовы инструментов и передачу сообщений между пользовательским интерфейсом и агентом. Он изолирован по умолчанию с помощью этого двойного iframe. Это стандарт для доставки стороннего пользовательского интерфейса сегодня. Станет ли это стандартом? И интересно то, что это не только для стороннего пользовательского интерфейса. Он также может использоваться для собственного пользовательского интерфейса. И именно поэтому я думаю, что то, что делает Anthropic с функцией визуализатора, очень интересно со стратегической точки зрения, потому что они могли бы просто создать свою собственную архитектуру рендеринга для доставки этого взаимодействия в облаке, но они решили использовать MCP-приложения, потому что MCP-приложения предоставляют большинство из этих функций, которые я упомянул ранее, из коробки. Так что, если Anthropic решил использовать MCP-приложения для своего собственного пользовательского интерфейса, вы можете спросить себя, почему мы не можем сделать то же самое? Это очень, очень сильный протокол. И особенно когда пользовательский интерфейс генерируется на лету агентами, моделями кодирования, тогда это лучший механизм доставки. Теперь сегодня, вероятно, не окончательная форма. И люди продолжают спрашивать, является ли чат окончательной формой? Являются ли MCP-приложения окончательной формой? Мы все еще пытаемся это выяснить. И очевидное будущее, вероятно, слишком очевидно. И мы говорили о том, где мой Джарвис? Где мои плавающие окна? И если вы подумаете об этом, это очевидные вещи, которые люди подумали бы, как бы мы выглядели, если бы мы генерировали или создавали новое пользовательское взаимодействие. Но я думаю, что у нас пока недостаточно воображения. И эта аналогия, которую я недавно услышал, очень интересна: когда радио появилось в 30-х годах, первое, извините, телевидение появилось, первые телешоу были радиошоу с камерами, потому что они не могли представить, что можно сделать с этой новой технологией. Так что эта новая технология, которая у нас есть сегодня, очень похожа на то, когда появилось телевидение, и мы все еще находимся в радиоэре, где мы не знаем обо всех удивительных вещах, которые мы будем делать в будущем с этим новым медиа, с этой новой силой, которую мы имеем с новым компьютером. И мы видим, что мы даже не можем представить, как это будет выглядеть. Конечно, это спекулятивно, но я думаю, что на самом деле произойдет то, что мы выйдем за рамки компонентов и больше будем двигаться к сотрудничеству через сотрудничество человека и агента. Если вы еще не слышали о MCP-приложении Excalidraw, обязательно ознакомьтесь с ним, потому что MCP-приложение Excalidraw — это не просто вывод и визуализация диаграмм. MCP-приложение Excalidraw делает кое-что очень интересное: оно создает общий артефакт. Оно создает холст, где человек и агент могут сотрудничать вместе в общем пространстве, где вы можете обмениваться информацией с агентом и просить, знаете ли, изменить это, но вы также можете щелкать, изменять пользовательский интерфейс так, как вы привыкли. И это становится новым способом взаимодействия, новым способом переживания возможностей агента. И на данный момент, опять же, мы очень ограничены нашим воображением. И я считаю, что эти агенты очень, очень мощные, чтобы просто использовать их как оркестратор и механизм доставки, чтобы показать мне некоторые визуализации. Поэтому я считаю, что за пределами компонентов будущее генеративного пользовательского интерфейса будет скорее совместным опытом, где да, у нас будет некоторый генеративный пользовательский интерфейс, но этот пользовательский интерфейс будет супер-персонализированным и совместным. Так что мы все еще на ранней стадии. У нас нет ответа. Люди говорят, знаете ли, каково будущее пользовательского взаимодействия, пользовательских интерфейсов? Мы еще не знаем. Но мы можем сформировать это будущее и создать этот новый компьютер. И это все от меня. Большое спасибо за то, что выслушали это. >> [аплодисменты] >> Вы можете найти меня и задать любые вопросы. Спасибо.