Spec-Driven Development With AI Coding Agents

Ini alur kerja di mana Anda menulis spesifikasi yang jelas sebelum implementasi, lalu meminta agen coding AI membangun berdasarkan spesifikasi itu alih-alih coding satu prompt demi prompt. Spesifikasi adalah artefak tahan lama yang bisa dicek, dirujuk agen, dan menjadi acuan verifikasi kode akhir.
Prompt bersifat sekali pakai dan hilang dari konteks, sehingga tidak menyisakan acuan untuk memverifikasi hasil. Spesifikasi adalah sumber kebenaran tertulis yang terus dibaca ulang agen dan bisa di-diff peninjau, mengubah permintaan samar menjadi kriteria penerimaan yang eksplisit.
Loop umumnya adalah specify, plan, implement, verify. Anda jelaskan apa yang dibangun dan seperti apa keberhasilannya, tetapkan stack dan batasan, biarkan agen membuat perubahan terfokus yang bisa ditinjau, lalu cek kode terhadap kriteria penerimaan dan ulangi jika belum memenuhi.
Ya, keduanya berperan sebagai spesifikasi hidup di level proyek. Claude Code membaca CLAUDE.md di awal tiap sesi sebagai konteks tetap, dan AGENTS.md adalah format terbuka yang dibaca banyak agen untuk perintah build dan konvensi. Keduanya memberi agen instruksi tahan lama, bukan prompt sekali jalan.
Untuk perbaikan satu baris atau skrip sekali pakai, maksudnya sudah muat dalam prompt dan spesifikasi penuh lebih mahal daripada manfaatnya. Pakai alur ini pada fitur dengan ambiguitas nyata, banyak bagian bergerak, atau kode legacy di mana salah menafsirkan maksud itu mahal.

