Vibe Coding vs Spec-Driven: Kenapa Proyek AI Kamu Berantakan (dan Cara Benarnya)

Demo pertama selalu bikin melongo. Kamu ketik "bikin app to-do dengan login", tiga menit kemudian ada UI jalan, tombol nyambung, data kesimpan. Rasanya kayak dapet superpower. Terus kamu lanjut ke fitur ketiga, keempat, dan tiba-tiba agent mulai nulis ulang fungsi yang tadi udah bener, naruh state di tiga tempat beda, dan kolom database yang minggu lalu namanya user_id sekarang jadi userId. Proyeknya nggak crash sekaligus. Dia luruh pelan-pelan sampai kamu takut nyentuh file sendiri.

Itu bukan kamu gagal ngoding. Itu efek samping dari cara kerjanya: vibe coding. Dan ada cara kerja lain yang bikin AI tetap ngebut tanpa bikin proyeknya berantakan.

Apa itu vibe coding dan kenapa istilahnya lagi ramai

Vibe coding artinya kamu ngasih instruksi ke AI pakai bahasa manusia, lihat hasilnya, terus lanjut instruksi berikutnya berdasarkan "kayaknya udah oke". Nggak ada spesifikasi tertulis. Nggak ada kontrak soal struktur folder, penamaan, atau alur data. Kamu ngobrol, agent nebak, kode keluar. Istilahnya meledak setelah Andrej Karpathy nulis soal ngoding sambil pasrah ke vibes awal 2025, dan langsung nempel karena semua orang yang pernah buka Cursor atau Claude Code ngerasain hal yang sama.

Buat prototipe, ini beneran ngebantu. Throwaway script, tes ide di weekend, mancing bentuk fitur, vibe coding menang telak. Masalahnya bukan di tekniknya. Masalahnya di titik kamu berhenti nganggap outputnya coretan dan mulai berharap dia jadi produk.

Kenapa terasa cepat di awal: demo to-do app yang selalu nyala di percobaan pertama

To-do app itu contoh yang enak buat AI karena state-nya nyaris nol. Satu tabel, empat operasi: create, list, toggle, delete. Nggak ada peran user, nggak ada pembayaran, nggak ada race condition. Model bahasa udah lihat pola app kayak gini ribuan kali di data latihnya, jadi dia bukan lagi mikir, dia recall. Wajar keluarnya rapi.

Kecepatan yang kamu rasain di menit-menit awal itu asli, tapi menipu. Yang bikin ngebut bukan karena AI ngerti maksud kamu. Ngebut karena masalahnya kecil dan generik. Begitu masalah membesar dan mulai spesifik ke bisnis kamu, recall itu berubah jadi tebakan. Dan tebakan yang keluarnya kelihatan meyakinkan justru yang paling mahal buat dibersihin nanti.

Titik ambruk: begitu masuk proyek nyata

Proyek nyata punya hal yang nggak ada di demo. Tiga peran user dengan izin beda. Status pesanan yang boleh maju tapi nggak boleh mundur. Webhook pembayaran yang bisa datang dua kali. Timezone. Angka duit yang haram dibulatkan sembarangan. Di sinilah vibe coding pecah, dan pecahnya selalu di pola yang sama:

• State kececer. Data user yang sama disimpan di context, di localStorage, dan di server, dan ketiganya nggak pernah sepakat.
• Konvensi berubah tiap sesi. Sesi Senin pakai camelCase, sesi Rabu pakai snake_case, karena agent nggak ingat keputusan kemarin.
• Edge case ditebak diam-diam. Kamu nggak pernah bilang gimana kalau stok habis pas checkout, jadi agent milih sendiri, dan kamu baru tahu pas ada user komplain.
• Duplikasi logika. Validasi email nongol di empat file karena tiap kali agent lupa yang lama udah ada.
• Nggak ada yang jadi sumber kebenaran. Waktu dua bagian kode saling bantah, nggak ada dokumen yang bisa kamu tunjuk buat mutusin siapa yang benar.

Perhatiin: nggak satu pun dari ini soal AI nulis kode jelek. Sintaksnya bener semua. Yang hilang adalah kesepakatan tentang bentuk sistemnya. Vibe coding nggak pernah minta kamu bikin kesepakatan itu, jadi tiap sesi agent isi kekosongan itu dengan tebakan barunya sendiri.

Apa itu spec-driven development: PRD dulu, konvensi dikunci sebelum ngoding

Spec-driven development itu kebalikannya. Sebelum satu baris kode ditulis, kamu bikin spesifikasi: apa yang dibangun, entitas datanya apa, alurnya gimana, aturan mainnya apa, edge case-nya ditangani seperti apa. Baru setelah itu agent disuruh ngerjain, dan spesifikasi tadi jadi kontrak yang dia patuhi, bukan tebakan yang dia karang.

Spesifikasi ini nggak harus dokumen 40 halaman. Yang penting dia eksekutabel, artinya cukup konkret sampai agent bisa langsung kerja tanpa nanya balik. Contoh potongan dari sebuah PRD:

## Entitas: Pesanan
status: draft | dibayar | dikirim | selesai | batal
- Transisi status hanya boleh maju. draft->dibayar->dikirim->selesai.
- batal hanya dari draft atau dibayar. Setelah dikirim, TIDAK bisa batal.
- Nominal disimpan sebagai integer (rupiah), bukan float. Jangan pernah pakai desimal.

