Spec Driven Development Part 1: Overview

AI coding agent sekarang bisa menulis ratusan baris kode dalam hitungan detik. Tapi kecepatan ini punya sisi gelap: semakin cepat agent menghasilkan kode, semakin cepat pula kode yang salah arah ikut terproduksi. Masalahnya bukan di kemampuan model — masalahnya ada di cara kita berkomunikasi dengan agent tersebut. Spec-Driven Development (SDD) lahir sebagai jawaban atas masalah ini: disiplin menulis spesifikasi terstruktur sebagai sumber kebenaran utama, sebelum satu baris kode pun dihasilkan. Artikel ini adalah pembuka dari series Spec Driven Development, membahas kenapa pendekatan ini relevan sekarang, apa bedanya dengan metodologi lama seperti TDD dan BDD, dan bagaimana gambaran besar workflow-nya.

Masalah dengan “Vibe Coding”

Istilah “vibe coding” — coding hanya berdasarkan instruksi singkat dan intuisi, tanpa spesifikasi jelas — menjadi populer seiring AI coding assistant makin mainstream. Caranya sederhana: kamu ketik prompt, agent menghasilkan kode, kamu coba jalankan, kalau salah kamu prompt lagi. Loop ini terasa produktif di awal, terutama untuk prototype kecil. Tapi begitu kompleksitas project naik, vibe coding mulai menunjukkan keretakannya.

Ada tiga gejala yang hampir selalu muncul:

Output tidak bisa diverifikasi. Tanpa acceptance criteria yang eksplisit, tidak ada cara objektif untuk menilai apakah kode yang dihasilkan agent benar-benar “selesai” atau cuma terlihat selesai. Review jadi panjang karena reviewer harus menebak-nebak apa sebenarnya yang diminta.

Drift dari intent asli. Agent menghasilkan kode yang plausible — terlihat masuk akal, lolos compile, bahkan lolos test sederhana — tapi diam-diam menyelesaikan masalah yang berbeda dari yang dimaksud. Drift ini sering baru ketahuan saat code review atau, lebih buruk, saat sudah di production.

Context hilang antar sesi. Agent bersifat stateless. Begitu context window penuh atau sesi baru dimulai, semua keputusan arsitektur, alasan di balik suatu pendekatan, dan kesepakatan implisit ikut hilang. Developer harus mengulang penjelasan dari nol, dan agent berikutnya bisa saja mengambil keputusan yang bertentangan dengan yang sebelumnya.

Riset menunjukkan bahwa LLM bisa menghasilkan kode dengan kerentanan keamanan pada rentang yang cukup signifikan tergantung benchmark yang digunakan — bukan kasus langka, tapi pola yang konsisten muncul ketika spesifikasi keamanan tidak dinyatakan eksplisit. Akar masalahnya selalu sama: AI tidak kekurangan kemampuan, tapi kekurangan kejelasan tentang apa yang sebenarnya diminta.

• Vibe coding bukan musuh — untuk prototype cepat atau script sekali pakai, ini justru pendekatan yang tepat
• Masalah muncul ketika vibe coding dipakai untuk kode yang harus bertahan di production dan dipelihara jangka panjang
• Semakin besar codebase dan semakin banyak orang (atau agent) yang terlibat, semakin mahal biaya ambiguitas

Apa itu Spec-Driven Development

Spec-Driven Development adalah metodologi di mana spesifikasi — bukan kode — menjadi artefak utama dan sumber kebenaran dari proses pengembangan software. Kode menjadi output yang bisa diregenerasi dari spec, baik oleh manusia, AI agent, maupun kombinasi keduanya. Spec ini bukan dokumentasi pasif yang ditulis setelah fitur selesai, melainkan dokumen hidup yang mendahului implementasi dan dipakai untuk memvalidasi hasilnya.

