Retrospective: Sebulan Penuh Vibe Coding Barbar dengan Claude untuk Penyimpanan Lokal Game

Sebulan terakhir di kantor, saya benar-benar all-in nyobain Claude vibe coding (biasanya saya pake Gemini buat side project). Kebetulan kantor ngasih kuota API yang gede banget, dan saya disuruh bikin fitur penyimpanan galeri foto lokal baru buat game kita. Jadi, saya balik cara kerjanya: saya yang jadi arsitek ngurusin big-picture, dan biarin Claude Opus 4.6 yang jadi kuli kodenya (code monkey).

Setelah sebulan full nerapin ini, real talk aja nih: kalau kalian tahu persis apa yang dimau, AI tuh gila banget jagonya. Tapi begitu kalian mulai ngutak-ngatik requirements atau nge-fix bug, pengalaman manusia bener-bener 100% nggak tergantikan.

Kalau Udah Jelas, AI Langsung Sikat

Selama fase setup awal, asalkan saya ngasih batasan yang ketat, Claude bisa ngeluarin kode yang persis kayak yang saya butuhin.

Misalnya, biar file album lokalnya nggak corrupt, saya minta fitur keamanan data. Claude langsung nangkep maksudnya dan nge-copas pattern WAL (Write-Ahead Logging) yang mulus banget langsung dari SQLite. Dia beresin logika buat temp files, atomic swaps, sampe crash recovery. Di titik ini, kalau spec kalian jelas, AI bakal ngerjain tugas-tugas kotornya dengan sempurna dan ngemat waktu kalian nulis kode boilerplate.

Realita Pahit: AI Pake Kacamata Kuda Kalau Nge-Fix Bug

Tapi masa bulan madunya langsung kelar begitu kita mulai nyesuaiin fitur dan benerin bug. Di situlah kelihatan banget batas kemampuannya Claude.

Kelemahan paling parah dari AI adalah dia nggak punya pemahaman sistem secara global. Kalau ada logika yang tabrakan, insting pertamanya tuh selalu asal nambal sulam (slap a band-aid). Dia hobi banget asal nambahin flag boolean aneh-aneh atau bikin branch if-else baru, bukannya mundur bentar buat nyesuaiin fix itu ke sistem keseluruhannya. Kalau kalian nurut-nurut aja sama AI di sini, kode kalian bakal jadi mimpi buruk buat di-maintain nantinya.

Kasus Asli yang Ancur: Texture2D Cache Ref Counting

Saya kena contoh nyatanya waktu lagi bikin sistem reference counting buat cache Texture2D di C#.

Inti fiturnya itu buat nge-manage memori halaman album. Saya bagi cache-nya jadi dua zona: aktif dan inaktif. Kalau teksturnya punya referensi, dia tetep aktif; kalau referensinya nol, dia bakal dilempar ke inactive pool, siap buat dibuang.

Semuanya mulai kacau pas nyambungin async callbacks sama referensi cache-nya. Claude nulis logika timing yang ancur banget: dia nge-push halamannya ke inactive pool sebelum nandain referensinya. Ini bikin race condition yang parah. Kalau cache-nya kebetulan lagi penuh, ngelempar ke inactive pool bakal langsung men-trigger pembersihan, ngebuang halaman itu bahkan sebelum async callback-nya sempat nandain referensinya.

Ide brilian Claude buat nge-fix ini? Nambahin flag hacky banget namanya is_early_marked ke struktur data biar bisa nge-bypass masalah lifecycle itu sepenuhnya.

Langsung saya tolak mentah-mentah. Karena saya ngerti gimana lifecycle komponennya bekerja, saya kasih rule keras: tunda proses pembersihan inactive page sampai setelah operasi asinkron nandain referensinya. Cuma dengan ngubah timing di level arsitektur, bug-nya langsung musnah—nggak perlu pake flag-flag tambahan yang maksa.

Intinya Gini

Kejadian ini ngebuktiin kalau AI emang bikin kalian ngoding jauh lebih cepet, tapi dia juga gampang banget nyembunyiin technical debt di arsitekturnya.

Kalau junior dev yang nemu bug async tadi, paling mereka bakal langsung nge-merge kode hacky dari Claude. Lewat beberapa minggu kemudian, kalian bakal punya selusin flag dan loma yang nggak ada gunanya, dan modul itu udah ancur total nggak ketolong. Dengan vibe coding, kalian emang nggak perlu ngetik semua baris kode sendiri, tapi mantau big picture dan mencegah aplikasi kalian jadi monster spaghetti code itu murni tugas yang cuma bisa dilakuin manusia.