AI-Driven Development в геймдеве: как внедрить ИИ-агентов в команду разработчиков игр в 2025–2026 году

TL;DR: AI-агенты перестали быть экспериментальной игрушкой — они стали полноценными «цифровыми сотрудниками», которые пишут код, проводят ревью и поддерживают архитектуру. Но без правильного управления, документации и culture shift агент превратится в генератор технического долга. В этой статье — практическое руководство по AI-Driven Development для геймдев-команд: от выбора инструментов до построения feedback loop.

Что такое AI-Driven Development и почему это важно прямо сейчас

AI-Driven Development (AIDD) — подход к разработке программного обеспечения, при котором ИИ-агенты становятся полноправными участниками процесса: они пишут код, исправляют баги, генерируют тесты, ведут документацию и проводят ревью. Это не автодополнение в редакторе и не чат с GPT — это делегирование полноценных инженерных задач автономным системам с доступом к кодовой базе, терминалу и внешним сервисам.

По данным GitHub Copilot Business Report 2024 года, разработчики, использующие ИИ-ассистенты, завершают задачи на 55% быстрее. Но реальное ускорение зависит от типа задачи: на новых greenfield-проектах прирост может достигать 70–75%, на legacy-коде — 20–30%. Это подтверждает исследование McKinsey «The economic potential of generative AI» (2023), где зафиксирован прирост продуктивности разработчиков в диапазоне 20–45%.

Антон Керп, технический директор Funzen and Games с почти 10-летним опытом в коммерческой разработке, сформулировал эту мысль точно: «Нейросети уже реально можно рассматривать как своих младших сотрудников. Раньше это могло звучать как громкий кликбейт, но сегодня это уже реальность — по крайней мере, в разработке и написании кода». Его компания практически не пишет код вручную: Claude, Codex и MiniMax заменяют часть команды, при этом получают зарплату в виде подписок, а не оклада.

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

Базовые концепции: LLM, агенты, контекст, токены

Прежде чем внедрять AI-Driven Development, команде необходимо понять базовые концепции. Без этого фундамента невозможно ни правильно поставить задачу агенту, ни оценить качество его работы.

Что такое LLM и почему она «усилитель»

LLM (Large Language Model, большая языковая модель) — вероятностная модель, которая предсказывает наиболее вероятное следующее слово. У неё нет «понимания» в человеческом смысле: каждый ответ генерируется заново и гарантированно уникален даже при одинаковом промте. Из этого вытекают два важных следствия:

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

Агент vs. чат: в чём принципиальная разница

Агент — это LLM, у которой есть рычаги воздействия на среду: она может читать и создавать файлы, запускать команды в терминале, вызывать внешние API, взаимодействовать с браузером. Обычный чат — это только текстовый диалог без доступа к реальным инструментам.

Именно агентный режим делает AI-Driven Development возможным: вы ставите задачу на уровне требований, агент самостоятельно изучает кодовую базу, пишет код, запускает тесты, исправляет ошибки и рапортует о результате.

Контекст и токены: экономика внимания

Контекстное окно — это всё, что «видит» модель в момент генерации ответа: ваш промт, история диалога, файлы, которые вы передали, логи и скриншоты. Токен — единица обработки текста (примерно 3–4 символа в русском языке, 4–5 в английском). Чем больше контекст — тем дороже запрос и тем медленнее ответ.

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

Важная деталь про русский язык: LLM обучены преимущественно на английском. Инструкции на английском воспринимаются точнее и расходуют примерно в 1,5–2 раза меньше токенов, чем аналогичный текст на русском. Это не значит, что нужно переходить на английский полностью, но системные промты и правила для агентов лучше писать на английском.

Инструменты AI-разработки: от чата до CLI-агентов

Инструменты AI-разработки можно разбить на несколько уровней по глубине интеграции в рабочий процесс.

Уровень 1: веб-чаты (устаревший подход)

ChatGPT, Claude.ai, Gemini — генерируете код в браузере, копируете обратно в IDE. Это уже устаревший подход, но многие команды до сих пор работают именно так. Главный минус — агент не видит контекст вашего проекта и каждый раз начинает «с нуля».

Уровень 2: плагины в IDE (Cursor, Windsurf, Rider AI)

Следующий шаг — IDE с встроенным ИИ. Cursor, Windsurf (бывший Codeium) и JetBrains Rider с AI Assistant добавляют панель агента прямо в редактор. Ключевое преимущество — индексация кодовой базы: IDE переводит весь проект в векторное представление и позволяет агенту искать не по совпадению символов, а по смыслу.

