Меня зовут Андрей, я XR‑разработчик в SimbirSoft.
Есть мнение, что искусственный интеллект уже способен создавать приложения практически без участия разработчика, эта тема обсуждается после появления AI‑агентов.
В этой статье я попробую разобраться, почему XR остаётся сложной областью для AI‑разработки, какие задачи уже сегодня доверяют искусственному интеллекту, а где без человека пока не обойтись. И это с учетом появления инструментов вроде XR Blocks Gem, которые обещают собрать XR‑приложение только по текстовому описанию.
Статья может быть интересна компаниям, рассматривающим применение искусственного интеллекта для ускорения разработки XR‑продуктов и оценки его возможностей и ограничений.
Vibe Coding XR
Недавно Google представила связку Gemini и XR Blocks, которая позволяет создавать WebXR‑приложения по текстовому описанию буквально за несколько минут. Компания назвала этот подход Vibe Coding XR.
На первый взгляд кажется, что XR наконец‑то пришёл туда же, где сегодня находятся веб‑ и мобильная разработка: пишете хороший промпт — вуаля, приложение почти готово. Но на поверку всё не так просто.
Современные LLM действительно неплохо пишут код, умеют работать с Unity и WebXR, генерируют шейдеры, создают 3D‑модели и даже собирают сцены. Но каждый раз между «код работает» и «XR‑приложением удобно пользоваться» может обнаружиться огромная пропасть.
Что вообще считается XR‑разработкой
Прежде чем говорить о роли AI, стоит разобраться, что понимают под XR.
XR (Extended Reality) — это термин для технологий, объединяющих цифровой и физический мир. Здесь выделяют три основных направления:
Virtual Reality (VR) — полностью виртуальная среда, в которую пользователь погружается с помощью шлема. Всё, что он видит, генерируется компьютером. Типичные примеры — игры, тренажёры, симуляторы и виртуальные шоурумы.
Augmented Reality (AR) — дополненная реальность, в которой цифровые объекты накладываются поверх изображения реального мира. Самый распространённый пример — AR на смартфонах, когда через камеру отображаются виртуальные объекты, привязанные к окружающему пространству.
Mixed Reality (MR) — смешанная реальность. Здесь виртуальные объекты не отображаются поверх изображения с камеры, а становятся частью окружающего пространства. Они могут взаимодействовать со стенами, столами, мебелью и другими объектами реального мира.
Важно, что XR — это класс приложений, а не отдельная платформа. Одно и то же решение может быть рассчитано на совершенно разные устройства:
-
смартфоны;
-
VR‑гарнитуры;
-
AR‑ и MR‑очки;
-
браузеры с поддержкой WebXR;
-
настольные компьютеры.
И это разнообразие отличает XR от привычной веб‑ или мобильной разработки. Вместо одной платформы разработчику приходится учитывать разные устройства, способы взаимодействия и сценарии использования. И это одна из причин, почему автоматизировать разработку XR‑приложений сложно.
Инструменты для разработки XR
Самый распространённый способ создания XR‑приложений — использовать готовые 3D‑движки: Unity, Unreal Engine, Godot и другие.
Они берут на себя почти всю базовую инфраструктуру. Разработчику не нужно самостоятельно реализовывать рендеринг, физику, систему взаимодействий, управление ресурсами или поддержку разных устройств — всё это уже есть из коробки.
Современные движки обычно включают:
-
визуальный редактор сцен;
-
инструменты для работы с 3D‑графикой и анимацией;
-
физический движок;
-
систему пользовательского интерфейса;
-
средства профилирования и отладки;
-
интеграцию с OpenXR и SDK различных устройств;
-
сборку сразу под несколько платформ.
Кроме того, вокруг Unity и Unreal сформировались огромные экосистемы готовых решений: ассеты, модели, анимации, плагины и SDK. Благодаря этому разработчики могут сосредоточиться на логике приложения и пользовательском опыте, а не думать о создании инфраструктуры.
Как вы уже догадываетесь, игровые движки остаются основным инструментом разработки большинства коммерческих XR‑проектов — от корпоративных тренажёров до промышленных симуляторов.
WebXR
Другой подход — это запускать XR‑приложения прямо в браузере.
Для этой задачи обычно используют Three.js, Babylon.js, A‑Frame, XR Blocks, 8th Wall и другие библиотеки.
Главное преимущество WebXR заключено в отсутствии установки. Пользователю достаточно открыть ссылку или отсканировать QR‑код, чтобы сразу перейти к AR‑ или VR‑контенту. Как вы могли заметить, такой подход особенно популярен в маркетинговых проектах, рекламе и демонстрационных приложениях.
Нативная разработка
Ещё один вариант — использовать SDK конкретной платформы: Android XR, visionOS, Meta Horizon OS SDK, ARKit или ARCore.
Этот способ даёт максимальный доступ к возможностям устройства, но делает приложение менее кроссплатформенным.
OpenXR
Отдельно стоит упомянуть OpenXR. Это не движок и не фреймворк, а открытый стандарт взаимодействия между приложением и XR‑устройством.
Благодаря OpenXR одно и то же приложение работает на гарнитурах разных производителей без отдельной реализации для каждой платформы.
В результате современная XR‑разработка опирается сразу на несколько классов инструментов: игровые движки, браузерные технологии, нативные SDK и открытые стандарты. И это разнообразие и делает автоматизацию значительно сложнее, чем в веб‑ или мобильной разработке.
Почему XR — особый случай для AI‑разработки
Чтобы понять ограничения AI в XR, сначала стоит посмотреть на области, где современные модели уже чувствуют себя уверенно и комфортно. Это веб‑ и мобильная разработка.
Сегодня LLM неплохо справляются с типовыми задачами: генерируют CRUD‑приложения, проектируют интерфейсы, пишут API, создают тесты и рефакторят готовый код. Во многих случаях модели способны довести типовую задачу до рабочего состояния почти без участия разработчика.
Но дело здесь не столько в уме модели, сколько в природе веб‑разработки. Веб‑ и мобильные приложения хорошо формализованы — это набор экранов, UI‑компонентов, бизнес‑логики и предсказуемых сценариев взаимодействия. Такое приложение легко проверить автоматически: существуют линтеры, статический анализ, тесты, сборка, CI/CD. Даже техническое задание описывает систему в тех же терминах, в которых она реализована.
Поэтому AI работает в комфортной для себя среде: проверяет результат, воспроизводит, а затем исправляет ошибки.
С XR всё иначе. Здесь приложение перестаёт быть просто набором экранов. Оно становится частью физического пространства, в котором пользователь перемещается, смотрит по сторонам, взаимодействует с объектами и постоянно меняет точку обзора.
Появляются параметры, которых просто нет в классической разработке, и они напрямую влияют на пользовательский опыт.:
-
положение пользователя;
-
размеры помещения;
-
направление взгляда;
-
положение рук и жесты;
-
глубина сцены;
-
особенности трекинга конкретного устройства.
Главная проблема заключается в том, что правильный код ещё не гарантирует правильное поведение приложения.
Допустим, AI разместил кнопку точно по заданным координатам и формально всё работает. Но если до неё неудобно тянуться, её приходится искать взглядом или она находится слишком близко к лицу пользователя, приложение становится неудобным, хотя с точки зрения кода ошибок нет. И вот здесь проходит граница между вебом и XR.
В классическом интерфейсе кнопка остаётся обычной кнопкой. В XR она превращается в объект пространства. Пользователь может подойти к ней, обойти её, посмотреть сверху, изменить угол обзора или взаимодействовать с помощью жестов. Поэтому разработчику приходится думать о композиции пространства, а не только о логике работы программы.
Такие ошибки невозможно обнаружить привычными средствами вроде линтеров или юнит‑тестов. Они проявляются только тогда, когда человек начинает пользоваться приложением.
Но есть проблема, которую ИИ пока решить не может. Даже если он способен самостоятельно собрать сцену, проверить рендеринг и убедиться, что все объекты находятся на местах, он всё равно не знает, как эту сцену воспринимает человек.
Он не может ответить на вопросы вроде:
-
удобно ли расположены элементы интерфейса;
-
не перегружает ли сцена внимание пользователя;
-
естественно ли ощущается масштаб объектов;
-
возникает ли дискомфорт во время взаимодействия.
Как можно заметить, между двумя утверждениями «Приложение работает» и «Приложением удобно пользоваться» в XR лежит огромная дистанция.
И пока современные модели не умеют оценивать человеческое восприятие пространства, этот разрыв невозможно закрыть ни анализом кода, ни автоматическим тестированием. Таким образом, XR остаётся одной из самых сложных областей для автоматизации и агентной разработки.
Что AI уже умеет делать в XR
Сказанное выше не означает, что AI пока бесполезен для XR‑проектов. Наоборот, сегодня он используется в коммерческих проектах и способен существенно ускорить написание кода. Но есть важное отличие от веб‑разработки. Если для создания сайта достаточно одной языковой модели, то XR‑приложение состоит не только из кода. Это ещё и 3D‑модели, материалы, текстуры, анимации, интерфейсы, звуки и десятки других компонентов.
Поэтому современная AI‑разработка в XR — это не один универсальный инструмент, а целый набор специализированных моделей.
Код
Самое зрелое направление — это генерация программного кода.
ChatGPT, Claude, Gemini, GitHub Copilot и Cursor уже умеют писать C# для Unity, создавать логику для Unreal Engine, разрабатывать WebXR‑приложения на Three.js, генерировать шейдеры и автоматизировать рутинные задачи.
Но за последние два года произошло серьезное изменение. Раньше LLM работали как продвинутый автокомплит: предложили функцию — разработчик вставил в проект. Сегодня для этого используются AI‑агенты.
Благодаря MCP (Model Context Protocol) и Editor API ИИ получает доступ не только к исходному коду, но и к самому проекту. Агент анализирует структуру сцен, создает объекты, меняет настройки компонентов, пишет скрипты и сразу связывает всё между собой.
Например, вместо нескольких часов ручной работы разработчик пишет:
«Создай тренировочную сцену с кнопкой запуска, таймером и системой подсчёта очков»
После этого агент самостоятельно создаст необходимые GameObject, добавит компоненты, напишет скрипты и соберёт базовую логику приложения.
По сути теперь разработчики работают с цифровым помощником, а не просто с генератором кода.
Графика
Код — это лишь небольшая часть XR‑проекта. Пользователь взаимодействует с окружающим пространством, поэтому на следующем этапе от ИИ ждут генерацию визуального контента.
Для создания текстур, материалов и элементов интерфейса сегодня используют Midjourney, Stable Diffusion, Flux и Adobe Firefly. Конечно, результат редко сразу попадает в прод. Но получить за несколько минут десяток вариантов текстуры, которую раньше художник рисовал несколько часов, — уже рабочий сценарий.
3D‑модели
Похожая ситуация и с генерацией моделей.
Tripo AI, Meshy, Hunyuan3D и Rodin умеют создавать 3D‑объекты по текстовому описанию или изображению и экспортировать их в Unity или Unreal Engine.
Пока такие модели не готовы к использованию без доработки, однако для быстрого прототипирования или первых итераций экономят огромное количество времени.
Анимация
Отдельное направление — это генерация анимации.
DeepMotion, Move AI и Wonder Studio переносят движения с обычного видео на персонажей, автоматически создают анимации. С ними можно обойтись без дорогостоящих mocap‑систем.
Особенно полезны такие инструменты в VR‑тренажёрах и образовательных проектах, где нужно быстро создавать большое количество анимированного контента.
Вместо одного AI — целый конвейер
Если посмотреть на процесс разработки, становится понятно, что AI‑пайплайн в XR — это не одна модель. Это производственный конвейер: одни инструменты пишут код, другие создают текстуры, третьи генерируют модели, четвёртые отвечают за анимацию.
Вместе они ускоряют разработку, особенно на этапе прототипирования. Но здесь мы снова возвращаемся к главной проблеме XR. Эти инструменты умеют создавать контент, но не умеют оценивать опыт пользователя.
AI может правильно расставить объекты, написать код и собрать сцену без единой ошибки. Но он по‑прежнему не способен ответить на вопросы, которые определяют качество XR‑приложения:
-
удобно ли расположены элементы интерфейса;
-
естественно ли ощущается масштаб объектов;
-
не перегружает ли сцена внимание пользователя;
-
комфортно ли взаимодействовать с виртуальным пространством.
Где‑то можно выдохнуть, ведь сегодня AI берёт на себя всё больше инженерной работы, но финальная оценка XR‑продукта всё ещё остаётся за человеком.
Так заменит ли AI XR‑разработчика?
Несмотря на стремительное развитие генеративных моделей и появление агентных систем, XR остаётся одной из самых сложных областей для полной автоматизации.
Причина проста: ценность XR‑продукта определяется не только качеством кода, но и тем, как человек воспринимает пространство.
Сегодня AI уже способен писать код, создавать 3D‑модели, генерировать текстуры, анимации и даже собирать сцены. Всё это ускоряет разработку и делает создание прототипов проще, чем 5 лет назад.
Но есть одна задача, которую современные модели пока не умеют решать. Они не могут ответить на вопрос, комфортно ли человеку в этом пространстве?
А этот вопрос в конечном итоге определяет качество XR‑приложения.
Поэтому в ближайшие годы AI, скорее всего, не заменит XR‑разработчиков, а станет ещё более мощным инструментом в их арсенале.
Подписывайся на наши соцсети и блог, где мы публикуем другие полезные материалы, в том числе и для XR‑разработчиков:
Автор: SSul
