Pertanyaan ini muncul di hampir setiap tim yang mulai serius menulis kode dengan agen AI: cukup mengandalkan vibe coding, atau pindah ke spec-driven development? Jawaban singkatnya: keduanya bukan lawan. Vibe coding adalah jalur tercepat dari ide ke demo ketika kodenya boleh dibuang; spec-driven development (SDD) adalah cara menjaga agen tetap selaras dengan maksud Anda ketika kodenya harus hidup lama. Artikel ini membedah mekanisme keduanya, menunjukkan bentuk spesifikasi dalam praktik, membandingkan keduanya pada kriteria eksplisit, dan menamai alternatif di tengahnya. Satu hal yang tidak kami lakukan: mengklaim salah satu pendekatan lebih cepat atau lebih baik secara umum. Itu tergantung biaya kegagalan di proyek Anda, bukan pada artikel mana pun.
Apa sebenarnya vibe coding?
Vibe coding adalah membangun perangkat lunak dengan mendeskripsikan hasil yang diinginkan ke AI, lalu menerima outputnya tanpa membaca setiap baris. Istilah ini lahir dari postingan Andrej Karpathy pada 2 Februari 2025: menulis perangkat lunak dengan “sepenuhnya mengikuti vibes dan melupakan bahwa kodenya ada”. Karpathy membingkai praktik ini untuk proyek akhir pekan yang bisa dibuang, dan detail itu penting — definisi aslinya memang sengaja meninggalkan pemahaman baris-per-baris demi kecepatan ide-ke-demo.
Mekanismenya sederhana. Anda menulis prompt berbahasa alami, agen menghasilkan kode, Anda menjalankannya, lalu menyalin pesan error kembali ke agen sampai hasilnya bekerja. Peran manusia bergeser dari penulis menjadi operator dan penguji: Anda tidak lagi tahu persis apa yang ditulis, Anda hanya tahu perilaku yang terlihat. Selama kode itu sekali pakai, trade-off ini rasional. Masalahnya muncul ketika praktik yang sama dipakai untuk sistem yang harus hidup lama. Kode yang tidak pernah dibaca adalah kode yang tidak bisa Anda pertanggungjawabkan saat gagal, dan pengetahuan tentang kenapa kode itu seperti itu tidak tinggal di repositori — ia tinggal di riwayat chat yang hilang begitu sesi ditutup.
Apa yang dimaksud spec-driven development?
Spec-driven development menempatkan spesifikasi tertulis, bukan riwayat chat, sebagai artefak utama dan sumber kebenaran. Implementasi paling terlihat saat ini adalah Spec Kit dari GitHub, toolkit open source dengan sekitar 140 ribu star saat kami tangkap pada 1 Oktober 2026. Menurut dokumentasi resminya, alur intinya terstruktur: Specify → Plan → Tasks → Implement → Converge. Anda menulis spesifikasi perilaku, agen menyusun rencana teknis, rencana dipecah menjadi daftar tugas, agen mengimplementasikan tugas-tugas itu, lalu tahap konvergensi memeriksa hasilnya terhadap spesifikasi. Setiap fase menghasilkan artefak Markdown yang menjadi input fase berikutnya, sehingga agen bekerja dari konteks terstruktur, bukan prompt ad-hoc.
Dalam praktiknya, alur itu dijalankan lewat perintah slash di agen Anda — /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement untuk jalur pendek, dengan /speckit.clarify, /speckit.analyze, dan /speckit.converge sebagai gerbang kualitas tambahan pada jalur lengkap. Ada pula langkah /speckit.constitution yang menetapkan aturan tetap proyek (konvensi, batasan, prinsip yang tidak boleh dilanggar agen) sebelum fitur apa pun ditulis. Spec Kit bekerja dengan banyak coding agent — dokumentasinya menyebut 38 integrasi, termasuk Copilot dan Claude Code — dan dipasang lewat CLI specify init. Poin utamanya bukan tool-nya, melainkan posisi spesifikasi sebagai kontrak: ia bisa ditinjau sebelum kode ada, tersimpan di git, bisa di-diff ketika berubah, dan bisa diaudit ketika ada yang bertanya kenapa sistem berperilaku seperti ini.
Seperti apa bentuk spesifikasinya dalam praktik?
Spesifikasi yang baik menuliskan maksud, kriteria penerimaan, dan batasan — bukan kode. Berikut contoh ilustratif untuk fitur reset kata sandi; ini bukan proyek nyata, hanya untuk menunjukkan bentuk artefaknya:
# Spesifikasi: Reset kata sandi
## Maksud
Pengguna yang lupa kata sandi dapat mengatur ulang tanpa menghubungi admin.
## Kriteria penerimaan
- Meminta tautan reset mengirim email berisi tautan sekali pakai yang
kedaluwarsa dalam 30 menit.
- Tautan yang sudah dipakai atau kedaluwarsa ditolak dengan pesan yang sama,
tanpa membocorkan apakah email terdaftar.
- Kata sandi baru minimal 12 karakter; semua sesi aktif lain dibatalkan
setelah reset berhasil.
## Batasan
- Tidak mengubah skema tabel pengguna yang ada.
- Batas laju: maksimal 3 permintaan reset per email per jam.Bandingkan dengan prompt vibe yang setara: “buatkan fitur lupa kata sandi yang aman”. Satu kalimat itu menyerahkan setiap keputusan — masa berlaku token, pembatalan sesi, kebocoran enumerasi email — ke default agen, dan default itu berbeda antar model dan antar hari. Spesifikasi membuat keputusan-keputusan itu eksplisit dan bisa diperdebatkan sebelum satu baris kode pun ada; perbedaan pendapat muncul di dokumen yang murah diubah, bukan di diff yang mahal dibuang. Ini juga artefak yang bisa dibaca anggota tim berikutnya tanpa harus menebak maksud dari kode.
Kapan masing-masing masuk akal?
Garis pemisahnya bukan label “prototipe versus produksi”, melainkan biaya kegagalan dan umur kode. Empat situasi konkret:
- Prototipe akhir pekan untuk validasi ide. Anda ingin tahu apakah ide layak dilanjutkan, bukan membangun fondasi. Kode akan dibuang setelah keputusan diambil. Vibe coding menang di sini — menulis spesifikasi untuk kode yang akan dihapus adalah birokrasi.
- Demo hackathon. Deadline dalam hitungan jam, tidak ada pengguna setelah presentasi, tidak ada yang akan merawat kodenya. Vibe coding lagi; justru di sinilah definisi asli Karpathy berlaku penuh.
- Sistem produksi dengan pengguna nyata dan data pelanggan. Setiap perubahan perilaku harus bisa ditinjau sebelum rilis dan dilacak sesudahnya. SDD masuk akal: spesifikasi adalah jejak keputusan, dan agen bekerja di dalam pagar yang Anda tulis.
- Serah terima antar anggota tim. Ketika orang yang menulis fitur pindah, yang tersisa adalah artefak di repo. Riwayat chat tidak ikut pindah; spesifikasi ikut. Untuk tim yang berganti orang, SDD sekaligus berfungsi sebagai dokumentasi onboarding.
Aturan praktis kami tetap seperti semula: jika Anda tidak bisa menjawab “siapa yang membaca kode ini bulan depan?”, Anda sedang vibe coding — pastikan itu memang niatnya. Pola spesifikasi-sebagai-kontrak ini juga yang kami pakai saat membangun agen untuk klien; lihat layanan agen AI dan otomasi dan proyek prompt enhancer kami.
Memulai SDD tidak berarti mengubah seluruh cara kerja dalam sehari. Dokumentasi Spec Kit menyarankan jalur bertahap: pasang dengan specify init, pilih agen yang sudah Anda pakai, lalu jalankan satu fitur kecil lewat alur penuh sebelum memutuskan seberapa jauh tim Anda mengadopsinya.
Bagaimana perbandingannya pada kriteria eksplisit?
Tabel berikut adalah penilaian kualitatif kami — bukan pengukuran, dan kriterianya adalah kriteria yang kami pilih:
| Kriteria | Vibe coding | Spec-driven development |
|---|---|---|
| Kecepatan ke demo pertama | Sangat cepat; prompt langsung jadi kode | Lebih lambat di awal; spesifikasi ditulis dulu |
| Kemudahan perawatan | Rendah; kode yang tidak dibaca sulit dirawat | Lebih tinggi; spesifikasi menjelaskan maksud |
| Auditabilitas | Nyaris tidak ada jejak selain riwayat chat | Spec, rencana, dan tugas tersimpan sebagai artefak di git |
| Biaya onboarding | Hampir nol | Perlu belajar alur dan disiplin menulis spec |
| Konteks teregulasi atau fintech | Tidak cocok; tidak ada jejak keputusan | Lebih cocok; keputusan terdokumentasi dan bisa ditinjau |
Satu baris yang sengaja tidak ada di tabel: “kualitas kode”. Tidak ada bukti terukur yang kami miliki bahwa salah satu pendekatan menghasilkan lebih sedikit cacat secara umum, dan kami tidak akan mengarang angkanya.
Apa saja alternatif di antara kedua kutub?
Vibe coding penuh dan pipeline SDD penuh bukan satu-satunya pilihan. Beberapa alternatif nyata, dan kapan masing-masing menang:
- Kiro (AWS). IDE agentik dengan spek bawaan: fitur dipecah menjadi
requirements.md,design.md, dantasks.md, dengan notasi EARS untuk kriteria penerimaan. Menang ketika Anda ingin struktur SDD yang terintegrasi dalam satu IDE dan bersedia memakai IDE itu. - TypeSpec (Microsoft). Bahasa deskripsi API untuk mendefinisikan kontrak API terlebih dahulu, lalu menghasilkan kode dan dokumentasi darinya. Menang ketika yang perlu dikunci adalah bentuk API, bukan seluruh proses pengembangan fitur.
- AGENTS.md plus plan mode. Konvensi tetap di level repo (satu berkas AGENTS.md) dikombinasikan dengan mode rencana di coding agent — agen menyusun rencana dan meminta persetujuan sebelum mengubah berkas. Menang ketika tim belum butuh pipeline penuh tapi ingin agen berhenti menebak.
- Tulis tes dulu. Tes sebagai kontrak perilaku; agen diarahkan untuk membuat tes lulus. Menang ketika perilaku yang diinginkan bisa dinyatakan sebagai assertion, dan tim sudah disiplin menulis tes.
Semuanya berbagi satu ide dengan SDD: memindahkan maksud dari kepala Anda ke artefak yang bisa dibaca agen dan manusia. Perbedaannya hanya seberapa berat artefak itu.
Kapan masing-masing menang?
Vibe coding menang ketika biaya kegagalan mendekati nol dan umur kode pendek: eksplorasi, demo, skrip sekali pakai. SDD menang ketika perubahan harus bisa diaudit, pengetahuan harus hidup lebih lama dari orang yang menulisnya, dan agen perlu pagar yang eksplisit. Di antara keduanya ada pola yang kami lihat paling sering berhasil: vibe untuk eksplorasi, spec sebelum produksi. Gunakan vibe coding untuk menemukan bentuk solusi, lalu tuliskan spesifikasi dari apa yang Anda pelajari sebelum kode itu diperkeras dan dirawat. Yang perlu dihindari adalah posisi tengah tanpa sadar — kode hasil vibe yang diam-diam menjadi sistem produksi tanpa pernah ada yang menuliskan maksudnya.
Apa yang belum dijawab artikel ini?
Artikel ini tidak menetapkan bahwa SDD menghasilkan lebih sedikit cacat; kami tidak menjalankan perbandingan terkontrol, dan klaim semacam itu tidak boleh dibuat tanpa pengukuran. Jumlah star mengukur perhatian, bukan kesesuaian untuk tim Anda. Spesifikasi juga bisa basi: spec yang tidak diperbarui ketika kode berubah lebih berbahaya daripada tidak ada spec, karena ia berbohong dengan percaya diri. Dan verifikasi output agen tetap disiplin tersendiri — spesifikasi tidak menggantikan evaluasi, hanya memberinya target. Pola evaluasi semacam itu yang kami bangun di proyek llm-eval-harness. Terakhir, Spec Kit berkembang cepat; nama perintah dan alur yang kami sebut berlaku per pemeriksaan sumber pada 1 Oktober 2026 dan bisa berubah di rilis berikutnya.
Jika Anda ingin menata proses pengembangan berbantu AI di tim Anda — dari konvensi repo sampai evaluasi output agen — bicara dengan kami.
