- Terkait klaim dalam agentic coding bahwa "dokumen spesifikasi dapat menggantikan kode", artikel ini menunjukkan batasan mendasar bahwa ketika spesifikasi dibuat cukup presisi, pada akhirnya ia akan berkonvergensi ke bentuk yang setara dengan kode
- Melihat proyek Symphony dari OpenAI,
SPEC.md terkait pada praktiknya bukan spesifikasi, melainkan pseudocode dalam format Markdown
- Saat implementasi Haskell benar-benar dicoba berdasarkan spesifikasi Symphony, muncul banyak bug serta masalah keandalan seperti agent menunggu tanpa akhir
- Pekerjaan membuat spesifikasi pada dasarnya menuntut pemikiran yang lebih dalam daripada coding, tetapi dalam budaya industri saat ini yang mengoptimalkan kecepatan, AI justru mendorong produksi massal spesifikasi berkualitas rendah
- Prinsip "garbage in, garbage out" berlaku sama untuk coding agent, dan dengan dokumen yang kurang jelas serta kurang detail, mustahil menghasilkan kode yang dapat diandalkan
Dua kesalahpahaman tentang agentic coding
- Ada dua kesalahpahaman utama yang menjadi sandaran para pendukung agentic coding
- Kesalahpahaman 1: dokumen spesifikasi lebih sederhana daripada kode yang bersesuaian — sudut pandang ala outsourcing bahwa engineer bisa diubah menjadi manajer yang menulis dokumen spesifikasi lalu mendelegasikan pekerjaan ke tim agent
- Kesalahpahaman 2: pekerjaan spesifikasi pasti lebih penuh pertimbangan daripada pekerjaan coding — klaim bahwa melalui dokumen spesifikasi kualitas akan meningkat dan praktik engineering yang lebih baik akan terdorong
Kode yang berpura-pura menjadi spesifikasi: analisis kasus Symphony
- Proyek Symphony dari OpenAI diperkenalkan sebagai agent orchestrator yang dihasilkan dari dokumen spesifikasi (
SPEC.md), tetapi isi SPEC.md yang sebenarnya lebih dekat ke pseudocode dalam format Markdown daripada sebuah spesifikasi
- Jenis isi yang tercantum di
SPEC.md:
- Dump skema database dalam bentuk prosa — daftar field seperti
session_id, thread_id, codex_input_tokens, dan lain-lain
- Transformasi prosa dari kode — rumus seperti
available_slots = max(max_concurrent_agents - running_count, 0) untuk kontrol konkurensi, serta formula backoff retry (delay = min(10000 * 2^(attempt-1), agent.max_retry_backoff_ms))
- Bagian redundan seperti "Config Fields Summary (Cheat Sheet)" yang secara eksplisit ditambahkan untuk membantu model menghasilkan kode
- Bagian "Reference Algorithms" yang pada dasarnya adalah kode itu sendiri, seperti fungsi
start_service()
- Mengklaim bahwa dokumen spesifikasi adalah pengganti kode, sementara dokumen itu sendiri justru terbaca seperti kode, adalah hal yang menyesatkan
- Agar dokumen spesifikasi cukup presisi, ia pada akhirnya niscaya harus diubah ke bentuk kode atau ditulis dalam bahasa Inggris formal yang sangat terstruktur
Argumen "narrow interface" dari Dijkstra
- Mengutip tulisan Dijkstra, pemilihan interface bukan sekadar pembagian kerja sederhana; ada juga biaya kolaborasi dan komunikasi tambahan saat melintasi interface
- Diberikan contoh sejarah bahwa matematika Yunani stagnan karena tetap berada pada aktivitas linguistik dan visual, aljabar Islam mengalami kemunduran saat kembali ke gaya retoris, dan Eropa Barat berkembang setelah keluar dari "upaya sia-sia menuju presisi linguistik" dalam skolastisisme abad pertengahan, berkat sistem simbol formal dari Vieta, Descartes, Leibniz, Boole, dan lainnya
- Para agentic coder tidak bisa menghindari "narrow interface" (= kode) yang dituntut oleh kerja engineering; mereka hanya bisa mengubahnya ke bentuk lain yang tampak berbeda di permukaan tetapi tetap menuntut tingkat presisi yang sama
Ketidakstabilan: masalah keandalan pada pembuatan kode berbasis spesifikasi
- Ketika, sesuai rekomendasi README Symphony, Claude Code diminta membuat implementasi dalam Haskell, hasilnya tidak berjalan
- Muncul banyak bug, sehingga perlu diperbaiki lewat prompt tambahan (dapat dilihat di riwayat commit)
- Bahkan saat terlihat "berjalan" tanpa pesan error, agent
codex untuk tiket Linear sederhana ("membuat repositori git kosong") tetap menunggu tanpa akhir tanpa kemajuan apa pun
- Dengan meminjam ungkapan Dijkstra, dapat dilihat bahwa "upaya sia-sia menuju presisi linguistik" dalam Symphony tetap gagal menghasilkan implementasi yang andal
- Masalah ini tidak terbatas pada Symphony — bahkan spesifikasi seperti YAML, yang sangat detail, dipakai luas, dan bahkan memiliki test suite kesesuaian, tetap tidak sepenuhnya dipatuhi oleh sebagian besar implementasi YAML
- Spesifikasi Symphony sudah mencapai seperenam ukuran implementasi Elixir yang disertakan, dan jika terus diperluas akan berujung pada situasi seperti dongeng Borges "On Exactitude in Science" — peta yang dibuat sebesar kekaisaran itu sendiri hingga akhirnya tidak berguna
- Terhadap sanggahan bahwa "hasilnya akan lebih baik jika dihasilkan dalam bahasa yang lebih mainstream", penulis menilai bahwa jika agent kesulitan menghasilkan kode Haskell, itu menunjukkan kurangnya kemampuan generalisasi di luar data pelatihan
Slop: masalah kualitas pada spesifikasi buatan AI
- Pekerjaan spesifikasi pada dasarnya memang seharusnya lebih sulit daripada coding, karena tujuannya adalah mendorong kita melihat proyek secara reflektif dan kritis sebelum mulai menulis kode
- Namun dalam arus industri teknologi yang terus berupaya mengecilkan dan meremehkan kerja, jika kita berangkat dari asumsi bahwa "pekerjaan spesifikasi lebih mudah daripada coding", maka kegagalan sudah ditentukan sejak awal
- Tidak mungkin mengejar optimasi kecepatan pengiriman sambil sekaligus melakukan kerja sulit dan tidak nyaman yang dibutuhkan untuk menyusun spesifikasi
- Section 10.5 (
linear_graphql extension contract) dalam SPEC.md Symphony adalah contoh slop yang representatif — hasil agent berupa kalimat-kalimat yang terlihat seperti spesifikasi tetapi tidak memiliki konsistensi, tujuan, maupun pemahaman atas gambaran besar
- Aturan per item seperti
query harus berupa string yang tidak kosong, harus memuat tepat satu operasi GraphQL, dan sebagainya memang didaftarkan, tetapi konteks menyeluruhnya tidak ada
- Dokumen spesifikasi seperti ini, bahkan jika ditulis manusia pun, tak terelakkan akan menjadi slop — karena yang dioptimalkan adalah waktu pengiriman, bukan konsistensi atau kejelasan
- Fakta bahwa snippet kode diberi anotasi sebagai
text tanpa syntax highlighting juga menjadi tanda dokumen buatan AI — diduga karena model mengikuti permintaan secara harfiah, bukan memahami maksudnya
Kesimpulan
- Spesifikasi pada dasarnya tidak dirancang sebagai alat penghemat waktu
- Jika tujuannya adalah mengoptimalkan waktu pengiriman, maka menulis kode secara langsung lebih menguntungkan daripada melewati dokumen spesifikasi perantara
- Prinsip "garbage in, garbage out" berlaku apa adanya — jika yang dimasukkan adalah dokumen yang kurang jelas dan kurang detail, tidak ada dunia di mana coding agent bisa mengisi kekurangan itu secara andal
- Coding agent bukan pembaca pikiran, dan bahkan seandainya iya, jika pemikirannya sendiri kacau maka tetap tidak banyak yang bisa dilakukan
6 komentar
Sepertinya sama persis seperti saat pengembangan yang dipimpin model.
Bukankah pengembangan berbasis spesifikasi, SDD, memang sudah ada sejak dulu?
Sepertinya solusi berbasis Python atau JavaScript memang bisa diimplementasikan dengan memuaskan hanya dari dokumen spesifikasi yang rinci. Saya sendiri ada di bidang game/medis berbasis C/C++, dan belakangan ini makin merasa bahwa bukan cuma delegasi penuh ke AI agent yang masih jauh, bahkan mengotomatisasi hanya dengan dokumen spesifikasi rinci saja pun terasa terlalu berisiko.
Komentar Hacker News
Saya tidak setuju dengan pernyataan bahwa agen coding tidak bisa mengisi detail hanya karena dokumentasinya kurang jelas
LLM pada dasarnya adalah mesin interpolasi/ekstrapolasi bahasa, jadi sangat mampu mengisi detail yang kurang
Ada banyak kasus di mana kode yang berfungsi bisa dihasilkan hanya dari penjelasan yang singkat dan ringkas
Namun, pelengkapan detail seperti ini tidak selalu akurat, dan untuk memastikan keandalan, bagian-bagian penting harus dibatasi secara eksplisit
Saat ini kita punya budaya menulis kode, tetapi hampir tidak ada budaya menulis spesifikasi superpresisi kecuali di tempat seperti NASA
Semakin pendek dan umum kodenya, semakin baik hasilnya, tetapi pada penjelasan yang kompleks ia mudah runtuh
Pada akhirnya, mengakui bahwa “pelengkapan detail bisa salah” berarti mengakui bahwa generasi yang andal itu sulit
Misalnya ada bahasa sintesis program seperti Synquid
Ini menunjukkan batasan spesifikasi yang akurat secara matematis dalam pembuatan program
Masalah yang disebut specification gap, yakni membuktikan apakah program benar-benar mengimplementasikan spesifikasi dengan setia, adalah tantangan intinya
Bahasa alami terlalu ambigu sehingga tidak cocok untuk mendefinisikan program
Fakta bahwa LLM mengisi detail yang tampak masuk akal tidak berarti kesenjangan ini teratasi
Bahasa spesifikasi matematis memang presisi, tetapi kurva belajarnya tinggi, dan jauh lebih sulit serta padat kerja dibanding sekadar menulis prompt dalam Markdown
Model bisa mengingat minat saya, atau mengisi celah dengan pengetahuannya sendiri untuk menghasilkan aplikasi, game, atau whitepaper yang selesai
Kadang hasilnya “persis seperti yang saya inginkan”, kadang “tepat seperti nuansa yang saya maksud”
Dalam menangani makna, konteks, dan nuansa, ada bagian yang bahkan melampaui manusia
AI makin lama makin cerdas dan kompeten
Artinya, itu lebih dekat ke menarik dari data pelatihan daripada benar-benar menciptakan detail yang sepenuhnya baru
Saya setuju dengan kalimat “spesifikasi yang cukup rinci adalah kode”
Ini sejalan dengan argumen Brooks dalam No Silver Bullet
Namun kebanyakan orang tidak menginginkan detail sebanyak itu
Saat mereka berkata “buatkan aplikasi to-do untuk saya” kepada AI, sebenarnya maksudnya adalah “buatkan aplikasi yang lebih baik daripada yang saya bayangkan”
Tetapi pendekatan seperti ini tidak bisa diperluas dengan baik ke jenis perangkat lunak lain
Pada akhirnya, pembeda itu harus diekspresikan sebagai spesifikasi
Tetapi di area seperti database, filesystem, komputasi paralel, di mana ketepatan dan performa itu penting, implementasi jauh lebih sulit daripada spesifikasi
Di area seperti ini, membuat AI menghasilkan kode yang lolos verifikasi formal adalah tantangan besar
Untuk menghasilkan uang atau bersaing, dibutuhkan requirement yang konkret
Jika melihat vibe coding dari sudut pandang teori informasi, itu mengasumsikan adanya decoder yang bisa merekonstruksi ruang program yang berguna dari ruang prompt yang kecil
Rasio kompresi di sini adalah keuntungan dari vibe coding
Prompt seperti “aplikasi komunikasi tim berbasis kanal IRC” tidak bisa didekode jika orang tidak mengenal Slack
Karena itu, penting untuk mengenali apa yang hilang
Untuk melakukan AI coding secara efektif, prompt harus dipecah menjadi unit-unit kecil, dan dokumen yang sudah ada atau kode yang pernah dicoba perlu disertakan
Menurut Algorithmic Information Theory, jumlah informasi sebuah string sama dengan panjang representasi mandiri yang paling terkompresi
Hanya saja, syarat “mandiri” itu berlaku hanya ketika bobot model berperan sebagai codebook
Manusia mengasumsikan konteks bersama yang jauh lebih besar daripada LLM, sehingga cenderung melebih-lebihkan kemampuan decoder
Tetapi pada sistem dengan batasan yang kuat dan titik tekan yang jelas, rasio kompresi vibe coding tampaknya bisa meningkat secara eksplosif
Bahasa alami memberi antarmuka baru bagi orang-orang yang aksesnya ke bahasa pemrograman lebih rendah
LLM bukan berpikir menggantikan mereka, tetapi membuka jalur baru untuk mengubah ide menjadi sistem yang bekerja
Sebentar lagi orang-orang tampaknya akan membuat dialek bahasa Inggris teknis seperti LLMSpeak demi performa model dan efisiensi token
Caranya dengan mengurangi ambiguitas, menghemat token, dan memadatkan konsep rumit ke dalam satu kata
Secara tata bahasa, mungkin juga akan muncul aturan seperti Oxford comma untuk meningkatkan kejelasan
Kalau spesifikasinya akan dibuat sedetail itu, tidak ada alasan khusus untuk memakai prompt
Pada akhirnya tetap harus didefinisikan ulang dalam bahasa manusia, jadi penghematan tokennya terbatas
Lihat wiki Lojban, video penutur Lojban
Upaya membuat dialek buatan kemungkinan besar gagal seperti Esperanto
Bahasa seperti ini justru bisa berguna saat dipakai antar-LLM
Bahasa pemrograman pada dasarnya sudah menjalankan peran itu
Spesifikasi (spec) itu seperti selubung (envelope) yang mencakup semua program yang memenuhi kondisi tersebut
Membuat selubung ini lebih sulit daripada menulis satu program tertentu
Seperti LLM yang menghasilkan kode berbeda setiap kali, spesifikasi mengizinkan implementasi yang baik maupun yang buruk
Dalam praktiknya, begitu satu implementasi diadopsi, itulah yang menjadi spesifikasi de facto untuk versi berikutnya
Dalam lingkungan brownfield yang sudah punya kode lama, spesifikasi tidak bersih sehingga sulit bagi LLM untuk merespons dengan baik
Ada ledakan kombinatorial karena harus mempertimbangkan bagaimana satu baris spesifikasi berinteraksi dengan baris lain
Tetapi dari sudut pandang compiler, kode juga hanyalah spesifikasi
Jadi pada akhirnya, “kode lebih mudah daripada spesifikasi” adalah pernyataan yang relatif
Spesifikasi seperti “menyimpan kredensial pengguna” mencakup semuanya, dari bcrypt sampai cookie plaintext
Manusia punya naluri bahwa “itu tidak boleh dilakukan”, tetapi agen tidak akan tahu jika itu tidak dinyatakan secara eksplisit
Karena itu, untuk memastikan keamanan, kita juga harus menspesifikasikan hal-hal yang tidak boleh dilakukan
Jika performa atau keamanan penting, properti itu harus disebutkan
Misalnya kalimat seperti “program ini harus O(n)” jauh lebih sederhana daripada implementasinya
Tampaknya tiap orang memakai arti spec secara berbeda
Bagi saya, spec berarti mendefinisikan “apa (what) yang harus dilakukan”, plan berarti “bagaimana (how)”, dan build packet berarti “langkah-langkah rinci”
Dalam kebanyakan kasus, yang penting adalah “apa”-nya
Menulis sebagai spesifikasi bahwa data dipertahankan dari A ke B, melalui C, hingga ke D dan direpresentasikan dalam bentuk F di E jauh lebih mudah daripada mengimplementasikannya dalam kode Rust
Saat melakukan agentic engineering, sering kali dokumen spesifikasi menjadi lebih panjang daripada kode
Bahasa alami tidak sempurna, tetapi kode itu presisi
Tujuan spesifikasi adalah menjaga fitur tetap utuh meskipun pengembangan diulang berkali-kali
Dibanding test atau komentar, dokumen desain gaya waterfall ternyata lebih efektif
Dengan cara ini, saya juga bisa dengan mulus merefaktor proyek vibe coding yang sepenuhnya jadi atau mengganti bahasanya
Sekarang rasanya seperti kembali ke alur pengembangan tahun 70-an sampai 80-an
Kalimat seperti “implementasikan antarmuka TCP” jauh lebih singkat daripada kode nyatanya
Pada akhirnya, jika bisa dipetakan ke skema yang jelas, bahasa alami pun bisa cukup terkompresi
Arah Spec → LLM itu tidak efisien dan boros
Justru LLM → Spec lebih realistis
Jika spesifikasi ada dalam bentuk yang bisa dikompilasi, LLM bisa menerima umpan balik itu untuk menghasilkan kode yang lebih baik
Upaya membuat “validated English” justru menambah kompleksitas
Pada akhirnya, yang penting adalah kode yang benar-benar berjalan
Kode memuat jauh lebih banyak hal daripada spesifikasi
Di kebanyakan proyek, 90%-nya adalah kode framework atau infrastruktur, dan hanya 10% yang merupakan logika bisnis
Karena spesifikasi tidak membahas detail bahasa atau framework, ia jauh lebih ringkas
Dengan begitu akan tercipta kode yang hampir setara dengan spesifikasi
Pakar domain pun bisa membacanya dan pengujiannya juga lebih mudah
Tetapi kode nyatanya bisa berubah cukup banyak
Benturan antara cara pandang terhadap spesifikasi sebagai alat manajemen dan sebagai alat rekayasa menimbulkan disonansi kognitif
Manajer melihat spesifikasi sebagai tiket delegasi, tetapi developer menggunakannya sebagai alat berpikir untuk memurnikan pemikiran
Sebagian developer memulai dengan pola pikir manajer demi kenyamanan, tetapi segera menyadarinya
Hype atau pertemuan investor mungkin bisa menopang sebentar, tetapi pada akhirnya pengguna menginginkan produk nyata
Berikutnya mereka mungkin akan menemukan kembali waterfall dan agile juga.
Sebagai pengembang embedded C, saya membuat spesifikasi sehingga hampir seluruh alur untuk Feature/Subfeature bisa diperiksa lewat chart.
Setelah spesifikasi ditinjau panjang lebar dan akhirnya dikunci,
saya lalu membuat dan menggunakan kode yang sepenuhnya berkorespondensi 1 banding 1 dengan spesifikasi. Karena jika ditinjau lewat spesifikasi, keterbacaannya jauh lebih baik dibandingkan review kode.