- Spec-Driven Development (SDD) adalah pendekatan bergaya waterfall yang dihidupkan kembali dengan menulis dokumentasi besar sebelum mulai coding. Tujuannya memberi struktur bagi alat bantu coding AI, tetapi berisiko menghambat kelincahan
- Komunitas open source telah mengembangkan alat yang secara otomatis membuat spesifikasi, rencana implementasi, dan daftar tugas berdasarkan prompt serta instruksi awal; contohnya Spec-Kit, Kiro, Tessl, dan BMad Method
- Namun dalam penggunaan nyata, muncul berbagai keterbatasan seperti kurangnya pemahaman konteks, dokumentasi berlebihan, review kode ganda, dan rasa aman semu, dan pada codebase besar efisiensinya turun drastis
- Tulisan ini menilai SDD sebagai upaya menggantikan developer yang pada akhirnya mengulangi kegagalan model waterfall, dan sebagai gantinya mengusulkan pendekatan pengembangan iteratif berbasis bahasa alami
- Pendekatan yang menggabungkan prinsip Agile dan Lean Startup dinilai lebih cocok untuk pengembangan modern dengan coding agent, sementara kemajuan alat interaksi visual menjadi tantangan berikutnya
Munculnya Pengembangan Berbasis Spesifikasi (SDD)
- Spec-Driven Development (SDD) memperkenalkan prosedur penulisan dokumen spesifikasi sebelum coding untuk menyediakan cara pengembangan yang terstruktur bagi alat bantu coding AI
- Berdasarkan prompt dan instruksi awal, LLM menghasilkan spesifikasi produk, rencana implementasi, dan daftar tugas
- Tiap dokumen bergantung pada tahap sebelumnya, lalu pengguna menyuntingnya untuk menyempurnakan spesifikasi
- Dokumen yang telah selesai kemudian diberikan ke coding agent seperti Claude Code, Cursor, dan Copilot untuk dipakai dalam penulisan kode
- Contoh alat yang mewakili pendekatan ini antara lain Spec-Kit milik GitHub, Kiro milik AWS, Tessl, dan BMad Method (BMM)
- Sebagai analisis perbandingan terkait, disebut tulisan Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Masalah Dokumentasi Markdown
- Spesifikasi SDD umumnya berbentuk file Markdown; sebagai contoh, implementasi fitur sederhana dengan GitHub Spec-Kit mencapai 8 file dan 1.300 baris
- Contoh penambahan field “referred by” pada Atomic CRM menggunakan Kiro juga terpecah ke dalam banyak dokumen
- Dalam penggunaan nyata, kelemahan berikut terlihat jelas
- Kurang memahami konteks (Context Blindness): fungsi yang sudah ada atau konteks kode sering terlewat, sehingga review ahli tetap dibutuhkan
- Dokumentasi Markdown berlebihan (Markdown Madness): dokumen yang panjang membuat pencarian error sederhana memakan banyak waktu
- Birokrasi sistematis (Systematic Bureaucracy): pengulangan yang tidak perlu dan detail berlebihan menimbulkan inefisiensi
- Agile palsu (Faux Agile): konsep “User Story” disalahgunakan hingga menimbulkan kekacauan
- Review kode ganda (Double Code Review): kode dalam spesifikasi dan implementasi nyata harus ditinjau secara terpisah
- Rasa aman semu (False Sense of Security): agent tidak sepenuhnya mengikuti spesifikasi
- Manfaat yang terus menurun (Diminishing Returns): berguna pada proyek awal, tetapi makin lambat saat skala membesar
- Karena sebagian besar coding agent sudah menyediakan mode perencanaan dan fitur daftar tugas, nilai tambah SDD menjadi terbatas dan justru dapat meningkatkan biaya pengembangan
Balas Dendam Project Manager
- Keterbatasan SDD mungkin disebabkan oleh alat yang belum matang, tetapi secara mendasar berasal dari perumusan masalah yang keliru
- Pendekatan ini berangkat dari tujuan “bagaimana mengeluarkan developer dari proses pengembangan software”
- Strukturnya berupaya mengganti developer dengan coding agent lalu mengendalikannya lewat rencana yang sangat rinci
- Ini mirip dengan model waterfall, yakni menjadikan developer sekadar penerjemah melalui dokumentasi yang sangat besar
- Padahal pengembangan software adalah proses non-deterministic yang tidak bisa menghilangkan ketidakpastian hanya lewat perencanaan (mengutip makalah No Silver Bullet)
- Pada tahap requirement, SDD tetap membutuhkan keahlian business analyst, dan pada tahap desain tetap membutuhkan keahlian developer, sehingga pada praktiknya hanya sedikit orang yang bisa memakai keduanya sekaligus
- Akibatnya, seperti alat No Code, SDD menjanjikan “pengembangan tanpa developer” tetapi pada akhirnya tetap membutuhkan developer
Alternatif Baru: Pengembangan Iteratif Berbasis Bahasa Alami
- Metodologi Agile memilih adaptabilitas alih-alih prediktabilitas untuk mengatasi masalah pengembangan yang non-deterministic
- Kunci memanfaatkan coding agent adalah memecah requirement yang kompleks menjadi beberapa masalah sederhana
- Disajikan prosedur iteratif sederhana yang menerapkan prinsip Lean Startup
- Identifikasi asumsi produk yang paling berisiko
- Rancang eksperimen minimum untuk memvalidasinya
- Kembangkan eksperimen lalu iterasikan berdasarkan hasilnya
- Sebagai contoh, dengan Claude Code, alat 3D sculpting (sulpt-3D) dikembangkan dalam sekitar 10 jam
- Tanpa spesifikasi formal, fitur ditambahkan secara bertahap hanya dengan instruksi singkat
- Implementasi yang salah segera diperbaiki sambil melakukan iterasi cepat
- Pendekatan ini memungkinkan konvergensi yang cepat tanpa dokumentasi bergaya waterfall, dan kombinasi Agile dengan coding agent memungkinkan pembangunan produk secara real-time
- Namun karena coding agent masih berpusat pada teks, interaksi visual masih kurang; ke depan diperlukan pengembangan alat yang memperkuat antarmuka visual
Kesimpulan
- Metodologi Agile pada dasarnya sudah membuat dokumen spesifikasi menjadi tidak perlu, dan SDD dinilai sebagai upaya untuk menghidupkannya kembali
- SDD adalah pendekatan teoritis yang berusaha menyingkirkan developer, sehingga melewatkan peluang memberdayakan generasi developer baru melalui coding agent
- Coding agent diibaratkan sebagai mesin pembakaran dalam; SDD membatasinya hanya pada lokomotif, padahal kita seharusnya memperluasnya ke mobil, pesawat, dan berbagai bentuk lain
- Terakhir, jika mempertimbangkan lingkungan, maka penggunaan coding agent secara hemat tetap diperlukan
1 komentar
Opini Hacker News
Sebagai developer, peningkatan produktivitas terbesar yang saya dapatkan berasal dari membiasakan diri merencanakan semua pekerjaan lebih dulu
Setiap kali menerima tiket, saya memecahnya menjadi daftar TODO besar agar desain, dependensi, dan spesifikasi jelas sejak awal
Dengan begitu, saat memrogram saya bisa lebih sering masuk ke kondisi flow
Pendekatan ini juga efektif untuk agen coding AI, karena proses berpikirnya sudah dituangkan lebih dulu
Detailnya saya tulis di artikel saya
Pada praktiknya, memecah masalah dan menulis spesifikasi itu hal yang baik
Yang menimbulkan masalah adalah spesifikasi yang tidak bisa diubah. Jika implementasi baru dimulai beberapa bulan kemudian, spesifikasinya sudah telanjur membeku
Sebaliknya, Agile sering dipakai sebagai alasan untuk menunda perencanaan strategis. Akibatnya, rework jadi banyak
Pada akhirnya ini soal keseimbangan, dan saya rasa “It depends” adalah moto yang bagus baik untuk hidup maupun pengembangan
Jika LLM yang mengelola spesifikasi, sepertinya ada keuntungan berupa berkurangnya beban pemeliharaan
Artikelnya ada di sini
Jika sulit diprediksi, kami melakukan spike lebih dulu untuk mengeksplorasi kode dan library
Kami membuat diagram struktur ideal sekaligus diagram yang mencerminkan batasan realistis, agar dalam jangka panjang bisa menghindari jebakan arsitektural
Setelah beberapa bulan melakukan vibe coding, dalam 6 bulan terakhir saya beralih ke spec-driven development
Saya menghabiskan 2–3 jam sehari untuk menulis spesifikasi, lalu pada hari yang sama merilis fitur yang sudah teruji
Menulis spesifikasi tidak membuat saya jadi kurang gesit. Justru memungkinkan iterasi cepat per 8 jam
Spesifikasi bukan prompt, melainkan kriteria penilaian akurasi
Tes end-to-end yang didefinisikan dengan baik sangat mengurangi kesalahan AI
Hasilnya bisa berbeda di setiap eksekusi, dan pada akhirnya tetap harus ditinjau manusia, jadi bisa tidak efisien
Menyebut pekerjaan satu hari sebagai ‘spesifikasi’ itu menyesatkan. Pada akhirnya ini cuma proses lama dengan nama baru
Bahkan ekspresi logika sederhana pun sering salah ditafsirkan, jadi berisiko jika harus memahami spesifikasi bahasa alami
Lalu saya serahkan ke agen, dia yang mengimplementasikan, dan saya hanya meninjau sesekali
Sementara AI bekerja, saya bisa mengutak-atik mobil balap saya, jadi benar-benar saling menguntungkan
Pada akhirnya yang penting hanya apakah kodenya lolos tes
Artikel ini rasanya ditujukan untuk orang-orang yang sudah lebih dulu menyimpulkan “spec-based development tidak cocok untuk saya”
Saya melihat spesifikasi sebagai titik masuk konteks untuk LLM
Jika struktur proyek, model, fungsi, requirement, dan sebagainya diberikan dengan cukup, LLM bisa memahami konteks dan mengembangkannya
Selain itu, jika LLM dibiarkan memperbarui spesifikasinya sendiri, iterasi yang Agile juga jadi mungkin
Tes berfungsi sebagai grounding ke realitas bagi LLM sehingga mencegah halusinasi
Tes menjadi dokumentasi sekaligus standar kualitas, dan LLM perlu dikelola seperti developer junior
Jalankan beberapa agen secara paralel, lalu biarkan mereka saling memverifikasi lewat lapisan tes, hasilnya bisa luar biasa
Berkat LLM, seluruh spesifikasi bisa diiterasi dengan murah dan cepat, tetapi esensinya tetap sama
Spesifikasi yang terlalu panjang justru menghambat pemikiran eksploratif
LLM bukan sistem deterministik melainkan sistem probabilistik, jadi sekarang kita harus men-debug spesifikasi, bukan kode
Developer kini harus berevolusi menjadi arsitek sistem kognitif
Ada spesifikasi tingkat tinggi dan ada juga spesifikasi komponen yang rinci
Saya pernah membuat alat CLI dengan Spec-Kit milik GitHub, tetapi butuh terlalu banyak proses perbaikan, analisis, dan penulisan ulang
Seperti waterfall, kurangnya umpan balik iteratif terasa membuat frustrasi
Pada akhirnya, daripada melihat kode yang salah dan mencari penyebabnya, lebih baik mulai dari awal
Coding bersama LLM itu bagus, tetapi SDD terasa seperti workflow yang berat dan tidak efisien
LLM menyukai konteks, jadi perlu diarahkan berulang kali dengan jelas
Sebagai contoh, saat membuat aplikasi NextJS, saya menuliskan dengan jelas login, RBAC, implementasi yang mengutamakan tes, dan sebagainya
Memulai dari unit kecil lalu menambah fitur secara bertahap adalah pendekatan yang lebih cocok
Masalah waterfall adalah lead time yang panjang dan biaya iterasi yang mahal
Dalam SDD, dua hal ini teratasi, jadi menurut saya tidak masalah
Menyebut spesifikasi yang dibuat dalam hitungan jam sebagai waterfall itu berlebihan
Jika terlalu cepat masuk ke ruang solusi yang kompleks, penyelesaian masalah yang sederhana jadi sulit
Agile dimulai dari ruang kecil lalu berkembang secara bertahap
Jika spesifikasi cukup detail, iterasi jadi lambat; jika kurang, LLM tidak bisa bekerja dengan baik
Pada akhirnya ini tetap membawa kontradiksi waterfall yang disukai manajer
LLM bekerja paling baik ketika diberi instruksi yang jelas dalam unit kecil
Mereka akan menulis spesifikasi multi-tahun, menjalankan LLM tiap 6 bulan, dan jika gagal akan menyalahkan developer
Saya penulis artikelnya
Menarik juga bahwa perdebatan waterfall vs agile masih begitu hidup
Menyenangkan membaca latar belakang orang-orang yang merasa SDD itu bernilai
Tetapi saya sendiri sudah menggunakan mode Plan sebelum implementasi, jadi SDD tidak memberi nilai tambah
Agen coding pun hampir tidak pernah mengimplementasikan semuanya dengan sempurna dalam sekali jalan
Pada akhirnya tetap perlu iterasi, jadi makna Big Design Up Front pun hilang
Meski begitu, saya percaya agen coding sedang membuka paradigma pengembangan baru
Ini mengingatkan saya pada video yang pernah saya lihat
Di situ dibahas apa yang bisa dipelajari engineer dan programmer satu sama lain, dan pentingnya perencanaan di awal sangat membekas
Orang bilang agile membunuh dokumen spesifikasi, padahal sebenarnya cuma memecahnya menjadi ribuan tiket Jira
AI bisa mencatat semua keputusan dan konteks yang tersebar seperti ini, lalu bertanya ketika bertentangan dengan pilihan masa lalu
Ia bisa memberi umpan balik seperti, “Apakah alasan Jim menulis kode ini seperti ini 5 tahun lalu masih berlaku?”
Artikel ini terasa agak aneh
Menerima spesifikasi yang tidak lengkap lalu menyelesaikannya lewat trial and error sama saja, baik bagi developer manusia maupun AI
Jika kita memang sudah tahu dengan jelas, maka memang seharusnya memberi instruksi secara detail
Mungkin inti artikel ini sebenarnya tentang “spesifikasi yang buruk”
Secara keseluruhan, ini terlihat seperti logika pembelaan diri industri Agile
Saya pernah mencoba SDD dengan beberapa file spesifikasi Markdown, dan yang benar-benar efisien justru beads
Itu membantu agen tetap fokus dengan mengikuti pohon kerja
Setiap tugas dipecah dengan TDD, dan tidak boleh lanjut ke tahap berikutnya sebelum tes lolos
Agen bahkan memberi tahu perintah review, jadi code review jadi mudah
Spec-Kit terlalu berat, jadi beads jauh lebih praktis
Proyek zmx yang saya buat sepenuhnya dengan vibe pun belakangan saya tulis ulang total dengan merujuk pada kode agen