Як це зроблено

Один розробник, ШІ-помічник для програмування та безліч правил, які перевіряє машина.

Автор: 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 тіках на секунду. Це мета: персонажів поки немає, тож запускач бенчмарків існує, але в такому масштабі нічого не вимірювалося.