Cara Nyusun Prompt “Spec → Plan → Diff” Biar AI Coding Nggak Ngawur

AI coding sering terlihat “ngawur” bukan karena modelnya selalu buruk. Sering kali masalahnya lebih sederhana: kita memberi instruksi yang terlalu kabur.

Contohnya: “tolong bikin fitur login” terdengar jelas bagi manusia, tapi untuk AI itu masih terlalu luas. Login pakai email? OAuth? Session atau JWT? Validasi di frontend saja atau backend juga? Kalau tidak diarahkan, AI akan menebak. Dan tebakan itulah yang biasanya bikin kode melebar, file berubah terlalu banyak, atau bug baru muncul.

Salah satu cara paling praktis untuk mengontrol hasil AI coding adalah memakai pola Spec → Plan → Diff.

Pola ini sederhana:

1. Spec: jelaskan hasil akhir yang kamu mau.
2. Plan: minta AI membuat rencana sebelum coding.
3. Diff: minta perubahan kecil dan terarah, bukan rewrite besar-besaran.

Dengan cara ini, AI tidak langsung “ngebut nulis kode”. Ia dipaksa paham konteks dulu, lalu bergerak dalam batas yang kamu tentukan.

Kenapa prompt AI coding sering gagal?

Ada tiga penyebab yang paling sering muncul.

Pertama, prompt terlalu fokus ke output, bukan batasan. Kamu minta fitur jadi, tapi tidak menjelaskan apa yang tidak boleh diubah.

Kedua, prompt terlalu besar. Satu prompt dipakai untuk minta database schema, UI, API, validasi, test, dan refactor sekaligus. Hasilnya, AI mencoba menyelesaikan semua dalam satu tarikan napas.

Ketiga, tidak ada tahap review. AI langsung diminta edit kode, padahal rencananya belum tentu sesuai struktur project.

Masalahnya, AI coding tools bekerja sangat cepat. Kalau arahnya salah, salahnya juga cepat menyebar.

Apa itu pola Spec → Plan → Diff?

Spec → Plan → Diff adalah format prompt yang memecah pekerjaan coding menjadi tiga tahap.

1. Spec: tulis target dengan jelas

Spec adalah deskripsi hasil akhir. Di tahap ini, kamu menjelaskan fitur, batasan, dan acceptance criteria.

Contoh spec yang buruk:

Bikin halaman pricing yang bagus.

Contoh spec yang lebih berguna:

Buat section pricing untuk landing page SaaS.
Ada 3 paket: Harian, 2 Hari, dan 3 Hari.
Tiap card berisi nama paket, harga, durasi aktif, CTA, dan 3 benefit.
Jangan ubah navbar dan footer.
Gunakan style CSS yang sudah ada.

Prompt kedua memberi AI pagar yang jelas. Ia tahu apa yang harus dibuat, apa yang tidak boleh disentuh, dan gaya implementasi yang diharapkan.

Template Spec yang bisa kamu pakai

Pakai format ini saat mulai fitur baru:

Saya ingin kamu membantu implementasi [nama fitur].

Konteks:
- Project ini menggunakan [stack/framework].
- File yang kemungkinan relevan: [sebutkan file jika tahu].
- Style atau pola existing yang harus diikuti: [jelaskan singkat].

Target hasil:
- [hasil 1]
- [hasil 2]
- [hasil 3]

Batasan:
- Jangan ubah [bagian/file].
- Jangan rewrite total jika tidak perlu.
- Prioritaskan perubahan kecil dan mudah direview.

Acceptance criteria:
- [kriteria selesai 1]
- [kriteria selesai 2]
- [kriteria selesai 3]

Kuncinya bukan membuat prompt panjang. Kuncinya membuat prompt yang mengurangi ruang tebak-tebakan.

Plan: jangan langsung suruh AI ngoding

Setelah spec jelas, jangan langsung minta AI edit kode. Minta ia membuat plan dulu.

Contoh:

Sebelum mengubah kode, baca file yang relevan lalu buat rencana implementasi singkat.
Tulis:
1. File mana yang akan diubah.
2. Perubahan apa di tiap file.
3. Risiko yang perlu diperhatikan.
4. Hal yang perlu saya konfirmasi sebelum eksekusi.

Jangan edit kode dulu.

Tahap ini penting karena kamu bisa melihat apakah AI benar-benar paham struktur project. Kalau plan-nya salah, kamu bisa koreksi sebelum kode berubah.

Untuk project kecil, tahap plan mungkin terasa lambat. Tapi untuk project yang sudah punya banyak komponen, plan bisa menyelamatkan kamu dari refactor yang tidak perlu.

Diff: minta perubahan kecil, bukan rewrite besar

Setelah plan disetujui, baru masuk tahap diff.

Prompt-nya bisa seperti ini:

Eksekusi plan tadi dengan perubahan sekecil mungkin.
Jaga naming dan style existing.
Jangan ubah behavior lain di luar scope.
Setelah selesai, jelaskan diff utama dan cara test manualnya.

Kenapa “perubahan sekecil mungkin” penting?

Karena AI cenderung membantu terlalu banyak. Kadang kamu minta validasi form, ia sekalian merapikan layout, mengganti struktur komponen, dan mengubah helper function. Niatnya baik, tapi review jadi susah.

Dengan meminta diff kecil, kamu menjaga proses tetap aman:

• lebih mudah direview,
• lebih mudah rollback,
• lebih kecil peluang bug menyebar,
• lebih cocok untuk kerja tim.

Contoh lengkap prompt Spec → Plan → Diff

Misalnya kamu ingin menambahkan empty state di dashboard.

Prompt 1 — Spec

Saya ingin menambahkan empty state di halaman API Keys.

Konteks:
- Project menggunakan React.
- Empty state muncul jika user belum punya API key.
- Tombol CTA membuka modal create API key yang sudah ada.

Target hasil:
- Tampilkan icon sederhana, heading, body copy, dan CTA.
- Copy harus ramah untuk developer pemula.
- Gunakan class/style existing jika memungkinkan.

Batasan:
- Jangan ubah logic create API key.
- Jangan ubah API call.
- Jangan rewrite halaman dashboard.

Acceptance criteria:
- Jika list API key kosong, empty state tampil.
- Jika API key sudah ada, list tetap tampil seperti sebelumnya.
- CTA create key tetap memakai flow existing.

Prompt 2 — Plan

Baca file yang relevan dulu.
Jangan edit kode.
Buat rencana implementasi: file yang diubah, perubahan di tiap file, dan risiko.

Prompt 3 — Diff

Plan sudah oke. Sekarang implementasikan dengan diff sekecil mungkin.
Setelah selesai, jelaskan perubahan utama dan cara test manual.

Dengan format ini, kamu tetap mengendalikan arah kerja. AI menjadi pair programmer, bukan autopilot liar.

Cara pakai pola ini di Claude Code

Di Claude Code, pola ini enak dipakai karena kamu bisa bekerja langsung dari terminal project.

Urutan praktisnya:

1. Buka project di terminal.
2. Jalankan Claude Code.
3. Mulai dengan prompt spec.
4. Minta plan tanpa edit kode.
5. Review plan.
6. Baru minta implementasi diff kecil.
7. Jalankan test/manual QA.

Kalau kamu baru setup Claude Code, kamu bisa baca panduan ini: tutorial Claude Code setup awal untuk pemula.

Di mana VibeRouter masuk?

VibeRouter bukan pengganti prompt yang bagus. Prompt tetap perlu jelas.

Tapi kalau workflow kamu sudah mulai intens—misalnya bolak-balik minta plan, review diff, generate test, dan debugging—kamu butuh setup AI coding yang tidak gampang mengganggu ritme kerja.

Di sini VibeRouter relevan sebagai jalur API untuk Claude Code dan workflow AI coding lain. Kamu tetap pakai tool yang sama, tapi request diarahkan lewat endpoint VibeRouter.

Kalau ingin memahami konsep router untuk AI coding, baca juga: router AI untuk coding.

Kesalahan umum saat pakai Spec → Plan → Diff

Ada beberapa hal yang sebaiknya dihindari.

1. Spec terlalu abstrak

“Bikin lebih bagus” bukan spec. Jelaskan bagus itu dari sisi apa: layout, copy, UX, performa, atau maintainability.

2. Plan tidak dibaca

Kalau kamu tetap langsung menyetujui semua plan, tahap plan jadi formalitas. Baca file yang mau diubah dan cek apakah scope-nya masuk akal.

3. Diff terlalu besar

Kalau AI mulai mengubah banyak area yang tidak diminta, stop. Minta ia ulangi dengan scope lebih kecil.

4. Tidak ada test manual

Minimal minta AI menulis cara cek hasilnya. Bahkan untuk perubahan UI sederhana, checklist manual bisa mencegah bug kecil masuk production.

Ringkasan workflow

Kalau ingin AI coding lebih terarah, jangan mulai dari “tolong bikinin”. Mulai dari struktur kerja.

Spec → Plan → Diff → Test

Spec membuat tujuan jelas. Plan mencegah AI salah arah. Diff menjaga perubahan tetap kecil. Test memastikan hasilnya tidak cuma terlihat selesai, tapi benar-benar berjalan.

AI coding paling berguna saat kamu tetap menjadi driver. AI membantu mempercepat eksekusi, tapi arah tetap dari kamu.

Kalau kamu ingin mulai dari setup tool-nya dulu, lanjutkan ke cara pakai Claude Code dengan VibeRouter API.