Claude Operator: Prompt to Autonomy · 20 min · 140 XP
Plan first, then review the diff
Separate deciding what to do from doing it, and never accept an unread change.
For anything beyond a one-line change, split the work in two: decide what should happen, then let it happen. Claude Code has a plan mode for exactly this — it investigates and proposes without touching files. You can start a session in it with --permission-mode plan, or switch modes inside a session.
claude --permission-mode plan
A plan worth approving names the files it will touch, the check it will run afterwards, and what it is unsure about. A plan that says "I'll refactor the auth module and improve error handling" has told you nothing you can evaluate — send it back and ask which files.
Then review the diff. Not the description of the diff — the diff. The failure mode here is social rather than technical: a confident summary of a change is pleasant to read and reviewing the change is work, so the summary quietly becomes the thing you approve. Read what actually changed, and if it's larger than the plan said, that discrepancy is the most interesting thing on your screen.
Finish by running the project's own checks — the narrowest relevant one, not the whole suite. "Run the tests for the file you changed" is a tighter loop than a full CI run, and a failure points somewhere specific. The project's existing test command is the authority on whether the change worked; Claude's opinion that it looks correct is not.
Practice. Take a small change in your practice project and get a read-only plan first, with files, checks and risks named. Approve it, let one disposable file change, then inspect the diff and write one sentence describing what actually changed. Ask Claude to find and run the narrowest relevant check, and record the exact command and its result.
Loading your workspace…