Plan Mode — Tinjau Pendekatannya Sebelum Satu Baris pun Berubah

Claude itu cepat. Justru itulah masalahnya. Pada tugas yang tidak sepele, ia bisa dengan percaya diri menyunting delapan berkas ke arah yang salah sebelum Anda selesai membaca kalimat pertamanya — dan kini Anda malah membatalkan perubahan yang setengah jadi alih-alih merilisnya. Plan mode memperbaiki ini dengan memecah pekerjaan menjadi dua: pertama Claude meneliti dan mengusulkan, Anda meninjau dan mengoreksi, baru setelah itu ia membangun. Anda menangkap pendekatan yang salah saat harganya baru satu pesan, bukan satu jam.

Inti Utama

Pisahkan "apa rencananya?" dari "kerjakan." Setujui pendekatannya selagi masih berupa kata-kata — karena kata-kata gratis untuk diubah, sedangkan kode tidak.

Apa sebenarnya plan mode itu

Plan mode adalah mode read-only. Selama aktif, Claude bisa menjelajahi codebase Anda — membaca berkas, mencari, menelusuri jalur pemanggilan — tetapi ia secara fisik tidak bisa menyunting, menulis, atau menjalankan perintah yang mengubah apa pun. Ketika sudah punya rencana, ia menyajikannya dan menunggu persetujuan Anda sebelum menyentuh apa pun.

Kata "secara fisik tidak bisa" itulah inti seluruhnya. Menyuruh Claude "buat rencana dulu" hanyalah permintaan sopan yang mungkin ia lewati begitu saja. Plan mode adalah pengaman — ia mencabut kemampuan untuk bertindak, sehingga rencana dijamin datang sebelum kode.

Cara masuk ke plan mode

• Beralih di tengah sesi: tekan Shift+Tab untuk memutar mode permission sampai Anda melihat plan mode aktif (indikator mode menampilkan ⏸ plan mode).
• Mulai sesi langsung di dalamnya: claude --permission-mode plan.

Saat Claude selesai meneliti, ia memunculkan rencananya dalam sebuah prompt persetujuan. Anda lalu:

• Setujui → Claude keluar dari plan mode dan menjalankan persis apa yang Anda sepakati.
• Minta perubahan → sempurnakan rencananya; tetap nol baris kode yang ditulis.
• Tolak → tidak ada yang terjadi. Tanpa bersih-bersih, tanpa membatalkan apa pun.

Tip: di versi terbaru Anda bisa membuka rencananya di editor (Ctrl+G) dan menyuntingnya langsung sebelum menyetujui — sering lebih cepat daripada satu putaran "minta perubahan" bolak-balik.

Di mana posisinya dalam loop inti

Loop profesional adalah explore → plan → code → verify. Plan mode menguasai dua fase pertama dengan aman:

┌─ plan mode (read-only) ─┐        ┌─ normal mode ─┐
│  explore  →  plan        │  →✓→  │ code → verify │
└──────────────────────────┘  ↑    └───────────────┘
                          you approve here

Gerbang persetujuan adalah jahitannya. Segala hal sebelum titik itu, menurut definisinya, bisa dibalik.

Sebelum / Sesudah: demonstrasi hasilnya

Tugas: "refactor auth agar memakai refresh-token rotation."

Tanpa plan mode — Claude langsung mulai menyunting:

> refactor auth to use refresh-token rotation

Editing src/auth/login.ts...
Editing src/auth/session.ts...
Editing src/middleware/auth.ts...
Editing 5 more files...

# ...halfway through you notice it's storing refresh tokens in localStorage
# (should be httpOnly cookies) and touched files you didn't want changed.
# Now you revert 8 half-edited files and start over.

Dengan plan mode — Claude mengusulkan lebih dulu:

> [⏸ plan mode] refactor auth to use refresh-token rotation

PLAN
 1. Store refresh token in an httpOnly, Secure cookie (not localStorage).
 2. Add POST /auth/refresh that rotates + invalidates the old token.
 3. Files to change: auth/session.ts, auth/refresh.controller.ts (new),
    middleware/auth.ts.  (login.ts unchanged.)
 4. Risk: existing sessions invalidated → note migration.
 5. Tests: add refresh-rotation + reuse-detection cases.

