Вайб-кодинг вместо унылых ТЗ: как автономные ИИ-агенты ускоряют разработку игр

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

«Как же хорошо, что человечество уже придумало нейросети», — подумали мы в Magnus Tech и полностью отказались от ручного написания текстовых ТЗ для проверки гипотез. Потому что зачем описывать механику буквами, если ее можно быстро навайбкодить? Теперь для тестирования новых фичей мы не пишем таски на десятки страниц, мы собираем черновой прототип на примитивах за пару часов и сразу его тестируем. В результате время от задумки до первого теста сократилось с недель до нескольких часов.

Но чтобы такая схема работала, обычного чат-бота в соседней вкладке браузера недостаточно. Нейросеть должна сама шерстить папки с проектом, ковыряться в скриптах и понимать структуру движка. Чтобы показать, как это устроено на практике, мы поговорили с Иваном Дворяновым, продюсером игрового направления в Magnus Tech. В этой статье делимся его опытом и рассказываем, как мы пустили Claude напрямую в Unity через MCP, почему вайб-кодинг всё равно требует жесткого планирования и в каких задачах лучше не доверяться ИИ, а по старинке работать руками.

От браузерных чатов к прямому доступу

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

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

Прямой доступ

Обычный Claude и так умеет читать файлы в папке, но плюс использования MCP в том, что ИИ не пытается запихнуть весь ваш гигантский проект сразу в свой контекст. Вместо этого агент выборочно ищет нужные файлы и обращается к логике внутри Unity: умеет сам находить нужные скрипты, понимает структуру сцен, собирает иерархию GameObjects, разбирается в зависимостях префабов и напрямую вызывает команды редактора.

И Unity тут совершенно не уникален: сейчас вендоры и опенсорс очень активно разрабатывают MCP-серверы под свой софт. Хорошие рабочие связки уже есть под Unreal Engine, Godot, Blender, Figma и много для чего еще.

Конкретно наш рабочий сетап выглядел так: используем Claude Code прямо внутри VSCode, а мостом выступает open-source сервер unity-mcp от CoplayDev. Под капотом там крутятся топовые модели семейства Claude Fable 5 или Opus 5, а если задача попадается уж очень сложная и объемная — просто выкручиваем параметр effort, чтобы у алгоритма было больше вычислительного времени на поиск решения.

В какой-то момент дошло до того, что на одном из сайд-проектов в Godot продюсер вообще не открывал редактор для сборки сцены. Он заходил в движок исключительно ради QA — запустить билд и проверить, как играется то, что агент уже навайбкодил по его запросам.

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

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

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

Как подключить Claude к Unity

Само подключение не требует сложной настройки. Через Package Manager устанавливаем в Unity пакет MCP for Unity от CoplayDev. Затем в меню Unity открываем Window → MCP for Unity. Проверяем необходимые зависимости, выбираем Claude Code и запускаем автоматическую настройку подключения.

После этого можно открыть проект в VS Code и давать агенту команды обычным языком. Например, попросить изучить текущую сцену, найти нужный префаб или добавить игровой объект. Claude обращается к инструментам MCP-сервера, а тот передает команды редактору Unity. Так агент получает возможность не только писать код, но и работать непосредственно с игровым проектом.

Это базовая схема подключения, без технических тонкостей. Если хотите разобраться подробнее, загляните в документацию MCP for Unity или на GitHub проекта. А можно и вовсе не возиться: Claude Code справится с установкой сам, если его попросить.

Секретное оружие — Plan Mode

Вообще, Plan Mode — это один из главных инструментов как работы с ИИ в целом, так и прототипирования в частности. И если вы его до сих пор по каким-то причинам игнорируете, то очень зря!

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

1. Продуктовый запрос. Вы описываете фичу простыми словами: «Нужно, чтобы было вот это, вот так взаимодействовало, а по клику происходило вот то». Если есть какие-то референсы — обязательно прикрепляете их к этому запросу.

2. Анализ и планирование. Запускаете Plan Mode. Claude идет в проект через MCP, изучает текущий код, сопоставляет его с вашей задачей и выдает подробный технический план примерно на один лист А4.

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

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

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

Пацаны не извиняются

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

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

Угадайте, что произошло при следующем сбое? Он выдал: «Да, я действительно ошибся. Но извинений не будет».

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

Внедрение ИИ в реальный пайплайн коммерческой разработки

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

Кейс 1. Playable Ads

Если вы играли в мобильные игры, то наверняка сталкивались с playables — играбельной рекламой, где вам дают подвигать тайлы или пострелять прямо внутри креатива. Очень часто студии отдают разработку плейблов на аутсорс. Создание таких креативов — процесс не самый простой, к тому же достаточно долгий и дорогой. Сначала вы пишете подробное ТЗ, затем ждете пару-тройку недель, платите приличный чек и надеетесь, что результат не будет выглядеть как дешевая поделка. Мы в какой-то момент решили собрать плейблы in-house силами одного продюсера, который вообще не умеет кодить.

Вводные данные проекта: игра состоит из двух частей. Есть core-геймплей (классический Match-3 с фишками) и meta-геймплей (изометрическое исследование карты, где персонаж бегает и разрушает объекты за энергию). Нам нужны были креативы под обе механики.

