Apa itu pengembangan berbasis spesifikasi?

Dengan aksesibilitas alat AI dan asisten pengodean, seperti GitHub Copilot dari Microsoft, Claude Code dari Anthropic, atau Bob dari IBM, hambatan masuk untuk pembuatan kode menjadi berkurang. Agen AI berdukungan LLM yang menggunakan model AI canggih dapat menjalankan serangkaian tugas berulang secara real-time kapan saja, semuanya dengan satu prompt dari pengguna.

Dalam pengembangan perangkat lunak, ini berarti kita dapat mengoptimalkan dan mengotomatiskan alur kerja pengembangan untuk membangun prototipe, fitur baru, pengujian unit, dan lain-lain. Pembuatan kode tidak pernah semudah ini. Namun, ada semacam jebakan yang perlu diwaspadai oleh praktisi vibe coding: kualitas AI bergantung pada instruksi yang diterimanya. 

Anda mungkin pernah menjumpai utang teknis dalam kehidupan nyata, mungkin tanpa menyadarinya. Utang teknis sudah ada sebelum munculnya tren "vibe coding" dan telah menjadi bagian dari pengembangan perangkat lunak selama beberapa dekade; utang ini menumpuk ketika pengembang mengambil jalan pintas demi kecepatan. Namun, vibe coding justru mempercepat penumpukan utang teknis dengan memudahkan pembuatan sejumlah besar kode tanpa pemahaman atau validasi secara menyeluruh terhadap kode tersebut. Mungkin ada tekanan untuk memberikan hasil dengan cepat, atau praktisi vibe coding tidak memiliki latar belakang teknis untuk menghentikan utang teknis sebelum dimulai.  

Utang teknis dalam pengembangan berdukungan AI dapat muncul dalam beberapa bentuk: 

• Penyimpangan konteks terjadi ketika perbaikan bug di satu area secara tidak sengaja merusak fungsionalitas di area lain. Ini merupakan ciri dari kode yang dihasilkan tanpa pemahaman lengkap tentang sistem yang lebih luas.  
• Fragmentasi merupakan gejala umum lainnya, ketika fitur-fitur yang baru dibuat tidak selaras dengan konvensi arsitektur yang sudah ada, sehingga secara bertahap mengikis konsistensi dan kemudahan pemeliharaan basis kode.  
• Ada juga biaya operasional yang perlu dipertimbangkan. Tanpa spesifikasi yang jelas sebagai landasan bagi proses pembuatan, pengembang dapat terjebak dalam siklus pembuatan prompt yang tak berkesudahan. Pendekatan ini bisa menghabiskan ribuan token untuk memperbaiki kesalahan yang sebenarnya dapat dicegah jika ada spesifikasi yang dirumuskan dengan baik. 

Bayangkan skenario yang diketahui dengan baik oleh banyak pengembang di industri ini. Anda telah mengerjakan sebuah fitur baru selama beberapa hari atau minggu, dan fitur ini hampir siap diluncurkan. Kemudian, terdesak oleh tenggat yang makin dekat, Anda mempercepat proses penyesuaian terakhir melalui serangkaian perubahan menggunakan prompt AI.

Fungsi kode yang dihasilkan, baik yang ditulis dengan Python maupun bahasa lain, mungkin terlihat baik-baik saja dari sudut pandang pengguna. Namun, dalam prosesnya, beberapa kerentanan terungkap, terjadi konflik dependensi, dan penanganan serta pengujian edge case terlupakan sepenuhnya.

Spesifikasi formal yang ditetapkan sejak awal memberikan sumber kebenaran bersama bagi tim untuk mengatur setiap fase siklus proses pengembangan perangkat lunak (software development lifecycle, SDLC), terlepas dari siapa yang menulis kode. 

Ada beberapa pendekatan dan templat untuk pengembangan berbasis spesifikasi, serta ada berbagai tingkat pemeliharaan spesifikasi dan berbagai kompromi. Alih-alih selalu mencari perkembangan yang “lebih baik”, pilihan yang tepat bergantung pada basis kode, tim, dan ruang masalah Anda. Pertimbangkan kebutuhan dan kendala tim Anda sebelum memilih pendekatan yang paling sesuai.

Dalam pengembangan yang mengutamakan spesifikasi, spesifikasi disusun sebelum kode apa pun dihasilkan, baik dalam bentuk kisah pengguna, kriteria penerimaan, atau dokumen persyaratan formal. Setelah kejelasan awal diberikan dan kode dihasilkan, spesifikasi tersebut belum tentu tetap dipertahankan. Spesifikasi mungkin menjadi usang seiring dengan perkembangan perangkat lunak. Tujuan utamanya adalah memberikan kejelasan awal tanpa pemeliharaan spesifikasi berkelanjutan. Aspek ini dianggap sebagai “titik masuk ke SDD”. ¹

