Seorang praktisi penilaian kerentanan (vulnerability assessment) yang berbasis di Jepang membagikan pengalamannya dalam merilis tujuh game Android selama kurun waktu dua bulan terakhir tanpa menulis sebagian besar kodenya sendiri. Pengembangan game tersebut dilakukan sebagai proyek sampingan dengan memanfaatkan satu sesi Claude Code yang bertindak sebagai "produser". Sesi produser ini membawahi lima belas subagen, di mana masing-masing subagen bertindak layaknya sebuah departemen, seperti desain game, pemrograman, jaminan kualitas (QA), kritikus uji main (playtest critic), perilisan, periklanan, analitik, dan aspek terkait lainnya.

Dalam alur kerja yang diterapkan, instruksi sederhana seperti evaluasi bahwa level 3 terlalu mudah akan langsung ditangani oleh produser. Produser tersebut kemudian meminta desainer game untuk menentukan angka-angka baru, menugaskan pemrogram untuk memasukkannya ke dalam kode, memerintahkan tim QA mengukur tingkat penyelesaian (clear rate) menggunakan pemain otomatis (auto-player), dan menyerahkannya kepada kritikus untuk dimainkan secara objektif tanpa prasangka. Penulis sendiri hanya menyentuh dan menguji versi rakitan (build) game tersebut secara langsung pada ponsel asli di tahap akhir untuk memberikan keputusan akhir berupa persetujuan atau penolakan.

Eksperimen Pengembangan dan Metrik Awal

Eksperimen pengembangan ini dimulai pada 23 Agustus 2026 dengan sepuluh departemen, yang kemudian berkembang menjadi lima belas departemen. Dari total tujuh game yang berhasil dibangun, sebagian telah aktif tersedia di Google Play, sementara beberapa lainnya masih berada dalam tahap pengujian tertutup (closed testing). Ketika siklus pengujian penuh dijalankan pertama kali pada game bertema pendorong koin (coin-pusher), simulasi sistem ekonominya sempat menghasilkan 3,15 juta koin dalam sepuluh menit pengujian. Namun, setelah tiga putaran perbaikan, angka median produksi koin berhasil ditekan ke angka 10.000 koin, berada tepat di dalam rentang target yang diinginkan.

Terkait stabilitas kerja sistem, ketika salah satu subagen sempat berhenti beroperasi di tengah tugas akibat mencapai batas penggunaan (usage limit), satu pesan berhasil memulihkannya kembali dengan seluruh konteks percakapan yang tetap utuh tanpa kehilangan data apa pun. Di sisi bisnis, total pendapatan iklan yang dikumpulkan selama 30 hari terakhir tercatat sebesar 152 yen, atau kira-kira setara dengan satu dolar Amerika Serikat. Catatan keuangan ini sengaja diungkapkan untuk menunjukkan bahwa struktur multi-departemen berbasis agen AI sangat mempercepat proses produksi, namun tidak serta-merta membantu game tersebut agar mudah ditemukan oleh pengguna.

Alasan Pembagian Multi-Subagen Mandiri

Keputusan untuk memecah sistem ke dalam banyak subagen diambil setelah pendekatan satu sesi tunggal mengalami dua kegagalan utama. Masalah pertama adalah sesi tunggal cenderung menilai pekerjaannya sendiri; meminta sesi yang menulis kode untuk membuat pengujian otomatis menghasilkan tes yang selalu berhasil karena tes tersebut memang dirancang untuk lulus. Masalah kedua adalah ketiadaan pihak yang mengevaluasi apakah game tersebut benar-benar menyenangkan. Sesaat setelah menyelesaikan penulisan kode, sistem AI hanya berfokus pada kesesuaian kode terhadap spesifikasi, bukan pada apakah level game terasa membosankan.

Untuk memastikan evaluasi kualitas permainan tetap berjalan, setiap sudut pandang diberikan subagen mandiri. Di dalam lingkungan Claude Code, satu subagen direpresentasikan oleh satu berkas Markdown di direktori .claude/agents/ dan selalu memulai instruksinya dengan konteks awal yang bersih (blank context). Bagi peran peninjau, kondisi tanpa riwayat ini sangat ideal karena subagen peninjau tidak akan terpengaruh oleh asumsi-asumsi pembuat kode asli yang tidak pernah diketahuinya.

Struktur Departemen Berbasis Pertanyaan

Langkah krusial lainnya adalah membagi departemen berdasarkan pertanyaan yang harus dijawab, bukan berdasarkan hasil keluaran (output). Percobaan awal yang membagi agen berdasarkan wujud hasil kerja—seperti satu agen pembuat kode, satu pembuat gambar, dan satu penyusun teks—gagal dalam beberapa hari. Sebagai contoh, penentuan sudut pantulan bola mencakup lima pertanyaan mendasar: sudut apa yang digunakan game asli, berapa sudut yang harus dipakai pada game yang dibuat, bagaimana menerapkannya ke dalam kode, suara apa yang dimainkan saat memantul, dan bagaimana sudut tersebut memengaruhi tingkat penyelesaian level.

  • Jika pembagian dilakukan berdasarkan hasil keluaran, kelima pertanyaan tersebut akan dipaksakan masuk ke dalam satu departemen yang sama. Dengan pendekatan berbasis pertanyaan, masing-masing peran memegang tanggung jawab yang spesifik: analis spesifikasi (spec analyst) menjawab perilaku game asli, desainer game menentukan parameter yang tepat, pemrogram menangani konstruksi kode, tim antarmuka dan pemolesan (UI and juice) menentukan sensasi permainan, tim QA memeriksa kerusakan serta membaca metrik angka, dan kritikus uji main mengevaluasi faktor kesenangan. Pembagian batas tanggung jawab ini berhasil menghentikan konflik wewenang antardepartemen.
  • Sepuluh departemen awal pada mulanya hanya berfokus pada tahap pembuatan game. Setelah sistem berjalan, terlihat bahwa tidak ada pihak yang menangani urusan pascarilis. Akibat kekosongan ini, sembilan masukan dari penguji pada satu game sempat terlewat seluruhnya karena tidak ada departemen yang bertugas membacanya. Pada kasus lain, penayangan iklan sempat terhenti pada angka nol impresi selama dua hari akibat adanya pembatas (gate) di dalam kode buatan sendiri karena metrik lintas aplikasi tidak dipantau secara berkala, serta sebuah game hanya mendapatkan dua unduhan baru per hari karena halaman daftarnya di toko aplikasi tidak terkelola.
  • Menyadari kekurangan tersebut, penulis menambahkan lima departemen baru: optimasi toko aplikasi (store optimization), operasional langsung (live ops), dan dukungan pemain (player support), disertai penambahan periset web (web researcher) serta operator peramban (browser operator) untuk menangani halaman administrasi tanpa API. Celah pascaproduksi ini dapat diidentifikasi karena seluruh departemen didokumentasikan dalam format tabel, sehingga baris tugas yang kosong menjadi mudah terlihat. Rincian konfigurasi, langkah teknis, dan kendala operasional lainnya didokumentasikan secara lengkap dalam buletin penulis.