Cursor и Windsurf — это форки VS Code с добавленной панелью агента. В Cursor есть режим Agent, где справа отображается область ревью правок агента: вы видите каждое изменение до того, как оно будет принято. Rider идёт другим путём — это плагин JetBrains с Marketplace для подключения внешних агентов (OpenCode, Codex), хотя стабильность пока бета-уровневая.

Уровень 3: CLI-агенты (революционный сдвиг)

CLI-агенты — это главное, что изменило индустрию в 2024–2025 годах. Claude Code, OpenAI Codex, OpenCode запускаются прямо в терминале. Почему это важно:

• Нет посредников между вашей подпиской на модель и инструментом — не нужно платить сторонним агрегаторам
• Запуск везде: в любом терминале, в Docker-контейнере, на сервере через SSH, в CI/CD пайплайне
• Headless-режим: агента можно вызвать через командную строку с промтом, получить результат и интегрировать в скрипты или оркестраторы
• Sandbox: можно запустить агента в изолированном Docker-контейнере с полными правами, не боясь повредить основную систему

OpenCode — особый случай: он работает по архитектуре клиент-сервер (сервер поднимается на вашей машине, терминал — клиент), что позволяет подключаться удалённо без дополнительных инструментов. OpenCode поддерживает практически любую модель от любого провайдера и имеет GUI с просмотром файлов проекта и встроенной поддержкой Git Worktrees.

Уровень 4: CoWork-решения и GUI-обёртки

В 2025 году появилось движение по созданию графических интерфейсов для терминальных агентов. Первым был Claude CoWork — по сути, тот же Claude Code в красивой обёртке. Затем OpenAI, MiniMax и open-source-сообщество создали свои варианты. IONUI — универсальный GUI, который работает по протоколу MCP и поддерживает любого установленного на компьютере агента, включает Telegram-интеграцию для работы через мессенджер.

Транскрибация речи: диктуйте задачи агенту

Многие IDE поддерживают голосовой ввод нативно. Claude Code недавно добавил поддержку микрофона прямо в терминале. Для других агентов можно использовать сторонние инструменты: как облачные сервисы (высокое качество, платно), так и локальные модели типа Whisper (бесплатно, работают без GPU, занимают от 100 МБ до 3+ ГБ в зависимости от модели). Локальная Whisper отлично распознаёт русский, английский, смешение языков, расставляет пунктуацию.

Модели и тарифные планы: как не переплатить

Выбор модели — одно из ключевых решений при внедрении AI-Driven Development. Нет универсальной «лучшей» модели: у каждой свои сильные стороны, скорость и стоимость.

Топовые модели для разработки (2025–2026)

• Claude (Anthropic) — сильнейший в понимании контекста, архитектурных решениях и следовании инструкциям. Лидер для задач планирования и проектирования.
• OpenAI Codex / GPT-серия — высокое качество кода, особенно с появлением GPT-5, который стал «точкой перелома» для всей отрасли. Codex специализирован именно на коде.
• MiniMax — лидер по соотношению цена/качество среди китайских моделей. По словам Антона Керпа: «MiniMax у нас вообще закуплен на всю компанию: раздали разработчикам, гейм-дизайнерам, тестировщикам, вообще всем поставили агентов». Для задач по спецификации справляется не хуже топовых моделей, при этом существенно дешевле.
• Qwen (Alibaba), Kimi (Moonshot AI) — сильные альтернативы, предоставляют подписки с доступом к нескольким моделям сразу.

Coding plans vs. токены: когда что выгоднее

Традиционные тарифы продают «корзину токенов» на месяц. Coding plans (появились с Claude Code в 2024 году) работают иначе: они дают лимит запросов в рамках временных окон — 5-часовых, недельных, месячных. Если вы используете агентов активно (несколько сессий в день), coding plan окажется значительно выгоднее. Если запускаете агента раз в неделю — традиционный токенный тариф экономичнее.

Лидеры coding plans: Anthropic (Claude) и OpenAI (Codex). Китайские провайдеры предлагают более высокие лимиты по более низкой цене, но топовые западные модели пока выигрывают по качеству архитектурных решений.

Правило выбора модели по задаче

Используйте самую дорогую мощную модель (Claude, GPT-5) для планирования, проектирования архитектуры и сложного дебаггинга. Для рутинного кодинга по спецификации, написания тестов, рефакторинга — берите более дешёвые модели (MiniMax, Qwen): они справляются не хуже и стоят в разы меньше.

Принципы работы с агентами: промтинг и context engineering

Эффективность работы с AI-агентами определяется прежде всего умением правильно ставить задачи. Это не «набирать правильные слова в строке поиска» — это полноценная инженерная дисциплина.

