Spec-Driven Development dari Nol

Di episode 5 kemarin kita membahas plan mode, yaitu cara menyuruh AI membuat rencana dulu sebelum menyentuh satu baris kode pun. Sekarang kita naik satu tingkat lagi. Kalau plan mode itu "rencana sebelum kode", maka spec-driven development itu "spesifikasi sebelum rencana". Bedanya tipis tapi dampaknya besar, dan episode ini akan membuatmu paham kapan memakainya.

Satu catatan jujur seperti biasa. Saya tidak akan mengklaim sudah bertahun-tahun mempraktikkan metode ini di proyek besar. Pembahasan di bawah disusun dari dokumentasi resmi dan laporan komunitas developer per Oktober 2026, lalu saya sederhanakan supaya masuk akal untuk proyek seukuran tugas sekolah atau portofoliomu.

Apa Itu Spec-Driven Development

Spesifikasi adalah dokumen yang menjelaskan apa yang harus dibangun dan kenapa, bukan bagaimana cara membangunnya. Contohnya: "pengguna bisa memilih satu dari dua opsi, satu orang hanya bisa memilih sekali, hasilnya tampil langsung di halaman." Itu spesifikasi. Sedangkan "pakai localStorage untuk menyimpan pilihan, lalu render ulang daftar dengan fungsi render()" itu sudah masuk wilayah implementasi.

Alur spec-driven development ada empat langkah yang selalu berurutan. Pertama, tulis spesifikasi. Kamu menuliskan tujuan, aturan main, dan kriteria sukses dalam bahasa sehari-hari. Kedua, buat rencana. Kamu (atau AI) mengubah spesifikasi menjadi langkah-langkah teknis: file apa yang dibuat, urutannya bagaimana. Ketiga, implementasi. AI menulis kode mengikuti rencana, bukan mengikuti imajinasinya. Keempat, verifikasi. Hasilnya dicek satu per satu terhadap spesifikasi. Kalau ada aturan yang dilanggar, kembali ke langkah tiga.

Analogi dapurnya begini. Spesifikasi itu seperti daftar pesanan tamu plus kriteria rasa: "nasi goreng untuk lima orang, tidak terlalu pedas, satu porsi tanpa telur." Rencana itu resep langkah demi langkah. Implementasi itu proses memasaknya. Verifikasi itu mencicipi sebelum disajikan. Tanpa daftar pesanan yang jelas, koki sehebat apa pun bisa salah masak. AI coding pun begitu.

Alur Kerja Langkah demi Langkah: Sistem Voting Sederhana

Supaya tidak abstrak, mari pakai contoh nyata: fitur voting sederhana di halaman web. Pengunjung memilih antara "Kopi" atau "Teh", hasilnya langsung terlihat. Kedengarannya sepele, tapi justru contoh kecil seperti ini yang paling pas untuk latihan.

Langkah 1: tulis spesifikasi mini. Sebelum membuka tools AI, tulis dulu 10 sampai 20 baris seperti ini: tujuan fitur, siapa penggunanya, aturan main (satu orang satu suara), apa yang tampil di layar, dan apa yang TIDAK boleh terjadi (misalnya suara ganda dari browser yang sama ditolak). Tulis dalam bahasa Indonesia santai, tidak perlu formal.

Langkah 2: minta AI membuat rencana dari spesifikasi. Tempel spesifikasimu, lalu perintahnya: "Buatkan rencana implementasi dari spesifikasi di atas. Sebutkan file yang dibuat, struktur datanya, dan urutan langkahnya. Jangan menulis kode dulu." AI yang baik akan mengembalikan daftar langkah yang bisa kamu baca dan koreksi. Di sinilah kamu masih memegang kendali penuh.

Langkah 3: implementasi mengikuti rencana. Jalankan rencananya satu langkah per perintah, atau biarkan agen mengerjakan semuanya kalau kamu sudah percaya dengan rencananya. Karena rencananya lahir dari spesifikasimu, AI tidak akan mengarang fitur tambahan yang tidak kamu minta.

Langkah 4: verifikasi terhadap spesifikasi. Ini langkah yang paling sering dilewati pemula. Buka halamannya, vote sekali, vote lagi dari browser yang sama, dan pastikan suara kedua ditolak. Cek setiap baris spesifikasimu: apakah semuanya terpenuhi? Kalau ada yang meleset, kamu tahu persis apa yang harus diperbaiki karena acuannya tertulis jelas.

Kapan Cara Ini Lebih Baik dari Prompt Langsung

