Mulai SDD: dari ide ke spesifikasi ke implementasi

Setelah Build an App with AI, Live pada 12 September 2026, beberapa orang bilang hal yang sama: sesinya keren — lalu coba SurveyDesk malah makin bingung. Reaksi itu biasa. Live stream memampatkan berjam-jam kerja kontrak menjadi demo. Artikel ini adalah jalur pelan yang bisa Anda ikuti sendiri.

• Rekaman: https://youtu.be/h3FPQEw2QNI
• Catatan sesi 12 Sep: https://suherman.net/id/articles/surveydesk-12-sep-session-notes
• Selain Gherkin (ADR / SHALL / OpenAPI): https://suherman.net/id/articles/beyond-gherkin-adr-shall-openapi
• Webinar: https://suherman.net/id/#webinars

Bahasa bukan intinya (Node cuma salah satu interface)

Kalau Anda lebih suka Java dan tidak mau hidup di Node.js — tidak masalah. Kontrak tahan lama SurveyDesk adalah OpenAPI + SQLite + aturan lifecycle, bukan runtime Node. API referensinya Python (FastAPI) supaya demo tetap netral bahasa. Implementasikan spesifikasi yang sama di Java, Kotlin-JVM, Go, atau apa pun yang menghormati kontrak. Next.js di web publik hanya interface UI responden dari sesi live — bukan syarat SDD itu sendiri.

Petanya (supaya demo tidak terasa acak)

Jika Anda membuka repo di tengah jalan — apps/, chat Cursor, terminal hijau — Anda melihat langkah 3 dan 4 tanpa peta dari langkah 1 dan 2. Itu sebabnya terasa seperti sulap (atau omong kosong).

1. Ide — tulis cerita produk dulu

Jangan mulai dengan “buatkan saya aplikasi.” Mulai dengan cerita pendek yang bisa dibaca rekan tanpa nonton livestream. Untuk SurveyDesk ceritanya menjawab: siapa yang mengoperasikan, siapa yang menjawab, apa yang lokal vs publik, apa yang secara eksplisit di luar cakupan.

Product: SurveyDesk — local-first survey desk.

Operators: native iOS / Android apps only.
Respondents: anonymous Next.js web — no login.
API: local HTTP + SQLite via OpenAPI (Python reference;
     Java or any language welcome — no cloud tenant).

Must: create survey → open → collect → live results → close.
Must not: multi-tenant SaaS, SSO, email invites, payments.

Demo proof: create “Session feedback”, open it,
submit anonymously, see results update, close,
further submit rejected.

2. Spec — bekukan kontraknya

Spesifikasi bukan novel. Itu daftar kebenaran: apa yang SHALL terjadi, apa yang SHALL NOT terjadi, dan bagaimana kita mengetahuinya. Di SurveyDesk itu hidup di bawah specs/ — requirements (SHALL), acceptance (Gherkin), ADR (keputusan arsitektur).

• SHALL: aturan produk yang tahan lama (“submit SHALL ditolak ketika survey ditutup”).
• Acceptance: skenario yang bisa dijalankan tes (Given / When / Then).
• ADR: kenapa kita memilih SQLite / local-first / operator native — supaya agent berikutnya tidak “memperbaiki” Anda ke cloud.

Feature: Survey lifecycle
  Scenario: Reject submit when closed
    Given a survey that is closed
    When a respondent submits answers
    Then the API SHALL reject the submit

Alat bisa membantu menulis paket pertama dari bahasa alami (Agent On Rails gather). Anda tetap mengonfirmasi outline. Tidak ada yang penting yang hanya mendarat di chat.

3. Implementasi — agent membangun menurut ID

Baru buka Cursor (atau coding agent apa pun). Arahkan ke ID requirement atau file fitur — bukan ke perasaan kabur. Prompt yang bagus terdengar seperti: “Implementasikan lifecycle SD-003 menurut specs/acceptance/lifecycle.feature. Jangan mengarang perilaku multi-tenant.”

1. 01Baca SHALL + skenario acceptance yang relevan.
2. 02Minta agent mengimplementasi ID itu saja.
3. 03Review diff apps/ menurut kontrak — bukan menurut vibe.
4. 04Jika keputusan produk berubah, update spesifikasi dulu, baru implementasi ulang.

Langkah terakhir itu inti momen live “refresh iPad”: permintaannya update the spec, bukan hanya UI. Detail: https://suherman.net/id/articles/vibe-coding-vs-spec

4. Buktikan — jalankan acceptance sebelum percaya demo

UI hijau bukan bukti. Di SurveyDesk, npm run test:acceptance (atau pytest terhadap API OpenAPI) adalah permukaan buktinya. Jika suatu perilaku tidak bisa ditunjuk ke skenario, itu masih kecelakaan prototype.

# After clone / install — names may vary by repo
npm run test:acceptance
# or: pytest against the Python API / any OpenAPI-compliant server
# Expect: features/scenarios pass for the IDs you claimed to ship

Rencana akhir pekan (kalau rekaman bikin pusing)

1. Tonton rekaman sekali untuk ceritanya, bukan setiap ketukan: https://youtu.be/h3FPQEw2QNI
2. Baca sekilas catatan sesi 12 Sep: https://suherman.net/id/articles/surveydesk-12-sep-session-notes
3. Baca Selain Gherkin untuk ADR / SHALL / OpenAPI: https://suherman.net/id/articles/beyond-gherkin-adr-shall-openapi
4. Buka https://github.com/iman-suherman/survey-desk dan baca specs/ sebelum apps/.
5. Pilih satu file fitur (lifecycle cocok untuk pertama). Baca Given/When/Then keras-keras.
6. Jalankan suite acceptance. Petakan satu skenario (lulus atau gagal) kembali ke sebuah SHALL.
7. Baru setelah itu minta agent mengubah sesuatu — dan suruh update spesifikasi jika aturan produk berubah.

Langkah berikutnya

• Pendalaman konsep: Spec-Driven Development — https://suherman.net/id/articles/spec-driven-development
• Selain Gherkin: ADR, SHALL, OpenAPI — https://suherman.net/id/articles/beyond-gherkin-adr-shall-openapi
• Catatan sesi 12 Sep — https://suherman.net/id/articles/surveydesk-12-sep-session-notes
• Paket spesifikasi hands-on dengan Agent On Rails — https://suherman.net/id/articles/agent-on-rails-surveydesk-specs
• Kenapa chat tidak cukup: vibe coding vs spec — https://suherman.net/id/articles/vibe-coding-vs-spec
• Cara membaca file crafted vs generated — https://suherman.net/id/articles/crafted-vs-ai-generated-code
• Hasil survei sesi Sabtu — https://suherman.net/id/#survey

Intinya: jika coba repo malah makin bingung, mulai dari ide dan kontrak — bukan dari pohon apps/ yang mengkilap. Energi yang sama dengan vibe live. Zona pendaratan yang berbeda.