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 быстро начинает вносить хаос

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