Prompt Vibe Coding yang Jelas: Struktur dan Contoh Praktis

Verdict Cepat

Prompt yang bagus bukan prompt yang panjang. Prompt yang bagus adalah prompt yang memberi konteks cukup, tujuan yang terukur, dan batasan yang jelas, lalu meminta satu perubahan dalam satu waktu. Pola lima bagian yang dipakai di artikel ini, yaitu konteks, tujuan, batasan, contoh, dan kriteria selesai, terbukti membuat hasil AI coding lebih mudah ditebak, lebih mudah diuji, dan lebih mudah diperbaiki ketika ada yang meleset. Bagi pembaca yang sering mengulang prompt yang sama berkali-kali tanpa hasil yang stabil, struktur ini adalah perbaikan pertama yang paling murah dan paling berdampak.

Artikel ini membahas anatomi prompt vibe coding yang efektif, lengkap dengan contoh praktis membangun fitur daftar tugas, tabel perbandingan prompt kabur dan prompt terstruktur, serta kesalahan umum yang membuat AI salah arah. Semua contoh memakai alat yang umum dipakai, seperti Cursor, Claude Code, dan Windsurf, tetapi prinsipnya berlaku untuk hampir semua asisten coding berbasis AI.

Kenapa Prompt Kabur Menghasilkan Kode Berantakan

Model AI coding tidak membaca pikiran. Model membaca teks, menebak maksud yang paling mungkin, lalu mengisi kekosongan dengan asumsi. Ketika prompt hanya berisi “buatkan aplikasi kasir yang bagus”, ada puluhan keputusan yang dibiarkan terbuka, mulai dari teknologi yang dipakai, struktur data, sampai tampilan antarmuka. Setiap keputusan yang dibiarkan terbuka akan dijawab dengan tebakan, dan tebakan yang berbeda di setiap sesi menghasilkan kode yang tidak konsisten.

Masalahnya membesar ketika prompt kabur dipakai berulang kali pada proyek yang sama. Satu sesi menambahkan pustaka baru, sesi berikutnya mengubah struktur folder, sesi ketiga menulis ulang komponen yang sudah jalan. Hasil akhirnya adalah proyek yang sulit dipelihara, bukan karena AI tidak mampu, tetapi karena arahan yang diberikan berubah-ubah dan tidak terdokumentasi. Panduan praktik vibe coding dari roadmap.sh menekankan hal yang sama, yaitu menulis prompt yang spesifik, menyebutkan file yang boleh diubah, dan menyatakan apa yang tidak boleh disentuh, sebelum meminta kode apa pun.

Sebaliknya, prompt yang terstruktur mengurangi ruang tebakan. AI tetap bisa salah, tetapi kesalahan menjadi lebih mudah dilacak karena setiap keputusan penting sudah tertulis. Ketika hasil meleset, perbaikan tidak perlu menebak ulang dari nol, cukup mengubah satu bagian prompt, misalnya batasan teknologi atau kriteria selesai, lalu meminta revisi pada bagian yang sama.

Anatomi Prompt Vibe Coding yang Bagus

Prompt yang kuat biasanya memuat lima unsur, yaitu konteks, tujuan, batasan, contoh, dan kriteria selesai. Konteks menjawab pertanyaan tentang proyek yang sedang dibangun, termasuk teknologi, struktur folder, dan kondisi saat ini. Tanpa konteks, AI akan berasumsi memakai teknologi paling populer, padahal proyek pembaca mungkin memakai teknologi yang berbeda.

Tujuan menjawab pertanyaan tentang hasil akhir yang diinginkan, dalam bentuk perilaku yang bisa diamati, bukan sekadar nama fitur. “Formulir kontak” adalah nama fitur, sedangkan “formulir kontak dengan validasi email, pesan kesalahan di bawah setiap kolom, dan penyimpanan ke tabel leads” adalah perilaku yang bisa diuji. Semakin perilaku ditulis secara konkret, semakin mudah menilai apakah hasil AI sudah benar atau belum.

