NintendaDev 

Я Unity/C# разработчик, создатель UniKit AI и автор Telegram-канала NintendaDev. Unity, код и пиксели. За 4+ года в геймдеве выпустил 5 игр на Google Play, App Store и Яндекс Игры - суммарно больше миллиона скачиваний.

Самый крупный проект - Escape Master: Obby Parkour, 1M+ скачиваний. Соревновательная мобильная игра с мультиплеером на Photon PUN 2, 10+ режимами и полным циклом монетизации. Делали командой, я был тех-лидом. Довели до релиза через издателя на Google Play и App Store.

Geometry Dash Levels - ритм-платформер для Яндекс Игр - написал полностью сам, от первой строчки кода до релиза. Старался максимально приблизить к оригиналу: окружение реагирует на реальный ритм музыки, каждый уровень - свой уникальный трек. Игра до сих пор приносит ~40 000 ₽/мес пассивного дохода и ежедневная средняя аудитория до 8 тысяч человек.

Так же был опыт создания с командой MVP мобильного сюжетного шутера BattleMeat: World at War. Смогли достичь очень крутой метрики CPI в США - 0.09$ при проведении теста.

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

Более подробно обо мне и моих проектах можно узнать на моем официальном сайте.

В первом посте я рассказал, зачем написал UniKit AI. Во втором разобрал пайплайн работы - от исследования до коммита.

Сейчас финальная часть и, пожалуй, самая техническая: как устроена память фреймворка и почему она принципиально отличается от классического CLAUDE.md и его аналогов в других агентах.

Напомню, с чего мы стартовали. Классический подход к правилам в AI-разработке - это CLAUDE.md. Файл грузится в контекст при старте сессии, и все правила, которые в нём лежат, сразу занимают место в контекстном окне. На маленьких проектах это терпимо. На реальных - правила для фреймворков, модулей, стиля кода, архитектурных принципов быстро съедают до 40-50 тысяч токенов контекстного окна. 

Решений в классике два, и оба плохие:

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

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

Скиллы UniKit AI не читают всю память целиком. Они работают через специальный индекс - файл .unikit/memory/RULES_INDEX.md, в котором для каждого правила есть краткое описание: что это за правило, к какому фреймворку/модулю относится, когда его нужно применять.

Когда создаётся или выполняется план, агент для каждой задачи смотрит индекс и подтягивает только те правила, которые нужны именно этой задаче. Пишем UI-анимацию - подтянутся правила по UI и по DOTween. Пишем систему сохранений - подтянутся правила по сериализации и по конкретной библиотеке, которую используем. Другие правила в это время мирно лежат на диске и не занимают контекст.

В первом посте я рассказал, зачем вообще написал UniKit AI и какие проблемы классического AI-кодинга он закрывает.

Сейчас разбираем практику: как устроен полный цикл работы над фичей - от исследования до готового кода.

Если не читал первый пост - сначала туда, иначе дальнейшее будет без контекста.

Сначала общий обзор, потом пройдёмся по каждому шагу с примерами:

/unikit - первоначальная настройка проекта, генерация архитектурных документов и правил

/unikit-explore - исследование фичи, когда непонятно с чего начинать

/unikit-plan - создание плана по артефакту исследования или из промта

/unikit-improve - улучшение плана через повторный анализ

/unikit-implement - выполнение плана целиком или по фазам

/unikit-review - ревью кода по правилам проекта

/unikit-verify - ревью результата по целям плана

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

Я сел и начал делать свой - параллельно с боевым проектом, в котором как раз взялся обкатывать AI-пайплайн.

Сегодня готов это показать. Встречайте UniKit AI - фреймворк для Spec-Driven разработки игрового кода на Unity, Godot и Unreal Engine.

UniKit AI работает с кодовой базой: архитектура, системы, тесты, рефакторинг. Настройка сцен, префабов и ассетов остаётся за разработчиком.

Поддержка трёх движков: Unity, Unreal Engine 5 и Godot.

Для каждого движка скиллы адаптированы под его специфику, а инсталлер предлагает свой набор MCP-серверов. Крайне рекомендую не отказываться от их установки - без них работа менее удобная.

Поддержка шести агентов: Claude Code, Cursor, Codex CLI, Gemini CLI, Qwen Code и OpenCode.

Основная разработка ведётся под Claude Code - под него сделана более глубокая интеграция, так как у него есть функции, которых нет у других. Другие агенты работают в Beta режиме. Какие есть нюансы с агентами я подробно описал в документации в Git.

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

Всё чаще вижу прогнозы, что из-за ИИ через год-два уже полетят головы даже у разработчиков.

Мое мнение - правда, но частично.

Я считаю, что ИИ может серьёзно усложнить жизнь тем разработчикам, кто не адаптируется.

Но полетит ли голова у хорошего разработчика, который адаптировался? Нет. Скорее наоборот - работы станет больше. Просто другой.

❗️Что реально происходит

Бурный рост ИИ создаёт опасную иллюзию: зачем глубоко изучать предметную область, если агент "и так всё сделает"? Отсюда поверхностная проверка результатов, слепое доверие модели.

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

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

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

⚙️ Главное: без понимания архитектуры ты не контролируешь агента

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

Поделюсь командами в Claude Code, которые появились относительно недавно и которыми я сейчас пользуюсь постоянно.

1️⃣ /skill-creator

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

Пример из практики. Сейчас делаю сайт для своего фреймворка AI-разработки в геймдеве - UniKit AI. Скоро представлю его для всех, думаю вам очень зайдет! 😊

И мне нужно было переносить верстку из макетов Pencil в код.

Я просто написал:

Всё. Сгенерировался базовый скилл /pencil-designer под мою задачу. Теперь мне не нужно каждый раз копировать промпты и объяснять агенту одно и то же - я просто вызываю скилл и сразу ставлю задачу. А он уже под капотом знает как обращаться к MCP и как верстать страницы.

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

❗️Важно: этого плагина нет по умолчанию. Ставится один раз через команду /plugin в Claude Code. После этого доступен во всех сессиях и будет обновляться автоматически.