Опыт разработки игры с помощью AI-агентов: процесс, ограничения и выводы

TL;DR

• вокруг вайбкодинга много хайпа, но чаще всего это прототипы и демки

• стало интересно, можно ли использовать AI-агентов для реальной разработки небольшого проекта

• в качестве хобби я сделал игру, выстроив процесс вокруг документации, Epics и планов

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

• подход хорошо работает для новых и небольших проектов

• для больших систем всё упирается в контекст и требует жёсткой автоматизации, а не «вайба»

Введение

За последний год вокруг вайбкодинга появилось много шума.
Статьи, YouTube, Twitter — везде показывают, как с помощью AI за вечер собираются демки и прототипы.

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

Постановка задачи

Это был не эксперимент ради эксперимента.

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

Геймдев никогда не был моей основной специализацией, но раньше я уже делал игры. Один из проектов — Cosmix (2012–2013) — так и остался незавершённым. В этот раз хотелось проверить, можно ли выстроить процесс иначе.

Выбор инструментов

Рабочий сетап был максимально обычным:

• VS Code

• плагин Codex

Codex был выбран по двум причинам:

1. уже была активная подписка GPT

2. он работает с проектом локально и читает контекст файлов, а не только текущий диалог (в отличие от ряда альтернатив)

Никаких no-code платформ или визуальных конструкторов не использовалось.

Почему без процесса это не работает

Довольно быстро стало понятно, что без чёткого процесса AI начинает вести себя как генератор случайных решений.

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

• что за проект делается

• какие решения считаются правильными

• где проходят границы изменений

Документы и уровни контекста

PROJECT_OVERVIEW.md

Короткий, но полный документ:

• что за игра

• какие механики каноничны

• какие решения нельзя менять без согласования

Этот файл агент читает перед любой работой.
Если задача затрагивает канон — он обязан остановиться и запросить подтверждение.

PROJECT.md

Журнал изменений.

После каждой завершённой задачи агент добавляет одну строку:

• что изменилось

• как теперь это работает

Это помогает не терять контекст и снижает количество логических противоречий.

Как появляются задачи (Epics)

Epics тоже создавались с помощью AI. Использовалось два сценария.

Сценарий 1. Идея → Epic

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

Сценарий 2. Дизайн → Epics

Для крупных изменений сначала проектировалась механика: поведение, ограничения, пограничные случаи.
После этого создавался .md-документ, который агент разбивал на несколько Epics.

Рабочий цикл: Epic → Plan → Execution → Log

Epic описывает что должно появиться, но не как именно.

Пример Epic:

# EPIC-04 Cosmometer (Energy Multiplier) ## Goal Implement energy-based multiplier with thresholds and cooldown behavior. ## Scope - Energy gain per drop - Energy decay over time - Thresholds for x2/x3/x5 - x5 burst behavior and cooldown modifier - Multiplier integration with scoring ## Out of scope - Shop/upgrades - Bubbles and bonuses ## Deliverables - Energy system - Multiplier state and timing - Debug telemetry

Plan

Перед началом работы агент строит план и выносит его на подтверждение.

# PLAN_EPIC_4 — Cosmometer - [x] Locate energy integration points (drop, update loop, scoring). - [x] Implement energy system: gain, decay, thresholds x2/x3/x5, x5 burst + cooldown modifier. - [x] Drive gameMultiplier from energy and add debug telemetry. - [x] Add HUD cosmometer thermometer animation with color states (1x/2x/3x/5x). - [x] Update PROJECT.md to reflect new behavior.

Log

После завершения Epic результат фиксируется в PROJECT.md.

- Cosmometer: energy increases on each drop (internal max 125, visual scale 0–100); energy decays faster at higher charge (x1→x3), thresholds drive game multiplier (x1/x2/x3/x5) and HUD thermometer with color transitions and level popups.

Управление reasoning и размером задач

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

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

Повышение reasoning полностью убрало зацикливания.
Так появился рабочий паттерн:

• простые задачи — средний reasoning

• сложные, затрагивающие несколько систем — высокий reasoning

Баланс контроля

Изначально агент запрашивал подтверждение после каждого шага.
Со временем стало заметно, что большинство ответов — это просто «да, продолжаем».
На среднем reasoning такой контроль имеет смысл.
На высоком — он мешает.

В итоге:

• на среднем reasoning — подтверждение после каждого шага

• на высоком — агент выполняет Epic целиком, проверка происходит по результату

Контекст растёт — рефакторинг становится обязательным

По мере роста проекта агент начинал работать медленнее. Контекст разрастался.
Регулярно выполнялся рефакторинг:

• разбивались длинные файлы

• удалялся мёртвый код

• упрощались структуры

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

Что бы я сделал иначе, начиная проект сейчас

• выбрал бы TypeScript вместо JavaScript и добавил type-check и линтер в стадию завершения Epic

• автоматизировал Git-флоу: ветка на Epic, коммит и merge в develop по завершении

• сразу заложил бы правило: агент выполняет Epic целиком, задавая вопросы до начала

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

• попробовал бы параллельную работу с несколькими Epics

Результат

На выходе получился законченный продукт.
Игра опубликована в Яндекс Играх:

https://yandex.ru/games/app/489826

Выводы

• для новых и небольших проектов подход рабочий

• при отсутствии легаси и чётких требованиях AI хорошо справляется с ролью исполнителя

Для больших и существующих проектов всё упирается в контекст:

• нужны жёсткие правила

• обязательна документация уровня PROJECT и PROJECT_OVERVIEW

• без автоматизированного процесса AI быстро начинает вносить хаос

Вайбкодинг подходит для идей и прототипов.
Для реальной разработки нужен управляемый и формализованный подход.