Мы натравили Claude на репозиторий Unity через тот самый MCP и дали максимально «тупой» стартовый промпт: «Вот папка с игрой, изучи ее. Возьми оттуда все ассеты и собери играбельный креатив с кором и креатив с метой. Разберись сам».

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

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

Согласитесь, это мало похоже на ту самую ИИ-магию, которую нам обещают вендоры в рекламных презентациях.

Здесь мы применили тот самый Plan Mode. Вместо того чтобы лезть руками в C#-скрипты, продюсер просто дал нейросети фидбэк в стиле ревьювера: «Исправь потекшие глаза модели, почини кривой бэкграунд. Хочу, чтобы здесь добавился квест, а тут появились визуальные эффекты». Итоговый результат:

На всё про всё ушло примерно 3 календарных дня, но чистого времени на промптинг и отладку было потрачено от силы 4–5 часов. Были 3–4 больших стартовых промпта со всеми деталями, 10–15 запросов с точечными правками и еще 5–6 итераций на отлов багов.

Код-ревью тоже отдали Claude. Плейбл — это изолированный маркетинговый продукт. Он никак не связан с ядром основной игры и не несет каких-то архитектурных рисков для прода. Если креатив выглядит как надо и играется без багов, то без разницы как там внутри написан код.

В итоге мы получили качественные интерактивы, сэкономили бюджет на внешних студиях и, что самое главное, не отвлекли от основной работы собственных senior-инженеров.

Кейс 2. Быстрые скрипты для отладки механик

Второй кейс отлично показывает, как избавиться от типовых рутинных задач разработчиков без ущерба общей эффективности.

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

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

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

Обратная сторона хайпа и реальные ограничения нейросетей

Однако давайте внесем чуть больше реализма. Если послушать евангелистов ИИ, может показаться, что завтра любой школьник навайбкодит свой Skyrim одним промптом, а послезавтра все программисты дружно пойдут на пенсию. Давайте немного снизим градус хайпа. На практике, по крайней мере, в геймдеве, нейросети всё еще потрясающе глупы в вещах, которые делают игру игрой.

Почему мы никогда не пускаем ИИ в архитектуру проекта

Сгенерировать изолированный прототип или скрипт-утилиту — это одно. Строить на вайб-кодинге ядро проекта — заведомо провальный путь.

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

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

• плодить циклические зависимости там, где можно было обойтись простым ивентом;

• лепить костыли в Update, чтобы просто работало здесь и сейчас, игнорируя принципы SOLID;

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

Рано или поздно логика такой игры неизбежно сломается. А хуже всего то, что вы даже не сможете найти корень проблемы, потому что этот код писали не вы, и в итоге придется откатывать месяцы прогресса. Поэтому самые важные решения мы в Magnus Tech не делегируем ИИ. Архитектура проекта, сетевой код и кор-луп остаются за разработчиками.

Шаблонные игровые механики вместо глубокого вовлечения

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

• Шаблонные механики. ИИ, скорее всего, просто спарсит топ-10 стора и выдаст вам усредненный батлпасс, базовую систему квестов или типовую прогрессию. Делать банальных клонов он мастер.

• Стерильный геймплей. Нейросеть не понимает, что такое эмоциональные качели и удержание интереса игрока. Да, результат будет, скорее всего, рабочим, но совершенно не интересным.

Любая языковая модель математически стремится решить задачу самым коротким и логичным путем. Проблема в том, что хороший гейм-дизайн строится на изящном создании препятствий, а не на их оптимизации.

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

Арт и динамика — пока что слезы

Если в кодинге ИИ выступает как крепкий мидл, то в графике для интерактивных медиа он всё еще на уровне джуна, а иногда даже хуже.

Да, вы можете нагенерить приличных статичных 2D-персонажей или бэкграунды. Но игры — это динамика, тут важны:

• Сложные анимации и VFX. Как только вам понадобится скелетная анимация, разлетающиеся искры или сочные эффекты попаданий — придется делать руками.

• 3D-модели. Несмотря на большой прогресс, до production-ready качества нейросетям еще далеко. Топология и риггинг хромают, а полученные 3D-объекты больше годятся для концептов, чем для полноценной игры.

• Ручная доработка. Любой сгенерированный ассет требует серьезного вмешательства художника, чтобы нормально смотреться в движке (иначе получится та самая ситуация с «потекшими глазами» из примера выше).

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

Адаптация инженерных процессов под автономных ИИ-агентов

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

Спойлер: утонут только те, кто воспринимает ИИ как волшебную кнопку «сделай красиво».

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

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

Резюмируя наш опыт в Magnus Tech, мы сформулировали три главных правила работы с ИИ-агентами:

• Хватит писать многостраничные ТЗ. Оставьте раздутые диздоки в прошлом. Используйте ИИ, чтобы побороть страх чистого листа. Надиктуйте идею голосом, соберите интерактивный черновик на примитивах, пощупайте его руками и только потом отдавайте механику в полноценный продакшен.

• Относитесь к ИИ как к живому коллеге. Это не всезнающий оракул. Это крепкий, инициативный, но иногда хитрый и ленивый мидл. С ним нужно спорить, его нужно заставлять писать планы (обязательно используйте Plan Mode), и его пулл-реквесты необходимо пропускать через жесткое ревью.

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

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