Промтинг как базис

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

• Chain-of-Thought — просите модель рассуждать вслух перед финальным ответом
• Few-Shot — давайте 2–3 примера желаемого результата
• Role Prompting — «Ты senior Unity developer с опытом в мобильном гейм-дизайне...»
• Negative Instructions — явно указывайте, чего делать не нужно
• Structured Output — просите вывод в заданном формате (JSON, markdown, таблица)

Context Engineering: управление контекстом агента

Context Engineering — более высокий уровень по сравнению с промтингом. Это дисциплина по управлению тем, что именно попадает в контекстное окно агента в каждый момент времени. Включает:

• Селективная передача файлов: не бросайте всю кодовую базу в контекст — передавайте только релевантные для задачи файлы
• Структурированная документация: архитектурные решения, соглашения команды, технический стек должны быть описаны так, чтобы агент мог их самостоятельно прочитать и применить
• Контроль «засорения»: удаляйте из контекста неудачные ответы (откат, а не продолжение диалога)
• Инструменты поиска: подключайте к агенту векторный поиск по кодовой базе, чтобы он сам находил нужные файлы

Менеджерский подход к агентам

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

Задача хорошего менеджера при работе с агентом — создать среду, в которой у агента:

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

Это ровно то же самое, что делает хороший менеджер для живых сотрудников. Инструменты разные — принципы одинаковые.

Memory Bank: управление знаниями проекта

Memory Bank — методология структурированного управления документацией проекта специально для работы с AI-агентами. Каждый раз, когда вы начинаете новую сессию с агентом, он «забывает» всё из предыдущей (если не предусмотрено иное). Memory Bank решает эту проблему.

Что хранить в Memory Bank

Создайте отдельную директорию в проекте (например, memory/ или .ai/) и собирайте туда всю метаинформацию, которая агенту недоступна из кода:

• Архитектурные решения: почему выбрана та или иная структура, какие альтернативы были отклонены
• Командные соглашения: стиль кода, naming conventions, паттерны, которые приняты в команде
• Технический стек: версии зависимостей, внешние сервисы, инфраструктура
• User stories и задачи: описания фич с контекстом и приоритетами
• Workflows: пошаговые инструкции для типовых операций (деплой, ревью, создание новой фичи)
• Известные проблемы: технический долг, известные баги, ограничения

Рабочий цикл с Memory Bank

1. Начало сессии: агент читает Memory Bank, обновляет контекст
2. Работа над задачей
3. Конец сессии: агент обновляет Memory Bank с новыми решениями и артефактами

Это двусторонний процесс — агент не только читает Memory Bank, но и актуализирует его. Это ключевое отличие от статической документации. Существуют готовые фреймворки для реализации Memory Bank (например, для Claude Code есть CLAUDE.md-конвенция), но структуру можно выстроить самостоятельно.

Диаграммы и Mermaid

Современные LLM отлично работают с диаграммами и схемами. Особенно хорошо поддерживается Mermaid — текстовый язык разметки диаграмм. Описывайте архитектуру в Mermaid внутри Memory Bank: агент сможет «увидеть» структуру вашего проекта как граф зависимостей, а IDE-плагины красиво отрисуют диаграммы для людей.

Архитектура проекта для AI-разработки

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

Древовидная архитектура как стандарт

Оптимальная архитектура для AI-Driven Development в игровых проектах — древовидная: все зависимости выстраиваются в дерево от корневого узла. Чем глубже по дереву — тем более высокоуровневые фичи. Пример для Unity-проекта:

EntryPoint
├── Core Architecture (State Machine, DI Container)
│   ├── Auth Module
│   ├── Core Gameplay
│   │   ├── Player Controller
│   │   ├── Level Manager
│   │   └── Physics System
│   ├── Meta Gameplay
│   │   ├── Shop
│   │   ├── Offers
│   │   └── Progression
│   └── Infrastructure
│       ├── Analytics
│       └── Remote Config

Ключевые принципы:

• Каждый узел-модуль независим: модуль Shop не знает о модуле Offers напрямую — они взаимодействуют только через родителя
• Изолированность позволяет работать в одном узле, не боясь сломать другие
• DI-фреймворки (Zenject, VContainer) строят именно такое дерево зависимостей — это дополнительный довод в пользу их использования

Разграничение ответственности: архитектура — разработчикам, фичи — агентам

Это принципиальная граница при AI-Driven Development:

• «Ствол дерева» (архитектура) — ответственность разработчиков. Агент не должен трогать ядро архитектуры без явного задания.
• «Листья» (конкретные фичи) — зона ответственности агентов. Здесь они работают автономно.

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

