Spec Driven Development Part 4: Dari Spec ke Kode — Workflow Praktis

Part 1 sampai 3 sudah membahas kenapa spec penting, bagaimana menulis spec yang baik untuk fitur, dan bagaimana menulis kontrak untuk API serta data. Tapi spec yang sempurna pun tidak otomatis menghasilkan kode yang baik kalau cara mengeksekusinya keliru. Banyak tim sudah punya spec yang solid, lalu tetap melempar seluruh spec itu ke agent sekaligus dengan instruksi “implementasikan ini”, dan terkejut ketika hasilnya tetap berantakan. Artikel ini membahas mekanik praktis menjalankan loop spec-driven sehari-hari: bagaimana spec diterjemahkan menjadi langkah-langkah kecil yang bisa dieksekusi, pola prompting yang efektif, kapan harus berhenti untuk review, dan bagaimana menjaga spec tetap menjadi sumber kebenaran yang akurat seiring kode terus berubah.

Dari Spec ke Plan: Memecah Pekerjaan

Spec mendefinisikan apa yang harus benar. Plan menerjemahkan itu menjadi urutan kerja — task-task kecil yang masing-masing bisa dieksekusi, diverifikasi, dan di-review secara terpisah. Melompat langsung dari spec ke “tolong implementasikan semua ini” adalah kesalahan paling umum dalam praktik SDD, bahkan oleh tim yang sudah disiplin menulis spec.

Alasannya sederhana: semakin besar potongan pekerjaan yang dieksekusi sekaligus, semakin sulit memverifikasi hasilnya, dan semakin mahal biaya ketika ada yang salah di tengah jalan. Kalau agent diminta mengimplementasikan seluruh fitur reset password dari Part 2 dan Part 3 dalam satu langkah — endpoint, validasi, email service, audit log, rate limiting — sekaligus, dan ternyata pendekatan rate limiting-nya salah, kamu harus mengevaluasi ulang seluruh hasil untuk memastikan bagian lain tidak ikut terdampak.

Plan yang baik memecah spec menjadi task dengan granularitas yang tepat — tidak terlalu besar (sulit diverifikasi), tidak terlalu kecil (overhead koordinasi jadi tidak sepadan):

Plan: Reset Password Mandiri

Task Group 1: Skema dan Migrasi
  1.1 Buat tabel password_reset_tokens (token_hash, email, expires_at, used_at)
  1.2 Tambah index pada email dan expires_at

Task Group 2: Endpoint Request Reset
  2.1 Buat endpoint POST /api/v1/password-reset/request
  2.2 Implementasikan rate limiting (3 request/email/jam)
  2.3 Generate token, simpan hash ke database
  2.4 Kirim email via SendGrid dengan link reset

Task Group 3: Endpoint Confirm Reset
  3.1 Buat endpoint POST /api/v1/password-reset/confirm
  3.2 Validasi token (exists, belum expired, belum dipakai)
  3.3 Validasi password baru sesuai kebijakan
  3.4 Update password, invalidate token

Task Group 4: Audit dan Observability
  4.1 Tambah audit log untuk setiap percobaan reset
  4.2 Tambah metric untuk monitoring rate limit hit

Setiap task group berkorespondensi dengan subset acceptance criteria yang sudah ditulis di spec, dan bisa diverifikasi secara independen sebelum lanjut ke task group berikutnya. Task Group 1 bisa diverifikasi dengan migration test sebelum Task Group 2 dimulai. Kalau ada masalah, lokasinya jelas — tidak perlu menelusuri seluruh fitur.

Aturan praktis untuk granularitas task: satu task group idealnya bisa diverifikasi dalam satu sesi review tanpa perlu memahami ulang seluruh konteks fitur dari awal. Kalau review satu task group butuh waktu lebih dari setengah jam untuk dipahami, task itu kemungkinan terlalu besar.

Tools yang Mendukung Workflow Spec-Driven

Workflow spec-driven tidak mengharuskan tool khusus — spec markdown biasa dan disiplin proses sudah cukup. Tapi beberapa kategori tool memang dirancang untuk memformalkan loop ini, dan layak diketahui meskipun tidak digunakan secara langsung.