Bedanya dengan dokumentasi tradisional ada di sifat “executable”. Spec tradisional dibaca manusia lalu dilupakan begitu kode selesai. Spec dalam SDD dirancang supaya bisa dieksekusi sebagai validation gate — agent membaca spec untuk menghasilkan kode, lalu spec yang sama dipakai untuk memverifikasi apakah hasilnya sesuai.

Sebuah spec yang baik biasanya memuat empat elemen inti:

Elemen-elemen ini akan dibahas lebih detail di Part 2 series ini. Untuk sekarang, yang penting dipahami adalah pergeseran cara berpikir: dari “saya minta AI membuat X” menjadi “saya definisikan apa itu X secara presisi, lalu AI mengeksekusinya”.

Spec-Driven vs TDD vs BDD

SDD sering disalahpahami sebagai TDD atau BDD dengan nama baru. Ketiganya memang berbagi semangat yang sama — menentukan “benar” sebelum menulis kode — tapi berbeda di artefak mana yang dianggap kanonik.

SDD tidak menggantikan TDD atau BDD — SDD justru mengakomodasi keduanya. Acceptance criteria dalam spec pada dasarnya adalah skenario BDD yang lebih ketat formatnya, dan workflow SDD yang baik tetap menghasilkan unit test maupun integration test sebagai bagian dari output. Bedanya, test tersebut diturunkan dari spec, bukan ditulis manual terlebih dahulu lalu spec menyusul.

Yang membuat SDD relevan secara khusus di tahun-tahun terakhir adalah munculnya AI coding agent yang mampu mengeksekusi instruksi kompleks secara otonom. TDD dan BDD dirancang untuk koordinasi antar manusia. SDD dirancang untuk koordinasi antara manusia dan agent — di mana presisi bahasa jauh lebih krusial karena agent tidak punya konteks implisit yang dimiliki rekan kerja manusia.

Anatomi Workflow Spec-Driven

Hampir semua framework SDD yang ada saat ini — baik yang open source maupun built-in di berbagai tool AI coding — konvergen ke pola loop empat fase yang sama:

flowchart TD
    A[Tulis Spec] --> B[Review & Refine Spec]
    B --> C[Generate Plan & Task]
    C --> D[Agent Implementasi]
    D --> E[Verifikasi terhadap Spec]
    E -- Sesuai --> F[Merge / Selesai]
    E -- Tidak Sesuai --> G[Identifikasi Gap]
    G --> B

Tulis Spec — Developer (atau agent dengan supervisi developer) menulis spec yang memuat intent, constraint, dan acceptance criteria. Ini fase paling penting karena seluruh akurasi hasil akhir bergantung pada kejelasan tahap ini.

Review & Refine — Spec direview sebelum eksekusi dimulai. Ambiguitas, kontradiksi, atau requirement yang hilang diperbaiki di tahap ini — jauh lebih murah daripada memperbaikinya setelah kode sudah ditulis.

Generate Plan & Task — Spec diterjemahkan menjadi rencana arsitektur dan dipecah menjadi task-task kecil yang bisa dieksekusi secara terpisah. Pemecahan ini penting supaya agent tidak mencoba menyelesaikan seluruh fitur dalam satu langkah besar yang sulit diverifikasi.

Implementasi — Agent (atau developer) mengeksekusi task sesuai plan, dengan spec sebagai rujukan constraint sepanjang proses.

Verifikasi — Output diperiksa terhadap acceptance criteria di spec. Idealnya proses ini sebagian otomatis (test, linter, type-check) dan sebagian melibatkan review manusia, terutama untuk keputusan arsitektur.

Jika verifikasi gagal, loop kembali ke fase refine — bukan langsung “prompt ulang” seperti pada vibe coding. Inilah perbedaan struktural yang membuat SDD lebih predictable: kegagalan dianggap sebagai sinyal bahwa spec atau plan perlu diperbaiki, bukan sekadar dilempar ke agent untuk dicoba lagi dengan harapan hasil berbeda.

