- 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
Belum ada komentar.