Wie es entsteht

Ein Entwickler, ein KI-Programmierassistent und viele maschinell geprüfte Regeln.

Von Nick

Prison Life schreibe ich zusammen mit Claude Code (dem Programmieragenten von Anthropic). Ich entscheide, was das Spiel ist und welche Wege wir gehen; der Assistent übernimmt das meiste Tippen. Weil niemand außer mir und einem KI-Agenten für Reviews den Code prüft, setze ich auf Automatisierung: Regeln werden von automatischen Prüfungen und vom Build durchgesetzt, nicht von guten Absichten.

Delegation

Die Haupt-Session von Claude Code plant die Arbeit und führt den Aufgaben-Tracker, die schriftlichen Designentscheidungen und die Änderungshistorie. Code schreibt sie nicht: Jede Änderung, auch die kleinste, gibt sie an einen spezialisierten KI-Agenten weiter. Jeder hat eine eigene schriftliche Definition, die seine Rolle und sein Modell festlegt.

Rolle	Modellstufe	Aufgabe
Architektur	Opus	Datenmodell, Tick, Threads, Wegfindung, Entscheidungen
Simulationscode	Opus	Simulationssysteme, KI der Figuren, heiße Schleifen
Performance	Opus	Profiling, Benchmark-Regressionen
Review (nur lesend)	Opus	prüft einen Diff; kann keine Dateien bearbeiten
Client und Werkzeuge	Sonnet	Godot-Client, UI, Werkzeuge
Tests	Sonnet	Tests nach Abnahmekriterien
Inhaltsdaten	Sonnet	JSON-Definitionen nach einem Schema
Suche, Prüfungen ausführen	Haiku	Codesuche; Prüfungen ausführen und Fehler zusammenfassen

Schwere Arbeit geht an das stärkste Modell, Routinearbeit an günstigere. Scheitert ein günstigerer KI-Agent zweimal an den Prüfungen, wandert die Aufgabe eine Stufe höher; scheitert die oberste Stufe zweimal, hält sie an und fragt mich.

Hooks, die Nein sagen

Hooks in Claude Code sind Skripte, die rund um die Aktionen des Assistenten laufen. Meine setzen drei Regeln durch:

Kein Abschluss auf Rot. Wenn eine Session oder ein KI-Agent nach einer Codeänderung aufhören will, führt ein Hook die schnelle Prüfung aus (Build plus schnelle Tests). Schlägt sie fehl, wird das Aufhören verweigert.
Die Haupt-Session kann keinen Code bearbeiten. Ein Hook lehnt Schreibzugriffe der Haupt-Session auf Quellcode, Tests, Inhalte und Werkzeuge ab.
Der Reviewer ist nur lesend. Seine Bearbeitungswerkzeuge sind entfernt, und ein Hook lehnt Befehle ab, die Dateien oder die Projekthistorie ändern.

Sie schützen vor Fehlern, nicht vor absichtlichem Umgehen: Ein entschlossener Shell-Trick kommt an ihnen vorbei, und einer der Hooks sieht eine rote Prüfung bei einem KI-Agenten, kann ihn aber nicht aufhalten (der Stop-Hook der Haupt-Session fängt es trotzdem ab). Das sage ich lieber offen.

Schriftliche Entscheidungen und Prüfungen

Jede nicht triviale Entscheidung wird aufgeschrieben. Aufgaben, Meilensteine und Designentscheidungen liegen als einfacher Text neben dem Code, in einem Aufgaben-Tracker. Wenn wir zwischen Optionen wählen, die mehr als eine Aufgabe betreffen, wird die Wahl mit Kontext und Folgen festgehalten.
Prüfungen laufen auf meinem Rechner. Kein Cloud-CI. Ein lokales Skript hat vier Modi: fast, test, bench und full. Skripte und Hooks sind PowerShell 7, unter Windows wie unter macOS.
Prüfungen bei jeder Änderung. Lokale Automatisierung lehnt eine Änderung ab, die schlecht beschrieben oder schlecht formatiert ist. Bei Codeänderungen führt sie außerdem die schnelle Prüfung aus; Änderungen, die nur Notizen oder die Website betreffen, überspringen den Build.
Referenzdateien sind geschützt. Festgeschriebene Determinismus-Hashes, Golden-Spielstände und die Benchmark-Basislinie ändern sich nur mit meiner ausdrücklichen Zustimmung, nie stillschweigend.
Das Projekt selbst ist die Quelle der Wahrheit. Ein lokales Gedächtniswerkzeug indexiert das Projekt und frühere Gespräche für die Suche, aber alles Wichtige ist zusätzlich eine Aufgabe, eine festgehaltene Entscheidung oder ein Dokument.

Der deterministische Kern

Die Simulation lebt in einer reinen .NET-Bibliothek ohne Godot-Referenzen; der Godot-Client liest nur ihren Zustand und sendet Befehle. Der Kern folgt festen Regeln: Die Welt ändert sich nur durch Befehle, Zeit sind ganzzahlige Ticks, Zufall kommt nur aus den geseedeten Generatoren der Welt. Derselbe Seed und dasselbe Befehlsprotokoll müssen dieselbe Welt ergeben. Diese Regeln prüfen der Compiler und Tests, nicht nur Reviews; wie, steht in Devlog #1, und zu Welt, Spielständen und Replays in Devlog #2.

Der Simulationskern, wie er heute existiert. Es gibt noch keine Systeme und keine Figuren; die Welt enthält eine Kachelkarte mit Ebenen, und der Hash deckt die Karte ebenso ab wie das Gezeichnete.

Befehle sind der einzige Weg hinein. Jeder hat eine feste Typ-ID und eine Binärkodierung, und jeder Befehl wird mit seinem Ergebnis protokolliert, auch abgelehnte.
Der Tick hat drei Phasen in fester Reihenfolge. Die Reihenfolge der Systeme ist an einer Stelle im Code festgelegt, und sie zu ändern ändert jeden Hash.
Zufall nutzt eigene Generatoren (SplitMix64 und xoshiro256**). Benannte Ströme werden aus dem Seed der Welt abgeleitet und im Weltzustand gespeichert. Ein zustandsloser, schlüsselbasierter Generator, gesteuert von Domäne, Schlüssel und Tick, bedient reihenfolgeunabhängige Arbeit.
Der Zustands-Hash ist ein reihenfolgeabhängiger 64-Bit-Hash für Determinismusprüfungen. Er ist nicht kryptografisch.
Die Welt ist ein Raster aus Kacheln von 1×1 m auf diskreten Ebenen; Wände, Türen und Böden ändern sich nur durch Baubefehle.
Spielstände und Replays teilen sich einen geprüften Dateicontainer. Ein Replay ist der Seed plus das Befehlsprotokoll, mit Kontroll-Hashes unterwegs, und wird beim Abspielen Schritt für Schritt geprüft.
Benchmarks kommen aus einem Szenario-Runner ohne Oberfläche mit einer Basislinie pro Rechner und einer Schranke von null Allokationen pro Tick.

Das Designziel sind bis zu 1.000 Insassen und Mitarbeiter bei 20 Ticks pro Sekunde. Es ist ein Ziel: Figuren gibt es noch nicht, also existiert der Benchmark-Runner, aber in dieser Größenordnung wurde noch nichts gemessen.