ИИ собрал 3D-игру за сутки: чему на самом деле учит эксперимент с агентом и критиком
Бывший UX-инженер Apple Аншу Чимала устроил показательную проверку современного агентного программирования: дал модели пустой репозиторий, подключил Blender и попросил собрать браузерную игру про исследование космоса без готовых ассетов. Через сутки появился работающий проект примерно на сорок тысяч строк JavaScript, с кораблём, планетами и процедурно созданными сценами. История выглядит как очередное «ИИ заменил студию», но её самые полезные выводы лежат совсем в другом месте.
Сильный результат начался не с идеального промпта
Первая версия не стала финальной. Сначала агент самостоятельно настроил инструменты и сделал базовую модель корабля. Человек давал обратную связь, пока качество не стало приемлемым. Затем удачный процесс превратили в повторяемый навык, который модель использовала для следующих сцен. Это важнее магической формулировки: хороший результат появился благодаря накоплению рабочего контекста, проверкам и последовательным улучшениям.
Второй агент оказался не помощником, а независимым критиком
На следующем этапе отдельному агенту поручили сравнивать скриншоты проекта с визуальной планкой дорогих космических игр. Первый агент строил, второй искал слабые места: грубые модели, артефакты, освещение, интерфейс и переходы. Получился автоматизированный цикл «сделал — посмотрел глазами пользователя — сформулировал замечания — переделал».
Главная идея эксперимента — не один всезнающий ИИ, а разделение ролей: исполнитель не должен сам выставлять себе итоговую оценку.
Такой паттерн переносится далеко за пределы игр. Один агент может писать текст, а другой сверять факты и стиль. Один собирает интерфейс, другой проходит сценарии и ищет визуальные дефекты. Один пишет код, другой читает изменения как ревьюер. Независимая проверка не гарантирует качество, но заметно снижает риск, что система примет собственную ошибку за успех.
Сутки — впечатляюще, но это были очень дорогие сутки
По рассказу автора, агент работал непрерывно около 24 часов и сгенерировал порядка пяти миллионов выходных токенов, израсходовав значительную часть недельного лимита дорогой подписки. Поэтому сравнивать эксперимент с обычным рабочим днём разработчика некорректно. Это скорее ускоренный прогон команды из множества виртуальных итераций, оплаченных вычислениями.
Стоимость здесь измеряется не только подпиской. Нужно хранить длинный контекст, запускать браузерные проверки, управлять Blender, делать скриншоты и не давать агенту зацикливаться на одной задаче. Чимала несколько раз вмешивался именно потому, что модель могла слишком долго полировать отдельные планеты вместо движения к общей цели.
Прототип и продукт — всё ещё разные вещи
Внешне проект получился эффектным и доступен в браузере, но разработчики, посмотревшие репозиторий, спорят о поддерживаемости кода. Это знакомый компромисс генеративной разработки: модель умеет быстро связать множество деталей в работающую демонстрацию, однако архитектурный долг проявляется позже — при изменении механики, исправлении редкого бага или попытке добавить команду людей.
Поэтому правильный вопрос звучит не «может ли ИИ сделать игру?». Может — в смысле создать играбельный прототип. Гораздо интереснее другое: сколько стоит следующая неделя разработки, насколько легко заменить подсистему, можно ли воспроизвести сборку и кто поймёт код через три месяца. Эти критерии отделяют вау-демо от производства.
Как повторить подход в реальном проекте
Начинать лучше с узкой вертикали: один короткий, но полностью проходимый сценарий. Затем зафиксировать проверяемые критерии — частоту кадров, список поддерживаемых устройств, отсутствие ошибок в консоли, время загрузки. После каждой успешной итерации полезно сохранять не только код, но и навык: инструкции, примеры, команды проверки и известные ограничения.
Роль критика стоит отделять от исполнителя и давать ей наблюдаемые артефакты: скриншоты, видео прохождения, тестовые отчёты, метрики производительности. А человеку оставить право остановить цикл, поменять приоритет и решить, когда качество достаточно для следующего шага. Автономность полезна, пока цель и цена итерации остаются видимыми.
Главный вывод
Эксперимент не доказывает, что одному агенту можно передать разработку большой игры. Он показывает более практичную вещь: маленькая команда теперь способна за день проверить идею, на которую раньше ушли бы недели подготовки. Побеждает не тот, кто написал самый пафосный запрос, а тот, кто построил цикл работы — инструменты, память, независимую критику, измеримые проверки и своевременное человеческое решение.
Контрольный лист перед автономным запуском
До запуска стоит зафиксировать предел бюджета и времени, критерии готовности, запрещённые операции, команду остановки и частоту контрольных точек. Репозиторий должен собираться с нуля одной документированной командой, а каждое крупное изменение — проходить автоматические тесты и визуальную проверку.
После эксперимента полезно считать не только скорость появления демо. Запишите стоимость токенов и вычислений, количество ручных вмешательств, долю переделанного кода, время холодной сборки и число дефектов после смены механики. Эти показатели покажут, ускорил ли агент разработку или просто перенёс расходы на следующий этап.
Пока нет комментариев