Kalau di series pertama kita banyak ngomongin cara mulai dan kebiasaan dasar, sekarang kita naik satu level.

Di titik ini, masalahnya biasanya bukan lagi, “Claude Code itu apa?”

Masalahnya mulai pindah ke, “kenapa hasilnya kadang pas, kadang aneh?”

Dan salah satu jawabannya sering sederhana: karena konteks yang kalian kasih terlalu tipis.

Hasil jelek sering mulai dari konteks yang tipis

Banyak orang merasa sudah kasih instruksi. Tapi kalau dilihat lagi, yang dikasih sering cuma permukaan.

Misalnya begini:

“Coba cek project ini.”

Atau:

“Tolong bantu fix bug ini.”

Secara teknis, itu memang instruksi. Tapi buat Claude Code, instruksi seperti itu masih kebanyakan ruang kosong.

Dia belum tahu ini project apa. Belum tahu kalian lagi ngejar apa. Belum tahu batasan pentingnya di mana. Belum tahu apakah kalian mau penjelasan dulu, diagnosis dulu, atau langsung solusi.

Akhirnya hasil yang keluar sering terasa setengah nyambung. Bukan karena Claude lemah. Tapi karena fondasinya belum cukup jelas.

Makanya, waktu hasil Claude terasa ngaco, jangan langsung curiga ke modelnya dulu. Kadang yang perlu dibenerin pertama justru cara kita buka percakapan.

Claude itu kuat, tapi bukan cenayang

Ini lanjutan dari pelajaran awal yang sebenarnya sudah pernah kita singgung: Claude Code bisa baca file, ngerti struktur kerja, bantu analisis, bahkan bantu nulis perubahan. Tapi dia tetap bukan cenayang.

Dia nggak otomatis tahu mana file yang sensitif. Dia nggak otomatis tahu bagian mana yang kalian takut ubah. Dia juga nggak tahu apakah kalian butuh jawaban cepat, jawaban aman, atau jawaban yang paling kecil dulu.

Kalau kalian datang tanpa konteks, Claude akan tetap berusaha bantu. Tapi dia terpaksa menebak lebih banyak.

Dan makin banyak tebakan, makin besar peluang hasilnya terasa meleset.

Di sinilah banyak orang salah paham. Mereka kira yang penting itu prompt harus terdengar pintar. Padahal sering kali yang lebih penting bukan kata kata keren, tapi informasi dasar yang bikin arah kerjanya jelas.

Konteks apa aja yang sebenarnya berguna?

Konteks yang berguna itu bukan berarti kalian harus nulis satu esai panjang sebelum mulai.

Yang berguna biasanya hal hal ini:

• project ini jenisnya apa
• kalian lagi ngerjain tujuan apa sekarang
• batasan apa yang harus dijaga
• file atau area mana yang sensitif
• hasil seperti apa yang kalian pengen

Contohnya, beda sekali antara bilang, “tolong bantu login error,” dengan bilang, “ini project admin dashboard kecil, saya cuma mau cari akar masalah login tanpa ubah flow utama.”

Kalimat kedua kasih pegangan.

Claude jadi tahu konteks kerjanya lebih sempit. Dia tahu targetnya diagnosis dan fix kecil. Dia juga tahu ada batasan penting: jangan ubah flow besar.

Kalau kalian kerja di project yang punya bagian rawan, bilang juga. Misalnya ada folder lama yang jarang disentuh, ada config produksi yang sensitif, atau ada deadline yang bikin kalian cuma butuh solusi aman dulu.

Info seperti itu kecil, tapi efeknya besar.

Pendek boleh, yang penting jelas

Kadang orang takut kasih konteks karena ngerasa harus panjang.

Padahal tidak.

Yang bikin konteks berguna itu bukan panjangnya. Yang bikin berguna itu kejernihannya.

Brief singkat yang jelas sering jauh lebih membantu daripada prompt panjang yang muter muter tapi nggak bilang inti masalahnya.

Kurang jelas: “Tolong bantu cek project ini”

Lebih kebaca: “Project ini API kecil buat inventaris toko. Saya lagi cari kenapa login admin gagal setelah submit form. Tolong jelasin dulu akar masalahnya, lalu usulkan fix paling kecil tanpa ubah flow utamanya.”

Lihat bedanya.

Versi pertama bikin Claude harus menebak semuanya dari nol.

Versi kedua langsung ngasih peta kecil:

• jenis projectnya apa
• masalahnya di mana
• bagian proses mana yang sedang terjadi
• urutan bantuan yang diinginkan
• batas perubahan yang aman

Itu sudah lebih dari cukup untuk bikin responsnya naik level.

Contoh briefing yang lebih enak dibaca Claude

Kalau kalian bingung mulai dari mana, anggap saja kalian lagi briefing partner kerja baru yang belum kenal project kalian.

Bukan berarti kalian harus jelasin semuanya. Cukup kasih hal yang paling menentukan arah.

Contoh sederhana:

Project ini dashboard internal buat tim operasional.
Saya lagi fokus cari kenapa export laporan sering gagal.
Tolong baca dulu file yang paling relevan, jelasin akar masalah yang kamu curigai, lalu kasih saran perbaikan paling kecil.
Kalau ada bagian yang berisiko nyentuh flow lain, kasih tahu dulu sebelum usul perubahan.

Brief seperti ini enak karena padat, tapi nggak kabur.

Claude tahu medan kerjanya. Kalian juga tetap pegang kontrol.

Dan ini penting: konteks bukan ritual sekali jadi. Kalau di tengah jalan arahnya berubah, kalian boleh tambah konteks lagi. Itu bukan berarti kalian gagal kasih prompt dari awal. Itu tanda kalian lagi kerja beneran, bukan lagi main tebak tebakan.

Penutup

Kalau kalian merasa hasil Claude kadang nggak pas, mulai cek lagi dari hal paling dasar: apakah konteks yang kalian kasih sudah cukup buat bikin arah kerja jelas?

Sering kali, perbaikannya bukan ganti model, bukan ganti tool, dan bukan nulis prompt yang terdengar canggih. Cukup kasih briefing yang lebih manusiawi dan lebih tajam.

Setelah konteks beres, tantangan berikutnya biasanya beda lagi.

Bukan soal kurang jelas, tapi soal task yang kalian kasih kegedean.

Dan itu yang bakal kita bahas di tulisan berikutnya.