Как это сделано

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

Автор: Nick

Prison Life пишу я вместе с Claude Code (агентом для программирования от Anthropic). Я решаю, какой будет игра и какие варианты мы выбираем; основную часть набора текста делает помощник. Поскольку код никто не просматривает, кроме меня и ИИ-агента для ревью, я опираюсь на автоматизацию: правила обеспечиваются автоматическими проверками и сборкой, а не благими намерениями.

Делегирование

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

Роль	Уровень модели	Задача
Архитектура	Opus	модель данных, тик, потоки, поиск пути, решения
Код симуляции	Opus	системы симуляции, ИИ персонажей, горячие циклы
Производительность	Opus	профилирование, регрессии бенчмарка
Ревью (только чтение)	Opus	проверяет диф; файлы править не может
Клиент и инструменты	Sonnet	клиент на Godot, интерфейс, инструменты
Тесты	Sonnet	тесты по критериям приёмки
Данные контента	Sonnet	определения в JSON по схеме
Поиск, запуск проверок	Haiku	поиск по коду; запуск проверок и краткое изложение сбоев

Сложная работа достаётся самой сильной модели, рутинная – более дешёвым. Если более дешёвый ИИ-агент дважды проваливает проверки, задача переходит на уровень выше; если дважды проваливается высший уровень, он останавливается и спрашивает меня.

Хуки, которые говорят «нет»

Хуки Claude Code – это скрипты, которые запускаются вокруг действий помощника. Мои обеспечивают три правила:

• Нельзя закончить на красном. Когда сессия или ИИ-агент пытается остановиться после изменения кода, хук запускает быструю проверку (сборка плюс быстрые тесты). Если она не проходит, остановка отклоняется.
• Основная сессия не может править код. Хук отклоняет записи в исходники, тесты, контент и инструменты из основной сессии.
• Ревьюер работает только на чтение. Его инструменты правки убраны, а хук отклоняет команды, меняющие файлы или историю проекта.

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

Письменные решения и проверки

• Каждый нетривиальный выбор записывается. Задачи, этапы и проектные решения хранятся обычным текстом рядом с кодом, в трекере задач. Когда мы выбираем между вариантами, затрагивающими больше одной задачи, выбор записывается вместе с контекстом и последствиями.
• Проверки работают на моей машине. Никакого облачного CI. Один локальный скрипт имеет четыре режима: fast, test, bench и full. Скрипты и хуки – на PowerShell 7 и в Windows, и в macOS.
• Проверки на каждое изменение. Локальная автоматизация отклоняет изменение, если оно плохо описано или плохо отформатировано. Для изменений кода она ещё запускает быструю проверку; изменения, затрагивающие только заметки или сайт, пропускают сборку.
• Эталонные файлы защищены. Закреплённые хеши детерминизма, эталонные файлы сохранений и базовая линия бенчмарка меняются только с моего явного согласия, никогда молча.
• Источник истины – сам проект. Локальный инструмент памяти индексирует проект и прошлые разговоры для поиска, но всё важное при этом ещё и задача, записанное решение или документ.

Детерминированное ядро

Симуляция живёт в обычной библиотеке .NET без ссылок на Godot; клиент на Godot только читает её состояние и отправляет команды. Ядро подчиняется жёстким правилам: мир меняется только командами, время – целые тики, случайность берётся только из генераторов мира с сидом. Один и тот же сид и один и тот же журнал команд должны давать один и тот же мир. Эти правила проверяются компилятором и тестами, а не только ревью; как именно, см. девлог №1, а о мире, сохранениях и повторах – девлог №2.

• Команды – единственный путь внутрь. У каждой есть стабильный идентификатор типа и бинарное кодирование, и каждая команда попадает в журнал вместе с результатом, включая отклонённые.
• Тик состоит из трёх фаз в фиксированном порядке. Порядок систем задан в одном месте кода, и его изменение меняет каждый хеш.
• Случайность идёт от наших собственных генераторов (SplitMix64 и xoshiro256**). Именованные потоки выводятся из сида мира и хранятся в состоянии мира. Генератор без состояния с ключом из домена, ключа и тика обслуживает работу, где порядок не важен.
• Хеш состояния – 64-битный хеш, чувствительный к порядку, для проверок детерминизма. Он не криптографический.
• Мир – сетка клеток 1×1 м на дискретных уровнях; стены, двери и полы меняются только командами строительства.
• Сохранения и повторы используют один проверяемый файловый контейнер. Повтор – это сид плюс журнал команд с контрольными хешами по ходу, и при воспроизведении он проверяется шаг за шагом.
• Бенчмарки идут от безголового запускателя сценариев с базовой линией для каждой машины и порогом «ноль выделений на тик».

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