Spec kit / CLI scaffolding — tool yang menyediakan struktur direktori dan command standar untuk fase spec, plan, dan task. Biasanya bekerja dengan command sekuensial: satu command untuk menangkap requirement awal, satu untuk menerjemahkan jadi rencana arsitektur, satu untuk memecah jadi task, dan satu untuk menjalankan implementasi sesuai task tersebut. Strukturnya memaksa keempat fase loop di Part 1 benar-benar dilalui berurutan, bukan dilompati.

Skill atau custom command pada AI coding agent — alih-alih menulis ulang instruksi yang sama setiap kali, konvensi tim (struktur file, pola error handling, standar testing) dienkapsulasi jadi skill yang bisa dipanggil berulang. Ini membuat setiap task dalam plan otomatis mengikuti konvensi project tanpa perlu dijelaskan ulang di setiap prompt.

Plan mode pada coding agent — mode di mana agent diminta menyusun rencana eksekusi terlebih dahulu dan menunggu persetujuan sebelum mulai mengubah kode. Ini secara langsung mengimplementasikan fase “review & refine” dari loop Part 1 di level tooling, bukan hanya proses manual.

Terlepas dari tool spesifik yang dipakai, prinsip yang sama berlaku: jangan biarkan agent lompat dari spec langsung ke kode tanpa fase plan yang eksplisit dan bisa direview.

Pola Prompting untuk Eksekusi Bertahap

Begitu plan sudah ada, cara meminta agent mengeksekusi task juga berpengaruh besar pada kualitas hasil. Pola yang efektif adalah merujuk eksplisit ke file spec dan plan, lalu meminta satu task group pada satu waktu — bukan seluruh plan sekaligus.

ANTI-PATTERN:
"Implementasikan fitur reset password sesuai spec yang sudah dibuat."

BENAR:
"Ambil Task Group 2 (Endpoint Request Reset) dari plan.md. Gunakan
spec.md sebagai rujukan acceptance criteria dan constraint. Setelah
selesai, update status task di plan.md dan jangan lanjut ke Task Group
3 sebelum saya review."

Perbedaan ini terlihat kecil tapi dampaknya signifikan. Instruksi pertama memberi agent kebebasan menafsirkan urutan kerja sendiri, yang sering berarti agent mencoba menyelesaikan semuanya sekaligus dalam satu respons panjang — sulit direview, dan kalau ada kesalahan di awal, kesalahan itu menjalar ke seluruh hasil. Instruksi kedua membatasi scope eksekusi ke satu task group, eksplisit merujuk ke dokumen yang jadi sumber kebenaran, dan menyisipkan jeda untuk review sebelum lanjut.

Pola “satu task group, lalu berhenti untuk review” ini konsisten dengan loop dari Part 1 — implementasi dan verifikasi berjalan berselang-seling, bukan implementasi besar diikuti satu verifikasi besar di akhir.

Godaan terbesar saat tenggat mepet adalah meminta agent “selesaikan semuanya sekaligus” untuk menghemat waktu. Ini biasanya kontraproduktif — waktu yang dihemat di fase eksekusi sering habis dua kali lipat di fase debugging ketika kesalahan baru ketahuan setelah semuanya tergabung jadi satu perubahan besar.

Review Selama Eksekusi, Bukan Hanya di Akhir

Salah satu pergeseran kebiasaan paling penting dalam SDD dibanding workflow lama adalah kapan review dilakukan. Workflow konvensional biasanya: developer menulis seluruh fitur, baru membuka pull request untuk direview. Dalam workflow spec-driven dengan agent, menunggu sampai akhir berarti menunggu terlalu lama untuk menangkap penyimpangan dari spec.

Checkpoint review di tengah eksekusi punya dua tujuan:

Menangkap drift sedini mungkin. Kalau Task Group 1 (skema database) sudah menyimpang dari constraint — misalnya kolom yang seharusnya di-hash malah disimpan plaintext — lebih murah memperbaikinya sebelum Task Group 2 dan 3 dibangun di atas skema yang salah, dibanding menemukan masalah ini setelah seluruh fitur selesai.

Memverifikasi bahwa plan masih relevan. Kadang implementasi task pertama mengungkap bahwa asumsi di plan ternyata keliru — misalnya ternyata index yang direncanakan tidak cukup untuk pola query yang dibutuhkan. Checkpoint memberi kesempatan menyesuaikan task berikutnya sebelum melanjutkan, bukan menemukan masalah ini setelah semua task selesai dikerjakan berdasarkan asumsi yang salah.