Batasan menjawab pertanyaan tentang apa yang tidak boleh dilakukan. Batasan yang sering dilupakan antara lain larangan mengubah file lain, larangan menambah dependensi baru, dan larangan mengubah skema database tanpa persetujuan. Panduan dari Emergent menekankan pentingnya batasan ini, karena AI coding cenderung menambahkan hal yang tidak diminta ketika ruang geraknya tidak dibatasi.

Contoh menjawab pertanyaan tentang bentuk hasil yang diharapkan. Satu contoh respons API, satu potongan kode gaya penulisan yang sudah ada, atau satu tangkapan layar tampilan yang diinginkan sering kali lebih efektif daripada satu paragraf kata sifat seperti modern atau rapi. Contoh memberi patokan konkret yang bisa ditiru, sedangkan kata sifat memberi ruang tafsir yang lebar.

Kriteria selesai menjawab pertanyaan tentang kapan pekerjaan dianggap beres. Kriteria selesai bisa berupa perintah pengujian yang harus lolos, perilaku pada kondisi tepi, atau daftar berkas yang harus berubah. Tanpa kriteria selesai, sesi vibe coding mudah melebar, karena selalu ada tambahan kecil yang terasa perlu dikerjakan.

Lima Bagian Wajib dalam Satu Prompt

Bagian pertama adalah konteks proyek. Tulis teknologi, bahasa, dan kerangka kerja dalam satu atau dua kalimat. Contoh konteks yang cukup adalah proyek React dengan TypeScript, styling memakai Tailwind, dan data disimpan di Supabase. Konteks yang terlalu panjang justru merugikan, karena konteks yang sudah basi membuat AI percaya pada informasi yang sudah tidak berlaku. Panduan dari roadmap.sh mengingatkan agar berkas konteks seperti CLAUDE.md atau aturan Cursor dijaga tetap ringkas dan mutakhir.

Bagian kedua adalah tujuan tunggal. Satu prompt sebaiknya meminta satu perubahan. Meminta tiga fitur sekaligus dalam satu prompt membuat kesalahan sulit dilacak, karena tidak jelas perubahan mana yang merusak bagian yang sudah jalan. Jika fitur besar, pecah menjadi urutan prompt, misalnya layar dulu, data kemudian, autentikasi terakhir. Urutan ini juga memudahkan pengujian, karena setiap langkah bisa diuji sebelum melangkah ke langkah berikutnya.

Bagian ketiga adalah batasan eksplisit. Sebutkan berkas yang boleh diubah, berkas yang tidak boleh disentuh, dan teknologi yang dilarang. Batasan juga mencakup aturan gaya, seperti mengikuti komponen tombol yang sudah ada atau memakai pola penamaan yang sama. Batasan yang tertulis membantu AI menolak godaan untuk menulis ulang bagian yang sudah stabil.

Bagian keempat adalah contoh dan referensi. Tempelkan potongan kode singkat, contoh respons API, atau aturan gaya dari berkas yang sudah ada. Jika tidak ada contoh, tulis contoh hasil yang diharapkan dalam bentuk teks, misalnya format tanggal, isi pesan kesalahan, atau urutan langkah pengguna. Contoh yang singkat dan relevan jauh lebih berguna daripada deskripsi panjang tanpa patokan.

Baca juga:

Bahkan Linus Torvalds Pakai AI untuk Kernel Linux

Bagian kelima adalah kriteria selesai dan cara menguji. Tulis perintah pengujian yang harus dijalankan, perilaku yang harus terlihat di layar, dan kondisi tepi yang harus ditangani. Ketika AI selesai menulis kode, minta ringkasan perubahan dalam bentuk daftar berkas yang diubah dan hasil pengujian. Ringkasan ini membuat peninjauan kode lebih cepat, karena pembaca tidak perlu menebak apa yang berubah.

Contoh Praktis: Membangun Fitur Daftar Tugas

Bayangkan proyek aplikasi web sederhana yang memakai React dan penyimpanan lokal di peramban. Prompt kabur untuk fitur ini biasanya berbunyi tambah fitur daftar tugas yang bagus. Hasil yang keluar bisa bermacam-macam, mulai dari desain yang berbeda dari aplikasi yang ada sampai penyimpanan data yang tidak konsisten. Prompt yang terstruktur menulis hal yang sama dengan jauh lebih presisi.

