Eksperimen Agentic AI: Bikin dodolanan.com Pakai Claude Code

Beberapa waktu lalu, di sela-sela kerjaan client yang lagi agak longgar, saya iseng eksperimen: seberapa jauh sih agentic AI bisa dipercaya buat bangun proyek dari nol, bukan cuma nambal-nambal kode yang udah ada? Daripada baca-baca thread orang soal “workflow agentic yang optimal”, saya putusin langsung praktik — bikin proyek nyata dari kosong pakai Claude Code, terus rilis beneran, bukan cuma demo lokal yang nggak pernah keluar dari laptop.

Hasilnya dodolanan.com — kumpulan mini game kecil yang bisa langsung dimainin di browser. Nggak ambisius, memang sengaja gitu. Saya nggak lagi nyoba bikin produk yang harus sukses, saya lagi nyoba ngerti batas workflow-nya.

Yang bikin saya kaget bukan “AI bisa nulis kode” — itu udah lama bukan berita. Yang baru buat saya adalah ngeliat agent nggak cuma jadi autocomplete pintar, tapi beneran ngerjain rangkaian task dari scaffolding project, nulis logic tiap game, sampe bantu proses deploy — dalam satu sesi kerja yang nyambung, bukan potongan-potongan terpisah yang saya rangkai sendiri belakangan.

Ada satu momen yang nempel di kepala. Waktu bikin salah satu game (puzzle grid sederhana), saya cuma bilang “tambahin fitur undo” tanpa jelasin detail gimana state-nya harus disimpan. Agent-nya milih pendekatan snapshot seluruh board tiap move — bukan diffing, bukan command pattern yang lebih “benar” secara akademis — dan jujur, buat scope game sekecil itu, itu keputusan yang tepat. Saya sempet mau intervensi, terus mikir ulang, dan biarin aja.

Beberapa hal yang saya bawa pulang dari eksperimen ini:

Instruksi yang scoped jauh lebih efektif daripada instruksi besar. “Bikinin game tebak angka” itu terlalu luas — hasilnya generik dan saya masih harus banyak koreksi. Begitu saya breakdown jadi task per fitur (skeleton game loop dulu, baru scoring, baru UI, baru animasi), hasilnya jauh lebih presisi dan saya lebih jarang harus rewrite total.

Iterasi kecil ngalahin spec lengkap di awal. Saya sempet coba nulis spec panjang buat satu game sekaligus, biar “efisien”. Hasilnya malah lebih berantakan dibanding kasih task kecil satu-satu, review, lanjut. Kedengarannya kontraintuitif — spec yang lebih detail harusnya hasilnya lebih bagus — tapi ternyata nggak, karena saya sendiri jadi males review sesuatu yang gede sekaligus.

Keputusan arsitektur besar tetap harus saya yang pegang. Struktur folder, gimana state game disimpan lintas game (localStorage vs in-memory), format asset — itu semua saya tentuin duluan sebelum agent mulai nulis apa-apa. Kalau saya biarin agent yang mutusin dari awal, hasilnya jalan, tapi nggak konsisten antar game satu sama lain.

Buat solo developer, ini kerasa beda levelnya dari sekadar “AI bantu ngoding lebih cepat”. Proyek yang biasanya makan waktu beberapa minggu kerja malam-malam sepulang kerjaan client, kepangkas jadi hitungan hari — bukan karena AI nulis kode sempurna, tapi karena loop scaffold-review-lanjut-nya jauh lebih cepat dari biasanya saya kerja sendirian.

Bukan berarti semua mulus. Ada satu game ritme sederhana, dan di situ agent-nya kesulitan — timing berbasis requestAnimationFrame yang presisi itu jenis kode yang susah divalidasi cuma dari baca, harus beneran dicoba pelan-pelan sambil ngerasain feel-nya. Beberapa iterasi saya buang karena kelihatannya benar di kode tapi kerasa lag pas dimainin. Itu bagian yang nggak bisa didelegasiin — feel cuma bisa dicek dengan main beneran, bukan dibaca dari diff.

Dodolanan.com sendiri saya anggap selesai sebagai eksperimen — nggak ada rencana rutin nambahin game baru. Tapi cara kerja yang saya temuin di situ sekarang jadi default saya buat proyek client juga: scope kecil, breakdown per fitur, review tiap potongan sebelum lanjut.