Технический долг в «стволе» — это катастрофа при AI-разработке. Агент будет разносить его по всему проекту. Следите за чистотой архитектурного ядра строго.

Feedback Loop: ключ к автономной работе агента

Feedback Loop (цикл обратной связи) — один из самых важных элементов AI-Driven Development. Именно он определяет, насколько автономно может работать агент без вашего участия.

Что такое Feedback Loop в разработке

Схема проста: агент работает → взаимодействует со средой → получает обратную связь → корректирует действия. Без обратной связи агент «слеп»: не знает, правильно ли написан код, компилируется ли он, проходят ли тесты.

Источники обратной связи для агента:

• Компилятор и линтеры — немедленная реакция на синтаксические и статические ошибки
• Unit-тесты — проверка корректности логики
• Логи и результаты запусков — динамическое поведение приложения
• Статические анализаторы — качество кода, потенциальные уязвимости
• Скриншоты и данные из браузера — визуальный результат для UI-задач

Почему тесты — обязательное условие

Агенты умеют генерировать unit-тесты быстро и качественно. Это само по себе ценно — но главное, что тесты замыкают feedback loop: агент пишет код, запускает тесты, видит провалы, исправляет. Без тестов агент не знает, сломал ли он что- то, поэтому каждое изменение требует ручной проверки. При AI-Driven Development наличие тестов — не опция, а базовая инфраструктура.

Автоматизация проверок

Идеальный feedback loop для агентной разработки:

1. Агент пишет код
2. Автоматически запускается компилятор / линтер → агент видит ошибки компиляции
3. Запускаются unit-тесты → агент видит провалы
4. Запускаются интеграционные тесты → агент видит системные проблемы
5. Если всё зелёное — агент рапортует о завершении задачи

Настройка полноценного feedback loop — серьёзная инженерная задача, сильно зависящая от вашего стека и проекта. Но даже минимальный вариант (компилятор + базовые тесты) кратно повышает автономность агента.

Работа с агентами в команде: внедрение и сопротивление

Самый сложный аспект AI-Driven Development — не технический, а человеческий. Внедрение ИИ-инструментов в команду неизбежно сталкивается с сопротивлением.

Типичное сопротивление и как с ним работать

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

Что работает:

• Не давить, а дать попробовать — выберите задачу, которую человек сам считает скучной (merge-конфликты, написание тестов, документация). После первого успешного опыта вопросы исчезают.
• Показывать цифры — конкретные сравнения «с агентом/без агента» на реальных задачах убеждают лучше любых докладов.
• Нормализовать неудачи пилота — заранее договоритесь, что «провалиться» на пилотном запуске — это нормально и ценно. Иначе команда будет скрывать проблемы, чтобы не выглядеть некомпетентной.

Культурный сдвиг: инженерная культура растёт

Парадокс AI-Driven Development: агенты не просто ускоряют работу — они повышают инженерную культуру команды. Агенты вынуждают:

• Больше заниматься проектированием до начала кодинга
• Писать детальную документацию (агент без документации работает плохо)
• Обсуждать неявные договорённости, которые раньше существовали «в головах» старших разработчиков
• Плотнее взаимодействовать с гейм-дизайнерами и другими отделами при формировании требований
• Создавать больше инструментов автоматизации — агенты делают это быстро

Правило ответственности за код

Критически важное правило: автор коммита отвечает за код, независимо от того, кто его написал — человек или агент. Без этого правила разработчики перестают читать код агента перед мержем, что рано или поздно приводит к инцидентам в проде.

Распределение ролей в AI-команде

При AI-Driven Development смещается фокус работы разработчика: меньше написания кода → больше проектирования, управления и ревью. Это требует переосмысления роли: разработчик становится ближе к архитектору и техническому менеджеру, чем к «кодеру».

Параллельная работа агентов

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

Настройки агентов: Rules, Skills, субагенты, протоколы

Зрелая настройка AI-агентов в команде включает:

• Rules (правила) — системные инструкции, которые агент соблюдает всегда: стиль кода, запрещённые паттерны, обязательные проверки
• Skills (навыки) — специализированные инструкции для конкретных типов задач: «как создать новый UI-компонент», «как написать unit-тест», «как провести ревью PR»
• Субагенты — специализированные агенты для конкретных задач (тестирование, документация, ревью), которые оркестратор вызывает по необходимости
• Протоколы взаимодействия — стандарты передачи задач между агентами (например, MCP — Model Context Protocol, открытый стандарт Anthropic)

ИИ и Unity: текущее состояние интеграции

Для геймдев-команд, работающих с Unity, интеграция ИИ-агентов имеет свою специфику. Большой проблемой остаётся именно взаимодействие с редактором.