## Edge case wajib
- Webhook pembayaran bisa datang >1x untuk order sama -> proses idempoten pakai payment_id.
- Stok habis pas checkout -> tolak, jangan diamkan. Kembalikan error STOK_HABIS.
- Timezone semua timestamp: Asia/Jakarta, simpan UTC di DB.

Begitu aturan kayak gini tertulis, agent nggak punya ruang buat nebak. Dia nggak akan bikin tombol batal di pesanan yang udah dikirim, karena kamu udah bilang haram. Itulah inti spec-driven: kamu mindahin keputusan penting dari ditebak agent pas ngoding ke diputuskan kamu sebelum ngoding. Kalau belum pernah nulis satu pun, mulai dari panduan bikin PRD untuk aplikasi.

Vibe coding vs spec-driven: perbandingan langsung

Dua-duanya pakai AI. Bedanya di mana keputusan diambil dan kapan kamu bayar ongkosnya.

• Kecepatan awal: vibe coding menang. Nggak ada setup, langsung jalan. Spec-driven minta kamu duduk nulis spec dulu di depan.
• Kecepatan di fitur ke-10: kebalik. Spec-driven konsisten karena agent punya rujukan. Vibe coding makin lambat karena kamu habis waktu benerin ulang yang kemarin.
• Skala: vibe coding mentok begitu ada lebih dari satu entitas yang saling nyambung. Spec-driven jalan terus karena kontraknya nahan bentuk sistem.
• Maintainability: kode vibe susah diutak-atik karena nggak ada yang tahu kenapa dia ditulis begitu. Kode spec-driven bisa ditelusuri balik ke keputusan di spec.
• Onboarding orang baru: di proyek vibe, satu-satunya dokumentasi adalah kodenya sendiri. Di spec-driven, spec itu dokumentasi yang dibaca duluan.

Ringkasnya: vibe coding minjem kecepatan dari masa depan. Spec-driven bayar di muka biar sisanya lancar. Untuk apa pun yang bakal kamu rawat lebih dari seminggu, hitungannya jelas ke arah mana. Mau lihat bentuk jadinya? Intip contoh PRD yang udah siap eksekusi biar kebayang.

Bukan anti-AI: tetap cepat, tapi terarah

Ini bagian yang sering disalahpahami. Spec-driven bukan balik ke nulis semua manual. Kamu tetap pakai agent, tetap ngebut, malah lebih ngebut karena agent nggak muter-muter nebak. Bedanya cuma: yang kamu kasih ke agent bukan bikinin fitur checkout, tapi spec checkout yang udah kamu putuskan aturannya.

Agent paling produktif itu bukan yang paling pinter menduga maksud kamu, tapi yang dikasih konteks paling jelas. Kasih dia spec plus file rules, dia jadi tukang yang patuh gambar kerja, bukan seniman yang improvisasi. Kalau kamu baru mulai pakai agent CLI, panduan pakai Claude Code untuk ngoding ini nunjukin gimana konteks yang rapi mengubah hasilnya.

Langkah praktis mulai spec-driven

Nggak perlu ubah tools. Cukup ubah urutan. Empat langkah:

1. Tulis PRD eksekutabel dulu. Entitas, alur, aturan, edge case wajib. Konkret sampai nggak ada yang perlu ditebak. Ini modal utamamu.
2. Kunci konvensi di file rules. Penamaan, struktur folder, gaya kode, aturan yang haram dilanggar. Simpan sebagai CLAUDE.md atau file rules Cursor (folder .cursor/rules) di root repo biar kebaca tiap sesi.
3. Serahkan spec ke agent, bukan kalimat lepas. Rujuk PRD-nya, minta dia kerja dalam batasan itu.
4. Pas ada keputusan baru, balikin ke spec, jangan ke chat. Chat lupa. Spec ingat. File itu yang jadi sumber kebenaran sesi berikutnya.

Contoh isi file rules yang bikin agent konsisten antar-sesi:

# Aturan Proyek (dibaca tiap sesi)

## Penamaan
- Kolom DB & field JSON: snake_case. Selalu. Tanpa kecuali.
- Komponen React: PascalCase. File util: camelCase.

## Uang & waktu
- Nominal = integer rupiah. Dilarang float untuk uang.
- Simpan timestamp UTC. Tampilkan Asia/Jakarta.

## Larangan
- Jangan tulis ulang fungsi yang sudah ada. Cek dulu, pakai lagi.
- Jangan tambah dependency baru tanpa alasan di komentar.
- Satu logika validasi = satu tempat. Dilarang duplikat.

Kalau mau lebih dalam soal nyusun file rules yang efektif, baca panduan file rules Cursor dan CLAUDE.md. Dan buat nulis instruksi yang presisi ke agent, panduan prompt untuk AI coding ini pasangannya.

Mulai dari PRD yang siap dieksekusi

Selisih antara proyek AI yang rapi dan yang berantakan bukan di model yang kamu pakai. Selisihnya di apakah agent kerja dari kesepakatan atau dari tebakan. Vibe coding oke buat mancing ide di sepuluh menit pertama. Untuk apa pun yang kamu rawat lebih lama dari itu, mulai dari spec.

Butuh titik awal? Skematik nyusun PRD eksekutabel plus file rules dalam sekali jalan, jadi agent kamu langsung punya kontrak buat dipatuhi. Nulis spec dulu itu ngeselin di menit ke-lima. Di minggu ketiga, itu satu-satunya alasan proyeknya masih bisa disentuh.