Dalam pengembangan berlandaskan spesifikasi, spesifikasi berkembang seiring dengan perangkat lunak. Saat persyaratan berubah dan fitur ditambahkan, spesifikasi diperbarui untuk mencerminkan kondisi sistem saat ini. Ini sangat berguna untuk proyek-proyek yang mendukung inisiatif yang lebih besar.

Pengujian otomatis berfungsi sebagai jembatan antara dokumentasi dan implementasi, yang sering kali diintegrasikan ke dalam pipeline CI/CD untuk memastikan keduanya tetap sinkron dan dapat dieksekusi di sepanjang siklus proses pengembangan. Keseimbangan antara struktur dan fleksibilitas ini menjadikan pengembangan berlandaskan spesifikasi sebagai pendekatan yang praktis dan dapat diskalakan bagi sebagian besar tim teknik.¹

Pada ujung terjauh spektrum, terdapat pengembangan dengan spesifikasi sebagai sumber, yang merupakan bentuk yang paling mengutamakan AI. Dalam pengembangan dengan spesifikasi sebagai sumber, perubahan spesifikasi akan otomatis memicu perubahan kode. Tidak ada seorang pun yang pernah secara langsung memfaktorkan ulang kode tersebut.

Tingkat otoritas spesifikasi ini menuntut kepercayaan yang tinggi terhadap kualitas dan konsistensi pipeline pembuatan kode AI, yang pada dasarnya tetap nondeterministik saat ini. Dalam praktiknya, ini berarti otoritas tersebut bisa jadi kurang kuat tanpa pengawasan manusia yang ketat. Sebelum mengadopsi pendekatan ini, tim harus mengevaluasi dengan cermat tingkat kematangan tumpukan teknologi dan kit spesifikasi mereka, kekritisan sistem yang terlibat, dan kapasitas mereka dalam memvalidasi output buatan AI.¹

Dalam praktiknya, banyak tim mengadopsi pendekatan hybrid:

• Memperlakukan spesifikasi sebagai artefak berversi yang dapat ditumpuk, seperti catatan keputusan arsitektur (architecture decision record, ADR), alih-alih selalu memperbaruinya sepenuhnya.
• Menggunakan sistem eksternal (misalnya, pelacak masalah) sebagai sumber kebenaran untuk menerapkan pemisahan yang disengaja.
• Menghindari otomatisasi berlebihan dalam proyek yang sangat kompleks atau berbasis komunitas, di mana pengendalian yang ketat atas perubahan sangat penting.

Setiap pendekatan memiliki kelebihan dan keterbatasan; konteks lebih penting daripada kepatuhan yang kaku terhadap satu model tertentu.

Tergantung pada tingkat otoritas spesifikasi yang Anda inginkan, spesifikasi yang efektif mungkin akan terlihat berbeda. Namun, dengan asumsi Anda berada di tengah-tengah spektrum tersebut dan memilih pendekatan pengembangan berlandaskan spesifikasi, spesifikasi tersebut harus menjelaskan apa yang harus dilakukan oleh sistem dengan istilah yang jelas dan dapat diuji. Spesifikasi ini mencegah Anda terikat terlalu dini pada cara implementasinya.

Spesifikasi harus cukup terperinci sehingga mencakup definisi input dan output, skema data, edge case, dan kriteria keberhasilan. Namun, spesifikasi ini juga harus cukup ringan agar dapat berkembang seiring dengan makin baiknya pemahaman terhadap masalah tersebut. Yang terpenting, spesifikasi yang baik seharusnya mempercepat pengembangan: jika spesifikasi tidak membantu Anda menulis kode yang lebih baik dengan lebih cepat atau mengurangi kesalahpahaman, kemungkinan besar spesifikasi tersebut terlalu terperinci daripada yang sebenarnya diperlukan. 

Untuk menggambarkan seperti apa spesifikasi yang efektif dalam praktiknya, perhatikan contoh berikut mengenai fitur autentikasi pengguna: 

Anda sedang mengimplementasikan fitur login pengguna untuk aplikasi web.  
Gunakan spesifikasi berikut sebagai sumber kebenaran tunggal.  
Jangan membuat asumsi tentang persyaratan apa pun yang tidak tercantum di sini. 
 
