AI Engineering Orchestrator: как эффективнее использовать дорогую ИИ-модель в разработке игр

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

Коротко

• Claude Code или Codex становится «тимлидом»; сами изменения в коде вносит Gemini (через Antigravity), а в качестве резерва — Cursor.
• Тимлид передаёт каждую задачу по письменному контракту на реализацию, сам проверяет вернувшийся код через git diff и тесты и выносит решение: ОДОБРЕНО или ТРЕБУЮТСЯ ИЗМЕНЕНИЯ.
• В замере самого проекта на одной задаче API-время дорогой модели сократилось с 8 мин 54 с до 3 мин 39 с; разработчик прямо пишет, что это единичный прогон и экономия не гарантируется.
• Лицензия MIT, установка одной командой из npm; инструмент затрагивает только настройки того проекта, в который установлен.

Для чего нужен AI Engineering Orchestrator?

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

AI Engineering Orchestrator (сокращённо AEO) пытается исправить этот перекос разделением труда. Тезис, как его формулирует сам проект, прост: дорогая модель решает, дешёвая пишет. Технически инструмент состоит из двух частей. MCP-мост даёт модели-тимлиду возможность вызывать другую модель, а файл политики, который добавляется в CLAUDE.md или AGENTS.md, определяет, когда этой возможностью пользоваться. Главная идея инструмента — различие между «используется, потому что инструмент есть» и «используется, потому что так велит правило».

Как с дешёвым доступом выжать больше из дорогой модели?

Слово «дешёвый» здесь относительное. Документация AEO это специально подчёркивает: модель может быть дешёвой именно для вас благодаря тарифу подписки, студенческой или корпоративной цене, региональному ценообразованию, акции или неиспользованной ёмкости уже оплаченного пакета. Для кого-то другого та же модель может оказаться невыгодной. Поэтому инструмент не объявляет «самой дешёвой» какую-то конкретную компанию; он лишь позволяет пользоваться самым выгодным из доступных вам и достаточно способным путём реализации.

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

Если на стороне Antigravity заканчивается квота, мост сначала пробует другие настроенные модели Gemini; если не помогает и это, политика перенаправляет тот же контракт в Cursor. Цель — не допустить, чтобы при затыке канала-исполнителя работа молча снова перетекала на дорогую модель.

Чем это полезно разработчикам игр?

Игровые проекты естественно вписываются в предлагаемое AEO разделение труда. В коде игры есть и немногочисленные, но дорогие решения (сетевая архитектура, авторитет сервера, система сохранений, правила экономики), и множество повторяющейся работы (новый экран меню, вариант правил для игрового режима, ключи локализации, недостающие тесты, рефакторинг). По логике AEO первая группа остаётся у ведущей модели, вторая уходит исполнителю.

• Небольшие команды и студии из одного человека: инди-разработчик одновременно дизайнер, программист и тестировщик. Если беречь лимит дорогой модели для архитектуры и отладки, а рутинную работу над фичами передавать, снижается риск, что к концу месяца лимит закончится.
• Мультиплеер и серверный код: в вопросах конкурентности, сессий и прав доступа политика рекомендует подключать независимого агента-ревьюера (reviewer). В этих областях, где ошибка обходится дорого, второй взгляд надёжнее, чем одна модель, одобряющая собственную работу.
• Игровая логика с тестами: движки правил, подсчёт очков, матчмейкинг и серверную валидацию можно проверять headless-тестами. Здесь шлюз качества AEO работает лучше всего, потому что ведущая модель смотрит не на фразу «тесты прошли», а на тест, который запустила сама.
• Параллельные задачи: две не пересекающиеся задачи, например игровой режим и экран статистики, можно одновременно отдать двум исполнителям в отдельных git worktree. Изменения попадают в основное рабочее дерево по одному и только после одобрения лидера.

Честная оговорка: визуальные ощущения, тайминг анимаций или вопрос «а весело ли играть» тестом не поймать. Шлюз качества AEO проверяет код на соответствие контракту; качество геймплея по-прежнему придётся оценивать, играя самому. Документация инструмента признаёт похожее ограничение: если ошибка проектирования заложена в сам контракт, код, который в точности её воспроизводит, пройдёт проверку.

Почему важен шлюз качества?