flowchart LR
    A[Task Group 1] --> B[Review Checkpoint]
    B -- OK --> C[Task Group 2]
    B -- Ada Masalah --> D[Perbaiki/Sesuaikan Plan]
    D --> C
    C --> E[Review Checkpoint]
    E -- OK --> F[Task Group 3]
    E -- Ada Masalah --> G[Perbaiki/Sesuaikan Plan]
    G --> F

Frekuensi checkpoint ini tidak harus seragam untuk semua jenis pekerjaan. Task group yang menyentuh skema data atau keamanan layak diverifikasi lebih ketat dibanding task group yang sifatnya kosmetik. Kalibrasi level ketelitian review sesuai risiko, bukan menerapkan satu standar review yang sama untuk semua jenis perubahan.

Menjaga Spec Tetap Sinkron dengan Kode

Spec yang akurat saat ditulis bisa dengan cepat jadi basi begitu implementasi berjalan dan menemukan detail yang tidak terantisipasi di awal. Masalah ini bukan hal baru — dokumentasi yang basi sudah jadi keluhan umum jauh sebelum AI coding agent ada. Tapi dalam SDD, masalah ini lebih serius karena spec bukan sekadar dokumentasi pasif — spec dipakai berulang kali sebagai rujukan oleh agent di sesi-sesi berikutnya.

Spec yang basi berbahaya dengan cara yang halus: agent di sesi berikutnya akan membaca spec, mempercayainya sebagai akurat, dan mengambil keputusan berdasarkan informasi yang sudah tidak sesuai dengan kode aktual. Hasilnya adalah inkonsistensi yang sulit dilacak, karena sumber masalahnya bukan di kode yang baru ditulis, tapi di spec lama yang tidak pernah diperbarui.

Strategi paling efektif untuk mencegah ini adalah menjadikan update spec sebagai bagian dari definisi “selesai” untuk setiap task, bukan langkah terpisah yang mudah dilewatkan:

Definition of Done per Task Group:
  □ Acceptance criteria terkait terpenuhi dan terverifikasi
  □ Test otomatis ditambahkan/diupdate
  □ Jika implementasi menyimpang dari plan awal (misal: pendekatan
    teknis berubah), spec.md atau plan.md diupdate untuk merefleksikan
    keputusan final
  □ Jika ditemukan requirement baru yang tidak tercakup spec awal,
    ditambahkan ke spec sebelum task dianggap selesai

Praktik ini mengubah hubungan antara spec dan kode dari satu arah (spec menentukan kode) menjadi dua arah (spec menentukan kode, tapi temuan selama implementasi juga mengalir balik memperbarui spec). Spec yang dirawat seperti ini tetap berguna sebagai rujukan akurat untuk sesi-sesi berikutnya — baik oleh agent yang sama maupun developer lain yang baru bergabung.

Perlakukan perubahan pada spec dengan level perhatian yang sama seperti perubahan pada kode — review, bukan sekadar edit bebas. Spec yang bisa diubah siapa saja tanpa review akan kehilangan otoritasnya sebagai sumber kebenaran.

Menangani Spec yang Berubah di Tengah Implementasi

Requirement berubah di tengah jalan adalah kenyataan yang tidak bisa dihindari, bukan tanda proses yang gagal. Stakeholder mengubah pikiran, kompetitor merilis fitur baru yang mengubah prioritas, atau tim menemukan constraint teknis yang tidak terlihat di awal. Pertanyaannya bukan bagaimana mencegah perubahan, tapi bagaimana menanganinya tanpa merusak konsistensi pekerjaan yang sudah berjalan.

Ada beberapa pola penanganan tergantung seberapa jauh implementasi sudah berjalan saat perubahan terjadi:

Perubahan sebelum implementasi dimulai — paling murah. Update spec, review ulang, regenerate plan jika perlu. Tidak ada kode yang perlu dibongkar.

Perubahan setelah sebagian task group selesai — perlu evaluasi dampak. Task group mana yang masih valid, mana yang perlu direvisi, mana yang harus dibuang. Spec diupdate dengan menandai jelas bagian mana yang berubah dari versi sebelumnya, supaya agent yang melanjutkan tahu task group mana yang perlu ditinjau ulang.

