Untuk order transaksi, tampaknya ada kemungkinan order yang tidak diinginkan bisa diproses akibat prompt injection dan sejenisnya, jadi fitur tambahan seperti pembatasan instrumen yang boleh dipesan atau batas nominal tampaknya akan sangat penting.
Membalik alur yang sebelumnya berpusat pada kode dengan PRD dan dokumen desain sebagai pendukung, sehingga spesifikasi menjadi sumber utama dan kode menjadi artefak ekspresi yang diimplementasikan dalam bahasa atau framework tertentu
Diajukan diagnosis bahwa kesenjangan permanen antara spesifikasi dan implementasi sulit diatasi hanya dengan penguatan dokumentasi atau prosedur
Jika spesifikasi yang dapat dieksekusi dan rencana implementasi menghasilkan kode, maka kesenjangan itu hilang dan yang tersisa hanya transformasi
AI memungkinkan penafsiran spesifikasi yang kompleks dan penyusunan rencana implementasi, tetapi generasi tanpa struktur menimbulkan kekacauan, sehingga SDD menjaga kualitas dengan struktur dan guardrail yang presisi
Pemeliharaan adalah tindakan evolusi spesifikasi, niat pengembangan diekspresikan melalui bahasa alami, aset desain, dan prinsip inti, sementara kode menempati posisi last mile
Debugging memprioritaskan perbaikan spesifikasi dan rencana implementasi alih-alih memperbaiki kode yang salah, dan refactoring didefinisikan ulang sebagai restrukturisasi demi kejelasan
The SDD Workflow in Practice
Ide dimatangkan menjadi PRD melalui interaksi percakapan dengan AI, dan AI memperjelas pertanyaan, edge case, dan kriteria penerimaan
Mengubah kebutuhan dan desain menjadi aktivitas berkelanjutan sehingga mendukung pekerjaan spesifikasi berbasis branch di tingkat tim, beserta review dan versioning
Research agent menelusuri kompatibilitas library, performa, keamanan, dan kendala organisasi (standar DB, autentikasi, kebijakan deployment), lalu otomatis mencerminkannya ke spesifikasi
Dari PRD dihasilkan rencana implementasi yang memetakan kebutuhan dan keputusan teknis secara dapat ditelusuri, sementara AI terus memverifikasi kontradiksi, ambiguitas, dan kekurangan
Saat spesifikasi dan rencana sudah cukup stabil, generasi kode dimulai, tetapi pada tahap awal dilakukan generasi eksploratif untuk memverifikasi kelayakan
Konsep domain diubah menjadi model data, user story menjadi endpoint API, dan skenario penerimaan menjadi test
Metrik dan insiden pada tahap operasional memperbarui spesifikasi agar tercermin dalam regenerasi berikutnya; bottleneck performa dinaikkan menjadi kebutuhan nonfungsional, dan kerentanan menjadi kendala global
Why SDD Matters Now
Titik ambang kapabilitas AI: kini dimungkinkan menghasilkan kode yang berfungsi secara andal dari spesifikasi bahasa alami, dan otomatisasi bagian mekanis dari penerjemahan implementasi mendukung eksplorasi serta amplifikasi kreativitas
Ledakan kompleksitas: banyaknya layanan, framework, dan dependensi membuat keselarasan antara niat dan implementasi sulit dipertahankan, sehingga diperlukan penyelarasan yang digerakkan spesifikasi ala SDD
Percepatan perubahan: dalam situasi pivot yang sering terjadi, SDD menangani perubahan lewat regenerasi sistematis alih-alih propagasi manual dokumen-desain-kode
Sebagai contoh, ini memungkinkan simulasi what-if dan implementasi paralel, sehingga memberi kelincahan pengambilan keputusan
Core Principles
Spesifikasi = bahasa bersama: spesifikasi adalah artefak kelas satu, kode adalah ekspresi dari stack tertentu, dan pemeliharaan adalah tindakan evolusi spesifikasi
Spesifikasi yang dapat dieksekusi: spesifikasi dengan tingkat akurat, lengkap, dan tidak ambigu menghasilkan sistem yang berjalan
Penyempurnaan berkelanjutan: melakukan verifikasi konsistensi terus-menerus, bukan gate sekali jalan
Konteks berbasis riset: performa, keamanan, dan kendala organisasi dikumpulkan secara kontinu lalu disuntikkan ke spesifikasi
Umpan balik dua arah: realitas operasional menjadi input pembaruan spesifikasi
Branching untuk eksplorasi: mendukung pembuatan banyak implementasi dari spesifikasi yang sama sesuai target optimasi seperti performa, maintainability, UX, dan biaya
Implementation Approaches
Praktik saat ini berfokus pada kombinasi alat yang sudah ada dan menjaga disiplin, dan dapat diimplementasikan dengan elemen berikut
AI assistant untuk penyempurnaan spesifikasi secara iteratif
Research agent untuk pengumpulan konteks teknis
Alat generasi kode untuk transformasi spesifikasi → implementasi
Version control yang disesuaikan dengan workflow spec-first
Pengecekan berbasis analisis konsistensi AI terhadap dokumen spesifikasi
Prinsip umumnya adalah menempatkan spesifikasi sebagai single source of truth, dan memperlakukan kode sebagai artefak yang diminta spesifikasi
Streamlining SDD with Commands
/specify: mengubah deskripsi fitur menjadi spesifikasi terstruktur, lalu mengotomatiskan penomoran, pembuatan branch, dan susunan direktori berbasis template
/plan: analisis spesifikasi → peninjauan kepatuhan konstitusi → penerjemahan teknis → dokumentasi model data, kontrak API, dan skenario test → menghasilkan validasi quickstart
/tasks: membaca plan.md dan desain terkait untuk menghasilkan daftar task yang dapat dieksekusi, serta memberikan penanda task yang bisa diparalelkan dan pengelompokan paralel yang aman
Contoh: fitur chat
Menunjukkan contoh alur yang mempersingkat sekitar 12 jam pekerjaan dokumentasi tradisional menjadi sekitar 15 menit penyiapan melalui otomasi spesifikasi, rencana, dan task
Artefaknya mencakup spesifikasi, rencana implementasi dan alasannya, kontrak API dan model data, skenario quickstart, serta tasks.md yang dikelola versinya di branch
The Power of Structured Automation
Mencegah item terlewat: template mencakup hingga kebutuhan nonfungsional dan penanganan error
Keterlacakan keputusan: semua pilihan teknis terhubung ke kebutuhan yang konkret
Dokumen yang hidup: karena spesifikasi menghasilkan kode, sinkronisasi lebih mudah dijaga
Iterasi cepat: saat kebutuhan berubah, regenerasi rencana memungkinkan respons dalam hitungan menit atau jam
Template-Driven Quality
Mencegah detail implementasi masuk terlalu dini: aturan fokus pada WHAT/WHY dan mengecualikan HOW membantu menjaga level abstraksi
Self-review berbasis checklist: mewujudkan quality gate dengan memeriksa kelengkapan, kejelasan, dan kriteria penerimaan yang terukur
Constitution gate: menerapkan pemeriksaan tahap awal (-1) seperti gate kesederhanaan (≤3 proyek), gate anti-abstraksi (langsung memakai framework), dan gate integrasi lebih dulu (kontrak dan contract test didahulukan)
Manajemen detail berlapis: kode dan detail yang berlebihan dipisahkan ke implementation-details/ untuk menjaga keterbacaan
Prioritas test: memastikan verifiabilitas dengan aturan pembuatan file dan test lebih dulu dalam urutan kontrak → integrasi → E2E → unit
Menekan asumsi dan fitur spekulatif: memperkuat pengelolaan cakupan lewat larangan fitur spekulatif dan penjelasan prasyarat tiap tahap
The Constitutional Foundation
Mengadopsi konstitusi pengembangan dalam bentuk prinsip tak berubah di memory/constitution.md untuk menjaga seluruh implementasi tetap konsisten, sederhana, dan berkualitas tinggi
Article I: Library-First — semua fitur dimulai sebagai library independen untuk memastikan modularitas
Article II: CLI Mandate — semua library harus mengekspos antarmuka CLI yang mendukung input/output teks dan JSON untuk menjamin observabilitas dan kemudahan pengujian
Article III: Test-First — implementasi dilarang sebelum test disetujui dan kegagalan (red) dikonfirmasi, dengan prinsip definisi perilaku didahulukan
Articles VII & VIII: Kesederhanaan dan anti-abstraksi — menekan overengineering dengan meminimalkan jumlah proyek dan mengandalkan framework secara langsung
Article IX: Integration-First Testing — mengutamakan test yang mendekati lingkungan nyata dan mewajibkan contract test didahulukan sebelum implementasi
Melalui gate Phase -1 pada template, kepatuhan pada konstitusi diubah menjadi checklist, dan pengecualian mencatat alasan eksplisit dalam Complexity Tracking
Melalui prosedur amandemen, cara penerapan prinsip dapat berevolusi, tetapi filsafat intinya tetap dipertahankan
The Transformation
Tujuannya bukan menggantikan developer, melainkan mengotomatiskan penerjemahan yang mekanis untuk mengamplifikasi kemampuan manusia dan menjaga keselarasan antara niat dan implementasi
SDD mempraktikkan transformasi berkelanjutan di mana spesifikasi menghasilkan kode, sehingga spesifikasi, riset, dan kode berevolusi bersama dalam feedback loop yang rapat
Dan, Anda juga menanyakan soal eksperimen terkait jumlah rangkaian prompt,
sebenarnya justru ini adalah elemen yang, dalam istilah kasarnya, bagus untuk dipakai penulis “mengakali” hasil.
Aktivitas development itu sendiri memiliki sangat banyak pilihan arah dalam prosesnya, dan jika prompt ditumpuk ke arah yang membuat penggunaan token semakin melebar, angka itu akan membengkak jauh lebih besar seperti bola salju.
Dalam penelitian, ada filosofi yang disebut Cumulative Science.
Setidaknya menurut standar saya, saya belum pernah sekalipun menemukan penelitian terkait penggunaan token untuk 1 kali perintah,
jadi alih-alih langsung melakukan penelitian N kali, saya memilih fokus pada pengujian dan kesimpulan untuk 1 kali yang benar-benar jelas,
dan penelitian N kali bisa dilanjutkan setelah eksperimen ini sebagai kelanjutan riset.
Singkatnya, tulisan tersebut membahas pengujian dan hasil bahwa kualitas output berubah tergantung pada codebase yang diberikan sebagai input ke AI.
Bergantung pada kualitas dan arah codebase awal, kualitas kode berikutnya bisa tetap terjaga, atau justru terus memburuk.
Artinya, biaya refactoring pada tahap awal proyek dan biaya refactoring pada proyek yang sudah berjalan jauh bisa sangat berbeda.
Jika penanya adalah seorang developer, mungkin Anda pernah sekali mendengar ungkapan 'kapal induk di atas perahu layar',
Refactoring adalah topik yang mendalam: pada titik mana ia harus dilakukan, atau bagaimana biaya dapat berubah sangat besar tergantung pada filosofi dan desain yang diterapkan di awal proyek.
Daripada memasukkan hal ini sebagai variabel dan membuat kesimpulan menjadi tidak stabil,
saya melakukan pengujian yang setidaknya bisa menjelaskan dengan pasti bahwa 'kalau kualitas codebase bagus, penggunaan token akan berkurang'.
Pelaku vibe coding mencakup rentang yang luas, dari non-developer hingga developer berpengalaman. Bergantung pada tingkat pengetahuan yang mereka miliki, kualitas hasil keluaran bisa sangat beragam, terlepas sama sekali dari isi tulisan ini.
Seseorang mungkin secara alami, dengan asumsi menggunakan Cursor, memasukkan aturan dasar OOP dan aturan pemisahan kelas/metode ke dalam .cursorrules, sehingga bisa beroperasi dalam bentuk yang hampir tidak memerlukan refactoring.
Namun bagi orang lain, bisa saja terjadi produksi massal kode level rendah akibat tidak memahami poin-poin utama yang sangat mendasar.
Bahkan, tulisan dan pengalaman yang menganjurkan agar kualitas kode tetap baik melalui pengaturan aturan proyek pada dasarnya sudah banyak dibagikan sebelumnya.
Ini menunjukkan kemungkinan bahwa sebagian orang sudah memperoleh keuntungan dari sisi penggunaan token bahkan tanpa refactoring yang eksplisit.
Namun, kasus-kasus di atas tidak merangkum penurunan penggunaan token yang jelas per unit eksekusi melalui definisi aturan tersebut. Karena itu, tulisan ini menguji perbedaan penggunaan token berdasarkan kualitas codebase dan merangkum hasilnya.
Dengan kata lain, tergantung pada penggunanya, jumlah refactoring eksplisit itu sendiri kembali menjadi variabel dari 0 hingga n kali,
Dan tampaknya akan lebih tepat jika dipahami bahwa maksud esensial tulisan ini adalah menjelaskan, 'mengapa penting untuk memperhatikan codebase yang berkualitas baik?'
Saya kurang memahami dengan baik apa yang Anda maksud dalam komentar. Komentar saya adalah, jika ingin membandingkan dua metode secara adil, bukankah yang harus dibandingkan adalah total jumlah token yang dikonsumsi? Refactoring juga menghabiskan token, bukan?
Selain itu, hal yang Anda sampaikan dalam balasan tampaknya juga tidak tertulis di artikel dan sepertinya belum diuji lewat eksperimen. Maksud Anda sepertinya bukan membandingkan token per satu kali kueri, melainkan bahwa saat kueri dilakukan berkali-kali, overhead refactoring akan mengecil dan karena jumlah token yang diharapkan per kueri berkurang, maka total jumlah token akhirnya akan lebih menguntungkan. Namun itu tampaknya hanya berlaku jika, dalam banyak kueri, penurunan biaya tersebut tetap terjaga seperti yang Anda bayangkan, dan menurut saya itu lebih seperti asumsi situasi yang sangat ideal. Tidak ada jaminan bahwa penurunan biaya akibat refactoring akan tetap bertahan terlepas dari jumlah kueri berikutnya, dan itu juga tidak bisa diasumsikan tanpa eksperimen. Jika Anda ingin menegaskan maksud tersebut, sepertinya Anda perlu menunjukkan lewat eksperimen adanya penurunan biaya untuk lebih dari satu kali kueri. Tetapi bukankah eksperimen yang dilakukan dan dibandingkan hanya satu kali?
Sebagai tambahan, ini hanya asumsi saya, tetapi jika untuk tujuan yang sama (hasil akhir ideal) kueri diulang tanpa batas, maka dalam situasi ideal, terlepas ada atau tidaknya refactoring, kodenya pada akhirnya tampaknya harus konvergen ke bentuk yang sama. (Hasil akhir ideal itu unik.)
Jika asumsi ini masuk akal, maka seiring kueri diulang, perbedaan ada atau tidaknya refactoring akan semakin kecil, sehingga keuntungan penurunan biaya token juga tampaknya akan makin berkurang. Jadi jika dilihat secara makro, bila keuntungan dari penurunan biaya ini tidak cukup bertahan lama, bukankah mungkin perbedaan total jumlah token yang digunakan dalam kueri pada akhirnya tidak signifikan?
Tiba-tiba terpikir kalau dengan Hangul mungkin ini bisa dilakukan... sepertinya juga bisa dibuat jadi puzzle...
Saya akan memakainya dengan baik hanya untuk keperluan screening
Untuk order transaksi, tampaknya ada kemungkinan order yang tidak diinginkan bisa diproses akibat prompt injection dan sejenisnya, jadi fitur tambahan seperti pembatasan instrumen yang boleh dipesan atau batas nominal tampaknya akan sangat penting.
Maaf;;
Ini mengingatkan saya pada Kiro IDE.
Terima kasih.
Ya, saya juga berpikir begitu. snif
Saya menikmati eksperimennya dengan senang hati.
Apakah Anda sempat ikut kursus bikin judul...
Sosial media terasa seperti perjudian atau narkoba karena sama-sama membuang waktu, tetapi yang lebih tepat adalah perasaan 'penyesalan' atau 'malu'.
Menarik juga. Masuk akal juga.
Terlepas dari isinya, sepertinya karena judulnya menyebut hanya satu baris prompt, maksud yang ingin dilihat jadi berbeda dengan isi tulisannya.
k9s - alat untuk mengelola klaster Kubernetes lewat UI terminal
Tautan penjelasan detail SDD di tengah tulisan itu bagus. Di bawah ini adalah ringkasan yang saya buat dengan AI.
Pengembangan Berbasis Spesifikasi (Specification-Driven Development, SDD)
The Power Inversion
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
Streamlining SDD with Commands
/specify: mengubah deskripsi fitur menjadi spesifikasi terstruktur, lalu mengotomatiskan penomoran, pembuatan branch, dan susunan direktori berbasis template/plan: analisis spesifikasi → peninjauan kepatuhan konstitusi → penerjemahan teknis → dokumentasi model data, kontrak API, dan skenario test → menghasilkan validasi quickstart/tasks: membacaplan.mddan desain terkait untuk menghasilkan daftar task yang dapat dieksekusi, serta memberikan penanda task yang bisa diparalelkan dan pengelompokan paralel yang amanThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]mendorong larangan berasumsi dan pertanyaan eksplisitimplementation-details/untuk menjaga keterbacaanThe Constitutional Foundation
memory/constitution.mduntuk menjaga seluruh implementasi tetap konsisten, sederhana, dan berkualitas tinggiThe Transformation
Kode sumber Big Brother bocor!
Dan, Anda juga menanyakan soal eksperimen terkait jumlah rangkaian prompt,
sebenarnya justru ini adalah elemen yang, dalam istilah kasarnya, bagus untuk dipakai penulis “mengakali” hasil.
Aktivitas development itu sendiri memiliki sangat banyak pilihan arah dalam prosesnya, dan jika prompt ditumpuk ke arah yang membuat penggunaan token semakin melebar, angka itu akan membengkak jauh lebih besar seperti bola salju.
Dalam penelitian, ada filosofi yang disebut
Cumulative Science.Setidaknya menurut standar saya, saya belum pernah sekalipun menemukan penelitian terkait penggunaan token untuk 1 kali perintah,
jadi alih-alih langsung melakukan penelitian N kali, saya memilih fokus pada pengujian dan kesimpulan untuk 1 kali yang benar-benar jelas,
dan penelitian N kali bisa dilanjutkan setelah eksperimen ini sebagai kelanjutan riset.
Kalau di bidang teknik sipil atau semacamnya, ini memang sudah digunakan bahkan di perkuliahan juga.
Selain itu, di tulisan lain, saya juga pernah membahas perbedaan perilaku AI berdasarkan perbedaan codebase.
(Ini juga pernah diperkenalkan di GeekNews ini: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Singkatnya, tulisan tersebut membahas pengujian dan hasil bahwa kualitas output berubah tergantung pada codebase yang diberikan sebagai input ke AI.
Bergantung pada kualitas dan arah codebase awal, kualitas kode berikutnya bisa tetap terjaga, atau justru terus memburuk.
Artinya, biaya refactoring pada tahap awal proyek dan biaya refactoring pada proyek yang sudah berjalan jauh bisa sangat berbeda.
Jika penanya adalah seorang developer, mungkin Anda pernah sekali mendengar ungkapan 'kapal induk di atas perahu layar',
Refactoring adalah topik yang mendalam: pada titik mana ia harus dilakukan, atau bagaimana biaya dapat berubah sangat besar tergantung pada filosofi dan desain yang diterapkan di awal proyek.
Daripada memasukkan hal ini sebagai variabel dan membuat kesimpulan menjadi tidak stabil,
saya melakukan pengujian yang setidaknya bisa menjelaskan dengan pasti bahwa 'kalau kualitas codebase bagus, penggunaan token akan berkurang'.
Izinkan saya menjelaskannya sekali lagi.
Pelaku vibe coding mencakup rentang yang luas, dari non-developer hingga developer berpengalaman. Bergantung pada tingkat pengetahuan yang mereka miliki, kualitas hasil keluaran bisa sangat beragam, terlepas sama sekali dari isi tulisan ini.
Seseorang mungkin secara alami, dengan asumsi menggunakan Cursor, memasukkan aturan dasar OOP dan aturan pemisahan kelas/metode ke dalam
.cursorrules, sehingga bisa beroperasi dalam bentuk yang hampir tidak memerlukan refactoring.Namun bagi orang lain, bisa saja terjadi produksi massal kode level rendah akibat tidak memahami poin-poin utama yang sangat mendasar.
Bahkan, tulisan dan pengalaman yang menganjurkan agar kualitas kode tetap baik melalui pengaturan aturan proyek pada dasarnya sudah banyak dibagikan sebelumnya.
Ini menunjukkan kemungkinan bahwa sebagian orang sudah memperoleh keuntungan dari sisi penggunaan token bahkan tanpa refactoring yang eksplisit.
Namun, kasus-kasus di atas tidak merangkum penurunan penggunaan token yang jelas per unit eksekusi melalui definisi aturan tersebut. Karena itu, tulisan ini menguji perbedaan penggunaan token berdasarkan kualitas codebase dan merangkum hasilnya.
Dengan kata lain, tergantung pada penggunanya, jumlah refactoring eksplisit itu sendiri kembali menjadi variabel dari 0 hingga n kali,
Dan tampaknya akan lebih tepat jika dipahami bahwa maksud esensial tulisan ini adalah menjelaskan, 'mengapa penting untuk memperhatikan codebase yang berkualitas baik?'
Saya kurang memahami dengan baik apa yang Anda maksud dalam komentar. Komentar saya adalah, jika ingin membandingkan dua metode secara adil, bukankah yang harus dibandingkan adalah total jumlah token yang dikonsumsi? Refactoring juga menghabiskan token, bukan?
Selain itu, hal yang Anda sampaikan dalam balasan tampaknya juga tidak tertulis di artikel dan sepertinya belum diuji lewat eksperimen. Maksud Anda sepertinya bukan membandingkan token per satu kali kueri, melainkan bahwa saat kueri dilakukan berkali-kali, overhead refactoring akan mengecil dan karena jumlah token yang diharapkan per kueri berkurang, maka total jumlah token akhirnya akan lebih menguntungkan. Namun itu tampaknya hanya berlaku jika, dalam banyak kueri, penurunan biaya tersebut tetap terjaga seperti yang Anda bayangkan, dan menurut saya itu lebih seperti asumsi situasi yang sangat ideal. Tidak ada jaminan bahwa penurunan biaya akibat refactoring akan tetap bertahan terlepas dari jumlah kueri berikutnya, dan itu juga tidak bisa diasumsikan tanpa eksperimen. Jika Anda ingin menegaskan maksud tersebut, sepertinya Anda perlu menunjukkan lewat eksperimen adanya penurunan biaya untuk lebih dari satu kali kueri. Tetapi bukankah eksperimen yang dilakukan dan dibandingkan hanya satu kali?
Sebagai tambahan, ini hanya asumsi saya, tetapi jika untuk tujuan yang sama (hasil akhir ideal) kueri diulang tanpa batas, maka dalam situasi ideal, terlepas ada atau tidaknya refactoring, kodenya pada akhirnya tampaknya harus konvergen ke bentuk yang sama. (Hasil akhir ideal itu unik.) Jika asumsi ini masuk akal, maka seiring kueri diulang, perbedaan ada atau tidaknya refactoring akan semakin kecil, sehingga keuntungan penurunan biaya token juga tampaknya akan makin berkurang. Jadi jika dilihat secara makro, bila keuntungan dari penurunan biaya ini tidak cukup bertahan lama, bukankah mungkin perbedaan total jumlah token yang digunakan dalam kueri pada akhirnya tidak signifikan?