Approve this plan?
> No — token store is right, but keep the old refresh endpoint for 1 release
  for backward compat.

Updated plan: adds a deprecation window on the old endpoint. Approve?
> Yes

Anda mengoreksi sebuah kesalahan keamanan sekaligus sebuah kesalahan cakupan sebelum satu berkas pun berubah. Itulah beda antara "cepat" dan "cepat dan benar."

Kapan memakainya (dan kapan melewatinya)

Pakai plan mode untuk:

• Apa pun yang menyentuh lebih dari satu-dua berkas.
• Codebase yang belum familier — biarkan Claude memetakannya sebelum menyuntingnya.
• Perubahan yang berisiko atau sulit dibalik (auth, migrasi, pembayaran, penghapusan).
• Tugas yang pendekatannya benar-benar belum pasti dan Anda ingin beberapa opsi.

Lewati untuk:

• Perbaikan satu baris, salah ketik, atau penggantian nama yang sudah Anda putuskan.
• Tugas yang biaya perencanaannya lebih besar daripada langsung mengerjakannya.

Kebiasaan yang perlu dibangun: kalau naluri Anda berkata "ini lebih dari sekadar suntingan cepat," tekan Shift+Tab dulu. Refleks dua detik yang menghemat berjam-jam.

Mendapatkan rencana yang hebat (bukan sekadar rencana apa adanya)

Permintaan yang samar menghasilkan rencana yang samar. Mintalah struktur. Permintaan rencana yang kuat menyebutkan apa saja yang Anda ingin ada di dalam rencananya:

Plan this. In the plan, include:
- the exact files you'll change (and confirm what you WON'T touch),
- the approach and why, plus one alternative you rejected,
- the order of steps,
- risks / anything that could break existing behavior,
- the test strategy,
- explicitly, what is out of scope.
Don't write any code yet.

(Prompt itu tersedia sebagai berkas siap salin-tempel di artefak di bawah.)

Tips ampuh:

• Arahkan ke jangkarnya. "Ikuti konvensi di CLAUDE.md" — plan mode menghormati konstitusi Anda (Bab 1.1), sehingga rencananya kembali sesuai gaya.
• Minta beberapa opsi. "Beri saya dua pendekatan beserta trade-off-nya" mengubah plan mode menjadi alat desain, bukan sekadar daftar tugas.
• Beriterasi sebebasnya. Menolak rencana itu gratis. Terus dorong sampai benar — di situlah seluruh nilainya.

Tinjau rencananya layaknya seorang reviewer

Rencana itu adalah pull request mini. Sebelum Anda menyetujuinya, periksa:

• Maksud — apakah ia menyelesaikan yang benar-benar Anda minta, bukan hal yang bersebelahan?
• Cakupan — apakah minimal? Ada perubahan sampingan yang perlu dipangkas?
• Berkas — sudah yang tepat, dan tidak ada yang mengejutkan?
• Risiko — apakah ia menyebutkan apa yang bisa rusak, dan menanganinya?
• Test — apakah "selesai" benar-benar bisa diverifikasi?

Kalau ada jawaban yang goyah, mintalah perubahan. Menyetujui rencana yang buruk hanya memindahkan masalah ke hilir. (Checklist lengkap ada di artefak.)

Peringatan

Plan mode adalah gerbang berpikir, bukan stempel karet. Nilainya ada pada review Anda — kalau Anda menyetujui setiap rencana tanpa membacanya, Anda hanya menambah satu langkah sambil tetap menyimpan risikonya. Dan jangan berlebihan memakainya: menggerbangkan perbaikan salah ketik di balik sebuah rencana adalah gesekan demi gesekan belaka. Kalau diff-nya muat dalam satu kalimat, lewati plan mode — overhead perencanaan tidak gratis (lihat praktik terbaik resmi). Pakai di tempat yang pendekatannya memang penting.

Bisa diunduh: Plan Mode Playbook

Di ../../artifacts/plan-mode-playbook/:

Pakai dalam satu baris: tekan Shift+Tab, tempel plan-request-template.md, tinjau dengan plan-review-checklist.md, setujui.