Spec-driven development bukan untuk semua tugas. Ia bersinar dalam empat situasi. Pertama, fitur punya banyak aturan yang saling terkait. Validasi, batasan, dan kasus khusus (edge case) mudah terlewat kalau hanya diucapkan sekilas di prompt. Kedua, kamu akan mengerjakan sesuatu dalam beberapa sesi. Spesifikasi tertulis menjadi acuan tetap yang tidak berubah setiap kali kamu membuka tools. Ketiga, kamu memakai agen yang menyentuh banyak file. Tanpa spesifikasi, agen cenderung mengarang keputusan sendiri di file yang tidak kamu awasi. Keempat, hasilnya akan diperiksa orang lain. Teman sekelas atau gurumu bisa membaca spesifikasimu dan menilai apakah hasilnya sesuai.

Sebaliknya, prompt langsung tetap raja untuk tugas kecil satu file: mengubah warna tombol, menambah satu fungsi sederhana, atau memperbaiki error yang pesannya sudah jelas. Memakai spec-driven development untuk tugas lima menit itu seperti membawa peta kelurahan untuk pergi ke warung sebelah. Kenali ukurannya, pilih senjatanya.

Contoh Spesifikasi Mini yang Siap Ditempel

Ini contoh spesifikasi untuk sistem voting tadi. Salin, sesuaikan dengan kebutuhanmu, lalu tempel ke AI favoritmu. Perhatikan polanya: tujuan, aturan, tampilan, dan batasan ditulis terpisah supaya mudah dicek satu per satu.

SPESIFIKASI: Sistem Voting Sederhana

Tujuan:
Pengunjung halaman bisa memilih satu dari dua opsi
(Kopi atau Teh) dan melihat hasil voting secara langsung.

Aturan main:
1. Satu orang hanya bisa memilih SATU kali per browser.
2. Pilihan kedua dari browser yang sama harus DITOLAK
   dengan pesan yang jelas.
3. Hasil voting (jumlah suara tiap opsi) tampil di halaman
   dan terupdate setiap ada suara masuk.

Tampilan:
1. Dua tombol besar: "Kopi" dan "Teh".
2. Di bawahnya ada batang persentase untuk tiap opsi.
3. Setelah memilih, tombol berubah jadi status "Kamu memilih: X".

Batasan:
1. Tanpa database dan tanpa backend, cukup penyimpanan lokal browser.
2. Satu file HTML saja, boleh ada CSS dan JS di dalamnya.
3. Tidak perlu halaman admin atau fitur hapus suara.

Kriteria sukses:
1. Vote pertama tercatat dan persentase berubah.
2. Vote kedua dari browser yang sama ditolak.
3. Refresh halaman tidak menghilangkan hasil voting.

Setelah menempel spesifikasi ini, perintah lanjutannya sederhana: "Buatkan rencana implementasi dari spesifikasi di atas. Jangan menulis kode dulu." Baru setelah rencananya kamu setujui, perintah berikutnya: "Jalankan rencananya langkah demi langkah."

Jebakan Umum yang Bikin Gagal

Ada tiga jebakan yang paling sering menjebak pemula. Jebakan pertama: spesifikasi terlalu samar. Menulis "buatkan voting yang bagus" itu bukan spesifikasi, itu prompt langsung yang dibungkus kata "spesifikasi". Kalau spesifikasimu bisa ditafsirkan lima cara berbeda, AI akan memilih tafsir yang paling mudah baginya, bukan yang kamu mau. Jebakan kedua: spesifikasi terlalu detail sampai menulis kodenya sendiri. Kalau kamu sudah menentukan nama fungsi dan struktur datanya, kamu tidak butuh AI, kamu butuh juru ketik. Biarkan AI memilih cara implementasinya selama aturan mainnya dipenuhi. Jebakan ketiga: tidak pernah verifikasi. Spesifikasi yang tidak dicek ulang hanya jadi pajangan. Langkah keempat itu bukan opsional, itu setengah dari nilainya.

Latihan Minggu Ini

Latihanmu minggu ini ada empat langkah dan semuanya bisa selesai dalam satu sore. Pertama, pilih satu fitur kecil dari proyek yang sedang kamu kerjakan, misalnya form kontak, daftar todo, atau kalkulator sederhana. Kedua, tulis spesifikasi mini 10 sampai 20 baris mengikuti pola contoh di atas: tujuan, aturan, tampilan, batasan, kriteria sukses. Ketiga, tempel ke AI dan minta rencana dulu, jangan langsung minta kode. Baca rencananya, koreksi kalau ada yang aneh. Keempat, jalankan rencananya lalu verifikasi setiap kriteria suksesmu satu per satu. Simpan spesifikasi itu di file teks. Minggu depan kamu akan terkejut betapa bergunanya ia saat kamu lupa detail yang kamu putuskan hari ini.

Di episode 7 kita lanjut ke "Context Management: Atur File Biar AI Nggak Ngawur", yaitu seni memberi AI bahan bacaan yang tepat supaya ia tidak mengarang sendiri isi codebase-mu. Sampai jumpa besok jam 21:00. Bakar semangat kodingmu seperti api kompor.