Setelah konteks beres, ada masalah berikutnya yang sering bikin hasil Claude tetap terasa aneh: task yang kalian kasih kegedean.

Ini kejadian umum banget.

Orang merasa sudah briefing dengan lumayan jelas, tapi tetap dapat jawaban yang terlalu lebar, terlalu nebak, atau terlalu susah direview. Pas dilihat akar masalahnya, ternyata yang diminta dari awal memang terlalu banyak.

Banyak orang kalah sebelum mulai

Ada momen waktu orang mulai nyaman pakai Claude Code, lalu rasa percaya dirinya naik cepat.

Itu bagus. Tapi kadang efek sampingnya, mereka langsung kasih tugas yang ukurannya nggak masuk akal buat satu putaran kerja.

Contohnya begini:

• “Refactor semua auth system di project ini.”
• “Audit seluruh codebase dan rapihin yang jelek.”
• “Beresin semua error yang mungkin ada.”

Masalahnya bukan karena Claude nggak bisa bantu sama sekali.

Masalahnya, task seperti itu terlalu lebar. Kalian sendiri nanti susah ngecek apakah hasilnya sudah sesuai atau belum. Bahkan kalau Claude kasih output yang kelihatan rapi, kalian belum tentu tahu itu benar, terlalu agresif, atau malah nyentuh area yang belum perlu disentuh.

Jadi kadang, kekalahan pertama bukan terjadi di hasil akhir. Kekalahan pertamanya sudah terjadi waktu kita nulis permintaan yang terlalu besar.

Kenapa task kegedean bikin hasil kabur

Semakin besar task, semakin banyak hal yang harus ditebak.

Claude jadi harus menebak prioritas. Menebak bagian mana yang harus didahulukan. Menebak seberapa besar perubahan yang aman. Menebak apakah kalian mau solusi cepat, solusi bersih, atau solusi sementara.

Begitu ruang tebakannya membesar, hasilnya juga makin gampang kabur.

Kalian mungkin tetap dapat jawaban. Tapi jawaban itu bisa terlalu umum. Bisa terlalu besar. Bisa juga technically masuk akal, tapi nggak cocok dengan kebutuhan kalian sekarang.

Ini mirip kalian kasih kerjaan ke partner baru dengan kalimat, “tolong beresin semuanya ya.” Secara teori mungkin dia bisa mulai. Tapi hasilnya akan jauh lebih rawan meleset daripada kalau kalian bilang bagian mana yang mau disentuh lebih dulu.

Di kerja teknis, kejelasan scope itu bukan detail kecil. Itu penentu kualitas kolaborasi.

Scope kecil itu bukan cupu

Kadang ada rasa gengsi waktu memecah kerjaan jadi kecil kecil.

Seolah kalau kita minta bantuan cuma untuk satu file, satu function, atau satu bug, berarti kita kurang berani. Padahal justru itu cara kerja yang sehat.

Scope kecil bikin kalian lebih gampang lihat hubungan antara permintaan dan hasil.

Kalau Claude diminta bantu satu flow login, kalian bisa review flow login. Kalau Claude diminta bantu satu file yang bikin export gagal, kalian bisa fokus ke file itu. Kalau hasilnya masih belum pas, kalian tahu tepatnya bagian mana yang perlu ditanya lagi.

Bandingkan dengan task raksasa. Waktu hasilnya datang, kalian malah capek duluan lihatnya.

Jadi jangan anggap memecah task itu kelemahan. Itu strategi biar kerja sama jadi lebih bisa diprediksi.

Patokan gampang buat pemula

Kalau kalian masih bingung ukuran task yang aman itu seperti apa, pakai patokan sederhana dulu.

Mulai dari salah satu ini:

• satu file
• satu function
• satu bug
• satu flow
• satu pertanyaan yang spesifik

Patokan ini membantu karena kalian punya batas kerja yang kelihatan.

Bukan berarti nanti selamanya harus sekecil itu. Tapi untuk bangun ritme yang sehat, itu titik mulai yang enak.

Begitu kalian sudah lebih terbiasa, kalian akan lebih gampang tahu kapan sebuah task masih aman, dan kapan sudah terlalu melebar.

Yang penting, jangan buru buru meloncat ke permintaan yang terlalu besar cuma karena Claude terlihat sanggup. Kalian tetap yang pegang arah kerja.

Contoh minta bantuan yang lebih aman

Beda antara task terlalu besar dan task yang lebih aman sering cuma soal framing.

Terlalu besar: “Refactor semua auth system di project ini”

Lebih aman: “Tolong cek file auth.js ini dulu. Jelasin bagian yang paling rawan bikin login gagal, lalu usulkan perbaikan kecil tanpa ubah struktur besar.”

Versi kedua jauh lebih gampang dikerjakan dan jauh lebih gampang direview.

Ada titik masuk yang jelas. Ada target yang jelas. Ada batasan yang jelas.

Kalau ternyata dari situ ketemu masalah yang lebih besar, kalian masih bisa lanjut ke putaran berikutnya. Tapi sekarang kalian masuk dari pintu yang lebih aman, bukan langsung dobrak seluruh rumah.

Ini juga bikin dialog berikutnya lebih enak. Claude bisa bantu satu lapis dulu, lalu kalian putuskan apakah mau lanjut lebih dalam atau cukup sampai situ.

Penutup

Kalau hasil Claude sering terasa terlalu lebar atau terlalu kabur, coba cek lagi bukan cuma konteksnya, tapi juga ukuran task yang kalian kasih.

Task yang pas bikin hasil lebih gampang dipahami, lebih gampang diverifikasi, dan lebih aman dipakai.

Dan kabar baiknya, kalian nggak perlu langsung jago buat mulai ngerasain bedanya. Cukup biasakan diri untuk mengecilkan scope sampai permintaannya terasa jelas di kepala kalian sendiri.

Setelah itu, tantangan berikutnya bukan lagi soal konteks atau ukuran task.

Tantangannya adalah cara ngobrol setelah jawaban pertama keluar.

Karena kerja bareng Claude yang bagus hampir nggak pernah berhenti di satu prompt doang.