Spec-Driven Development: Emang Beneran Beda dari Vibe Coding?

Hampir semua newsletter dev yang saya baca bulan ini ngebahas “spec-driven development”. Idenya, daripada prompting agent secara conversational terus iterate dari hasil yang keluar, kamu nulis spec formal dulu (requirement, plan, kadang acceptance criteria eksplisit). Habis itu dikasih ke agent, baru boleh generate kode. Pendekatan ini lagi dipromosiin sebagai jawaban lebih dewasa buat vibe coding. Katanya sih bisa ngubah situasi “AI yang bikin app-nya dan saya nggak tau cara kerjanya” jadi disiplin engineering beneran. Saya penasaran sekaligus skeptis, makanya saya cobain langsung di proyek klien dan nggak cuma baca opini orang. Kesimpulan saya ternyata lebih kompleks dari sekadar hype atau nyinyir: ini beneran improvement buat jenis kerjaan tertentu, tapi cuma rebrand doang buat sisanya.

Yang beneran kebantu: kerjaan yang punya lebih dari satu interpretasi masuk akal

Saya lagi nambahin sistem permission multi-tenant di internal tool. Buat fitur kayak gini, pertanyaan “apa yang terjadi kalau user masuk dua tim dengan role setting yang bentrok” itu nggak punya jawaban yang pasti benar, karena ini murni keputusan bisnis. Dulu saya bakal langsung mulai prompting agent dan ngoreksi asumsinya pas kodenya udah muncul. Ujung-ujungnya saya harus ngulang ambiguitas yang sama sampai tiga atau empat kali dalam satu sesi. Kali ini saya nulis spec dulu: aturan eksplisit soal role precedence, skenario pas user dikeluarin dari tim, dan apa yang harus dicatat di audit log. Proses nulis ini ngungkapin dua edge case yang sebenarnya belum saya pikirin sama sekali, bahkan sebelum ada kode yang ditulis. Di situlah value aslinya. Bukan karena agent-nya bisa hasilin kode yang lebih bagus gara-gara spec, tapi karena nulis spec itu maksa saya bikin keputusan penting. Kalau dibiarin, keputusan ini bakal saya bikin secara implisit dan nggak konsisten di tengah-tengah proses generate tanpa sadar.

Yang cuma vibe coding pakai paperwork tambahan: kerjaan yang udah saya tau cara ngerjainnya

Saya coba proses yang sama di endpoint CRUD standar dengan konvensi REST biasa, dan nulis spec formal buat urusan ini berasa kayak formalitas doang. Nggak ada ambiguitas yang perlu diselesain. Saya udah tau bentuk endpoint list dengan pagination dan filtering karena udah bikin puluhan kali. Ngubah pengalaman itu jadi dokumen spec sebelum generate kode cuma nambahin langkah kerja tanpa ngubah hasil akhir. Orang-orang di internet yang paling excited soal spec-driven development cenderung ngomongin ini sebagai praktik universal. Mereka selalu bilang “selalu tulis spec dulu”, dan saya kurang setuju di bagian ini. Spec itu baru worth it ditulis kalau ambiguitasnya beneran ada. Kalau kodenya udah jelas, kamu cuma ngetik informasi yang sama dua kali: sekali sebagai spec, dan sekali lagi pas ujung-ujungnya muncul di kode juga.

Framing marketing yang paling sering dipakai adalah “ini nyegah utang vibe coding”. Saya udah pernah bahas kenapa panik soal utang teknis ini terlalu dilebih-lebihkan seolah-olah fenomena baru. Padahal, kebanyakan cuma masalah klasik dari tim yang kurang disiplin gara-gara pengen jalan lebih cepat. Spec-driven development nggak otomatis benerin masalah itu. Saya bisa aja nulis spec, ngasih ke agent, terus dapet kode yang secara teknis cocok sama spec-nya. Tapi hasil akhirnya tetep bisa seberantakan vibe coding: error handling nggak konsisten, logic duplikat di beberapa file, atau komentar yang nggak nyambung sama kode aslinya. Spec cuma ngebatesin apa-nya, bukan gimana-nya. Kenyataannya, kebanyakan utang teknis yang beneran saya beresin di codebase klien justru ada di bagian “gimana”. Ini soal pilihan implementasi kecil yang nggak pernah didokumentasiin karena nggak ada yang mikir itu perlu ditulis. Kalau kamu nge-skip code review cuma karena udah percaya sama spec-nya, kamu sebenernya cuma mindahin masalah disiplin yang sama ke satu layer di atasnya.