Ringkasan Utama
Spec-driven development adalah alur kerja di mana Anda menulis spesifikasi yang jelas lebih dulu, lalu meminta agen coding AI mengimplementasikannya. Spesifikasi itu menjadi konteks tahan lama yang terus dirujuk agen, mengubah permintaan samar menjadi kriteria penerimaan yang bisa dicek, dan memungkinkan peninjauan serta verifikasi alih-alih mempercayai satu prompt untuk menghasilkan kode yang benar.
Agen coding AI itu cepat, dan kecepatan itu menyembunyikan sebuah masalah. Ketika Anda memberi agen prompt satu baris, ia mengisi setiap celah yang tidak Anda sebutkan dengan tebakannya sendiri. Hasilnya biasanya bisa dikompilasi dan sering terlihat benar, tetapi bagian yang tidak pernah Anda jabarkan justru bagian yang balik salah.
Spec-driven development membalik urutannya. Alih-alih menuju hasil lewat prompt satu per satu, Anda menulis spesifikasi lebih dulu, lalu mengarahkan agen ke sana. Tulisan ini membahas mengapa cara itu memberi hasil lebih baik dengan agen, loop specify-plan-implement-verify, dan kapan struktur tambahan ini tidak sepadan.
Tim GitHub menyebut mode default ini vibe coding: Anda menjelaskan tujuan, agen mengembalikan kode yang tampak masuk akal, dan Anda baru sadar belakangan bahwa kode itu tidak benar-benar bekerja. Ungkapan mereka tegas. Model sangat hebat menyelesaikan pola tetapi tidak bisa membaca pikiran Anda, sehingga prompt yang samar memaksa model menebak kebutuhan yang tidak pernah Anda tuliskan.
Masalah yang lebih dalam adalah prompt chat itu sekali pakai. Ia hilang dari jendela konteks, tidak pernah ditinjau, dan tidak meninggalkan artefak untuk mengecek kode akhir. Anda akhirnya mengejar sasaran yang bergerak, mengoreksi setiap kejutan saat muncul, tanpa definisi selesai bersama yang Anda dan agen sepakati sebelum pekerjaan dimulai.
Spec-driven development berarti Anda menghasilkan spesifikasi tertulis sebelum implementasi, dan dokumen itu menjadi sumber kebenaran yang dipakai agen. Kerangka GitHub memandang spesifikasi sebagai artefak hidup dan dapat dieksekusi, bukan paragraf yang dibuang begitu coding dimulai. Agen membacanya, merencanakan berdasarkannya, dan Anda mengecek kode terhadapnya.
Cara ini cocok dengan agen karena alasan konkret: spesifikasi adalah konteks tahan lama. Agen terus membacanya ulang sepanjang tugas panjang, sehingga maksud tetap bertahan meski riwayat percakapan dipangkas. Ia juga mengubah permintaan samar menjadi kriteria penerimaan yang eksplisit, dan itulah yang membuat peninjauan serta verifikasi menjadi mungkin. Idenya menggemakan design by contract, di mana kewajiban dan jaminan sebuah komponen ditulis sebagai spesifikasi yang tepat dan dapat diverifikasi, bukan dibiarkan tersirat.
Simpan spesifikasi dalam sebuah file di repo, bukan di kolom chat. Spesifikasi yang di-commit adalah sesuatu yang bisa dibaca ulang agen kapan saja dan bisa di-diff oleh peninjau manusia, hal yang tak pernah bisa dilakukan prompt yang sudah hilang.
Berbagai toolkit di bidang ini bertemu pada empat langkah yang sama. Spec Kit dari GitHub, sebuah toolkit open-source untuk spec-driven development, menyusun alurnya sebagai perintah-perintah terpisah, dan loop dasarnya mudah dijalankan manual di agen mana pun bahkan tanpa alat.
Spesifikasi baru bernilai ketika ia bertahan lebih dari satu sesi. File instruksi persisten melakukan ini di level proyek. Claude Code membaca file CLAUDE.md di awal setiap sesi sebagai konteks tetap, dan konvensi AGENTS.md, format terbuka yang diadopsi banyak agen coding, memberi alat tempat yang bisa diprediksi untuk menemukan perintah build, konvensi, dan aturan proyek. Semua ini berperan sebagai spesifikasi hidup tentang bagaimana codebase mengharapkan pekerjaan dilakukan.
Kriteria penerimaan terbaik cukup konkret untuk diverifikasi. Panduan memory Claude Code menyatakannya gamblang: tulis gunakan indentasi 2 spasi alih-alih format kode dengan rapi, dan jalankan perintah tes sebelum commit alih-alih uji perubahanmu. Kriteria yang bisa dicek secara mekanis adalah kriteria yang bisa dipenuhi agen dan bisa dikonfirmasi peninjau. Yang samar hanya memindahkan tebakan ke langkah berikutnya.
File instruksi persisten adalah konteks, bukan penegakan. Agen membacanya dan berusaha mengikutinya, tetapi tidak ada jaminan kepatuhan ketat, jadi apa pun yang harus selalu berlaku sebaiknya ditaruh di pemeriksaan nyata seperti tes, linter, atau commit hook.
Spec-driven development punya mode gagalnya sendiri. Dokumen yang terlalu rinci sama rapuhnya dengan prompt samar: ia usang begitu kode bergerak melampauinya, dan spesifikasi yang saling bertentangan membuat agen memilih separuh mana pun yang ia suka. Untuk pekerjaan yang benar-benar kecil, ceremoni ini lebih mahal daripada manfaatnya.
Spec-driven development bukan birokrasi tambahan tanpa guna. Ia memberi agen coding AI konteks tahan lama untuk dikerjakan, mengubah permintaan samar menjadi kriteria yang benar-benar bisa diverifikasi, dan mengganti koreksi reaktif dengan spesifikasi yang disepakati kedua belah pihak lebih dulu. Tuliskan, arahkan agen ke sana, dan cek hasilnya terhadapnya.