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

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:

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".

graph LR
    subgraph VC["❌ Vibe Coding"]
      A["Ngobrol dgn AI"] --> B["AI nulis kode"]
      B --> C["Cek, salah"]
      C --> A
    end
    subgraph SDD["✅ Spec-Driven Dev"]
      D["Tulis spesifikasi"] --> E["Review & validasi"]
      E --> F["AI nulis kode sesuai spec"]
      F --> G["Arsipkan & update spec"]
    end
    style VC fill:#450a0a,color:#fca5a5
    style SDD fill:#052e16,color:#86efac

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.

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

• openspec

  • specs

    • auth-login

      • spec.md
    • checkout-cart

      • spec.md
  • changes

    • add-dark-mode

      • proposal.md
      • design.md
      • tasks.md
      • specs

        • spec.md
  • project.md
  • AGENTS.md

Alur Kerja: Tiga Perintah Simpel

Seluruh siklus pengembangan OpenSpec berjalan dengan tiga perintah saja. Seperti siklus Rancang → Bangun → Arsipkan:

graph LR
    A["🎨 Propose"] -->|"Review & Approve"| B["🔨 Apply"]
    B -->|"Test & Verify"| C["📦 Archive"]
    C -->|"Siklus berikutnya"| A
    style A fill:#7c3aed,color:#fff
    style B fill:#059669,color:#fff
    style C fill:#d97706,color:#000

"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:

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 drastis

AI menerima: project.md + folder changes/ yang relevan

Hasilnya:
✅ Biaya API jauh lebih murah
✅ Respons lebih cepat
✅ Rasio sinyal vs noise hampir 100%
✅ Halusinasi berkurang drastis

Secara 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:

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 "[email protected]"
- WHEN pengguna memasukkan email dan password yang benar
- THEN sistem mengembalikan token akses valid
- AND pengguna diarahkan ke halaman dashboard

Analogi: 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:

## ADDED Requirements

### Dark Mode Support
Sistem MUST menyediakan opsi dark mode...

## MODIFIED Requirements

### Login Flow (UPDATED)
Sistem MUST mendukung OAuth2 selain email/password...

## REMOVED Requirements

### SMS Verification
- Reason: Biaya SMS terlalu tinggi, diganti WhatsApp OTP
- Migration: Semua pengguna akan dimigrasikan ke WhatsApp OTP

## RENAMED Requirements

- FROM: User Authentication
- TO: Identity Verification

Perbandingan: OpenSpec vs Kompetitor

Bagaimana posisi OpenSpec di antara platform SDD lainnya?

Peta Perbandingan

Kritik dan Risiko: Apakah Ini Waterfall 2.0?

Tidak ada pendekatan yang sempurna. Berikut kritik paling tajam terhadap SDD dan OpenSpec:

Kesimpulan: Kapan Harus Pakai OpenSpec?

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.

Referensi

• OpenSpec — Repository GitHub (Fission AI)
• Spec-Driven Development — Konsep dan Metodologi
• IETF RFC 2119 — Key Words for Use in RFCs
• Intentional Programming — Charles Simonyi (Microsoft Research)
• Context Engineering — Beyond Prompt Engineering