Yang beneran bikin beda: checkpoint review-nya, bukan dokumennya

Sebelum generate apapun, sekarang saya punya dokumen tertulis yang bisa dikasih lihat ke klien atau rekan kerja. Saya bisa nanya “ini maksudnya gini kan?” sebelum ngabisin waktu sejam nungguin output agent yang ujung-ujungnya bikin saya buru-buru nerima karena telanjur ada. Checkpoint ini beneran berguna. Tapi di sisi lain, saya sebenernya bisa dapet value yang mirip dari nulis email dua paragraf soal rencana kerja sebelum mulai ngoding. Jujur aja, ini hal yang udah dilakuin sama engineer disiplin dari dulu, jauh sebelum “spec-driven development” jadi istilah yang punya talk konferensi sendiri. Nyebut ini sebagai metodologi baru itu berasa kayak nganggep “tulis dulu apa yang mau dibikin sebelum coding” sebagai terobosan. Ini emang praktik yang bagus, cuma bukan barang baru aja.

Sisi tooling-nya justru yang bikin saya beneran terkesan. Beberapa framework agent yang lebih baru sekarang nganggep spec sebagai dokumen hidup. Dokumen ini terus dijadiin referensi sama agent sepanjang sesi, bukan cuma prompt sekali pakai. Agent-nya juga ngecek ulang kodenya sendiri dan ngebandingin sama spec sebelum nyelesain tugas. Ini bener-bener improvement mekanis yang jauh lebih mending dibanding sekadar paste spec ke chat window. Bayangin aja ngarepin modelnya tetep inget konteks awal pas udah masuk pesan ke-empat puluh. Saya sendiri udah mulai nyimpen SPEC.md ringan per feature branch justru gara-gara ini. Bukan karena wajib ikutin formalitas, tapi karena ini anchor yang beneran kepakai buat sesi agent yang panjang. Kalau nggak ada spec, kodenya gampang drift ke mana-mana. Ini satu-satunya bagian dari tren yang bakal terus saya pertahanin. Sebaliknya, aturan yang nyuruh tim bikin spec formal buat setiap perubahan — termasuk endpoint CRUD biasa — menurut saya bakal pelan-pelan hilang begitu gelombang blog post “ini metodologi saya” pindah ke tren baru.

Posisi saya sekarang secara praktis

Secara praktis, saya bakal nulis spec beneran kalau fiturnya ngandung keputusan yang bisa dijawab beda sama lebih dari satu orang. Contohnya kayak permission, logic billing, semua urusan yang nyentuh uang atau akses, atau kondisi pas nentuin “apa yang harusnya terjadi” itu jadi bagian paling susah. Saya bakal skip formalitas ini buat lima puluh endpoint CRUD dan integrasi standar yang jadi rutinitas minggu kerja biasa. Maksain spec buat kerjaan yang nggak ambigu itu bukan nambah rigor, tapi malah nambah friction yang ujung-ujungnya bakal di-skip juga pas ada tekanan deadline. Ironisnya, failure mode ini justru diklaim mau diselesain sama gerakan ini.

Saya nggak mikir spec-driven development itu scam. Tapi saya juga nggak mikir ini bakal jadi disiplin yang ujung-ujungnya nge-tame agentic coding. Ini tetep praktik yang beneran berguna buat sebagian kerjaan yang emang punya risiko ambiguitas tinggi, tapi dibungkus framing talk konferensi biar kelihatan universal. Pakai praktik ini di tempat yang ambiguitasnya beneran ada. Jangan percaya kalau ada yang bilang dokumen spec doang yang bisa misahin antara engineering yang hati-hati sama vibe coding. Dari dulu, disiplin review lah yang selalu ngerjain tugas itu, peduli amat mau ada spec atau nggak.