Spec: Reset Password Mandiri (v2)

CHANGELOG:
- v2: Menambah constraint MFA opsional untuk akun dengan 2FA aktif
  (lihat Task Group 5 baru). Task Group 1-4 tidak terdampak.

[isi spec lengkap...]

Task Group 5: Integrasi dengan 2FA (BARU di v2)
  5.1 Jika akun punya 2FA aktif, reset password harus tetap meminta
      verifikasi 2FA setelah password baru disimpan

Perubahan setelah seluruh fitur selesai dan sudah di production — ini bukan lagi “perubahan di tengah implementasi”, melainkan requirement baru yang butuh siklus spec-driven sendiri, dimulai dari fase spec lagi, bukan ditambal langsung ke kode tanpa proses.

Yang penting dijaga di semua skenario ini: histori perubahan tetap tercatat (changelog sederhana sudah cukup), dan task group yang sudah terverifikasi tidak diam-diam berubah maknanya tanpa ditandai eksplisit.

Anti-Pattern dalam Eksekusi

Beberapa kebiasaan yang sering merusak workflow spec-driven meski spec-nya sendiri sudah ditulis dengan baik:

One-shot seluruh fitur kompleks. Sudah disinggung di atas, tapi cukup umum untuk ditekankan ulang: meminta agent menyelesaikan seluruh plan dalam satu eksekusi besar tanpa jeda review menghilangkan keuntungan utama dari memecah pekerjaan jadi task group.

Melompati fase plan. Langsung dari spec ke “tulis kodenya”, tanpa fase eksplisit menerjemahkan spec jadi urutan task. Spec yang baik tetap bisa menghasilkan kode yang berantakan kalau eksekusinya tidak terstruktur.

Mengabaikan update spec setelah implementasi menyimpang. Tim sering merasa update spec adalah “kerja administratif” yang bisa ditunda. Dalam praktiknya, penundaan ini hampir selalu berarti spec tidak pernah diupdate sama sekali, dan jadi sumber kebingungan di sesi berikutnya.

Checkpoint review yang terlalu jarang atau terlalu sering. Review di setiap baris kode menghilangkan keuntungan delegasi ke agent; review hanya di akhir kehilangan keuntungan menangkap drift sedini mungkin. Kalibrasi frekuensi sesuai risiko task group, seperti dibahas di bagian checkpoint sebelumnya.

Plan yang ditulis sekali lalu dianggap immutable. Plan adalah rencana kerja, bukan kontrak yang tidak boleh disentuh. Kalau implementasi mengungkap bahwa urutan task perlu disesuaikan, plan harus ikut menyesuaikan — bukan dipaksakan mengikuti urutan yang sudah tidak relevan.

Tanda paling jelas workflow spec-driven berjalan baik bukan “tidak pernah ada perubahan”, tapi “perubahan selalu tercermin di spec sebelum atau bersamaan dengan kode berubah” — bukan kode yang diam-diam menyimpang sementara spec tertinggal di belakang.

Ringkasan

• Spec menentukan apa yang harus benar; plan menerjemahkannya jadi urutan kerja dalam task group yang masing-masing bisa diverifikasi secara independen
• Granularitas task yang ideal: cukup besar untuk bermakna, cukup kecil agar bisa direview tanpa perlu memahami ulang seluruh konteks fitur
• Pola prompting yang efektif merujuk eksplisit ke file spec dan plan, meminta satu task group pada satu waktu, dan menyisipkan jeda review — bukan meminta seluruh fitur sekaligus
• Review dilakukan di tengah eksekusi (checkpoint per task group), bukan hanya di akhir — ini menangkap drift dari spec sedini mungkin sebelum menjalar ke task berikutnya
• Update spec adalah bagian dari definition of done setiap task, bukan langkah administratif terpisah yang mudah dilewatkan
• Requirement yang berubah di tengah implementasi ditangani dengan mengevaluasi dampak ke task yang sudah selesai, mengupdate spec dengan changelog yang jelas, dan menandai task mana yang perlu ditinjau ulang
• Hindari eksekusi one-shot untuk fitur kompleks, melompati fase plan, dan membiarkan spec basi setelah implementasi menyimpang dari rencana awal