OpenSpec: Berhenti 'Vibe Coding', Mulai Kasih AI Peta Jalan yang Jelas
Vibe Coding itu seperti menyuruh tukang bangun rumah tanpa denah — hasilnya? Kacau di bulan ketiga. OpenSpec hadir sebagai 'denah arsitektur' untuk AI coding, menggeser paradigma dari ngobrol acak ke Spec-Driven Development yang terstruktur.
- OpenSpec: "Denah Arsitektur" untuk AI Coding
- Masalah: Kenapa "Vibe Coding" Itu Seperti Bangun Rumah Tanpa Denah?
- Solusi: Spec-Driven Development — Kasih AI Denah Dulu!
- Apa itu OpenSpec?
- Fondasi Pemikiran: Dari Mana Ide Ini?
- Arsitektur: Model Dua Folder
- Alur Kerja: Tiga Perintah Simpel
/opsx:propose— Rancang Dulu/opsx:apply— Baru Bangun/opsx:archive— Arsipkan & Bersihkan- "Konstitusi Proyek" — Buku Aturan yang AI Tidak Boleh Langgar
- Efisiensi: Kenapa OpenSpec Hemat Token?
- Aturan Menulis Spec: Tegas dan Tidak Ambigu
- Bahasa Wajib dan Haram
- Format Skenario: GIVEN / WHEN / THEN
- Empat Tipe Perubahan (Delta Operations)
- Perbandingan: OpenSpec vs Kompetitor
- Peta Perbandingan
- Kritik dan Risiko: Apakah Ini Waterfall 2.0?
- Kesimpulan: Kapan Harus Pakai OpenSpec?
- Intinya
- Referensi
OpenSpec: "Denah Arsitektur" untuk AI Coding
"Orang bijak membangun rumah di atas batu, bukan di atas pasir." — Pepatah universal yang juga berlaku untuk software engineering
TL;DR
OpenSpec adalah framework open-source dari Fission AI yang memaksa AI untuk membaca denah dulu sebelum mulai bangun. Alih-alih ngobrol bolak-balik tanpa rencana (vibe coding), OpenSpec mengubah cara kerja AI jadi terstruktur, terprediksi, dan aman untuk proyek skala besar.
Masalah: Kenapa "Vibe Coding" Itu Seperti Bangun Rumah Tanpa Denah?
Bayangkan Anda menyewa kontraktor untuk membangun rumah. Tapi alih-alih memberinya denah arsitektur, Anda hanya bilang:
"Bikinin kamar di situ ya. Oh iya, tambahin dapur juga. Eh, pintunya geser aja deh."
Awalnya sih oke. Kamar jadi, dapur jadi. Tapi di bulan ketiga:
- Ternyata pipa air dapur nabrak fondasi kamar 💥
- Kontraktor lupa Anda pernah minta pintu geser, jadi dipasang pintu biasa
- Mau renovasi? Kontraktor baru nggak tahu kenapa temboknya dibangun miring — kontraktor lama sudah pergi
Ini persis yang terjadi dengan vibe coding. Anda ngobrol dengan AI, minta kode ini-itu, semuanya lancar... sampai proyeknya membesar. Lalu:
🧠 AI Lupa
Jendela konteks percakapan terbatas. AI tidak ingat keputusan yang dibuat 3 hari lalu.
👻 Niat Hilang
Mengapa arsitektur dirancang begitu? Hilang bersama ditutupnya sesi chat.
💸 Utang Teknis Baru
Kode tumbuh melampaui kapasitas kognitif manusia DAN jendela konteks AI sekaligus.
🧱 Tembok Bulan Ketiga
Tambah fitur baru justru merusak fitur lama karena tidak ada pemetaan sistem.
Tembok Kompleksitas
Banyak proyek yang dibangun murni dengan vibe coding dilaporkan menabrak "tembok kompleksitas" pada bulan ketiga. Tambah fitur baru malah hancurkan yang sudah jalan — karena tidak ada yang merekam kenapa kode ditulis begitu.
Solusi: Spec-Driven Development — Kasih AI Denah Dulu!
Spec-Driven Development (SDD) adalah kebalikan dari vibe coding. Filosofinya sederhana:
Jangan suruh AI nulis kode sebelum ada spesifikasi yang jelas.
Kalau vibe coding itu "ngobrol → kode → berharap bener", maka SDD itu "tulis niat → validasi → baru kode".
Dan di garis depan gerakan SDD ini, berdiri platform bernama OpenSpec.
Apa itu OpenSpec?
OpenSpec adalah framework open-source buatan Fission AI yang berfungsi sebagai lapisan perencanaan universal antara niat manusia dan eksekusi AI.
Analoginya: kalau AI coding agent itu kontraktor, maka OpenSpec adalah meja arsitek di mana denah digambar, divalidasi, dan disimpan — sebelum palu dan paku disentuh.
Prop
Type
Tidak Ada Vendor Lock-in
OpenSpec tidak butuh API key khusus atau protokol tertutup. Seluruh spesifikasi hidup di dalam repositori Git Anda, berdampingan dengan kode. Pindah dari Claude ke Gemini? Specnya tetap sama.
Fondasi Pemikiran: Dari Mana Ide Ini?
Arsitektur: Model Dua Folder
Inovasi terpenting OpenSpec adalah pemisahan fisik antara "kebenaran saat ini" dan "rencana perubahan". Bayangkan seperti ini:
- 📚
specs/= Buku catatan resmi sekolah — berisi aturan yang sudah berlaku - 📝
changes/= Kertas coret-coretan — tempat ide baru diuji sebelum masuk buku resmi
Analogi: Seperti UUD 1945 — dokumen resmi yang berlaku saat ini.
- 📖 Mewakili realitas sistem saat ini yang sudah tervalidasi
- 🗂️ Dikelompokkan berdasarkan domain (auth-login/, checkout-cart/)
- 🔒 Bersifat read-only bagi AI — tidak boleh diubah langsung
- 🏛️ Stabil sampai ada proses pengarsipan resmi
Analogi: Seperti RUU (Rancangan Undang-Undang) — proposal yang belum disahkan.
- 🧪 Sandbox untuk fitur hipotetis masa depan
- 📋 Dikelompokkan berdasarkan tugas (add-dark-mode/, fix-payment-bug/)
- ✍️ AI boleh menulis di sini — tapi tetap di-review manusia
- 📊 Merekam delta spesifikasi — apa yang berubah dan kenapa
Kenapa Pemisahan Ini Penting?
Bayangkan AI berhalusinasi dan menulis spec yang salah. Dengan pemisahan ini,
kerusakan tertahan di folder changes/ — tidak merembet ke sumber
kebenaran utama. Seperti sistem airlock di kapal selam: bocor di satu
kompartemen, kapal tetap mengambang.
Alur Kerja: Tiga Perintah Simpel
Seluruh siklus pengembangan OpenSpec berjalan dengan tiga perintah saja. Seperti siklus Rancang → Bangun → Arsipkan:
/opsx:propose — Rancang Dulu
Anda mendeskripsikan apa yang diinginkan dalam bahasa sehari-hari. AI lalu:
- Menelusuri spesifikasi yang ada untuk mencari relevansi
- Menganalisis kode terkait
- Menghasilkan empat artefak di folder
changes/:
Prop
Type
Analogi: Seperti arsitek yang menggambar denah, menghitung material, dan membuat jadwal kerja — sebelum kontraktor mulai ngebor.
/opsx:apply — Baru Bangun
Setelah manusia menyetujui proposal, AI mulai implementasi:
- Mengambil tugas dari
tasks.md - Mengerjakan satu per satu secara iteratif
- Memperbarui checklist secara real-time
- Tidak boleh membuat keputusan yang bertentangan dengan
design.md
Analogi: Kontraktor mulai ngebor — tapi harus ikut denah. Mau pindahin pipa? Harus balik ke arsitek dulu.
/opsx:archive — Arsipkan & Bersihkan
Setelah implementasi dan testing selesai:
- Semua artefak dipindahkan ke
archive/dengan timestamp - Delta spec yang sudah terealisasi masuk ke
specs/(sumber kebenaran) - Folder kerja dibersihkan, siap untuk siklus berikutnya
Analogi: Setelah rumah jadi, denah arsitektur diupdate dan disimpan di brankas. Kertas coret-coretan dibuang. Bersih.
"Konstitusi Proyek" — Buku Aturan yang AI Tidak Boleh Langgar
Saat pertama kali menjalankan openspec init, platform memindai seluruh proyek Anda dan menghasilkan file project.md — semacam "UUD" untuk proyek Anda:
🎯 Tujuan Bisnis
Apa tujuan proyek ini? AI tidak boleh membuat keputusan yang menyimpang dari tujuan.
🔧 Tech Stack
TypeScript? Go? React? AI tahu batasan teknologinya dan tidak boleh tiba-tiba pakai framework lain.
📏 Konvensi Kode
Naming convention, folder structure, style guide — AI harus ikuti standar yang sudah ada.
🧪 Strategi Testing
Unit test wajib? E2E test untuk fitur kritis? AI tahu apa yang harus ditest.
20+ Agen AI Didukung
OpenSpec menolak vendor lock-in. Saat inisialisasi, platform otomatis
mendeteksi folder agen (.claude/, .cursor/, dll.) dan menyuntikkan
rules yang relevan. Anda bebas pakai Claude, Gemini, Codex, atau apa pun.
Efisiensi: Kenapa OpenSpec Hemat Token?
Ini bagian teknisnya — tapi analoginya simpel.
Vibe Coding itu seperti menyuruh kontraktor membaca ulang seluruh buku manual bangunan setiap kali Anda minta pasang satu lampu. Mahal, lambat, dan kontraktor sering lupa detail di halaman 847.
OpenSpec memberikan kontraktor cuma halaman yang relevan — denah listrik di lantai 2, standar watt yang dipakai, dan checklist keamanan. Itu saja.
AI menerima: SELURUH repositori (jutaan karakter)
Akibatnya:
❌ Biaya API membengkak
❌ Latensi tinggi
❌ AI "lupa" detail di tengah-tengah
❌ Halusinasi meningkat drastisAI menerima: project.md + folder changes/ yang relevan
Hasilnya:
✅ Biaya API jauh lebih murah
✅ Respons lebih cepat
✅ Rasio sinyal vs noise hampir 100%
✅ Halusinasi berkurang drastisSecara teknis, ini karena arsitektur transformer punya kompleksitas kuadratik — makin panjang input, makin mahal dan makin "pelupa" AI-nya. OpenSpec memotong input ke minimum yang diperlukan.
Aturan Menulis Spec: Tegas dan Tidak Ambigu
OpenSpec punya aturan ketat soal bagaimana spec ditulis. Tujuannya: supaya AI (dan manusia) tidak salah tafsir.
Bahasa Wajib dan Haram
OpenSpec mengadopsi standar IETF RFC 2119 — standar yang biasa dipakai untuk menulis spesifikasi internet global:
Prop
Type
Kenapa Ini Penting?
Kata "harus" dalam bahasa sehari-hari itu ambigu — bisa berarti wajib atau cuma saran. Dengan MUST vs SHOULD, AI langsung tahu: yang MUST itu hukum gravitasi (tidak bisa dilanggar), yang SHOULD itu pedoman (bisa dilenturkan dengan alasan bagus).
Format Skenario: GIVEN / WHEN / THEN
Setiap spesifikasi WAJIB punya minimal satu skenario pengujian. Formatnya dipinjam dari Behavior-Driven Development (BDD):
#### Scenario: Pengguna login dengan kredensial valid
- GIVEN pengguna terdaftar dengan email "user@example.com"
- WHEN pengguna memasukkan email dan password yang benar
- THEN sistem mengembalikan token akses valid
- AND pengguna diarahkan ke halaman dashboardAnalogi: Ini seperti soal ujian untuk kode Anda. Kalau tidak bisa jawab soal ini, berarti kodenya belum benar. OpenSpec bisa menjalankan openspec validate --strict untuk memastikan semua soal ada dan formatnya benar.
Empat Tipe Perubahan (Delta Operations)
Ketika mengusulkan perubahan, OpenSpec memaksa Anda untuk mengkategorikannya:
Fungsionalitas baru yang berdiri sendiri.
Seperti menambah ruangan baru di rumah — tidak mengganggu ruangan lain.
## ADDED Requirements
### Dark Mode Support
Sistem MUST menyediakan opsi dark mode...Mengubah perilaku yang sudah ada. Wajib tulis ulang spec secara lengkap (bukan cuma bagian yang berubah).
Seperti merenovasi dapur — Anda tulis ulang denahnya dari awal, bukan cuma coret-coret denah lama.
## MODIFIED Requirements
### Login Flow (UPDATED)
Sistem MUST mendukung OAuth2 selain email/password...Menghapus fitur. Wajib isi dua hal: alasan dan jalur migrasi.
Seperti merobohkan tembok — Anda perlu jelaskan kenapa dan bagaimana penghuni pindah ke ruangan lain.
## REMOVED Requirements
### SMS Verification
- Reason: Biaya SMS terlalu tinggi, diganti WhatsApp OTP
- Migration: Semua pengguna akan dimigrasikan ke WhatsApp OTPGanti nama tanpa mengubah fungsionalitas. Untuk menjaga jejak audit.
Seperti mengganti nama jalan — alamatnya berubah, tapi rumahnya tetap.
## RENAMED Requirements
- FROM: User Authentication
- TO: Identity VerificationPerbandingan: OpenSpec vs Kompetitor
Bagaimana posisi OpenSpec di antara platform SDD lainnya?
Peta Perbandingan
| Parameter | OpenSpec | GitHub Spec Kit | Amazon Kiro | BMAD |
|---|---|---|---|---|
| Fokus | 🏚️ Brownfield (kode lama) | 🏗️ Greenfield (proyek baru) | 🏢 Korporat (AWS) | 🤖 Multi-agen |
| Alur Kerja | 3 perintah simpel | 4 fase kaku | IDE terintegrasi | Delegasi otonom |
| Konteks | Delta (hemat) | Dokumen penuh (berat) | Steering files | Sharding |
| Tech Stack | TypeScript/npm | Python/UV | Terminal/VS Code | Framework-agnostik |
| Vendor Lock-in | ❌ Tidak ada | ⚠️ Bias GitHub | 🔒 AWS only | ❌ Tidak ada |
Kritik dan Risiko: Apakah Ini Waterfall 2.0?
Tidak ada pendekatan yang sempurna. Berikut kritik paling tajam terhadap SDD dan OpenSpec:
🌊 Bayangan Waterfall
Kritikus bilang SDD itu 'Waterfall pakai baju baru.' Obsesi dokumentasi di awal berpotensi membunuh kelincahan Agile.
📄 Ilusi Kontrol
Tumpukan dokumen spec TIDAK otomatis berarti kode berkualitas. Bisa jadi false sense of security.
🔄 Context Drift
Kalau spec tidak diupdate saat ada improvisasi mid-flight, spec yang basi lebih BERBAHAYA daripada tidak ada spec.
⚖️ Dilema Keseimbangan
Terlalu sedikit struktur = kacau (vibe coding). Terlalu banyak struktur = macet (waterfall). Sweet spot-nya di mana?
Pelajaran dari Sejarah
Model-Driven Development (MDD) di tahun 2000-an punya visi mirip: "model dulu, kode otomatis." Hasilnya? Gagal karena terlalu berat, tidak fleksibel, dan tidak bisa beradaptasi dengan perubahan. OpenSpec sadar akan risiko ini — makanya mereka memilih pendekatan delta (ringan) bukan pendekatan full-spec (berat).
Kesimpulan: Kapan Harus Pakai OpenSpec?
- Proyek berskala besar dengan banyak developer dan AI agent
- Basis kode legacy (brownfield) yang kompleks dan rawan regresi
- Tim yang butuh audit trail dan accountability atas keputusan AI
- Proyek di mana konsistensi arsitektural lebih penting dari kecepatan
- Lingkungan korporat yang butuh review gate sebelum AI boleh commit
- Prototipe cepat atau proof-of-concept yang akan dibuang
- Side project kecil yang dikerjakan satu orang
- Skrip otomasi sederhana yang tidak perlu maintenance jangka panjang
- Saat Anda masih eksplorasi ide dan belum tahu mau bangun apa
Intinya
OpenSpec bukan pengganti kreativitas atau kelincahan. Ia adalah jaring pengaman — memastikan bahwa semakin AI menjadi "kontraktor" yang lebih canggih, kita sebagai "arsitek" tidak kehilangan kendali atas desain bangunannya.
Vibe coding itu seperti improvisasi jazz — indah untuk solo pendek. Spec-Driven Development itu seperti orkestra — butuh partitur agar 50 musisi bermain harmonis.
OpenSpec adalah partiturnya.