Текущее состояние

Интеграции существуют, но оставляют желать лучшего. MCP-сервер для Unity (Unity MCP) позволяет агенту взаимодействовать с редактором через протокол MCP: создавать GameObjects, запускать Play Mode, вызывать функции редактора. Но стабильность и возможности по-прежнему ограничены. Многие команды до сих пор изобретают собственные велосипеды для более комфортной работы агентов с Unity.

Что работает хорошо

• Написание C#-кода по спецификации — агенты справляются отлично
• Генерация unit-тестов для игровой логики
• Создание ScriptableObject-конфигураций
• Рефакторинг и оптимизация кода
• Документирование систем
• Написание инструментов редактора (EditorWindow, PropertyDrawer)

Что пока требует ручного участия

• Работа со сценами — размещение объектов, настройка компонентов в Inspector
• Отладка визуальных/физических проблем (агент не «видит» сцену)
• Настройка анимационных машин состояний в Animator
• Работа с системой шейдеров

Лучшая практика для Unity + AI

Разделите проект так, чтобы максимум игровой логики был в чистом C# (без MonoBehaviour там, где это возможно). Чем меньше кода завязано на Unity API, тем лучше агент с ним справляется и тем проще написать тесты.

Риски и подводные камни AI-Driven Development

AI-Driven Development — мощный инструмент, но при неправильном применении он становится источником серьёзных проблем.

Технический долг в архитектуре

Уже описанный выше риск: агент не исправляет технический долг, который не входит в текущее задание, — он его обходит. Обходя, порождает новый долг. Держите архитектурное ядро чистым.

«Нейрослоп»: генерация мусора без контроля

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

Накопление контекстного «мусора»

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

Конфиденциальность и безопасность

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

Зависимость от агента снижает знания команды

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

FAQ

Что такое AI-Driven Development простыми словами?

AI-Driven Development — это подход, при котором ИИ-агенты становятся полноценными участниками разработки: пишут код, исправляют баги, генерируют тесты и ведут документацию, работая автономно или под минимальным руководством разработчика. Разработчик при этом смещается от написания кода к проектированию, постановке задач и ревью.

С чего начать внедрение AI-агентов в геймдев-команду?

Начните с малого: выберите один тип рутинных задач (написание unit-тестов, документирование кода, создание инструментов редактора) и запустите пилот с добровольцами из команды. Установите Claude Code, Codex или OpenCode, выберите подходящую модель и дайте им конкретную, хорошо описанную задачу с чёткими критериями приёмки. Итерируйте, документируйте результаты, расширяйте применение постепенно.

Нужно ли разработчику знать промтинг?

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

Как AI-агенты влияют на скорость разработки игр?

Влияние неоднородно. На задачах по написанию кода по готовой спецификации ускорение реально и значительно (на новых проектах — до 2-3x). На задачах с высокой долей проектирования и архитектурных решений ускорение меньше. На задачах с плохо описанными требованиями агент может замедлить работу. Общий эффект для команды, которая правильно выстроила процессы, — существенный рост пропускной способности без соответствующего роста численности.

Что такое Memory Bank и зачем он нужен в геймдеве?

Memory Bank — структурированная система документации проекта, которую агент читает в начале каждой сессии и обновляет по завершении. В геймдеве это особенно важно из-за специфики игровых проектов: сложные архитектурные решения, нестандартные паттерны, игровые механики с неочевидными зависимостями. Memory Bank позволяет агенту работать с вашим конкретным проектом, а не с «усреднённым Unity-проектом из интернета».

Как обеспечить качество кода, который написал агент?

Несколько уровней контроля: автоматические проверки (компилятор, линтер, статический анализатор) дают мгновенную обратную связь; unit-тесты проверяют логику; обязательное ревью разработчиком перед мержем обеспечивает человеческий контроль. Правило «автор коммита отвечает за код независимо от того, кто его написал», — фундаментальное. Никогда не мержьте код агента без прочтения.

Какие модели лучше всего подходят для разработки на Unity (C#)?

Claude 3.5+ и GPT-4o / Codex показывают лучшее качество для сложных архитектурных задач на C#. MiniMax — хорошая альтернатива для задач по спецификации при существенно меньшей стоимости. Для простых повторяющихся задач (генерация тестов, создание DTO-классов) подойдёт любая из современных моделей.

---

Ресурсы:

• Документация из доклада: funzen.slite.page — AI Notebook
• Блог автора в Telegram: @aks2dio
• McKinsey: The economic potential of generative AI
• Anthropic Model Context Protocol: modelcontextprotocol.io