FITUR: Login Pengguna

 RINGKASAN:
Izinkan pengguna terdaftar untuk melakukan autentikasi secara aman menggunakan  
alamat email dan kata sandi mereka. 
 
KRITERIA PENERIMAAN: 
1. Formulir login harus menerima alamat email dan kata sandi 
2. Jika kredensial valid, arahkan pengguna ke dasbor 
3. Jika kredensial tidak valid, tampilkan pesan kesalahan umum  
  tanpa menyebutkan kolom mana yang salah 
4. Kunci akun selama 15 menit setelah 5 kali percobaan  
  gagal berturut-turut 
5. Kirim kata sandi hanya melalui HTTPS — jangan pernah simpan sebagai teks biasa 
 
DI LUAR CAKUPAN: 
- Login sosial (OAuth) 
- Autentikasi dua faktor 
- Alur pengaturan ulang kata sandi 
 
EDGE CASE: 
- temukan kolom kosong pada sisi klien sebelum pengiriman 
- Arahkan sesi kedaluwarsa ke halaman login dengan pesan informatif 
- Formulir harus tetap berfungsi jika JavaScript dinonaktifkan 
 
jangan mulai implementasi hingga Anda mengonfirmasi pemahaman Anda  
tentang kriteria penerimaan.

Ini mirip dengan spesifikasi fungsional yang ditulis oleh manajer produk, tetapi ruang lingkupnya dipersempit hingga mencakup apa yang harus disertakan dalam implementasi, atau kriteria penerimaannya, dan bagaimana cara menangani edge case dengan baik.

Umumnya, spesifikasi ini akan disimpan dalam repositori (“repo”) proyek di GitHub sebagai file Markdown sepertiSPEC.md atau/docs/auth-login.md , yang diversikan melalui Git bersama dengan basis kode. Agen pengodean AI dapat mengaksesnya jika file ditempelkan ke prompt oleh pengguna, atau sebaiknya, file direferensikan melalui CLI dan agen membacanya dari direktori proyek. Misalnya, “Terapkan fitur yang dijelaskan dalam /docs/auth-login.md ”.

Dalam pipeline yang lebih otomatis, file spesifikasi diteruskan sebagai bagian dari prompt sistem atau jendela konteks pada awal tugas, yang memberikan instruksi kepada agen sebelum dimulai.

Meskipun pengembangan berbasis spesifikasi dapat menghemat banyak waktu dan mengurangi utang teknis, penting juga untuk diingat bahwa kita bisa saja menghabiskan terlalu banyak waktu untuk “rekayasa berlebihan”. Jika Anda membutuhkan tiga minggu untuk menentukan nama sebuah kunci JSON atau titik akhir API tertentu untuk fitur yang mungkin dihapus dalam sebulan, hal ini bertentangan dengan tujuan pengembangan berbasis spesifikasi.  

Jangan terlalu berfokus memodelkan setiap hal yang mungkin terjadi masa depan. Utamakan spesifikasi yang ringan dan terus berkembang, bukan spesifikasi yang lengkap dan “final”. Tulis apa yang Anda butuhkan untuk bergerak maju, validasikan dengan cepat dalam kode, dan lakukan iterasi seiring perubahan realitas. Prinsip umumnya adalah bahwa biaya penyempurnaan spesifikasi harus selalu lebih rendah daripada biaya untuk memperbaiki kesalahpahaman dalam tahap implementasi. Ketika keseimbangan tersebut berubah, ini adalah sinyal untuk berhenti menyempurnakan dan mulai membangun.

Dengan hadirnya alat bantu pengodean AI, pengembangan berbasis pengujian (TDD) dan pengembangan berbasis perilaku (BDD) mengilhami gelombang baru: pengembangan berbasis spesifikasi. Jika TDD meminta pengembang untuk menentukan hasil yang diharapkan melalui pengujian, dan BDD meminta pengembang untuk mendefinisikan perilaku melalui kolaborasi, pengembangan berbasis spesifikasi mengajukan pertanyaan yang lebih mendasar terlebih dahulu: sudahkah kita mendefinisikan dengan jelas apa yang kita bangun, dan untuk siapa?^2,3

Seiring meningkatnya porsi pekerjaan implementasi yang ditangani agen AI, kualitas pekerjaan tersebut menjadi berbanding lurus dengan kualitas instruksi yang diterima agen. Spesifikasi yang ditulis dengan baik tidak akan membatasi proses pengembangan, melainkan mempercepatnya dalam sistem perangkat lunak modern.