Автор игры с ИИ-агентом: 30 зелёных тестов ничего не доказывали, пока не написал новый

Знакомая ситуация: вы в третий раз объясняете агенту одно и то же, а он в четвёртый раз делает по-своему. Автор стратегии Age of Poleis, где код пишет ИИ, а он сам придумывает, решает и играет, описал, как вылез из этого цикла. Его опыт полезен всем, кто доверяет агентам рутину.

Правило, способ и проверка

Стек такой: бэкенд на Django, интерфейс на React и TypeScript. Контракт описан на бэкенде, из него получается OpenAPI-схема, из схемы генерируются TypeScript-типы. Соблазн очевиден: тип на фронте не сходится с ответом API, и его хочется поправить руками, ведь это одна строка. Но при следующей генерации правка тихо исчезнет, а баг вернётся.

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

Формула простая: правило, способ его выполнить и проверка. Без проверки правило работает, пока агент о нём помнит. С проверкой работает всегда. Так же автор закрывает форматирование, локализацию и другую повторяющуюся рутину.

Тридцать зелёных тестов, которые проверяли не то

В Windows-версии игра запускалась тремя окнами: загрузка, игра и ожидание на выходе. Автор хотел одно окно, внутри которого идут загрузка и игра. На словах задача в одну строку, в коде это несколько состояний: запуск, загрузка, закрытие посреди запуска, сохранение, повторный старт.

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

Чтобы агент мог проверять результат сам, автор формулирует желаемое как наблюдаемые факты: загрузка и игра в одном окне, закрытие во время запуска не открывает новое окно, сохранённая кампания на месте после перезапуска. В итоге прошли 96 JavaScript-тестов, а агент отдельно прогнал настоящее Electron-приложение.

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

Что остаётся человеку

Когда техническая часть проверяется без автора, он играет с другими вопросами: не «работает ли кнопка», а «хочется ли её нажать». Механика может быть безупречной и скучной, а экономика легко превращается в бухгалтерию. Ни один тест этого не поймает. Подбор жителей под профессии был веселым первые минуты, а после сотни игровых периодов утомил, и в итоге появился автоподбор кандидатов по критериям.

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

Сборки, подписи, сертификация и маркетинг остаются за человеком. ИИ набросает описание за пять минут, но не решит, кому нужна игра и что показать первым.

Практический вывод

• Повторили объяснение дважды — превращайте его в правило и сразу в автоматическую проверку.
• Для изменения поведения пишите тест, который падает на старом коде.
• Требуйте от агента список непроверенного и доказательства состояния, а не просто скриншот.
• То, что можно измерить, отдавайте агенту. Вкус и ощущение «интересно» оставьте себе.