Context engineering untuk vibe coding adalah praktik menyusun instruksi, aturan, dan dokumentasi proyek supaya AI coding assistant menghasilkan kode yang konsisten dengan standar tim. Tanpa konteks yang rapi, hasil AI bisa akurat di satu file lalu melenceng di file berikutnya.
Vibe coding memang menyenangkan. Cukup deskripsikan ide, lalu AI menulis kode dalam hitungan detik. Saat proyek membesar, masalah mulai muncul. AI memilih library berbeda, membuat nama fungsi yang tidak konsisten, atau menulis ulang bagian yang sebenarnya sudah ada. Di sinilah context engineering untuk vibe coding berperan langsung.
Penyebabnya sering bukan kemampuan model, melainkan informasi proyek yang tidak pernah diberikan.
Panduan ini membahas cara menyiapkan konteks yang bisa dipakai di Cursor, Claude Code, OpenCode, Codex, dan tool sejenis. Ada template siap adaptasi, tabel kesalahan umum, serta langkah pemeliharaan agar aturan proyek tidak cepat basi. Materinya disusun untuk orang yang sudah pernah meminta AI membuat kode, lalu bingung mengapa hasil pada sesi berikutnya berbeda total. Setiap bagian menghubungkan aturan dengan kegagalan yang hendak dicegah, jadi file konteks tidak berubah menjadi daftar larangan tanpa alasan. Tujuannya sederhana: agent memahami proyek sebelum menyentuh kode.
Context engineering adalah proses memilih, menyusun, dan merawat informasi yang diberikan kepada AI coding assistant sebelum dan selama pengerjaan kode. Isinya dapat berupa tujuan produk, struktur folder, keputusan arsitektur, aturan pengujian, contoh kode, serta batasan yang tidak boleh dilanggar. AI kemudian bekerja di dalam pagar tersebut, bukan menebak standar proyek dari satu prompt pendek.
Prompt engineering berfokus pada satu perintah. Misalnya, “buat endpoint login memakai JWT dan tambahkan tes.” Context engineering mengatur lingkungan informasi yang melingkupi perintah itu: framework backend, lokasi route, pola error handling, format respons, library pengujian, serta standar penamaan. Prompt menjelaskan pekerjaan hari ini. Context engineering untuk vibe coding menjelaskan cara proyek bekerja.
Analogi paling mudah adalah anggota tim baru. Instruksi tiket membantu dia menyelesaikan satu tugas, sedangkan README, keputusan arsitektur, dan convention guide membantu dia bekerja selaras dengan tim selama berbulan-bulan. Keduanya saling melengkapi.
| Aspek | Prompt engineering | Context engineering |
|---|---|---|
| Ruang lingkup | Satu permintaan atau percakapan | Seluruh proyek dan pola kerja |
| Umur informasi | Singkat, sering habis setelah sesi | Disimpan dan diperbarui bersama kode |
| Contoh | “Buat form registrasi” | Stack, struktur folder, validasi, testing, batasan |
| Risiko utama | Perintah ambigu | Konteks terlalu panjang atau kedaluwarsa |

