Vibe coding vs spec: perubahan tetap harus mendarat di kontrak

Pada 12 September 2026 kami menjalankan sesi live: Build an App with AI, From Idea to Running Application. Layarnya terlihat seperti “vibe coding” klasik — Cursor tema gelap, SurveyDesk terbuka, sidebar agent menunggu kalimat berikutnya. Prompt yang kami ketik bukan “ubah UI iPad.” Melainkan: update spec to allow iPad refresh button where it is available on Android but not iPad.

Apa yang orang maksud dengan vibe coding

Vibe coding adalah delivery percakapan: deskripsikan perasaan produk, biarkan agent menggerakkan file, terus prompt sampai UI terlihat benar. Cepat, sosial, dan bagus untuk discovery. Mode gagalnya bukan karena agent salah — melainkan satu-satunya catatan tahan lama tentang “apa yang kita putuskan” hidup di dalam tab yang sudah ditutup.

• Intent tinggal di riwayat chat yang agent berikutnya tidak bisa andalkan.
• Keunikan platform (“Android punya refresh; iPad tidak”) jadi pengetahuan suku.
• Demo yang hijau menyembunyikan coverage penerimaan yang hilang untuk perilaku baru.
• Regenerasi belakangan membangun ulang produk kemarin, bukan keputusan hari ini.

Apa yang diubah Spec-Driven Development

Di SurveyDesk sidebar kiri bukan dekorasi. specs/acceptance menyimpan fitur Gherkin. specs/adr menyimpan keputusan arsitektur. Script di package.json menjalankan execute:specs, regen:parallel, dan test:acceptance. Di stream live terminal sudah menunjukkan enam file penerimaan lulus — lifecycle, form-builder, adaptive-layout, dan kawan-kawan. Suite itu adalah permukaan bukti untuk apa pun yang diubah agent berikutnya.

Momen live: refresh di Android, bukan di iPad

Permintaan produk sering datang sebagai vibe: “Kenapa saya tidak bisa refresh di iPad seperti di Android?” Vibe coding murni menjawab dengan menambal layar iPad sampai tombol muncul. Spec-first menjawab dengan membuka adaptive-layout.feature (atau SHALL yang relevan) dan menulis aturan platform di tempat agent berikutnya — dan manusia berikutnya — bisa menemukannya.

# Illustrative — the durable form of the live ask
Feature: Adaptive operator layout
  Scenario: Refresh control by platform
    Given an operator session on Android
    Then the refresh control SHALL be available
    Given an operator session on iPad
    Then the refresh control SHALL NOT be available
    # After the product decision changes:
    # Then the refresh control SHALL be available on iPad too

Begitu file fitur (atau ID persyaratan) membawa aturan baru, implementasi dan tes mengikuti kontrak. Jika nanti seseorang meregenerasi apps/, perilaku refresh iPad tetap hidup karena tidak pernah hanya saran chat.

Berdampingan

• Vibe saja: “Tambah tombol refresh iPad.” → agent edit Swift/UI → demo terlihat oke → sesi berikutnya lupa kenapa Android berbeda.
• Vibe → spec: “Update spesifikasi supaya iPad boleh refresh seperti Android.” → agent edit acceptance + SHALL → implementasi → test:acceptance tetap hijau untuk aturan baru.
• Sumber kebenaran vibe saja: memori model atas prompt terakhir.
• Sumber kebenaran spec: specs/ berversi di git plus acceptance yang bisa dijalankan.

Loop praktis yang bisa Anda tiru

1. 01Rasakan perubahannya dalam natural language — pertahankan vibe-nya.
2. 02Arahkan agent ke kontrak: “update spesifikasi / feature / SHALL untuk …”
3. 03Biarkan agent mengimplementasi menurut ID yang sudah diperbarui.
4. 04Jalankan acceptance (dan regenerasi) supaya suite membuktikan perilaku baru.
5. 05Review diff di specs/ lebih dulu — itulah keputusan produk.

Bacaan terkait

• Spec-Driven Development — https://suherman.net/id/articles/spec-driven-development
• Crafted vs AI-generated di repo Spec-Driven — https://suherman.net/id/articles/crafted-vs-ai-generated-code
• Spesifikasi SurveyDesk dengan Agent On Rails — https://suherman.net/id/articles/agent-on-rails-surveydesk-specs
• SurveyDesk di GitHub — https://github.com/iman-suherman/survey-desk

Intinya dari stream live: tetap bicara ke agent seperti manusia. Pastikan saja kalimatnya berakhir di kontrak — karena produk harus kembali ke spesifikasi lagi.