Contoh prompt terstruktur untuk kasus ini berbunyi sebagai berikut. Konteks proyek adalah aplikasi React dengan TypeScript dan Tailwind, data disimpan di localStorage dengan kunci todos. Tujuan adalah menambahkan halaman daftar tugas dengan kemampuan menambah, menandai selesai, dan menghapus tugas. Batasan menyatakan hanya berkas di folder tugas yang boleh diubah, tidak boleh menambah dependensi baru, dan gaya tombol harus mengikuti komponen tombol yang sudah ada. Contoh yang dilampirkan adalah bentuk data tugas, yaitu objek dengan kolom id, judul, selesai, dan dibuatPada. Kriteria selesai menyatakan tugas baru muncul di atas daftar, tugas yang ditandai selesai menampilkan coretan, dan penyimpanan lokal tetap konsisten setelah halaman dimuat ulang.

Perbedaan utama antara dua prompt tersebut bukan panjangnya, tetapi kepastian. Prompt terstruktur memberi jawaban atas pertanyaan yang pasti muncul saat AI menulis kode, yaitu teknologi apa, data seperti apa, berkas mana, dan kapan pekerjaan dianggap selesai. Prompt kabur menyerahkan semua jawaban itu pada tebakan.

Setelah hasil pertama keluar, langkah berikutnya adalah menguji, bukan langsung menambah fitur baru. Jalankan aplikasi, tambah satu tugas, tandai selesai, hapus satu tugas, lalu muat ulang halaman. Jika ada perilaku yang meleset, laporkan dengan kalimat yang spesifik, misalnya tombol hapus tidak menghapus tugas kedua setelah halaman dimuat ulang, bukan dengan kalimat umum seperti perbaiki yang rusak. Laporan yang spesifik mengarahkan AI pada satu titik kegagalan, sedangkan laporan yang umum memaksa AI menebak ulang seluruh fitur.

Jika perbaikan ketiga masih gagal pada titik yang sama, hentikan putaran perbaikan dan mulai percakapan baru dengan ringkasan yang lebih kecil. Minta AI menjelaskan penyebab kegagalan sebelum meminta perbaikan lagi. Praktik ini, yang juga dianjurkan oleh panduan Emergent, sering kali mengungkap asumsi yang salah tentang struktur data atau alur aplikasi, yang tidak terlihat selama putaran perbaikan yang terburu-buru.

Perbandingan: Prompt Kabur dan Prompt Terstruktur

Tabel berikut membandingkan dua pendekatan pada dimensi yang paling terasa dalam praktik sehari-hari, yaitu kepastian hasil, kemudahan pengujian, dan biaya perbaikan.

Baca juga:

Bikin Aplikasi Android Cuma Modal Prompt, Tanpa Coding

Tabel ini juga menjelaskan kenapa prompt terstruktur sering terasa lambat pada awalnya. Waktu yang dipakai untuk menulis konteks dan kriteria selesai memang menambah menit di depan, tetapi waktu itu kembali berkali lipat pada saat pengujian dan perbaikan. Sebaliknya, prompt kabur menghemat menit di depan dan membayarnya dengan jam revisi di belakang.

Kesalahan Umum yang Membuat AI Salah Arah

Kesalahan pertama adalah meminta terlalu banyak dalam satu prompt. Fitur besar yang diminta sekaligus membuat AI menulis banyak kode baru tanpa titik pemeriksaan di tengah jalan. Ketika ada yang rusak, tidak jelas bagian mana yang menjadi sumber masalah. Solusinya adalah memecah pekerjaan menjadi langkah kecil yang masing-masing bisa diuji.

Kesalahan kedua adalah memakai kata sifat sebagai pengganti spesifikasi. Kata seperti bagus, modern, atau rapi tidak memberi informasi yang bisa dieksekusi. Ganti kata sifat dengan ukuran konkret, misalnya jarak antar bagian 80 piksel, lebar kolom mengikuti grid 12 kolom, atau tombol mengikuti komponen yang sudah ada. Panduan dari AIM Consulting juga menekankan hal yang sama, yaitu meminta tujuan yang spesifik dan terukur daripada deskripsi yang abstrak.