Loop ini akan menjadi kerangka acuan untuk seluruh artikel berikutnya di series ini. Setiap fase — menulis spec, menyusun acceptance criteria, menerjemahkan ke task, hingga verifikasi — akan dibahas secara mendalam satu per satu.

Kapan Spec-Driven Development Penting

SDD bukan pendekatan yang harus dipakai untuk semua hal. Menulis spec lengkap untuk perubahan satu baris jelas berlebihan. Ada trigger sederhana yang bisa dipakai untuk memutuskan: jika kamu akan kecewa ketika agent menginterpretasikan requirement secara berbeda dari yang kamu maksud, tulis spec. Jika hasil yang salah masih bisa diperbaiki dengan satu prompt susulan, langsung prompt saja tanpa spec.

Beberapa konteks di mana SDD memberi nilai jelas:

• Fitur dengan banyak edge case — semakin banyak kondisi khusus yang harus ditangani, semakin besar risiko agent melewatkan salah satunya tanpa spec yang eksplisit
• Kerja tim atau multi-agent — ketika lebih dari satu orang atau agent menyentuh codebase yang sama, spec menjadi kontrak bersama yang mencegah konvensi yang berbeda-beda
• Requirement keamanan atau compliance — constraint yang tidak boleh dilanggar perlu dinyatakan eksplisit, bukan diasumsikan agent akan “tahu sendiri”
• Modernisasi codebase lama — spec membantu mendokumentasikan ulang sistem yang requirement aslinya sudah tidak jelas
• Project jangka panjang — spec yang hidup membantu mempertahankan konteks meskipun developer dan agent yang terlibat berganti-ganti seiring waktu

Sebaliknya, untuk eksplorasi cepat, proof-of-concept yang akan dibuang, atau perbaikan kecil yang scope-nya jelas dari awal, overhead menulis spec biasanya tidak sepadan dengan manfaatnya.

Preview Series

Part 1 ini baru memberi gambaran besar. Empat artikel berikutnya dalam series Spec Driven Development akan membahas tiap fase loop di atas secara detail:

• Part 2 — Anatomi spec yang baik: struktur, elemen wajib, dan contoh spec buruk vs spec yang efektif
• Part 3 — Spec untuk API dan kontrak data, termasuk skema sebagai source of truth
• Part 4 — Workflow praktis dari spec ke kode, termasuk menjaga spec tetap sinkron dengan perubahan
• Part 5 — Testing dalam SDD: bagaimana acceptance criteria diturunkan menjadi test otomatis

Setelah series Spec Driven Development selesai, pembahasan akan berlanjut ke series terpisah tentang Agentic Development — bagaimana mendesain dan mengontrol AI agent yang bekerja secara lebih otonom, dengan spec sebagai fondasi yang sudah dibangun di series ini.

Ringkasan

• Vibe coding efektif untuk prototype cepat, tapi gagal scale untuk kode production karena output sulit diverifikasi dan rawan drift dari intent asli
• Spec-Driven Development menjadikan spesifikasi — bukan kode — sebagai sumber kebenaran utama yang dieksekusi, bukan sekadar dokumentasi pasif
• Spec yang baik memuat empat elemen inti: intent, constraint, acceptance criteria, dan non-goals
• SDD berbeda dari TDD dan BDD dalam cakupan: TDD fokus ke test, BDD fokus ke behavior, SDD mencakup keseluruhan siklus dari requirement hingga dokumentasi
• Workflow SDD mengikuti loop: tulis spec → review → generate plan → implementasi → verifikasi, dengan kegagalan diarahkan kembali ke perbaikan spec, bukan sekadar re-prompt
• Gunakan trigger sederhana untuk memutuskan perlu spec atau tidak: jika interpretasi yang salah akan mengganggu, tulis spec; jika cukup diperbaiki dengan satu prompt susulan, langsung saja
• SDD paling bernilai untuk fitur kompleks, kerja tim/multi-agent, requirement keamanan, dan project jangka panjang — bukan untuk eksplorasi cepat atau perbaikan kecil