Pertanyaan ini muncul hampir tiap minggu di grup: "sebelum bikin aplikasi pakai vibe coding, teman-teman pertama kali ngapain?" ...
Pertanyaan ini muncul hampir tiap minggu di grup: "sebelum bikin aplikasi pakai vibe coding, teman-teman pertama kali ngapain?" Jawaban jujurnya: yang paling produktif justru belum menyentuh prompt sama sekali.
Dari "nyerah ke vibes" jadi disiplin baru
Istilah vibe coding lahir Februari 2025 dari Andrej Karpathy — co-founder OpenAI dan mantan Director of AI di Tesla. Definisi aslinya jauh lebih ekstrem dari yang dipakai orang sekarang: menerima setiap diff tanpa dibaca, menempel pesan error tanpa komentar, dan pada dasarnya lupa bahwa kode itu ada. Karpathy sendiri memposisikannya untuk proyek akhir pekan yang sekali pakai — bukan untuk sistem produksi.
Setahun lebih berlalu, dan industri sudah mengumpulkan bukti tentang apa yang terjadi kalau batas itu diabaikan. Beberapa angka yang beredar sepanjang 2026:
- Riset Veracode terhadap lebih dari 100 model bahasa besar menemukan sekitar 45% sampel kode AI memperkenalkan celah dari kategori OWASP Top 10, dan angka itu relatif datar dari 2025 sampai awal 2026 meski skor benchmark coding terus naik.
- Audit terhadap 200+ aplikasi hasil vibe coding pada Q1 2026 menemukan mayoritas besar mengandung minimal satu kerentanan yang bisa dilacak ke halusinasi AI.
- GitGuardian mencatat kredensial hardcoded di commit publik naik puluhan persen tahun-ke-tahun, dengan commit berbantuan AI punya tingkat kebocoran rahasia sekitar dua kali lipat baseline.
- Riset Autonoma (April 2026) menyebut tim yang sudah merilis produk hasil vibe coding menghabiskan sekitar 20–30% kapasitas sprint hanya untuk memperbaiki bug di kode berat-AI, biasanya mulai terasa di sekitar hari ke-90.
Intinya bukan "vibe coding itu jahat". Intinya: alat ini mempercepat penemuan, tapi tidak otomatis memberi ketahanan. Selisih itu ditutup oleh apa yang kamu kerjakan sebelum prompt pertama.
1. Tulis PRD dulu, bukan prompt
Ini yang paling sering disebut praktisi sebagai aktivitas dengan leverage tertinggi. Sebelum satu baris prompt pun ditulis, buat dokumen kebutuhan produk — tidak perlu tebal, satu sampai tiga halaman sudah cukup. Isinya: siapa penggunanya, masalah apa yang diselesaikan, alur utama dari masuk sampai selesai, siapa boleh akses apa, dan apa yang tidak masuk versi pertama.
Manfaatnya dua arah. AI dapat instruksi yang tidak ambigu, dan kamu sendiri terpaksa berpikir jernih. Bandingkan dua prompt ini:
❌ "Buatkan aplikasi manajemen toko."
✅ "Bangun dashboard inventaris untuk toko retail kecil pakai React + Tailwind: daftar produk, tracking stok, alert stok menipis. Mobile-friendly, login untuk satu admin."
Yang pertama menghasilkan tiga puluh iterasi. Yang kedua menghasilkan tiga. Dan PRD-nya jadi sumber kebenaran yang bisa kamu rujuk terus: "implementasikan bagian 4.2 dari PRD", bukan improvisasi tiap sesi.
2. Sketsa layar dan alurnya — sekasar apa pun
Kamu tidak butuh Figma rapi. Coretan di kertas, Whimsical, atau Excalidraw sudah cukup untuk memetakan: layar apa saja yang ada, apa fungsi masing-masing, dan bagaimana pengguna berpindah antar layar. Kebanyakan tool vibe coding modern bisa menerima screenshot atau gambar mockup langsung sebagai input, sehingga hasil generate-nya mengikuti tata letak yang kamu maksud, bukan tebakan generik.
Efek sampingnya menarik: begitu kamu menggambar alur, biasanya ketahuan ada satu-dua state yang belum kamu pikirkan — kondisi kosong, kondisi error, kondisi loading. Lebih murah ketahuan di kertas daripada di production.
3. Kunci keputusan teknis sebelum AI memilihkan untukmu
Kalau kamu tidak menentukan stack, model akan memilih berdasarkan prior dari data latihannya — yang artinya "proyek open-source generik". Tentukan lebih dulu: bahasa dan framework, database, cara autentikasi, ke mana akan di-deploy, dan pola arsitektur dasar. Keputusan-keputusan ini paling mahal untuk diubah belakangan, karena perubahannya menyentuh hampir semua file.
4. Siapkan file konteks: AGENTS.md
Ini kebiasaan yang berkembang cepat sepanjang 2026. AGENTS.md adalah file Markdown di root repo yang berisi hal-hal yang tidak bisa disimpulkan agent dari kode saja: perintah build dan test lengkap dengan flag-nya, konvensi penamaan yang berbeda dari default bahasa, batasan arsitektur, aturan penanganan rahasia, dan daftar hal yang tidak boleh disentuh. Formatnya sudah dibaca puluhan agent — Claude Code, Codex CLI, Cursor, Copilot, Gemini CLI, Aider, dan lainnya — dan hadir di puluhan ribu repo publik.
Beberapa catatan dari praktik lapangan supaya file ini benar-benar berguna:
- Tulis perintah yang bisa langsung di-copy-paste, bukan nama tool yang samar.
uv run pytest tests/unit/ -v, bukan "jalankan test". - Hanya tulis aturan yang menyimpang dari default. Menjelaskan hal yang sudah standar cuma memakan konteks.
- Jangan biarkan membengkak. Ada pola umum di mana tiap kali agent salah, orang menambah satu aturan baru dan tidak pernah menghapus yang lama. Hasilnya file penuh tambalan yang saling bertentangan — dan justru menurunkan tingkat keberhasilan tugas.
- Taruh aturan kritis di bagian awal dan pakai bullet di bawah heading yang jelas (
## Do / Don't). Instruksi yang terkubur di tengah paragraf panjang lebih sering diabaikan.
Perlu kejujuran di sini: sebuah preprint arXiv Februari 2026 dari kelompok riset ETH Zurich menguji apakah file konteks repo benar-benar membantu agent pada tugas nyata, dan hasilnya lebih beragam daripada klaim marketing yang beredar. Jadi perlakukan AGENTS.md sebagai investasi sepuluh menit yang mengurangi pengulangan instruksi — bukan sebagai jimat.
5. Git init sebelum baris pertama
Ini nasihat yang paling membosankan sekaligus paling sering diabaikan. Agent bisa melakukan perubahan luas dalam satu langkah, dan tanpa titik pulih kamu tidak punya cara murah untuk kembali. Commit kecil dan sering, dengan pesan yang menyebut apa yang berubah dan kenapa. Anggap tiap hasil generate sebagai pull request dari junior developer yang cepat tapi kadang ngawur.
6. Tentukan aturan rahasia dari menit nol
Pola kegagalan keamanan yang paling sering muncul justru yang paling sederhana: kredensial hardcoded, kontrol akses yang bolong, dan validasi input yang tidak ada. Jadi tetapkan sejak awal — semua rahasia lewat environment variable, file .env masuk .gitignore sejak commit pertama, dan jangan pernah menempel token atau kunci API ke dalam prompt.
Satu kalimat di awal sesi juga sudah membantu banyak: minta secure default secara eksplisit, misalnya "pakai parameterized query dan validasi semua input". Dan periksa sendiri logika autentikasi serta peran pengguna yang dihasilkan AI — bagian ini sering terlihat benar tapi tidak benar-benar melindungi data.
7. Sepakati definisi "selesai"
Sebelum mulai, tulis bagaimana kamu akan tahu sebuah fitur beres. Test apa yang harus hijau, alur manual apa yang harus jalan, kondisi error apa yang harus ditangani. Tanpa ini, "selesai" berarti "tidak error di layar saya", dan itu definisi yang mahal.
Setelah prompt pertama: pola yang bikin hasilnya konsisten
Persiapan di atas cuma separuh cerita. Beberapa pola yang berulang muncul dari pengalaman banyak orang:
- Prompt berlapis. Minta kerangka dulu — model data, hierarki komponen, signature fungsi — sebelum minta implementasi. Fitur kompleks punya terlalu banyak dimensi untuk diselesaikan dalam satu respons.
- Minta rencananya sebelum kodenya. "Jelaskan pendekatanmu sebelum menulis kode" sering menyelamatkan setengah jam debugging.
- Potong kecil-kecil. Satu masalah per prompt. Membangun seluruh proyek dalam satu prompt adalah pertarungan yang sudah kalah sejak awal.
- Review sebelum menambah fitur. Jangan menumpuk fitur baru di atas logika bisnis yang belum diverifikasi.
- Mulai sesi baru untuk tugas baru. Konteks panjang bikin instruksi awal tenggelam.
Kapan vibe coding, kapan spec-driven?
Perdebatan besar 2026 sebenarnya sudah cukup selesai, dan jawabannya bukan "mana yang menang" tapi "mana yang cocok untuk pekerjaan di depanmu". Vibe coding membeli kecepatan penemuan: prototipe, eksperimen, validasi ide, alat internal sekali pakai. Spec-driven development — spesifikasi ditulis dulu dan diperlakukan sebagai sumber kebenaran yang diturunkan jadi kode, test, dan dokumentasi — membeli ketahanan produksi.
Sintesis praktis yang banyak dipakai tim: pakai vibe coding untuk menemukan kebutuhan, lalu bekukan hasil temuan itu jadi spesifikasi hidup yang di-version-control dan bertahan melampaui satu sesi chat. Riwayat percakapan bukan dokumentasi, dan itu yang bikin banyak proyek tumbang di bulan ketiga.
Checklist 10 menit sebelum prompt pertama
- PRD satu halaman: pengguna, masalah, alur utama, siapa akses apa, apa yang tidak dibuat.
- Sketsa kasar layar dan navigasinya.
- Stack, database, auth, dan target deploy sudah ditentukan.
AGENTS.md: perintah build/test, konvensi non-default, batasan, larangan.git init+.gitignoreyang sudah memuat.env.- Aturan rahasia: environment variable, tidak ada kredensial di prompt.
- Definisi "selesai" untuk fitur pertama.
- Rencana review: siapa yang membaca diff sebelum merge.
Delapan poin, sepuluh menit. Dibandingkan dengan tiga puluh iterasi yang kebakaran kredit, atau perbaikan arsitektur enam bulan kemudian, ini investasi termurah yang bisa kamu lakukan.
Penutup
Jadi, sebelum bikin aplikasi dengan vibe coding, apa yang pertama kali dilakukan? Bukan membuka Cursor. Bukan mengetik prompt. Yang pertama adalah menulis dengan jelas apa yang mau dibangun — karena keahlian inti di era ini memang bergeser dari menghafal sintaks ke kemampuan menjelaskan maksud secara presisi.
AI coding agent itu co-pilot, bukan autopilot. Kalau sepenuhnya di-autopilot-kan, kamu akan dapat aplikasi yang jalan mulus di laptop dan hancur di produksi.
COMMENTS