Figure 1. Workflow GitHub Spec Kit dari perumusan kebutuhan hingga implementasi, dengan Constitution sebagai prinsip dan standar dasar proyek (https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering/).

Bayangkan kamu sedang membuat aplikasi untuk tugas kuliah menggunakan AI coding assistant. Kamu hanya menulis, “Buatkan aplikasi manajemen tugas yang modern.” Dalam hitungan menit, AI menghasilkan halaman, database, dan sejumlah fitur yang terlihat menarik. Namun, pengguna ternyata tidak bisa mengedit tugas, data tidak tersimpan dengan benar, dan beberapa fitur tidak sesuai kebutuhan. Cepat memang, tetapi apakah hasilnya benar-benar tepat? Tantangan dalam AI-assisted coding bukan hanya menghasilkan kode, melainkan memastikan hasilnya sesuai dengan kebutuhan. Spec-Driven Development (SDD) menawarkan pendekatan dengan menjadikan spesifikasi sebagai acuan sebelum implementasi dimulai.

Apa Itu Spec-Driven Development?

Spec-Driven Development adalah pendekatan pengembangan perangkat lunak yang menempatkan spesifikasi sebagai panduan utama dalam proses pembangunan aplikasi. Spesifikasi menjelaskan tujuan fitur, perilaku yang diharapkan, batasan sistem, serta kriteria keberhasilan. Pendekatan ini semakin relevan seiring berkembangnya AI coding agent. Pada 2025, GitHub memperkenalkan Spec Kit, sebuah toolkit open source untuk membantu pengembang menerapkan workflow SDD. Melalui alur yang terstruktur, kebutuhan dapat diterjemahkan menjadi spesifikasi, rencana teknis, daftar tugas, hingga implementasi dan validasi. [1][2]

Bagaimana SDD Bekerja?

Salah satu contoh penerapan SDD dapat dilihat pada workflow GitHub Spec Kit di Figure 1. Diagram tersebut memperlihatkan enam tahap yang tersusun melingkar, dengan Constitution sebagai prinsip dasar di bagian tengah. Alurnya dimulai dari /speckit:specify, yaitu mendefinisikan kebutuhan dan tujuan fitur. Tahap /speckit:clarify kemudian membantu mengidentifikasi ambiguitas dan memperjelas kebutuhan yang belum lengkap. Setelah itu, /speckit:plan menyusun rencana teknis, seperti arsitektur, teknologi, dan batasan implementasi.

Berikutnya, /speckit:tasks memecah rencana menjadi pekerjaan yang lebih kecil dan terukur. Tahap /speckit:analyze membantu memeriksa konsistensi antara spesifikasi, rencana, dan tugas. Terakhir, /speckit:implement menjalankan pekerjaan implementasi berdasarkan hasil tahap sebelumnya. Sementara itu, Constitution di tengah diagram berfungsi sebagai pedoman proyek, misalnya standar kualitas kode, prinsip desain, dan aturan pengujian. Dengan demikian, implementasi tidak hanya mengejar fitur yang selesai, tetapi juga mengikuti prinsip yang telah disepakati. SDD juga bukan proses sekali jalan. Hasil implementasi dapat memunculkan kebutuhan untuk memperbarui spesifikasi, rencana, atau pengujian. Urutan dan perintah yang digunakan dapat berbeda sesuai konfigurasi workflow serta coding agent yang dipakai. [2]

Menjaga Spesifikasi, Pengujian, dan Kode Tetap Selaras

Figure 2 menunjukkan hubungan timbal balik antara tiga artefak penting dalam pengembangan perangkat lunak: spesifikasi (.md), pengujian (.yaml), dan kode (.py). Ketiganya membentuk sebuah segitiga karena perubahan pada satu bagian dapat memengaruhi bagian lainnya.

