Gambar 1. Tiga level spec-driven development dari spec-first sampai spec-as-source dalam esai Birgitta Bockeler (sumber: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)

Hai, Software Engineers! Bayangkan Anda meminta agen AI membuat fitur peminjaman ruangan kampus dan kode langsung mengalir dalam hitungan menit. Permintaan susulan membuat agen mengubah struktur database tanpa bertanya, lalu halaman admin yang kemarin rapi ikut rusak tanpa jejak yang jelas. Pola kerja seperti ini populer dengan sebutan vibe coding, yaitu Anda menulis prompt lepas lalu menerima apa pun yang keluar dari model.

Vibe coding cepat di awal, rapuh di akhir

Proyek vibe coding biasanya mulai dari satu prompt panjang yang mencampur keinginan pengguna dan detail tampilan. Agen menebak maksud Anda sekaligus menulis kode, sehingga keputusan tentang skema data dan batas akses tersebar di dalam balasan chat. Dokumentasi Kiro merangkum kelemahannya, yaitu vibe coding butuh banyak arahan untuk tugas kompleks, bisa salah menafsir konteks, dan sulit melacak keputusan di sepanjang jalan.

Dampaknya paling terasa pada proyek tim dan kode yang sudah berjalan lama. Anggota baru sulit memahami alasan di balik sebuah endpoint karena alasan itu tidak pernah ditulis. Perbaikan kecil berisiko merembet karena tidak ada kriteria uji yang disepakati sebelum kode ditulis.

Spec-driven development: requirement yang bisa dibaca mesin

Spec-driven development membalik urutannya, yaitu tulis spesifikasi dulu dalam bentuk yang bisa dibaca manusia dan mesin, lalu minta agen menulis kode dari spesifikasi itu. GitHub merilis Spec Kit sebagai toolkit open source yang memberi agen coding proses terstruktur, template siap pakai, dan outcome yang terdokumentasi. OpenSpec mengambil posisi serupa sebagai framework ringan untuk membuat spesifikasi dan memverifikasi bahwa implementasi cocok dengan spec.

Praktisi Thoughtworks Birgitta Bockeler memetakan tiga level kematangan praktik ini dalam esai yang banyak dirujuk. Level pertama disebut spec-first, yaitu spec ditulis matang lalu dipakai untuk satu tugas. Level kedua disebut spec-anchored, yaitu spec disimpan dan ikut diperbarui saat fitur berevolusi. Gambar 1 merangkum level-level ini, dan pesannya menenangkan, yaitu tim kampus cukup mulai dari spec-first yang disiplin.

Alur kerja: spec, plan, tasks, lalu kode

Alur Kiro dan Spec Kit mirip kebiasaan requirement klasik, hanya bahasanya disesuaikan agar bisa dieksekusi agen. Anda menulis requirement sebagai user story berformat As a dengan acceptance criteria berformat GIVEN WHEN THEN, lalu agen menurunkan desain dan daftar tugas yang tertaut ke requirement tersebut. Spec Kit meresmikan alur ini lewat perintah berurutan, yaitu tulis constitution sekali per proyek, lalu ulangi specify, plan, tasks, implement, dan converge untuk tiap fitur. Gambar 2 menunjukkan alur bertahap ini, dan aturan mainnya tegas, yaitu setiap tahap direview manusia sebelum lanjut.

Gambar 2. Alur spec-driven development dari ide sampai kode, tiap tahap direview manusia sebelum lanjut, ilustrasi penulis (sumber: https://github.com/github/spec-kit)

Contohnya modul peminjaman ruangan untuk biro umum kampus. Requirement ditulis sebagai user story staf yang memesan ruangan sehingga jadwal tidak ganda, lalu acceptance criteria menegaskan sistem menolak pemesanan yang bentrok. Dari situ agen menyusun desain model data dan endpoint API, lalu memecahnya menjadi tugas kecil yang dikerjakan satu per satu sambil diuji.

Perbedaannya bisa dirangkum seperti ini:

Aspek Vibe coding Spec-driven development
Titik mulai Prompt lepas yang campur keinginan dan detail Requirement tertulis dengan kriteria uji
Jejak keputusan Tersebar di riwayat chat Tercatat di spec, plan, dan tasks
Cara review Membaca diff besar di akhir Menyetujui tiap tahap sebelum kode ditulis

Batasnya: spec basi dan spec berlebihan

Spec-driven development bukan obat untuk semua ukuran masalah, dan batasnya perlu disebut sejak awal. Spec bisa basi ketika kode berubah tanpa memperbarui dokumen, sehingga tim memegang dua kebenaran yang bertentangan. Spec juga bisa berlebihan untuk masalah kecil, dan contohnya nyata, yaitu percobaan Kiro untuk bug kecil malah menghasilkan 4 user story dengan 16 acceptance criteria.

Kembali ke ruangan kampus yang kacau tadi, bayangkan ceritanya diulang dengan spec yang rapi di tangan. Agen tidak lagi menebak aturan bentrok jadwal karena aturan itu tertulis sebagai acceptance criteria yang bisa diuji. Ketua tim bisa menolak desain API yang janggal sebelum satu baris kode ditulis, dan anggota baru bisa membaca tasks.md tanpa mengobrak-abrik chat lama.

Referensi

  1. GitHub. Spec Kit: toolkit to help you get started with SDD. https://github.com/github/spec-kit
  2. Kiro. FAQs: what is spec-driven development and how is it different from vibe coding. https://kiro.dev/faq
  3. OpenSpec: a lightweight and configurable spec framework. https://openspec.dev/
  4. Bockeler, Birgitta. Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
  5. Arhipov, Anton. How to Use a Spec-Driven Approach for Coding with AI. JetBrains Blog. https://blog.jetbrains.com/junie/2025/10/how-to-use-a-spec-driven-approach-for-coding-with-ai/