Jak to powstaje

Jeden programista, asystent programistyczny oparty na SI i mnóstwo reguł sprawdzanych przez maszynę.

Autor: Nick

Prison Life piszę razem z Claude Code (agentem programistycznym Anthropic). Ja decyduję, czym jest gra i które opcje wybieramy; asystent wykonuje większość pisania. Ponieważ nikt poza mną i agentem SI do przeglądu nie ogląda kodu, polegam na automatyzacji: reguły są egzekwowane przez automatyczne kontrole i build, a nie dobre chęci.

Delegowanie

Główna sesja Claude Code planuje pracę i prowadzi system zadań, spisane decyzje projektowe oraz historię zmian. Nie pisze kodu: każdą zmianę, nawet drobną, przekazuje wyspecjalizowanemu agentowi SI. Każdy z nich ma własną spisaną definicję, która określa jego rolę i model.

Rola	Poziom modelu	Zadanie
Architektura	Opus	model danych, tick, wątki, wyszukiwanie ścieżek, decyzje
Kod symulacji	Opus	systemy symulacji, SI postaci, gorące pętle
Wydajność	Opus	profilowanie, regresje benchmarku
Przegląd (tylko odczyt)	Opus	przegląda diff; nie może edytować plików
Klient i narzędzia	Sonnet	klient Godot, interfejs, narzędzia
Testy	Sonnet	testy z kryteriów akceptacji
Dane treści	Sonnet	definicje JSON ze schematu
Wyszukiwanie, uruchamianie kontroli	Haiku	wyszukiwanie w kodzie; uruchamianie kontroli i streszczanie błędów

Trudna praca trafia do najsilniejszego modelu, rutynowa do tańszych. Jeśli tańszy agent SI dwa razy nie przejdzie kontroli, zadanie przechodzi poziom wyżej; jeśli dwa razy zawiedzie najwyższy poziom, zatrzymuje się i pyta mnie.

Hooki, które mówią „nie”

Hooki Claude Code to skrypty uruchamiane wokół działań asystenta. Moje egzekwują trzy reguły:

• Nie wolno skończyć na czerwono. Gdy sesja lub agent SI próbuje się zatrzymać po zmianie kodu, hook uruchamia szybką kontrolę (build plus szybkie testy). Jeśli zawiedzie, zatrzymanie jest odrzucane.
• Główna sesja nie może edytować kodu. Hook odrzuca zapisy do źródeł, testów, treści i narzędzi z głównej sesji.
• Recenzent ma tylko odczyt. Jego narzędzia edycji są usunięte, a hook odrzuca polecenia zmieniające pliki lub historię projektu.

Chronią one przed pomyłkami, a nie przed celowym obejściem: uparta sztuczka z powłoką potrafi je ominąć, a jeden z hooków widzi czerwoną kontrolę u agenta SI, ale nie może go powstrzymać (hook zatrzymania głównej sesji i tak ją wyłapie). Wolę powiedzieć to wprost.

Spisane decyzje i kontrole

• Każdy nietrywialny wybór jest spisany. Zadania, kamienie milowe i decyzje projektowe są przechowywane jako zwykły tekst obok kodu, w systemie zadań. Gdy wybieramy między opcjami, które dotyczą więcej niż jednego zadania, wybór jest zapisywany wraz z kontekstem i konsekwencjami.
• Kontrole działają na moim komputerze. Bez chmurowego CI. Jeden lokalny skrypt ma cztery tryby: fast, test, bench i full. Skrypty i hooki to PowerShell 7 zarówno w Windows, jak i w macOS.
• Kontrole przy każdej zmianie. Lokalna automatyzacja odrzuca zmianę, która jest źle opisana lub źle sformatowana. Przy zmianach kodu uruchamia też szybką kontrolę; zmiany dotyczące tylko notatek lub strony pomijają build.
• Pliki referencyjne są chronione. Przypięte skróty determinizmu, wzorcowe pliki zapisu i punkt odniesienia benchmarku zmieniają się tylko za moją wyraźną zgodą, nigdy po cichu.
• Źródłem prawdy jest sam projekt. Lokalne narzędzie pamięci indeksuje projekt i dawne rozmowy na potrzeby wyszukiwania, ale wszystko, co ważne, jest też zadaniem, zapisaną decyzją lub dokumentem.

Deterministyczny rdzeń

Symulacja mieszka w zwykłej bibliotece .NET bez odwołań do Godota; klient Godot tylko czyta jej stan i wysyła komendy. Rdzeń podlega sztywnym regułom: świat zmienia się tylko przez komendy, czas to całkowite ticki, a losowość pochodzi wyłącznie z generatorów świata z ziarnem. To samo ziarno i ten sam dziennik komend muszą dać ten sam świat. Te reguły sprawdzają kompilator i testy, a nie tylko przegląd; jak to działa, opisuje devlog #1, a świat, zapisy i powtórki – devlog #2.

• Komendy to jedyna droga do środka. Każda ma stały identyfikator typu i kodowanie binarne, a każda komenda trafia do dziennika razem z wynikiem, także odrzucone.
• Tick ma trzy fazy w stałej kolejności. Kolejność systemów jest ustawiona w jednym miejscu w kodzie, a jej zmiana zmienia każdy skrót.
• Losowość pochodzi z naszych własnych generatorów (SplitMix64 i xoshiro256**). Nazwane strumienie są wyprowadzane z ziarna świata i przechowywane w stanie świata. Bezstanowy generator kluczowany domeną, kluczem i tickiem obsługuje pracę niezależną od kolejności.
• Skrót stanu to 64-bitowy skrót wrażliwy na kolejność, służący do kontroli determinizmu. Nie jest kryptograficzny.
• Świat to siatka kafelków 1×1 m na dyskretnych poziomach; ściany, drzwi i podłogi zmieniają się tylko komendami budowania.
• Zapisy i powtórki dzielą jeden sprawdzany kontener plikowy. Powtórka to ziarno plus dziennik komend ze skrótami kontrolnymi po drodze i jest sprawdzana krok po kroku przy odtwarzaniu.
• Benchmarki pochodzą z bezgłowego runnera scenariuszy z punktem odniesienia dla każdego komputera i bramką zera alokacji na tick.

Docelowo gra ma obsługiwać do 1000 więźniów i pracowników przy 20 tickach na sekundę. To cel: postaci jeszcze nie ma, więc runner benchmarków istnieje, ale w takiej skali niczego nie zmierzono.