Cara dibuat

Satu pengembang, satu asisten pemrograman AI, dan banyak aturan yang diperiksa mesin.

Oleh Nick

Prison Life saya tulis bersama Claude Code (agen pemrograman dari Anthropic). Saya yang memutuskan game ini seperti apa dan jalan mana yang kami ambil; sebagian besar pengetikan dikerjakan asisten. Karena tidak ada yang meninjau kode selain saya dan sebuah agen AI peninjau, saya bersandar pada otomatisasi: aturan ditegakkan oleh pemeriksaan otomatis dan oleh build, bukan oleh niat baik.

Delegasi

Sesi utama Claude Code merencanakan pekerjaan dan mengelola pelacak tugas, catatan tertulis tentang keputusan desain, dan riwayat perubahan. Ia tidak menulis kode: setiap perubahan, sekecil apa pun, ia serahkan ke agen AI khusus. Masing-masing punya definisi tertulis sendiri yang menetapkan peran dan modelnya.

Peran	Tingkat model	Tugas
Arsitektur	Opus	model data, tick, thread, pencarian jalur, keputusan
Kode simulasi	Opus	sistem simulasi, AI karakter, loop panas
Performa	Opus	profiling, regresi benchmark
Tinjauan (hanya baca)	Opus	meninjau diff; tidak bisa mengedit file
Klien dan alat	Sonnet	klien Godot, UI, alat
Pengujian	Sonnet	tes dari kriteria penerimaan
Data konten	Sonnet	definisi JSON dari skema
Pencarian, menjalankan pemeriksaan	Haiku	mencari kode; menjalankan pemeriksaan dan merangkum kegagalan

Pekerjaan berat diserahkan ke model terkuat, pekerjaan rutin ke yang lebih murah. Jika agen AI yang lebih murah gagal dalam pemeriksaan dua kali, tugasnya naik satu tingkat; jika tingkat teratas gagal dua kali, ia berhenti dan bertanya kepada saya.

Hook yang bisa menolak

Hook di Claude Code adalah skrip yang berjalan di sekitar tindakan asisten. Hook saya menegakkan tiga aturan:

• Tidak boleh selesai saat merah. Ketika sebuah sesi atau agen AI hendak berhenti setelah mengubah kode, sebuah hook menjalankan pemeriksaan cepat (build ditambah tes singkat). Jika gagal, permintaan berhenti ditolak.
• Sesi utama tidak bisa mengedit kode. Sebuah hook menolak penulisan ke kode sumber, tes, konten, dan alat dari sesi utama.
• Peninjau hanya bisa membaca. Alat penyuntingannya dicabut, dan sebuah hook menolak perintah yang mengubah file atau riwayat proyek.

Hook ini melindungi dari kesalahan, bukan dari upaya sengaja untuk mengakalinya: trik shell yang gigih bisa lolos, dan salah satu hook melihat pemeriksaan merah pada agen AI tetapi tidak bisa menahannya (hook berhenti milik sesi utama tetap menangkapnya). Saya lebih suka mengatakannya terus terang.

Keputusan tertulis dan pemeriksaan

• Setiap pilihan yang tidak sepele dicatat. Tugas, tonggak, dan keputusan desain disimpan sebagai teks biasa di samping kode, dalam pelacak tugas. Ketika kami memilih di antara opsi yang memengaruhi lebih dari satu tugas, pilihan itu dicatat bersama konteks dan konsekuensinya.
• Pemeriksaan berjalan di komputer saya. Tanpa CI di cloud. Satu skrip lokal punya empat mode: fast, test, bench, dan full. Skrip dan hook ditulis dengan PowerShell 7, baik di Windows maupun macOS.
• Pemeriksaan pada setiap perubahan. Otomatisasi lokal menolak perubahan yang deskripsinya buruk atau formatnya berantakan. Untuk perubahan kode, ia juga menjalankan pemeriksaan cepat; perubahan yang hanya menyentuh catatan atau situs web melewati build.
• File referensi dilindungi. Hash determinisme yang dikunci, file simpanan acuan, dan baseline benchmark hanya berubah dengan persetujuan eksplisit saya, tidak pernah diam-diam.
• Proyek itu sendiri adalah sumber kebenaran. Alat memori lokal mengindeks proyek dan percakapan sebelumnya untuk pencarian, tetapi semua yang penting juga menjadi tugas, keputusan yang tercatat, atau dokumen.

Inti yang deterministik

Simulasi berada di pustaka .NET murni tanpa referensi ke Godot; klien Godot hanya membaca keadaannya dan mengirim perintah. Inti mengikuti aturan tetap: dunia hanya berubah lewat perintah, waktu berupa tick bilangan bulat, keacakan hanya berasal dari generator ber-seed milik dunia. Seed yang sama dan log perintah yang sama harus menghasilkan dunia yang sama. Aturan-aturan ini diperiksa oleh kompiler dan tes, bukan hanya oleh tinjauan; lihat devlog #1 untuk caranya, dan devlog #2 untuk dunia, simpanan, dan replay.

• Perintah adalah satu-satunya jalan masuk. Masing-masing punya id tipe tetap dan pengodean biner, dan setiap perintah dicatat bersama hasilnya, termasuk yang ditolak.
• Tick punya tiga fase dalam urutan tetap. Urutan sistem ditetapkan di satu tempat dalam kode, dan mengubahnya mengubah setiap hash.
• Keacakan memakai generator buatan sendiri (SplitMix64 dan xoshiro256**). Aliran bernama diturunkan dari seed dunia dan disimpan dalam keadaan dunia. Generator tanpa keadaan berbasis kunci, yang digerakkan oleh domain, kunci, dan tick, melayani pekerjaan yang tidak bergantung urutan.
• Hash keadaan adalah hash 64-bit yang peka urutan untuk pemeriksaan determinisme. Hash ini tidak bersifat kriptografis.
• Dunia adalah kisi ubin 1×1 m pada tingkat-tingkat terpisah; dinding, pintu, dan lantai hanya diubah oleh perintah pembangunan.
• Simpanan dan replay berbagi satu wadah file yang diperiksa. Replay adalah seed ditambah log perintah, dengan hash kontrol di sepanjang jalan, dan diperiksa langkah demi langkah saat diputar.
• Benchmark berasal dari runner skenario tanpa antarmuka dengan baseline per mesin dan gerbang nol alokasi per tick.

Target desainnya adalah hingga 1.000 narapidana dan staf pada 20 tick per detik. Itu sebuah target: belum ada karakter, jadi runner benchmark sudah ada tetapi belum ada yang diukur pada skala itu.