- Spec-Driven Development (SDD) adalah pendekatan dalam coding berbasis AI yang menulis spesifikasi (spec) terlebih dahulu sebelum menulis kode, sehingga spesifikasi berperan sebagai source of truth bagi developer dan AI
- SDD dibagi menjadi tiga tingkat implementasi dan berkembang bertahap dari spec-first (spesifikasi ditulis lebih dulu), spec-anchored (spesifikasi dipertahankan untuk pemeliharaan), hingga spec-as-source (spesifikasi digunakan sebagai file sumber utama dan developer tidak mengedit kode secara langsung)
- Kiro menyediakan workflow 3 tahap yang sederhana: requirement → design → task; spec-kit menggunakan workflow berbasis aturan yang kuat bernama constitution; sementara Tessl bereksperimen dengan pendekatan spec-as-source yang memetakan spesifikasi dan kode secara 1:1
- Ketiga alat sama-sama menuntut proses yang berlebihan untuk perbaikan bug kecil, review file Markdown yang lebih merepotkan dibanding code review, serta tetap memiliki keterbatasan karena AI tidak selalu mengikuti semua instruksi dengan benar meski context window besar
- SDD mengingatkan pada kasus kegagalan Model-Driven Development (MDD) di masa lalu, dan berisiko mewarisi kelemahan dari kedua sisi—nondeterminisme dan ketidakfleksibelan—sehingga kegunaannya di proyek nyata masih perlu dibuktikan
Definisi Spec-Driven Development (SDD)
- SDD adalah pendekatan "documentation first" yang menulis spesifikasi lebih dulu sebelum kode, dengan spesifikasi berfungsi sebagai single source of truth bagi developer maupun AI
- GitHub mendefinisikannya sebagai: "pemeliharaan software berarti evolusi spesifikasi, bahasa bersama dalam pengembangan berpindah ke level yang lebih tinggi, dan kode menjadi tahap akhir"
- Tessl menjelaskan SDD sebagai "pendekatan pengembangan di mana spesifikasi menjadi artefak utama, bukan kode; spesifikasi menjelaskan intent dalam bahasa yang terstruktur dan bisa diuji, lalu agent menghasilkan kode sesuai itu"
- SDD terbagi menjadi tiga tingkat implementasi
- Spec-first: menulis spesifikasi yang tersusun baik terlebih dahulu lalu menggunakannya dalam workflow pengembangan berbantuan AI
- Spec-anchored: spesifikasi tetap dipelihara setelah pekerjaan selesai dan terus digunakan untuk evolusi serta pemeliharaan fitur tersebut
- Spec-as-source: spesifikasi tetap menjadi file sumber utama seiring waktu; developer hanya mengedit spesifikasi dan tidak menyentuh kode secara langsung
- Semua pendekatan SDD bersifat spec-first, tetapi tidak semuanya mengarah ke spec-anchored atau spec-as-source, dan strategi menjaga spesifikasi seiring waktu sering kali samar atau dibiarkan terbuka sepenuhnya
Apa itu spesifikasi (spec)?
- Spesifikasi adalah artefak terstruktur dan berorientasi perilaku yang ditulis dalam bahasa alami untuk merepresentasikan fitur software dan menjadi panduan bagi AI coding agent
- Definisi yang paling konsisten adalah mengibaratkan spesifikasi sebagai dokumen kebutuhan produk (PRD)
- Spesifikasi harus dibedakan dari dokumen konteks umum untuk codebase
- Konteks umum mencakup file aturan, deskripsi tingkat tinggi tentang produk dan codebase, dan beberapa alat menyebutnya memory bank
- File memory bank relevan untuk semua sesi AI coding dalam codebase, sedangkan spesifikasi hanya relevan untuk tugas membuat atau mengubah fitur tertentu
- Tiap variasi SDD mendefinisikan pendekatannya sendiri terhadap struktur, tingkat detail, dan cara pengorganisasian spesifikasi di dalam proyek
Sulitnya mengevaluasi alat SDD
- Mengevaluasi alat dan pendekatan SDD secara mendekati penggunaan nyata sangat memakan waktu
- Perlu dicoba pada masalah dengan berbagai skala, pada proyek greenfield maupun brownfield, serta membutuhkan waktu untuk meninjau dan memperbaiki artefak perantara secara mendalam, bukan sekadar sepintas
- Dalam blog post spec-kit, GitHub menekankan bahwa "yang penting adalah peran Anda bukan sekadar memberi arah, tetapi memverifikasi, lalu merefleksikan dan menyempurnakan di setiap tahap"
- Dua dari tiga alat tampaknya membutuhkan lebih banyak pekerjaan untuk diadopsi ke codebase yang sudah ada, sehingga makin sulit menilai kegunaannya pada codebase brownfield
- Sebelum mendengar laporan penggunaan dari orang-orang yang memakainya di codebase nyata selama periode tertentu, masih ada banyak pertanyaan yang belum terjawab tentang cara kerjanya di praktik
Kiro
- Kiro adalah alat yang paling sederhana dan ringan di antara ketiganya, dan sebagian besar termasuk pendekatan spec-first
- Yang ditemukan hanya contoh penggunaan untuk task atau user story; tidak ada pembahasan tentang cara menggunakan dokumen requirement dalam mode spec-anchored lintas banyak task seiring waktu
- Workflow: requirement → design → task
- Setiap tahap workflow direpresentasikan oleh satu dokumen Markdown, dan Kiro memandu ketiga tahap ini di dalam distribusi berbasis VS Code
-
Komponen utama Kiro
- Requirements
- Disusun sebagai daftar requirement di mana setiap requirement merepresentasikan "user story" (format As a...)
- Kriteria penerimaan memakai format GIVEN... WHEN... THEN...
- Design
- Mencakup bagian seperti diagram arsitektur komponen, alur data, model data, penanganan error, strategi pengujian, pendekatan implementasi, strategi migrasi, dan lain-lain
- Belum jelas apakah strukturnya konsisten atau berubah tergantung task
- Tasks
- Daftar task yang dilacak berdasarkan nomor requirement
- Menyediakan elemen UI tambahan untuk menjalankan task satu per satu dan meninjau perubahan per task
-
Memory bank Kiro
- Kiro menyebut konsep memory bank sebagai steering
- Isinya fleksibel, dan workflow tampaknya tidak bergantung pada keberadaan file tertentu
- Struktur default yang dibuat Kiro saat diminta menghasilkan dokumen steering adalah
product.md, structure.md, tech.md
Spec-kit
- spec-kit adalah versi SDD dari GitHub, didistribusikan sebagai CLI yang dapat membuat setup workspace untuk berbagai coding assistant umum
- Setelah struktur disiapkan, interaksi dengan spec-kit dilakukan melalui slash command dari coding assistant
- Karena semua artefak ditempatkan langsung di workspace, ini menjadi alat yang paling bisa dikustomisasi di antara tiga yang dibahas
-
Workflow spec-kit
- Workflow: Constitution → 𝄆 Specify → Plan → Tasks 𝄇
- Konsep memory bank dalam spec-kit adalah prasyarat bagi pendekatan spec-driven
- Ini disebut constitution, berisi prinsip tingkat tinggi yang "immutable" dan harus selalu diterapkan ke semua perubahan
- File aturan yang sangat kuat dan banyak digunakan dalam workflow
-
Cara kerja spec-kit
- Pada tiap tahap workflow (
specify, plan, tasks), file dan set prompt diinstansiasi menggunakan script bash dan template
- Workflow banyak memanfaatkan checklist di dalam file untuk melacak klarifikasi pengguna yang diperlukan, pelanggaran constitution, tugas riset, dan sebagainya
- Berfungsi seperti "definition of done" untuk tiap tahap workflow (meski tidak 100% terjamin karena AI yang menafsirkannya)
- Satu spesifikasi terdiri dari beberapa file
- Misalnya:
data-model, plan, tasks, spec, research, api, component, dan total 8 file
-
Pendekatan spec-kit
- Awalnya GitHub tampak mengarah ke pendekatan spec-anchored
- "Alih-alih spesifikasi menjadi dokumen statis, spesifikasi dipikirkan ulang sebagai artefak hidup dan dapat dijalankan yang berevolusi bersama proyek, dan menjadi shared source of truth"
- Namun, karena spec-kit membuat branch untuk setiap spesifikasi yang dihasilkan, ini bisa ditafsirkan bahwa spesifikasi dipandang sebagai artefak hidup selama umur change request, bukan sepanjang umur fitur
- Diskusi komunitas juga menyoroti kebingungan ini, dan spec-kit tampaknya masih hanya berada di ranah spec-first, bukan spec-anchored dalam jangka panjang
Tessl Framework
- Tessl Framework masih dalam private beta, dan seperti spec-kit, didistribusikan sebagai CLI yang dapat membuat struktur workspace dan konfigurasi untuk berbagai coding assistant
- Perintah CLI juga dapat berfungsi sebagai server MCP
-
Karakteristik Tessl
- Satu-satunya dari tiga alat yang secara eksplisit menargetkan pendekatan spec-anchored, sambil juga mengeksplorasi SDD pada tingkat spec-as-source
- Spesifikasi Tessl dapat berperan sebagai artefak utama yang dipelihara dan diedit, sementara kode ditandai dengan komentar
// GENERATED FROM SPEC - DO NOT EDIT di bagian atas
- Saat ini ada pemetaan 1:1 antara spesifikasi dan file kode; satu spesifikasi diubah menjadi satu file dalam codebase
- Karena masih tahap beta dan sedang bereksperimen dengan berbagai versi, ini bisa berkembang ke tingkat di mana satu spesifikasi memetakan ke komponen kode yang terdiri dari banyak file
-
Struktur spesifikasi Tessl
- Tag seperti
@generate atau @test memberi tahu Tessl apa yang harus dihasilkan
- Bagian API menunjukkan gagasan untuk mendefinisikan antarmuka minimum yang diekspos ke bagian lain codebase di dalam spesifikasi, sekaligus memastikan bagian penting dari komponen yang dihasilkan tetap berada di bawah kendali penuh maintainer
- Menjalankan
tessl build akan menghasilkan file kode JavaScript terkait
-
Tingkat abstraksi Tessl
- Jika spesifikasi untuk spec-as-source ditempatkan pada tingkat abstraksi yang cukup rendah per file kode, jumlah langkah dan interpretasi yang harus dilakukan LLM berkurang, sehingga kemungkinan error juga menurun
- Bahkan pada tingkat abstraksi serendah ini, tetap teramati nondeterminisme saat menghasilkan kode beberapa kali dari spesifikasi yang sama
- Proses menulis spesifikasi berulang kali dan membuatnya makin spesifik agar generasi kode lebih dapat diulang mengingatkan pada jebakan dan tantangan menulis spesifikasi yang tidak ambigu dan lengkap
Pengamatan dan pertanyaan
-
Apakah satu workflow bisa menangani semua ukuran masalah?
- Kiro dan spec-kit masing-masing menawarkan satu workflow yang dogmatis, tetapi keduanya mungkin tidak cocok untuk sebagian besar masalah coding nyata
- Belum jelas apakah keduanya menyediakan variasi yang cukup untuk ukuran masalah yang berbeda
- Saat mencoba memperbaiki bug kecil dengan Kiro, workflow-nya terasa seperti memecahkan kacang dengan palu
- Dokumen requirement mengubah bug kecil itu menjadi 4 "user story" dengan total 16 kriteria penerimaan
- Saat memakai spec-kit juga tidak jelas untuk ukuran masalah seperti apa ia seharusnya dipakai
- Ketika mencoba fitur yang di masa lalu akan menjadi story 3–5 poin dalam tim, jumlah langkah yang diambil spec-kit dan banyaknya file Markdown yang dihasilkan terasa berlebihan dibanding ukuran masalah
- Dalam waktu yang sama, fitur itu mungkin bisa diimplementasikan dengan AI-assisted coding "biasa" dan terasa jauh lebih terkendali
- Alat SDD yang efektif perlu memberikan fleksibilitas setidaknya untuk beberapa workflow inti yang berbeda demi menangani perubahan dengan ukuran dan jenis yang beragam
-
Review Markdown alih-alih code review?
- spec-kit menghasilkan banyak file Markdown untuk direview
- Saling repetitif dan juga berulang terhadap kode yang sudah ada
- Sebagian bahkan sudah memuat kode, sehingga secara keseluruhan sangat verbose dan melelahkan untuk ditinjau
- Di Kiro, hanya ada 3 file dan model mental "requirements > design > tasks" lebih intuitif untuk dipahami, jadi sedikit lebih mudah
- Tetapi Kiro tetap terlalu verbose dibanding bug kecil yang diminta untuk diperbaiki
- Jujur saja, terasa lebih baik mereview kode daripada semua file Markdown ini
- Alat SDD yang efektif perlu menyediakan pengalaman review spesifikasi yang sangat baik
-
Rasa kontrol yang keliru?
- Terlepas dari semua file, template, prompt, workflow, dan checklist ini, sering terlihat bahwa agent pada akhirnya tidak mengikuti semua instruksi
- Context window yang lebih besar sering disebut sebagai salah satu pendorong SDD, tetapi jendela yang lebih besar tidak berarti AI benar-benar memahami semua isinya dengan tepat
- Contoh
- spec-kit punya tahap riset saat perencanaan dan telah melakukan banyak riset terhadap kode yang ada, tetapi pada akhirnya agent mengabaikan fakta bahwa itu adalah deskripsi tentang kelas yang sudah ada dan malah menganggapnya sebagai spesifikasi baru, lalu menghasilkan ulang semuanya sehingga terjadi duplikasi
- Bukan hanya mengabaikan instruksi, kadang juga terlihat agent yang berlebihan menjalankan instruksi (misalnya salah satu pasal constitution)
- Berdasarkan pengalaman masa lalu, cara terbaik untuk mengendalikan apa yang dibangun adalah langkah-langkah kecil yang iteratif, sehingga ada keraguan besar apakah banyak desain spesifikasi di muka adalah ide yang baik
- Alat SDD yang efektif harus mengakomodasi pendekatan iteratif, tetapi paket kerja kecil tampak hampir bertentangan dengan gagasan SDD itu sendiri
-
Bagaimana memisahkan spesifikasi fungsional dan spesifikasi teknis secara efektif?
- Dalam SDD, ada gagasan umum untuk secara sengaja memisahkan spesifikasi fungsional dari implementasi teknis
- Aspirasi dasarnya adalah agar AI pada akhirnya dapat mengisi semua solusi dan detail, bahkan memungkinkan perpindahan ke tech stack lain dengan spesifikasi yang sama
- Dalam praktiknya, saat mencoba spec-kit, sering muncul kebingungan kapan harus tetap di level fungsional dan kapan harus menambahkan detail teknis
- Tutorial dan dokumentasinya pun tidak konsisten soal ini, dan ada beragam tafsir tentang apa arti "murni fungsional" dalam praktik
- Jika mengingat banyak user story yang gagal memisahkan requirement dan implementasi dengan baik, rekam jejak profesi ini dalam melakukan hal tersebut memang tidak terlalu bagus
-
Siapa pengguna sasarannya?
- Banyak demo dan tutorial alat spec-driven development mencakup hal-hal seperti definisi tujuan produk dan fitur, serta menggunakan istilah seperti "user story"
- Gagasannya mungkin adalah menggunakan AI sebagai pendorong cross-skilling agar developer lebih aktif terlibat dalam analisis requirement
- Atau developer berpasangan dengan product person saat menjalankan workflow ini?
- Tidak satu pun dari ini dijelaskan secara eksplisit, dan seolah-olah diasumsikan developer akan melakukan semua analisis tersebut
- Kalau begitu, SDD ditujukan untuk ukuran dan jenis masalah yang seperti apa?
- Mungkin tidak cocok untuk fitur besar yang masih sangat belum jelas, karena situasi seperti itu jelas memerlukan keahlian produk dan requirement yang lebih khusus, juga banyak langkah lain seperti riset serta pelibatan stakeholder
-
Spec-anchored dan spec-as-source: apakah kita belajar dari masa lalu?
- Banyak orang membandingkan SDD dengan TDD atau BDD, tetapi terutama untuk spec-as-source, ada paralel penting lain yang perlu diperhatikan, yaitu MDD (Model-Driven Development)
- Di awal karier, penulis banyak mengerjakan proyek yang menggunakan MDD, dan saat mencoba Tessl Framework hal itu terus teringat
- Model dalam MDD pada dasarnya adalah spesifikasi, tetapi diekspresikan bukan dalam bahasa alami melainkan UML kustom atau DSL tekstual
- Lalu dibangun code generator kustom untuk mengubah spesifikasi tersebut menjadi kode
-
Perbandingan MDD dan SDD
- Pada akhirnya, MDD tidak berhasil di business application, karena berada pada tingkat abstraksi yang canggung dan menciptakan terlalu banyak overhead serta pembatasan
- Namun, LLM menghilangkan sebagian overhead dan pembatasan MDD, sehingga muncul harapan baru bahwa kini kita bisa fokus menulis spesifikasi dan menghasilkan kode
- Dengan LLM, kita tidak lagi dibatasi oleh bahasa spesifikasi yang telah didefinisikan dan dapat di-parse sebelumnya, dan juga tidak perlu membangun code generator yang canggih
- Tentu saja, imbalannya adalah nondeterminisme LLM
- Struktur yang dapat di-parse juga sebelumnya memberi keuntungan berupa banyak dukungan alat bagi penulis spesifikasi untuk menulis spesifikasi yang valid, lengkap, dan konsisten—dan kini hal itu hilang
- spec-as-source, bahkan juga spec-anchoring, bisa saja berakhir mewarisi kelemahan MDD dan LLM sekaligus: ketidakfleksibelan dan nondeterminisme
- Kita perlu melihat upaya spec-from-code di masa lalu dan belajar darinya ketika mengeksplorasi pendekatan spec-driven saat ini
Kesimpulan
- Secara pribadi, saat menggunakan AI-assisted coding, sering kali memang bermanfaat meluangkan waktu untuk dengan cermat menulis bentuk spesifikasi yang akan diberikan kepada coding agent
- Karena itu, prinsip umum spec-first jelas punya nilai dalam banyak situasi
- Beragam pendekatan untuk menyusun spesifikasi memang sangat dibutuhkan, dan ini adalah salah satu pertanyaan yang paling sering diterima dari para praktisi saat ini
- "Bagaimana menyusun memory bank?", "Bagaimana menulis spesifikasi dan dokumen desain yang baik untuk AI?"
- Namun, istilah "spec-driven development" sendiri masih belum terdefinisi dengan baik, dan secara semantik sudah mulai menyebar ke mana-mana
- Belakangan bahkan terdengar penggunaan "spec" sebagai sinonim dari "prompt yang detail"
-
Penilaian terhadap alat
- Sebagian alat tampak terlalu berusaha menerjemahkan workflow yang sudah ada secara terlalu literal untuk AI agent, dan pada akhirnya bisa memperbesar tantangan lama seperti beban review dan halusinasi
- Terutama pada pendekatan yang lebih rumit dan menghasilkan banyak file, ini mengingatkan pada kata majemuk bahasa Jerman "Verschlimmbesserung" (mencoba memperbaiki sesuatu tetapi justru membuatnya lebih buruk)
- Ada pertanyaan apakah dalam upaya memperbaiki, kita malah membuat sesuatu menjadi lebih buruk
3 komentar
Ini tampaknya mirip dengan pembahasan sebelumnya seperti document driven development atau README driven development.
https://id.news.hada.io/topic?id=15502
Komentar Hacker News
Saya mengikuti tren terbaru SDD (spec-driven development), dan arus ini terasa masuk akal, tetapi juga memberi kesan seperti kembali ke era pra-agile yang dipenuhi dokumen spesifikasi fitur dan dokumen desain; memang belum sepenuhnya Big Design Up Front, tetapi arahnya tampak makin menuju ‘perangkat lunak yang berfungsi == dokumentasi yang sempurna’
Referensi Big Design Up Front, Referensi Agile Manifesto
Pada akhirnya, spesifikasi fitur dan dokumen desain itu seperti menulis kode dalam bahasa alami; dulu manusia harus menuliskannya ulang dalam bahasa pemrograman, tetapi sekarang kompiler otomatis seperti LLM (large language model) mulai mengambil alih pekerjaan itu, sehingga satu tahap bisa dilewati (meski tingkat keberhasilannya bervariasi)<br /> Sebaliknya, agile tidak peduli perangkat lunak dibuat dengan bahasa apa; esensinya adalah ‘menyingkirkan manajer’ dan membuat developer menangani juga pekerjaan manajerial, dan 12 prinsip membahas lebih rinci apa yang harus dilakukan developer saat tidak ada manajer
Behaviour Driven Design, seperti Test Driven Design, bisa menghasilkan ‘spesifikasi yang hidup’; mulai dari kriteria eksplorasi domain hingga apakah tes lolos, semuanya dapat ditinggalkan dalam bentuk dokumen yang bisa dibaca manusia, lalu dihubungkan langsung ke test harness untuk memverifikasi fungsi yang berlaku saat ini; dengan begitu, melalui laporan BDD, kita mendapatkan dokumen spesifikasi yang tervalidasi dengan jelas serta bisa dikolaborasikan dan diiterasi, sambil tetap memenuhi agile, JIT, dan YAGNI tanpa pekerjaan awal yang tidak perlu; tidak perlu kembali ke waterfall
Kita juga bisa mulai dari desain skala kecil: menulis spesifikasi satu atau dua halaman, menghasilkan kode dan tes dengan LLM, lalu menyempurnakannya secara iteratif; jika benar-benar percaya pada coding 100% oleh LLM, maka mengelola input spesifikasi (prompt berbahasa Inggris) secara sistematis adalah langkah yang logis, karena prompt tidak dibuang melainkan dirapikan agar bisa dipakai ulang nanti atau diberi batasan tambahan yang lebih jelas<br /> Namun, saya masih ragu menggunakan LLM untuk kode produksi yang penting, jadi saat ini saya hanya bereksperimen untuk sandbox/tes/demo, yaitu area yang kualitas kodenya tidak terlalu krusial
Spec driven development sendiri adalah ide yang bagus, tetapi implementasi saat ini hanya menyerahkan file markdown yang tidak terstruktur kepada agent dan hasilnya sering tidak keluar dengan baik, sehingga pada praktiknya sama sekali tidak reproducible; jika agent juga menulis spesifikasi, maka spesifikasinya seharusnya terstruktur agar bisa otomatis diubah menjadi stub code dan test code; markdown saja jangan dibuang, tetapi jika dihubungkan dengan code generator, reproducibility akan jauh lebih baik, dan dalam praktiknya ini bisa sangat memangkas waktu untuk pembuatan kode berulang
Saat mencoba SpecKit, saya merasa itu sangat menarik dan memuaskan, tetapi saya kesulitan menemukan contoh atau cara pakai untuk kompleksitas dunia nyata; kebanyakan tutorial berhenti di level sederhana seperti instalasi lalu ‘membuat aplikasi to-do list’; saya ingin ada yang membagikan contoh nyata tentang bagaimana meningkatkan atau merefaktor codebase legacy yang sudah ada secara bertahap, atau bagaimana mendekati proyek besar yang tidak sejak awal menerapkan spec driven development
Saya sendiri juga merasakan bahwa saat menggabungkan pendekatan BDD dan coding berbasis CLI, mencatat fitur langsung dalam kode nyata jauh lebih efektif daripada markdown yang panjang dan bertele-tele; jika butuh checklist agar AI bisa mengikuti, file seperti agents.md saja sudah cukup; cukup catat sekali pola coding dan non-functional requirements (NFR), lalu agent bisa mengikutinya dengan jelas
Untuk benar-benar memanfaatkannya, kita tetap harus membaca template atau source code-nya langsung agar paham apa yang sebenarnya berjalan; menurut saya, untuk proyek seperti ini justru itu proses yang wajar
Setelah perkenalan tentang pakar delivery berbasis AI dari Thoughtworks, lalu muncul pembahasan soal memory banks, saya langsung merasa relate; kami juga bekerja di lapangan yang sedang ‘AI banget’, dan ketika memory bank membesar, AI justru kehilangan arah dan hasilnya jadi berantakan; pada akhirnya, hanya orang yang benar-benar memahami produknya yang bisa memimpin AI agar benar-benar bisa dipakai di lapangan; saya sudah tak terhitung berapa kali mengalami AI menyesatkan saya, dan ketika manusia memberi arahan ulang, AI memang selalu minta maaf dan tampak mengerti, tetapi itu tidak benar-benar mengubah apa pun; secara realistis juga mustahil bagi AI untuk membaca dan memverifikasi semua dokumen yang mereka tulis sendiri, jadi rasanya lebih baik langsung bekerja sendiri saja
Saya penasaran apa yang dimaksud dengan memory bank, dan secara konkret apa yang ingin disampaikan tentang perannya
Pada titik ini, fitur memory justru berdampak buruk; jika dipakai tanpa strategi ‘search/retrieval’ yang tepat, hasil buruk hanya akan makin diperbesar; kebanyakan sistem memory dirancang untuk paradigma chat tunggal, sehingga di lingkungan yang beragam justru menimbulkan masalah; ‘ingatan’ yang sesungguhnya seharusnya berupa ‘metakognisi/default mode network’ yang terpisah dari agen utama, yang secara asinkron merancang struktur tugas dan konteks, lalu model meta ini memberi arah pada setiap prompt—dengan kata lain, yang tepat adalah ‘agent-based memory’
Saya juga tidak paham dengan gelar ‘thought leader’ yang dipasang di tempat seperti LinkedIn; belakangan ini saya benar-benar sulit memahami apa arti titel seperti itu
Saya ingin berbagi pengalaman bereksperimen selama dua minggu terakhir dengan SpecKit dan Claude Code pada dua proyek baru; karena saya mengembangkan keduanya sendirian, saya bisa bereksperimen tanpa beban; proyek pertama saya serahkan begitu saja ke SpecKit, dan butuh 10 hari untuk menyelesaikan semua task, tetapi sebagian besar tes pada hasil akhirnya gagal dan build-nya juga rusak; saya harus menghabiskan waktu yang sama lagi untuk memperbaiki masalahnya, dan setiap kali Claude memperbaiki satu hal, bagian lain justru rusak, sehingga tingkat kepercayaannya turun drastis<br /> Pada proyek kedua, saya ingin beriterasi dalam unit kecil, jadi setelah planning SpecKit saya menambahkan slash command untuk membuat backlog.md, lalu memakai plan-sprint untuk membuat file berisi target sprint dan detail pekerjaan, kemudian memprosesnya sekaligus dengan implement-sprint. Tetapi proses ini juga tidak mengikuti perintah implementasi, jadi walaupun saya berkali-kali memperbaiki alurnya, tetap saja tes tidak dibuat atau task ada yang terlewat<br /> Karena itu saya mengubah setup lagi, dengan menempatkan subagent yang hanya menangani task tertentu, dan menjadikan implement-sprint hanya sebagai orkestrator. Dengan cara ini, saya bisa meninjau status kode di setiap sprint sehingga jauh lebih dapat dipercaya. Kadang masih ada situasi di mana ia mengklaim sudah selesai padahal tes gagal, tetapi tetap lebih mudah daripada harus memeriksa semuanya sendiri<br /> Hipotesis saya saat ini adalah bahwa Claude lemah dalam TDD; ia selalu bermasalah pada tahap menulis tes terlebih dahulu. Berikutnya saya berencana mencoba beralih ke cara menulis tes setelah implementasi selesai. Memang tidak ideal, tetapi kalau ini bisa meningkatkan produktivitas, mungkin tetap lebih baik daripada menulis semuanya sendiri
Menarik bahwa banyak tool tampaknya cocok untuk strategi ‘spec first’, tetapi cara memelihara spesifikasinya masih samar; secara pribadi saya dan cofounder sedang all-in pada ‘spec as source’; kami menganggap menjadikan spesifikasi sebagai source sungguhan adalah penggunaan yang paling menarik, dan sedang menantangnya, tetapi membuatnya benar-benar mapan sangat sulit. Jika ada pengalaman atau feedback terkait, saya benar-benar ingin mendengarnya<br /> Kalau tertarik, saya juga ingin meminta orang mencoba specific.dev, yang menjadi objek eksperimen kami, lalu memberi tahu pendapatnya
Saat mencoba workflow spec-driven milik Kiro, ia memuntahkan daftar pekerjaan dalam jumlah besar (setiap pekerjaan punya 4 subtask atau lebih, total lebih dari 12 task); workflow-nya sendiri cukup oke, tetapi ia menghapus kode secara tak terduga dan tidak melakukan rollback; karena dibuat sebagai IDE, rasanya sumber daya malah habis untuk penanganan pengecualian UI; dibanding memecah semuanya secara rumit, jauh lebih mudah melakukan iterasi sederhana sambil memperbaiki; ini seperti “memakai palu besar untuk memecahkan kenari”
Saya suka pendekatan custom slash command yang membungkus input menjadi prompt yang terstruktur dengan baik, dan juga bagus bahwa potongan yang dipecah dalam agents.md dan semacamnya ikut disuntikkan sebagai konteks<br /> Tetapi saya kurang suka bagian yang mencoba mengurai semua simpul sekaligus, karena malah terasa seperti memecahkan kenari dengan palu—menambah kompleksitas; namun, menurut saya ini bisa jadi lebih ringan jika pengelolaan konteks bisa dipilih secara selektif lewat slash command tambahan saat diperlukan saja (/experiment, /stub, dll.), lalu di akhir ada perintah khusus penutup seperti "/wrap-up" yang mengikat semua simpul sekaligus, seperti dokter yang memeriksa keseluruhan setelah operasi selesai
Saat memakai SpecKit, saya selalu bertanya-tanya, “kapan semua spec ini akan disatukan menjadi satu ground truth yang nyata?” dan saya kecewa karena tampaknya tahap itu sama sekali tidak ada<br /> Sekarang masih ada tugas untuk mendefinisikan/mendesain seperti apa spesifikasi komunikasi (spec) antara manusia dan agent seharusnya; saya sedang memikirkan bagaimana mewujudkan konsep ‘spec anchored’ yang disebut Birgitta
Saya tidak tahu kenapa SDD tiba-tiba jadi arus utama, tetapi secara pribadi saya merasa praktis hanya dengan membuat file spesifikasi untuk ‘memahami hasil akhir lebih dulu’ dan melacak progres saat memecah proyek menjadi bagian-bagian kecil; saya tidak memakai tool atau framework khusus, hanya file markdown, dan saya tidak terlalu melihat nilai tambah dari sistem yang lebih kompleks dari itu
Saat pertama kali memakai spec-kit, ekspektasi saya benar-benar tinggi, tetapi pada praktiknya ia memaksakan tugas sampai ke tahap “membangun robot di dalam gua”, dan memperbesar pekerjaan secara berlebihan padahal sebenarnya saya cuma perlu mengencangkan sekrup; saya akhirnya lelah terus memperbaikinya lalu berhenti, dan menurut saya workflow yang terlalu kompleks seperti ini bahkan tidak terasa layak untuk dikompensasi
Sebenarnya sederhana dan praktis jika menganggap apa yang dipelajari di rekayasa perangkat lunak dilakukan dalam bentuk Markdown. Cukup menulis spesifikasi kebutuhan dengan baik.