Learnings from a No-Code Library: Keeping the Spec Driven Development Triangle in Sync
Figure 2. Hubungan timbal balik antara spesifikasi, pengujian, dan kode dalam Spec-Driven Development
(https://www.dbreunig.com/2026/03/04/the-spec-driven-development-triangle.html).

Pada diagram tersebut, spesifikasi berada di bagian atas sebagai acuan perilaku yang diharapkan. Panah dari spesifikasi menuju kode menggambarkan bagaimana spesifikasi membantu mengarahkan implementasi, sedangkan panah balik menunjukkan bahwa proses implementasi dapat memunculkan keputusan atau kebutuhan baru yang perlu didokumentasikan. Hubungan antara spesifikasi dan pengujian juga bersifat dua arah: spesifikasi menentukan perilaku yang perlu diuji, sementara kebutuhan validasi yang belum terpenuhi dapat mendorong revisi spesifikasi. Di sisi bawah, hubungan antara kode dan pengujian menunjukkan bahwa kode baru dapat menghadirkan perilaku yang harus diuji. Sebaliknya, hasil pengujian dapat mengungkap kesalahan implementasi. Intinya, spesifikasi, kode, dan pengujian perlu diperbarui secara konsisten agar tidak berkembang menjadi tiga sumber informasi yang saling bertentangan.

Sebagai contoh, kebutuhan “pengguna dapat membuat tugas” masih terlalu umum. Spesifikasi yang lebih jelas dapat menetapkan bahwa sistem harus menyimpan judul tugas, menolak judul kosong, dan menampilkan tugas yang berhasil dibuat. Kriteria penerimaan (acceptance criteria) kemudian menjadi dasar untuk menyusun test case. Jika pengujian gagal, pengembang perlu memeriksa apakah masalahnya berada pada kode, pengujian, atau spesifikasi itu sendiri.

Contoh Penggunaan di Dunia Nyata

SDD dapat diterapkan dalam berbagai skenario pengembangan:

  1. Proyek kuliah: Mahasiswa menetapkan fitur, aturan bisnis, dan kriteria penilaian sebelum meminta AI membuat aplikasi.
  2. Pengembangan startup: Tim menyepakati kebutuhan pengguna sebelum membagi pekerjaan frontend dan backend.
  3. Pengembangan fitur baru: Developer menentukan batasan teknis dan kriteria penerimaan untuk membantu mengurangi risiko perubahan merusak fitur lama.
  4. Pemeliharaan aplikasi: Spesifikasi mendokumentasikan perilaku yang harus dipertahankan ketika AI membantu memperbaiki bug.

Kelebihan dan Keterbatasan

Aspek Dengan SDD Tanpa spesifikasi yang jelas
Kebutuhan Lebih terstruktur dan terdokumentasi Berisiko ambigu
AI coding Memiliki konteks dan batasan yang jelas Lebih bergantung pada konteks prompt
Pengujian Dapat mengacu pada kriteria penerimaan Berisiko melewatkan kasus tertentu
Kolaborasi Memiliki acuan bersama Interpretasi dapat berbeda
Proses awal Membutuhkan waktu untuk perencanaan Dapat langsung memulai coding

SDD membantu mengurangi ambiguitas, mempermudah proses review, dan membuat pengujian lebih terarah. Namun, pendekatan ini tetap memiliki keterbatasan. Spesifikasi yang keliru, terlalu rumit, atau tidak diperbarui dapat menghasilkan implementasi yang tidak sesuai kebutuhan. Penyusunan spesifikasi juga membutuhkan waktu dan keterlibatan manusia untuk memeriksa asumsi, prioritas, serta keputusan teknis. Karena itu, spesifikasi sebaiknya cukup rinci untuk mengarahkan pekerjaan, tetapi tetap mudah diperbarui ketika kebutuhan berubah.

AI coding bukan hanya soal seberapa cepat kode dapat dihasilkan, tetapi juga seberapa tepat hasilnya menjawab kebutuhan. Spec-Driven Development membantu menjembatani keduanya melalui spesifikasi yang terstruktur, rencana implementasi, dan validasi yang terarah. Dengan menjaga spesifikasi, pengujian, dan kode tetap selaras, developer dapat memanfaatkan AI secara lebih efektif tanpa kehilangan kendali terhadap kualitas perangkat lunak.

Penulis: Emmanuel Daniel Widhiarto, S.Kom – FDP Scholar

Referensi

  1. Delimarsky, D. (2025). Diving Into Spec-Driven Development With GitHub Spec Kit. Microsoft for Developers. https://developer.microsoft.com/blog/spec-driven-development-spec-kit/
  2. GitHub. (2025). GitHub Spec Kit: Toolkit to Help You Get Started with Spec-Driven Development. GitHub. https://github.com/github/spec-kit
  3. Gupta, A. (2026). Spec-Driven Development: A Spec-First Approach to AI-Native Engineering. Microsoft for Developers. https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering/
  4. Breunig, D. (2026). The Spec-Driven Development Triangle. https://www.dbreunig.com/2026/03/04/the-spec-driven-development-triangle.html