Известный риск передачи работы дешёвой модели — отчёт «готово», который не соответствует действительности. Поэтому AEO считает отчёт исполнителя доказательством, а не одобрением. Перед началом работы ведущая модель фиксирует исходное состояние через git status; когда работа возвращается, она сама изучает разницу, изменённые файлы и тесты. Тест, который исполнитель не смог запустить из-за ограничения прав, не засчитывается как пройденный. У решения два варианта: ОДОБРЕНО или ТРЕБУЮТСЯ ИЗМЕНЕНИЯ. Во втором случае замечания вместе с доказательствами отправляются обратно тому же исполнителю.

У этой дисциплины есть и побочная польза: благодаря зафиксированному исходному состоянию незакоммиченные изменения самого пользователя остаются под защитой — лидер не трогает изменение, владельца которого не может подтвердить. Кроме того, примеры разрешений по умолчанию запрещают трудно обратимые git-команды вроде push, reset, rebase, merge и commit.

Что показывает реальный замер?

В README проекта исправление ошибки с токеном обновления (refresh token) в API на Laravel замерено дважды: один раз с делегированием и один раз в контрольном прогоне, из которого убрали инструменты делегирования. Использовались один и тот же коммит и один и тот же промпт.

Показатель	С делегированием	Без делегирования
API-время дорогой модели	3 мин 39 с	8 мин 54 с
Расчётная стоимость	3,60 доллара	4,32 доллара
Стоимость модели-исполнителя	В отдельной подписке, в счёт не включена	Нет
Общее время ожидания	Примерно на 30% дольше	Короче
Источник	README проекта, октябрь 2026	По одному прогону на каждый вариант (n=1)

Разработчик не преувеличивает результат: разница в долларах составляет 17%, и она есть только потому, что исполнитель оплачивался отдельной подпиской. Главный выигрыш — во времени использования дорогой модели: примерно на 59% меньше. В подписке с лимитом использования сдерживает как раз это ограничение. Зато из-за передачи задач исполнителю и обратно работа заняла примерно на 30% больше времени, а оба прогона дали исправление сходного качества. Общий процент экономии из одного замера не вывести; проект предлагает скрипт и методику, чтобы вы измерили собственный случай.

Как установить?

Требования: Node.js 20 или новее, CLI Antigravity с выполненным входом (agy) и Claude Code или Codex в роли тимлида. Установка начинается с пробного запуска (dry run): он показывает, что изменится, не записывая ни одного файла. Затем команда npx ai-engineering-orchestrator@latest install --target . --claude (или --codex) добавляет в проект политику, определения агентов и MCP-сервер; команда doctor проверяет установку. Резервные копии изменённых общих файлов хранятся в папке пользователя, а глобальные настройки затрагиваются, только если явно указать --global.

Раскрытие информации: AI Engineering Orchestrator — открытый проект разработчика GAMEAREA Акифа Шена, и он используется в собственном процессе разработки GAMEAREA. Цифры замера в этой статье взяты из документации самого проекта; это не независимый тест. О том, как мы используем ИИ в блоге, мы рассказываем на странице принципов использования ИИ.

Часто задаваемые вопросы

AI Engineering Orchestrator платный?

Нет. Проект распространяется по лицензии MIT и бесплатно устанавливается через npm. Тарифы подписки или оплата за использование самих ИИ-сервисов (Claude, Codex, Gemini, Cursor) действуют отдельно.

Гарантирует ли он экономию денег?

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

С какими игровыми движками он работает?

Инструмент — не плагин для движка, он работает на уровне репозитория. В принципе тот же процесс применим к любой кодовой базе, которую понимают используемые вами модели, будь то Unity, Godot или веб-игра; а надёжность проверки зависит от тестов в проекте.

Что будет, если модель-исполнитель сломает мой код?

Пока изменение не одобрено, работа не считается завершённой. Ведущая модель изучает diff и тесты и может вынести решение ТРЕБУЮТСЯ ИЗМЕНЕНИЯ; при параллельной работе изменения остаются в отдельном worktree и применяются к основному рабочему дереву только после одобрения. Коммиты, push и подобные операции по умолчанию запрещены.

Источники

1. akifsen / GitHub — AI Engineering Orchestrator (README) Официальный источник
2. akifsen / GitHub — Cost-aware routing Официальный источник
3. akifsen / GitHub — Quality gate Официальный источник
4. npm — ai-engineering-orchestrator Официальный источник