Begitu kalian mulai nyaman kasih konteks, ngecilin scope, dan iterasi, ada satu tahap yang makin penting: review hasilnya.
Di sinilah banyak orang terbelah jadi dua kubu.
Kubu pertama terlalu percaya. Begitu Claude kasih jawaban yang kelihatan rapi, langsung diambil mentah mentah.
Kubu kedua kebalikannya. Baru lihat output sedikit, langsung ciut duluan. Ngerasa semuanya harus dicek total, seolah setiap kalimat bisa jadi jebakan.
Dua duanya capek.
Jangan telan mentah, tapi jangan panik juga
Review itu perlu. Tapi review bukan berarti kalian harus masuk mode takut.
Tujuan review bukan membuktikan bahwa Claude selalu salah. Tujuannya memastikan bahwa hasil yang keluar benar benar nyambung dengan yang kalian butuhkan.
Kalau kalian masuk ke tahap review dengan mindset panik, kalian malah cepat lelah. Semua terlihat mencurigakan. Semua terasa berat. Akhirnya kalian jadi malas pakai bantuannya sama sekali.
Sebaliknya, kalau kalian terlalu santai dan langsung percaya, kalian bisa kecolongan hal kecil yang nanti efeknya melebar.
Jadi posisi yang sehat itu ada di tengah: tetap cek, tapi cek dengan kepala dingin.
Apa yang perlu dicek duluan?
Kesalahan umum waktu review adalah mencoba memeriksa semuanya dengan intensitas yang sama.
Padahal tidak semua bagian punya risiko yang sama.
Kalau Claude cuma bantu merapikan kalimat dokumentasi, level risikonya beda dengan waktu dia nyaranin perubahan di flow login, billing, atau konfigurasi penting.
Makanya, langkah awal yang lebih waras adalah menentukan dulu bagian mana yang paling pantas dicek duluan.
Checklist cepat:
- Apakah hasilnya nyambung sama request awal?
- Apakah ada asumsi yang nggak pernah saya bilang?
- Apakah solusi ini terlalu besar untuk masalah sekecil ini?
- Kalau saya jalankan, bagian mana yang paling mungkin bikin masalah baru?
Empat pertanyaan ini sudah cukup buat jadi filter pertama.
Kalau lolos dari sini, barulah kalian lanjut lihat detail lain kalau memang perlu.
Cari mismatch, bukan cari sempurna
Kadang orang takut review karena membayangkan mereka harus menemukan semua kesalahan.
Padahal target paling realistis bukan itu.
Yang paling penting dulu adalah mencari mismatch.
Apakah hasilnya sesuai dengan permintaan awal?
Apakah Claude diam diam mengubah arah masalah?
Apakah dia memberi solusi yang terlalu besar padahal kalian minta langkah kecil?
Mismatch seperti ini jauh lebih penting dicari daripada sibuk berburu kesempurnaan di setiap sudut.
Kalau arah dasarnya saja sudah salah, hasil yang rapi pun tetap nggak banyak gunanya.
Sebaliknya, kalau arah besarnya sudah benar, kekurangan kecil biasanya lebih gampang diperbaiki lewat satu dua follow up.
Bagian berisiko pantas dicek lebih dulu
Kalau kalian lagi kerja di area yang sensitif, review harus makin sadar prioritas.
Misalnya:
- login dan auth
- pembayaran
- data penting user
- config produksi
- file lama yang jarang disentuh
Di area seperti ini, jangan mulai dari hal kosmetik dulu.
Lihat dulu apakah Claude menyentuh asumsi yang berbahaya. Apakah ada perubahan yang terlalu agresif. Apakah ada saran yang kelihatannya rapi tapi sebenarnya membuka risiko baru.
Ini bukan soal curiga berlebihan. Ini soal tahu mana bagian yang kalau salah, dampaknya lebih mahal.
Kalau risikonya tinggi, fokus review kalian juga harus naik.
Pertanyaan kecil yang bikin review lebih enak
Kadang review terasa berat karena kalian merasa harus sendirian menilai semuanya.
Padahal kalian bisa pakai Claude lagi untuk bantu menjelaskan output yang tadi dia kasih.
Misalnya kalian bisa tanya:
- “bagian mana dari saran ini yang paling berisiko?”
- “kenapa kamu pilih pendekatan ini, bukan alternatif yang lebih kecil?”
- “kalau saya mau cek satu bagian dulu, menurutmu bagian mana?”
- “apakah ada asumsi yang kamu buat tanpa saya bilang langsung?”
Pertanyaan seperti ini bikin review lebih ringan karena kalian nggak cuma membaca hasil. Kalian juga memaksa alasan di balik hasil itu naik ke permukaan.
Dan begitu alasannya kelihatan, kalian lebih gampang memutuskan: lanjut, revisi, atau stop dulu.
Penutup
Review yang sehat itu bukan soal curiga ke semuanya, dan juga bukan soal percaya ke semuanya.
Review yang sehat itu soal tahu apa yang harus dicek duluan, tahu mana bagian berisiko, dan tahu kapan sebuah hasil sudah cukup nyambung untuk dilanjutkan.
Mulai saja dari checklist kecil. Cek apakah hasilnya sesuai request. Cek apakah ada asumsi liar. Cek apakah solusinya kebesaran. Cek area mana yang paling rawan.
Kalau itu sudah jadi kebiasaan, kalian nggak akan gampang panik, tapi juga nggak gampang kecolongan.
Dan setelah konteks, scope, iterasi, dan review mulai rapi, tinggal satu langkah terakhir.
Gimana caranya semua ini masuk ke workflow harian yang realistis, bukan cuma jadi teori yang enak dibaca.