Kesalahan ketiga adalah membiarkan konteks menjadi basi. Berkas aturan proyek yang tidak diperbarui setelah perubahan besar akan menyesatkan AI pada sesi berikutnya. Luangkan waktu untuk memperbarui berkas konteks setelah perubahan arsitektur, pergantian pustaka, atau perubahan skema data. Konteks yang ringkas dan mutakhir lebih berguna daripada konteks yang panjang tetapi kedaluwarsa.

Kesalahan keempat adalah menerima perubahan tanpa membaca perbedaan kode. AI coding bisa menghapus fungsi, mengganti nama, atau menambah dependensi tanpa pemberitahuan yang jelas. Tinjau setiap perbedaan seperti meninjau permintaan tarik dari rekan kerja, periksa penghapusan, perubahan API, dan dependensi baru sebelum menerima. Praktik ini memang menambah waktu, tetapi jauh lebih murah daripada memperbaiki regresi yang baru ketahuan beberapa hari kemudian.

Kesalahan kelima adalah menumpuk perubahan tanpa pengujian. Setiap perubahan yang diterima tanpa diuji menjadi fondasi bagi perubahan berikutnya, sehingga satu kesalahan kecil bisa menyebar ke seluruh fitur. Uji setelah setiap perubahan yang diterima, walau pengujian hanya berupa menjalankan aplikasi dan mencoba satu alur utama. Kebiasaan ini menjaga proyek tetap dalam kondisi bisa kembali ke titik terakhir yang terbukti jalan.

Kesalahan keenam adalah menyimpan prompt yang bagus hanya di kepala. Prompt yang terbukti menghasilkan kode yang baik sebaiknya disimpan sebagai templat di dalam proyek, misalnya sebagai berkas panduan atau potongan teks yang bisa dipakai ulang. Templat yang tersimpan mengurangi variasi antar sesi dan membuat anggota tim lain bisa memakai pola yang sama tanpa mengulang proses coba-coba dari nol.

Baca juga:

Membangun MVP Startup dengan Vibe Coding

Kesimpulan dan CTA

Prompt yang bagus adalah spesifikasi yang singkat, bukan puisi tentang fitur yang diinginkan. Konteks memberi pijakan, tujuan tunggal memberi arah, batasan menjaga ruang gerak, contoh memberi patokan, dan kriteria selesai memberi titik akhir yang bisa diuji. Lima bagian ini cukup untuk mengubah vibe coding dari sesi tebak-tebakan menjadi alur kerja yang bisa diulang dan diperbaiki.

Langkah praktis berikutnya cukup sederhana. Pilih satu fitur kecil pada proyek yang sedang berjalan, tulis prompt memakai lima bagian di atas, lalu uji hasilnya sebelum menambah fitur lain. Simpan prompt yang berhasil sebagai templat, perbarui berkas konteks proyek, dan ulangi pola yang sama pada fitur berikutnya. Untuk referensi lebih lanjut, panduan praktik vibe coding dari roadmap.sh dan Emergent memberi daftar periksa yang sejalan dengan pola ini, sedangkan artikel AIM Consulting dan VibeCodeSource memberi contoh pola prompt yang bisa langsung dicoba. Pembahasan tentang pengaturan Cursor dan Claude juga tersedia di Cheesecake Labs.

Bagi pembaca yang sedang belajar vibe coding dari nol, artikel Vibe Coding Buat Pemula dan Membangun MVP Startup dengan Vibe Coding memberi gambaran alur dari ide menjadi aplikasi jadi. Pembahasan tentang penyusunan konteks untuk AI ada di Context Engineering, sedangkan contoh membangun aplikasi hanya bermodal prompt dibahas di Bikin Aplikasi Android Cuma Modal Prompt. Artikel AI Agent: Cara Kerja dan Manfaatnya melengkapi gambaran tentang cara kerja agen AI di balik alat-alat tersebut.

Mulailah dari satu prompt yang terstruktur pada fitur berikutnya. Hasil pertama mungkin belum sempurna, tetapi proses perbaikannya akan jauh lebih singkat, karena setiap revisi berangkat dari spesifikasi yang tertulis, bukan dari tebakan baru.