Ada tiga pendekatan populer untuk menyimpan instruksi. Pilih berdasarkan tool yang dipakai dan kebutuhan portabilitas. Tidak perlu membuat ketiganya sekaligus jika isinya hanya akan berulang.
AGENTS.md adalah format terbuka untuk memberi panduan kepada coding agent. Situs resminya menyebut format tersebut telah dipakai oleh puluhan ribu proyek open source. File ditempatkan di root repositori, mirip README khusus agent. Format ini cocok saat anggota tim memakai tool berbeda karena instruksi tetap tinggal bersama kode.
Struktur AGENTS.md tidak membutuhkan sintaks rumit. Markdown biasa sudah cukup. Isi paling berguna justru hal konkret: perintah build, cara menjalankan tes, struktur folder, convention, dan contoh implementasi yang disukai. Dokumen panjang tanpa prioritas biasanya kalah berguna dari 80 baris aturan yang spesifik.
Claude Code membaca CLAUDE.md sebagai instruksi proyek. Pendekatan just in time context yang dijelaskan Anthropic memungkinkan agent menyimpan penunjuk berupa path, query, atau tautan, lalu mengambil detail ketika diperlukan. Pola ini mencegah semua dokumentasi memenuhi context window sejak awal.
CLAUDE.md cocok untuk tim yang sudah memakai Claude Code sebagai tool utama. Simpan aturan global di root, kemudian taruh instruksi khusus dekat folder terkait jika proyek membutuhkannya. Aturan frontend tidak perlu membebani agent saat mengerjakan migrasi database.
Cursor Project Rules dapat mengaktifkan instruksi berdasarkan file atau folder yang sedang dikerjakan. Fitur ini praktis untuk monorepo. Paket mobile bisa punya aturan sendiri, sementara API dan dashboard memegang convention berbeda. Kekurangannya adalah ketergantungan pada Cursor, sehingga migrasi tool memerlukan penyesuaian.
Pilih AGENTS.md jika portabilitas menjadi prioritas. Gunakan CLAUDE.md ketika alur kerja berpusat pada Claude Code. Cursor Rules masuk akal untuk aturan bersyarat yang sangat terikat pada folder. Bila tim memakai beberapa tool, AGENTS.md dapat menjadi sumber utama dan file khusus tool cukup merujuk ke sana.
Saya biasanya mulai dari konteks minimum, lalu menambah aturan hanya setelah menemukan kesalahan berulang. Pada satu proyek kecil, file 67 baris memberi hasil lebih stabil dibanding dokumen lama 310 baris karena aturan penting tidak lagi terkubur. Pendekatan ini juga membuat review perubahan jauh lebih mudah.
Mulai dengan satu paragraf yang menjelaskan produk, pengguna, dan batas pekerjaannya. Hindari deskripsi pemasaran. Agent lebih membutuhkan kalimat seperti “dashboard internal untuk memeriksa transaksi gagal” daripada slogan yang tidak menjelaskan perilaku sistem.
Tulis versi runtime, package manager, framework, database, serta perintah build dan tes. Versi penting karena contoh dari internet sering memakai API lama. Berikan perintah yang benar-benar bisa dijalankan dari root repositori.
Sebutkan lokasi source, test, migration, dan dokumentasi. Tambahkan satu contoh pendek untuk pola yang sering salah, misalnya bentuk handler, validasi input, atau cara mengembalikan error. Contoh kode mengurangi ruang interpretasi.
Larangan tanpa alasan mudah diterapkan secara kaku. Tulis “jangan menambah library state management karena proyek memakai Context API” alih-alih hanya “jangan menambah dependency.” Alasan membantu agent mengambil keputusan pada kasus yang tidak tercantum secara eksplisit.
Minta agent mengerjakan perubahan kecil, lalu periksa nama file, import, error handling, dan tes. Catat pelanggaran yang berulang. Perbaiki context file, bukan menumpuk koreksi di percakapan yang akan hilang setelah sesi selesai.
# Project overview
Nama: [nama proyek]
Tujuan: [tujuan dalam satu kalimat]
Pengguna: [pengguna utama]
# Tech stack
Runtime: Node.js [versi]
Framework: [framework dan versi]
Database: [database]
Package manager: [npm, pnpm, atau yarn]
# Commands
Install: [perintah]
Development: [perintah]
Test: [perintah]
Build: [perintah]
# Structure
src/: kode aplikasi
tests/: pengujian
docs/: keputusan dan panduan teknis
# Coding rules
Gunakan TypeScript strict mode.
Ikuti pola error dari src/lib/errors.ts.
Tambahkan tes untuk perilaku baru.
Gunakan kebab case untuk nama file.
# Preferred example
[Rujuk file yang menjadi contoh terbaik]
# Avoid
Jangan menambah dependency tanpa alasan teknis.
Jangan mengubah file di luar scope tugas.
Jangan menghapus tes yang gagal untuk meloloskan build.
Template ini sengaja ringkas. Isi placeholder, hapus bagian yang tidak relevan, lalu tambahkan path menuju contoh terbaik di repositori. Tautan internal seperti arsip Vibe Coding Grafisify juga bisa dijadikan bahan lanjutan, tetapi sumber kebenaran teknis tetap berada di repositori proyek.
| Kesalahan | Dampak | Perbaikan |
|---|---|---|
| Menyalin semua dokumentasi ke satu file | Instruksi penting tenggelam | Simpan ringkasan dan rujuk path detail |
| Aturan saling bertentangan | Agent memilih pola secara tidak konsisten | Tentukan satu sumber kebenaran |
| Dokumentasi kedaluwarsa | Kode memakai API atau pola lama | Review bersamaan dengan perubahan arsitektur |
| Aturan abstrak tanpa contoh | Interpretasi berbeda antar sesi | Tambahkan satu contoh Preferred dan Avoid |
| Tidak ada urutan prioritas | Agent bingung saat instruksi berkonflik | Nyatakan prioritas aturan lokal dan global |
Kesalahan paling umum adalah context dump. Seluruh wiki, catatan rapat, dan dokumentasi library ditempel ke satu file. Context window terisi oleh informasi yang belum tentu dibutuhkan, sementara perintah build dan convention utama justru sulit ditemukan.
Tanpa context engineering untuk vibe coding yang baik, agent bekerja dalam ruang penuh tebakan.
Simpan identitas proyek dan aturan inti di file utama. Detail dapat dipanggil lewat path saat tugas membutuhkannya.
Konflik aturan sama berbahayanya. Satu bagian meminta functional component, bagian lain menampilkan class component sebagai contoh. Agent tidak tahu mana yang terbaru. Context engineering untuk vibe coding yang andal menuntut tanggal review dan pemilik dokumen, lalu hapus contoh lama daripada menyimpannya sebagai sejarah.
Jangan menulis aturan dari dugaan. Jalankan tes dan linter untuk memberi umpan balik yang objektif. Context engineering untuk vibe coding bekerja paling baik saat instruksi manusia dipasangkan dengan pemeriksaan otomatis. Agent mendapat arah, sedangkan CI membuktikan hasilnya.
Context engineering adalah pengelolaan informasi proyek yang diterima AI sebelum menulis kode. Informasi itu mencakup tujuan, stack, struktur folder, convention, contoh, dan larangan. Hasilnya lebih konsisten karena agent tidak menebak pola dari percakapan pendek.
Prompt engineering mengoptimalkan satu permintaan, sedangkan context engineering mengatur kumpulan informasi yang mendasari banyak permintaan. Prompt menjawab apa yang harus dikerjakan sekarang. Konteks menjelaskan bagaimana pekerjaan harus mengikuti sistem yang sudah ada.
Buat file di root repositori, lalu isi tujuan proyek, stack, perintah build dan tes, struktur folder, aturan coding, contoh rujukan, serta larangan. Mulai dari 50 sampai 100 baris. Uji dengan tugas kecil dan tambah aturan hanya ketika ada pola kesalahan yang nyata.
Ya. Pemula justru terbantu karena konteks yang jelas mengurangi koreksi berulang. Namun, hasil AI tetap perlu dibaca dan diuji. File instruksi bukan pengganti pemahaman kode, melainkan pagar agar proses belajar tidak terus terganggu oleh inkonsistensi tool.
Tidak ada angka baku, tetapi 50 sampai 150 baris cukup untuk banyak proyek kecil dan menengah. Jika melewati 200 baris, pecah detail berdasarkan domain atau folder. Ringkasan utama harus tetap mudah dipindai dalam beberapa menit.
Perbarui saat framework berganti, struktur folder berubah, perintah tes berbeda, atau agent mengulang kesalahan yang sama. Review ringan setiap dua sampai empat minggu cukup untuk proyek aktif. Perubahan arsitektur besar perlu disertai pembaruan konteks pada pull request yang sama.

Context engineering membuat vibe coding lebih terprediksi. AI tidak harus menebak ulang stack, struktur, dan convention setiap kali membuka sesi baru. Waktu review beralih dari membetulkan hal dasar ke menilai keputusan teknis yang memang penting.
Mulai kecil. Buat AGENTS.md atau CLAUDE.md, isi aturan inti, lalu uji pada satu tugas nyata. Jika agent melanggar pola yang sama dua kali, perjelas instruksinya dan sertakan contoh. Jika dokumen membengkak, pindahkan detail ke file terpisah.
Targetnya bukan context file yang sempurna. Targetnya adalah kode yang konsisten, mudah diuji, dan tidak mengharuskan tim mengulang penjelasan yang sama setiap hari.
