Spec Driven Development - Membuat vibe coding semakin kuat

Sebelum masuk

IDE bernama Kiro sudah pernah dibahas di GeekNews.

Namun, belum ada pengenalan dari sudut pandang Spec Driven Development (SDD), yaitu filosofi metodologi pengembangan yang dituju Kiro,

dan ada video yang bagus untuk memahami Spec Driven Development, jadi saya memperkenalkannya di sini.

---

Kiro

• IDE berbasis agen: membantu pengembangan dengan bahasa alami, tetapi dengan bias yang menempatkan “spec sebagai artefak kelas satu”.

• Sambil mempertahankan kecepatan “vibe coding” dari IDE agen yang ada, keputusan, asumsi, dan batasan tetap didefinisikan dalam dokumen spec.

• Alur kerja: ketika ide dimasukkan, sistem langsung membuat tiga file requirements / design / tasks sebagai titik awal. Editornya berbentuk fork dari Code OSS yang ditambahkan tab “Specs / Hooks / Steering”.

  • Specs: menstrukturkan requirement (user story + acceptance criteria dalam format EAR), lalu menghubungkan implementasi, pengujian, dan perubahan berikutnya dengan spec.
  • Hooks: memantau perubahan file/kode untuk memicu alur kerja spec.
  • Steering: melakukan check-in panduan tim sebagai aturan (markdown) di .kiro/ pada root repositori—misalnya menambahkan aturan TDD untuk membuat perilaku agen konsisten.

Mengapa Spec Driven diperlukan

• Melengkapi keterbatasan vibe coding: jika kode dibuat cepat lewat bolak-balik chat, dasar pengambilan keputusan tenggelam di aliran chat sehingga belakangan menjadi kabur “apa yang dibuat dan mengapa”. SDD menempatkan spesifikasi berbasis behavior lebih dulu agar menjadi kompas yang stabil.

• Definisi spec (behavior, property, invariant): menjelaskan bagaimana sistem harus berperilaku, bukan implementasinya—mengambil konsep property safety/liveness dan invariant, tetapi dengan filosofi agar tetap bisa diakses melalui sintaks yang ramah pengembang.

Kelebihan SDD

• Visibilitas pengambilan keputusan & reutilisasi: spec menjadi “sumber” dari perubahan kode sehingga review dan penyepakatan lebih mudah, dan meskipun fitur berubah, intent (behaviors) tetap tertinggal.

• Spec hidup yang bisa dikomposisikan: skenario pengguna, acceptance criteria, kontrak interface/data, performa/SLA, dan lainnya dapat dimodularisasi sehingga bisa digunakan ulang dan dikomposisikan (layanan → level sistem).

• Berlaku di seluruh SDLC: mulai dari penyelarasan awal requirement dan desain hingga feedback loop dari isu setelah deploy—sebuah kesadaran masalah untuk tetap menjaga review, kualitas, dan konsistensi meski kecepatan pembuatan kode meningkat di era AI.

Demo SDD

• Untuk tautan titik mulai demo pada video yang diposting di Main link, lihat URL ini: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

Alur SDD

A. Pengaturan awal

1. Pengaturan project - Hooks, Steering, MCP
2. Pengaturan TDD (disarankan)
3. Pengaturan Spec - menulis Spec berbasis format EAR (disarankan) (dapat dibuat otomatis melalui AI dari analisis project yang ada)

B. Implementasi fitur

1. Turunan Spec - mencerminkan/memperbarui requirement baru ke dalam Spec
2. Pengaturan guardrail (disarankan) - stub test, penulisan aturan
3. Implementasi <-> pengujian - bagian ini sebagian besar diulang melalui AI, dan developer hanya turun tangan untuk perbaikan kecil pada kode yang sulit diperbaiki AI

• Setelah konfigurasi project selesai, fitur diperluas dengan mengulangi tahap 'B. Implementasi fitur'

Hal yang perlu diperhatikan

• Tidak akan berjalan jika kualitas dokumen Spec tidak mencapai standar minimum.
• Aturan standar dokumen Spec di dalam video tidak dijelaskan secara rinci. (Referensi: https://kiro.dev/docs/specs/)
• Penggunaan TDD direkomendasikan, tetapi dikatakan bahwa sebagian besar project yang tidak menerapkan TDD tidak banyak merasakan manfaat dari metodologi ini.

---

Pendapat pribadi

• Salah satu metodologi yang diusulkan dari sudut pandang lain untuk memanfaatkan AI dengan baik.
• Dokumen yang selalu ditulis dengan 'baik' memang memiliki sangat banyak kelebihan. Namun, berdasarkan pengalaman realistis bahwa cukup banyak dokumen tidak terpelihara dengan baik, kuncinya tampaknya adalah seberapa besar konsensus yang bisa dibangun dari banyak orang.
• Pada saat ini, strategi pengembangan AI + TDD adalah metodologi yang cukup teruji dan banyak mendapat persetujuan developer. Jika efektivitasnya bisa diverifikasi melalui perbandingan antara penggunaan TDD saja dan penggunaan SDD bersama-sama, kemungkinan akan mendapat dukungan yang jauh lebih luas.