Halo, selamat datang di Ruang Developer Blog. Dalam beberapa bulan terakhir, coding dengan AI agent sudah menjadi praktik sehari-hari bagi banyak developer. Tools seperti GitHub Copilot, Claude Code, Cursor, dan Kiro memungkinkan kita menghasilkan kode dari prompt yang semakin kompleks. Tapi seiring proyek berkembang, keterbatasan “vibe coding” mulai terlihat jelas. Di sinilah Spec-Driven Development (SDD) hadir sebagai solusi.
Apa itu Spec-Driven Development?
Spec-Driven Development (SDD) adalah paradigma pengembangan software di mana spesifikasi menjadi artefak utama dan sumber kebenaran, bukan kode. Berbeda dengan spesifikasi klasik yang ditulis di Word atau Confluence dan cepat usang, SDD menggunakan executable specifications yang dapat dipahami oleh manusia dan mesin.
Jika kamu familiar dengan Test-Driven Development (TDD) atau Behavior-Driven Development (BDD), SDD bisa dianggap sebagai evolusi dari konsep tersebut:
- TDD: Tulis test dulu, lalu tulis kode minimal untuk lulus test
- BDD: Spesifikasikan behavior yang diharapkan dalam natural language terstruktur
- SDD: Sama seperti BDD, tapi format lebih machine-readable, menjadikan spesifikasi sebagai artefak utama
Dengan SDD, maksud dan tujuan developer menjadi “spec” yang mengatur AI agent dalam menghasilkan kode.
Mengapa Vibe Coding Tidak Cukup?
Mari kita lihat skenario yang umum terjadi. Kamu menulis prompt untuk AI assistant:
"Buat form registrasi React dengan validasi real-time untuk email dan password,
error handling, POST request ke /api/register, styling Tailwind modern,
state management pakai Zustand, dan HTTP calls dengan Axios."
Dalam hitungan detik, AI menghasilkan komponen lengkap. Terlihat bagus, ada validasi, feedback visual, bahkan toast notification. Kamu integrasikan, test happy path, semuanya jalan. Commit dan deploy.
Lalu realita datang mengetuk pintu: QA team menemukan banyak masalah.
Keterbatasan vibe coding:
- Tidak Presisi dan Ambigu: Ekspresi generik diinterpretasikan berbeda setiap kali menghasilkan kode
- Tidak Dapat Direproduksi: Prompt yang sama menghasilkan implementasi yang berbeda
- Maintenance Kompleks: Tidak ada standar konsisten untuk kode yang dihasilkan
- Risiko Keamanan dan Performa: Validasi hanya di sisi klien, parsing input tidak aman, masalah yang tidak terdeteksi saat generate tapi mahal saat scale
Vibe coding memang mempercepat prototyping dan menurunkan hambatan untuk memulai. Tapi tidak cukup untuk software yang beroperasi di konteks enterprise atau production.
Untuk melampaui prompt engineering berbasis intuisi, kita perlu pergeseran paradigma: dari kode yang didorong intuisi dan tampilan, ke kode yang didorong spesifikasi eksplisit, dapat diverifikasi, dan dibagikan.
Fase Operasional Spec-Driven Development
Untuk memahami bagaimana SDD mengubah cara kerja, mari kita lihat alur kerja tipikal developer yang mengadopsi SDD.
1. Specify (Spesifikasi)
Pada fase ini, developer mendeskripsikan perilaku yang diharapkan dari sistem dalam bahasa natural yang terstruktur:
- Perjalanan pengguna langkah demi langkah
- Tujuan bisnis
- Use cases utama dan edge cases
- Aturan validasi dan batasan yang tidak bisa dinegosiasikan
Pekerjaan utama di sini adalah analisis dan formalisasi maksud, bukan menulis kode.
Dari narasi ini, AI menghasilkan spesifikasi formal dan detail:
- JSON schemas untuk request dan response
- Aturan validasi dengan contoh konkret
- Kasus yang diharapkan dan kasus gagal dalam format Given-When-Then
- Invariant bisnis
- Mocks untuk layanan eksternal
Penting: Ini bukan aktivitas sekali jalan. Ini adalah proses iteratif di mana developer bekerja bersama AI, mendefinisikan spesifikasi: apa dan mengapa dari proyek.
Spesifikasi juga harus dipelihara seiring waktu agar tidak usang saat implementasi berkembang.
2. Plan (Perencanaan)
Pada fase perencanaan, developer mendefinisikan batasan teknis yang tidak bisa dinegosiasikan:
- Technology stack
- Arsitektur yang diinginkan
- Library untuk validasi, state management, HTTP calls, testing
- Batasan performa atau ukuran bundle
AI kemudian menghasilkan rencana teknis yang lengkap dan realistis:
- Struktur folder
- Komponen utama dengan tanggung jawab masing-masing
- Alur data
- Library yang dipilih dan alasannya
- Strategi pengelolaan error dan loading state
- Mocks yang dibutuhkan untuk testing
Di tahap ini, prompting menjadi prompt engineering yang sesungguhnya: bukan lagi “lakukan X untuk saya”, tapi membimbing AI agent dengan batasan yang jelas dan dapat diverifikasi.
3. Breakdown / Tasks
Pada fase pemecahan tugas, AI mengambil rencana yang sudah disetujui dan memecahnya menjadi tugas-tugas atomik, berurutan, dan independen.
Setiap tugas dirancang untuk:
- Kecil dan dapat ditest secara independen
- Terikat dengan kriteria penerimaan yang jelas
- Terhubung langsung ke satu atau lebih contoh dari spesifikasi
Langkah ini membuat pekerjaan terasa lebih dekat dengan backlog agile klasik, tapi yang dihasilkan dan dijaga konsistensinya dengan spesifikasi.
4. Implement (Implementasi)
Akhirnya, fase implementasi. AI menghasilkan kode satu tugas pada satu waktu, selalu menghormati spesifikasi dan rencana yang sudah disepakati.
Developer membaca dan memvalidasi potongan kode yang kecil dan tertarget:
- Mengecek apakah kode menangani kasus tipikal dan edge cases yang diharapkan
- Menjalankan test lokal atau preview hasil
- Menyetujui output atau meminta koreksi yang tertarget
Siklusnya cepat, biasanya 5 hingga 15 menit per tugas.
Dengan cara ini, AI menjadi kolaborator yang kamu kontrol, bukan generator blok monolitik yang sulit dipahami.
Tools untuk Spec-Driven Development
Sekarang mari kita lihat tools yang mendukung cara kerja SDD.
1. GitHub Spec Kit
GitHub Spec Kit adalah toolkit open source modular yang memungkinkan kamu menulis spesifikasi dalam structured markdown (dengan JSON schemas, Given-When-Then examples, dan invariants), memvalidasinya secara otomatis, dan menghasilkan kode via contextualized prompts ke LLM mana pun.
Kelebihan:
- Open source dan gratis
- Sederhana, transparan, tidak terikat ke satu penyedia
- Bisa digunakan dengan Claude, GPT, Gemini, atau model lokal
- Ideal untuk tim yang ingin bereksperimen dengan SDD tanpa vendor lock-in
Cocok untuk: Tim yang ingin mulai dengan SDD tanpa komitmen besar
2. OpenSpec
OpenSpec adalah framework open source untuk SDD dengan coding agents. Yang membuatnya menonjol adalah cocok untuk konteks brownfield dengan kode legacy.
Daripada requirement tingkat tinggi, kekuatannya adalah mendefinisikan requirement operasional untuk agent individual, dimulai dari konteks codebase yang ada dan memberikannya satu issue.
Cara mulai:
openspec init # Integrasikan ke codebase
Hanya menginstall 3 perintah:
proposal: Mengusulkan perubahan baruapply: Mengimplementasikan perubahanarchive: Mengarsipkan dan memperbarui spesifikasi
Kelebihan:
- Menjaga spesifikasi saat ini terpisah dari perubahan yang diusulkan
- Diff dapat dikelola dan dilacak setiap saat
- Sangat ringan, hanya file markdown
- Mendukung semua coding assistant utama (Claude Code, GitHub Copilot, Cursor, Windsurf)
Cocok untuk: Proyek brownfield dengan kode legacy
3. Spec-Kitty
Spec-Kitty dirancang untuk yang menginginkan kemampuan orkestrasi tinggi (eksekusi paralel beberapa agent tanpa konflik) dengan visibilitas penuh.
Fitur khas:
- Dashboard visual yang melacak semua progres secara otomatis
- Board bergaya kanban untuk tugas yang direncanakan, sedang dikerjakan, dalam review, dan selesai
- Melihat agent mana yang bekerja pada tugas mana
Cocok untuk: Tim besar dengan banyak agent bekerja paralel
4. Kiro
Kiro fokus pada alur kerja kolaboratif dengan “constitutions” (aturan style dan arsitektur yang diterapkan di tingkat proyek) dan checklist otomatis untuk setiap generasi.
Kelebihan:
- Konsistensi di tim besar
- Constitutions untuk menerapkan standar
- Pemeriksaan kualitas otomatis
Cocok untuk: Tim besar di mana konsistensi sangat penting
5. Tessl
Tessl merepresentasikan pendekatan paling radikal: tool spec-as-source pertama.
Spesifikasi adalah satu-satunya artefak yang dapat dimodifikasi. Kode di-regenerate dari awal setiap ada perubahan. Riwayat proyek hidup hampir sepenuhnya di spesifikasi itu sendiri.
Konsep:
- Spesifikasi berubah → rencana, tugas, dan kode di-regenerate otomatis
- Kode kehilangan peran sentral: menjadi output turunan, sementara dan dapat di-regenerate
Cocok untuk: Yang ingin mendorong maksimal ide bahwa kode adalah output turunan, bukan sumber kebenaran
Peran Developer Berubah: Dari Pelaksana ke Konduktor Orkestra
SDD tidak mereduksi developer menjadi “pengulas kode AI”. Sebaliknya, mengangkat developer ke peran strategis dan bernilai tinggi: dari yang menulis setiap baris, menjadi yang mendefinisikan, mengorkestrasi, dan menjamin kualitas seluruh sistem.
Dalam model tradisional, developer sering menjadi pelaksana requirement, menerjemahkan detail teknis dan logika bisnis ke kode setelah sebagian diformalkan. Dengan SDD, fokus bergeser secara decisif ke atas:
Peran baru developer:
- Formalisasi Maksud dan Batasan dengan Presisi Bedah: Mendefinisikan apa yang ingin dibangun dengan sangat jelas
- Desain Arsitektur yang Berkelanjutan dan Scalable: Membuat keputusan arsitektur jangka panjang
- Memilih Tools dan Pola yang Tepat: Dalam konteks produk nyata
- Validasi Kode yang Dihasilkan: Memastikan memenuhi requirement fungsional dan non-fungsional
- Penalaran tentang Trade-off Kompleks: Yang tidak bisa diputuskan AI
Dalam praktik, kamu menulis jauh lebih sedikit boilerplate code, tapi berinvestasi jauh lebih banyak dalam:
- Pemikiran kritis
- Desain sistem
- Komunikasi requirement yang jelas
- Keterampilan validasi mendalam
Ini adalah kompetensi langka, sulit diotomatisasi, dan semakin dicari di pasar.
Manfaat Konkret Spec-Driven Development
SDD datang dengan beberapa keuntungan konkret:
1. Kualitas Kode Lebih Tinggi dengan Lebih Sedikit Bug
Implementasi lebih setia ke requirement aktual karena spesifikasi eksplisit dan dapat diverifikasi.
2. Maintenance Jauh Lebih Sederhana
Spesifikasi yang jelas berfungsi sebagai dokumentasi hidup yang selalu up-to-date.
3. Keselarasan Nyata antara Bisnis dan Development
Melalui ekspresi eksplisit maksud sebelum generasi, bisnis dan tech berbicara bahasa yang sama.
4. Throughput Lebih Cepat
Reduksi drastis error yang diperkenalkan AI berkat validasi sistematis dan Human-in-the-Loop.
5. Dapat Direproduksi
Spesifikasi yang sama menghasilkan implementasi yang konsisten.
Kapan Menggunakan Spec-Driven Development?
SDD memberikan nilai maksimal dalam tiga skenario utama:
1. Proyek Greenfield
Proyek yang dimulai dari awal, tanpa batasan legacy, arsitektur yang sudah ada, atau technical debt yang terakumulasi.
Mengapa SDD cocok:
- Spesifikasi menjadi titik asal sejati sistem
- Arsitektur lahir sudah selaras dengan requirement fungsional dan non-fungsional
- Keputusan teknis dapat dilacak dan termotivasi
- Risiko perbedaan antara visi dan implementasi drastis berkurang
2. Proyek Brownfield
Konteks di mana kamu bekerja pada sistem yang sudah ada: platform legacy, arsitektur yang berlapis seiring waktu, ekosistem kompleks yang sudah production.
Mengapa SDD cocok:
- Membuat eksplisit apa yang sering hanya implisit: batasan arsitektur, dependensi, kontrak integrasi
- AI menghasilkan kode yang benar-benar terkontekstualisasi
- Reduksi risiko regresi, error integrasi, dan inkonsistensi sistemik
- Peningkatan throughput evolusioner
3. Evolusi Legacy
Transisi dari sistem legacy ke arsitektur modern.
Mengapa SDD cocok:
- Transisi bertahap dan terkontrol
- Perilaku yang diinginkan dari kode baru dideskripsikan terlebih dahulu
- Reverse engineering ditangani secara terstruktur
- Spesifikasi didefinisikan ulang atau diperbarui
- Bagian yang usang diganti dengan aman
Tantangan dan Jebakan yang Harus Dihindari
Seperti paradigma baru lainnya, SDD membawa manfaat tapi juga risiko konkret.
1. Verschlimmbesserung (Membuat Hal Lebih Buruk)
Alur kerja yang terlalu rumit dengan puluhan file markdown, checklist, dan constitutions bisa menciptakan overhead yang melebihi manfaatnya.
Solusi:
- Tetap sederhana
- Mulai kecil, iterasi
- Jangan perlakukan SDD sebagai penciptaan birokrasi
2. Spesifikasi yang Terlalu Verbose
Spesifikasi yang dihasilkan AI cenderung redundan, repetitif, dan melelahkan untuk direview.
Solusi:
- Edit dan sederhanakan spesifikasi
- Fokus pada kejelasan, bukan kelengkapan
- Spesifikasi harus mudah dipahami untuk orang, bukan hanya mesin
3. Tingkat Detail yang Salah
Terlalu samar → AI salah paham dan menghasilkan kode yang salah. Terlalu kaku → proses jadi tidak fleksibel.
Solusi:
- Temukan keseimbangan yang tepat melalui praktik dan iterasi
- Sesuaikan tingkat detail berdasarkan kompleksitas
4. Rasa Kontrol yang Salah
Bahkan dengan spesifikasi detail, AI sering mengabaikan instruksi, menduplikasi kode yang ada, atau menerapkan aturan secara berlebihan. Non-determinisme tetap ada.
Solusi:
- Selalu review kode yang dihasilkan
- Test secara menyeluruh
- Pahami keterbatasan AI
5. Amnesia
Dalam codebase kompleks atau sesi kerja panjang, agent bisa kehilangan jejak konteks.
Solusi:
- Jaga spesifikasi sebagai jangkar berkelanjutan
- Pecah pekerjaan menjadi sesi yang dapat dikelola
- Dokumentasikan keputusan secara eksplisit
6. Keterbatasan Umum SDD
Kapan SDD tidak cocok:
- Perbaikan trivial: overhead tidak proporsional
- Fitur yang sangat kompleks atau ambigu: sering tidak cukup
- Codebase legacy: memerlukan investasi awal yang tinggi
Ingat: Jika spesifikasi tidak dijaga tetap up-to-date, ia menjadi sumber kebingungan yang lebih berbahaya daripada kode itu sendiri.
Contoh Praktis: Spec-Driven Development dalam Aksi
Mari kita lihat contoh sederhana bagaimana SDD bekerja untuk fitur autentikasi pengguna.
Fase 1: Specify
Spesifikasi dalam natural language:
# User Authentication Feature
## User Story
As a user, I want to register and login to the application
so that I can access personalized features.
## Use Cases
### UC1: User Registration
Given: User is on registration page
When: User submits valid email and password
Then: Account is created and user is logged in
### UC2: User Login
Given: User has an account
When: User submits correct credentials
Then: User is authenticated and redirected to dashboard
## Validation Rules
- Email must be valid format
- Password must be at least 8 characters
- Password must contain uppercase, lowercase, and number
## Edge Cases
- Duplicate email registration → Show error "Email already exists"
- Invalid credentials → Show error "Invalid email or password"
- Network error → Show error "Connection failed, please try again"
Fase 2: Plan
AI menghasilkan technical plan:
# Technical Plan: User Authentication
## Architecture
- Frontend: React with TypeScript
- State Management: Zustand
- HTTP Client: Axios
- Validation: Zod
## Components
1. RegistrationForm
- Email input with validation
- Password input with strength indicator
- Submit button with loading state
2. LoginForm
- Email and password inputs
- Remember me checkbox
- Submit button
3. AuthService
- register(email, password)
- login(email, password)
- logout()
## Data Flow
User Input → Validation → API Call → State Update → UI Update
## Error Handling
- Client-side validation before API call
- API error responses mapped to user-friendly messages
- Loading states during async operations
Fase 3: Tasks
AI breakdown menjadi tasks:
## Task 1: Setup Zod Validation Schemas
- Create email validation schema
- Create password validation schema
- Export schemas for reuse
## Task 2: Create AuthService
- Implement register method
- Implement login method
- Add error handling
## Task 3: Build RegistrationForm Component
- Create form UI
- Integrate Zod validation
- Connect to AuthService
- Add loading and error states
## Task 4: Build LoginForm Component
- Create form UI
- Integrate validation
- Connect to AuthService
- Add remember me functionality
## Task 5: Write Tests
- Unit tests for validation schemas
- Integration tests for AuthService
- Component tests for forms
Fase 4: Implement
AI menghasilkan kode untuk setiap tugas, satu per satu. Developer mereview dan memvalidasi setiap tugas sebelum melanjutkan ke berikutnya.
Hasil:
- Kode yang konsisten dengan spesifikasi
- Semua edge cases ditangani
- Test disertakan
- Dokumentasi jelas
Best Practices Spec-Driven Development
Berikut adalah best practices untuk sukses dengan SDD:
1. Mulai Kecil
Jangan langsung terapkan SDD ke seluruh codebase. Mulai dengan satu fitur atau modul.
2. Jaga Spesifikasi Tetap Ringkas
Spesifikasi harus jelas dan ringkas, bukan verbose dan overwhelming.
3. Iterasi pada Spesifikasi
Spesifikasi bukan batu yang terpahat. Iterasi dan tingkatkan berdasarkan pembelajaran.
4. Pelihara Spesifikasi
Perbarui spesifikasi saat requirement berubah. Spesifikasi yang basi lebih buruk dari tidak ada spesifikasi.
5. Review Kode yang Dihasilkan
Selalu review dan pahami kode yang dihasilkan AI. Jangan terima secara membabi buta.
6. Test Secara Menyeluruh
Spesifikasi tidak menggantikan testing. Test kode yang dihasilkan secara menyeluruh.
7. Dokumentasikan Keputusan
Dokumentasikan mengapa keputusan tertentu dibuat dalam spesifikasi.
8. Kolaborasi dengan Tim
SDD bekerja paling baik saat seluruh tim selaras. Kolaborasi pada spesifikasi.
Masa Depan: Spec-as-Source dan Agent yang Selalu Aktif
SDD merepresentasikan frontier baru pengembangan yang didorong AI. Dalam konteks ini, evolusi yang lebih radikal sedang terbentuk: spec-as-source development.
Dalam pendekatan ini:
- Spesifikasi menjadi satu-satunya artefak yang stabil dan dapat dimodifikasi
- Saat requirement berubah, tech stack bergeser, atau model LLM yang lebih baik datang → perbarui hanya spesifikasi
- Rencana, tugas, dan kode di-regenerate sesuai, secara otomatis
- Riwayat proyek hidup di spesifikasi itu sendiri, termasuk “commit history”
- Kode kehilangan peran sentral: menjadi output turunan, sementara dan dapat di-regenerate
Tools seperti Tessl sudah mendorong ke arah ini, meskipun masih sangat eksperimental.
Tren paralel: Agent otonom mengeksekusi tugas kompleks di bawah guardrails yang didefinisikan oleh spesifikasi. Contoh: Agent Skills (awalnya dari Claude, sekarang open source).
Pergeseran paradigma:
- Orang yang tidak berpengalaman tetap dalam mode vibe-coding → hasil generik
- Developer senior membuka potensi eksplosif → spesifikasi presisi, guardrails ketat, arsitektur solid
Melihat ke depan:
- “Pergeseran tenaga kerja” dengan mesin dan agent beroperasi 24/7
- Manusia mengawasi, mendefinisikan maksud, spesifikasi, arsitektur
- Menulis kode menjadi kurang sentral
- Menulis spesifikasi yang jelas, dapat diverifikasi, dan tahan lama menjadi keterampilan inti
Kesimpulan
Spec-Driven Development adalah pergeseran paradigma dalam cara kita mengembangkan software dengan AI agent. Dengan menempatkan spesifikasi sebagai sumber kebenaran utama, SDD membantu kita melampaui vibe coding menuju pengembangan yang lebih terstruktur, dapat direproduksi, dan dapat dipelihara.
Poin-poin penting:
- SDD menempatkan spesifikasi sebagai artefak utama, bukan kode
- Empat fase: Specify, Plan, Tasks, Implement
- Tools tersedia: GitHub Spec Kit, OpenSpec, Spec-Kitty, Kiro, Tessl
- Peran developer berevolusi: Dari pelaksana ke konduktor orkestra
- Terbaik untuk: Proyek greenfield, proyek brownfield, evolusi legacy
- Waspadai: Spesifikasi yang terlalu verbose, tingkat detail yang salah, rasa kontrol yang salah
SDD bukan silver bullet. Ada kurva pembelajaran, ada overhead, ada tantangan. Tapi untuk proyek yang memerlukan kualitas, maintainability, dan skalabilitas, SDD menawarkan manfaat yang menarik.
Yang paling penting: SDD tidak menggantikan keterampilan developer. Sebaliknya, ia mengangkat developer ke pekerjaan bernilai lebih tinggi: berpikir, mendesain, memvalidasi, mengorkestrasi.
Jadi, jika kamu sudah coding dengan AI agent, pertimbangkan untuk mengambil langkah berikutnya: adopsi Spec-Driven Development. Mulai kecil, iterasi, dan lihat bagaimana ia mengubah alur kerja kamu.
Untuk kamu yang ingin belajar lebih lanjut tentang praktik pengembangan modern, jangan lupa baca juga artikel tentang Mengenal CI/CD dan Pengenalan TypeScript.
Selamat mencoba Spec-Driven Development! 🚀