Know when to use Claude Code
Chat thinks it through. Claude Code makes it real.
Two Claudes, two jobs. One thinks with you and hands you words. The other opens your project and changes it. Ask the wrong one to do the other's job, and you'll walk away with a confident paragraph instead of a changed file, and not notice the gap until someone else does.
14 min · You'll watch Claude Code make one real change, then know when to reach for it yourselfYou'll sort one real task into the right hands, Claude chat to think or Claude Code to change files, then name the proof that makes a confident "done" real.
Before you start
Complete Pick the tool from the work first if you use multiple AI tools.
The idea
Two Claudes, two jobs. Claude chat is a thought partner: it thinks with you, drafts with you, decides with you. Claude Code is the one that actually touches your files, runs commands, and shows you what changed. Ask the wrong one to do the other's job, and you'll walk away with a confident paragraph instead of a changed file.
| Claude chat | Claude Code | |
|---|---|---|
| Best output | Brief, memo, plan, analysis | Changed files, command results, review |
| Input shape | Notes, docs, screenshots, questions | Repo, issue, route, target behavior |
| Action | Think, draft, organize | Inspect, edit, run, verify |
| Proof | Source list, approval, final text | Diff, tests, build, rendered route |
Start Claude Code when the work must change files.
Here is the trap this lesson defuses. You ask an AI to update your pricing page, and it replies, in a calm confident paragraph, that the change is live. You tell your client it is done. Next morning the old headline is still there, because the file was never actually changed. The skill is knowing which jobs need proof you can point at, and refusing a confident "done" until you see it.
See the difference. Ask the same kind of question in Claude chat first, and watch what it can and cannot do.
Claude chat cannot open or edit your project. It is the right tool for thinking a plan through, drafting the words, or deciding what to build, before any file changes. Claude Code is for the moment after that. It reads files, edits files, and runs commands, on the real project.
Proof is what you can check after it acts. For Claude Code it is usually one of three things.
A diff (the before and after of a file). The output of a command it ran. Or the finished page, rendered (drawn on the screen) so you can look at it.
Worked example. Say the headline on your pricing page is wrong. You open Claude Code and type your instruction.
Claude Code v0.0.0
Sonnet (200K context) · Claude Pro
~/project
I'll update the pricing page headline. - "Simple, honest pricing" + "Pricing that grows with you" Approve this edit? (y/n)
First it shows you the exact edit and waits, the old line (Simple, honest pricing) next to the new one (Pricing that grows with you). Nothing changes until you approve. That side by side is your first proof, and you read it with your own eyes instead of taking its word.
You approve, and it runs the build (the step that turns the code into the working site) on your own computer. Then it hands you a local link, like localhost:3000, that opens the running page so you can see the new headline for real.
It works because you named three things, so nothing was left to guess. The target (the pricing page), the one change (the headline), and the proof (the changed file and the running page).
Start Claude Code with a target, the change, and the proof that marks it done. Then make it show you that proof before you accept a word of it.
Watch
You type this
Open the pricing page, change the headline to our new line, then show me the changed file and the page running.
Claude does this
First it shows you the one edit it wants to make and waits. Nothing changes until you approve it. Then it runs the build on your own computer and hands you a local link, like localhost:3000. You open it and see the changed file and your new headline live, so you are checking proof, not trusting a story.
Why this works
- Open the pricing page
you named the target, so Claude Code knows exactly where to look instead of guessing which file you mean.
- change the headline to our new line
you named the one change, so it makes that edit and nothing else widens.
- show me the changed file and the page running
you named the proof, so the session ends with something you can check, not a confident story.
Your turn
The proof to ask for
You cannot see this fix just by looking at the page, the way you could with a headline. So what could Claude Code show you that proves the rule actually works now?
Show one good answer
show me it try to submit a blank email and get refused, and a real email get through. Seeing the rule hold is the proof, because a screenshot of the form would look the same either way.
On your own
Pick one real task on your plate this week and write its ownership card in four short lines. Line one, the owner (Claude chat to think it through, or Claude Code to change files). Line two, the first file or page Claude Code should inspect. Line three, the one piece of proof you would demand before calling it done. Line four, the confident "done" you would refuse without that proof.
- I wrote who owns it, and why
- I named where Claude Code should look first
- I named one piece of proof I could actually check
- I said what "done" I would refuse without proof
Write your own
Loading your workbook…
When this breaks
- Breaks when the task is really strategy or writing work, because Claude Code will look for files to change.
- Breaks when no proof is named, because the session can end with a plausible story instead of checked work.
You can now
You can tell when Claude Code should own a task, and when chat should
- You can keep planning work in chat until the repo task is clear
- You can name the first files or page to inspect
- You can name the proof you would demand before you accept a change
Try it from memory
Pulling this out of your own head now is the part that actually moves it into long-term memory. Re-reading just feels like it does.
Without scrolling up, finish this in your own words. A confident "done" is not proof until it shows me one of three things, which are what? And for one task on my plate this week, the proof I would ask for is what?
Tap to see one good answer
The three proofs are a diff (the file's before and after), the output of a command it ran, or the page rendered so you can see it. Which one you ask for depends on the task. A wording change you can see on the page. A hidden rule, like an expired discount code that should be refused, you ask it to show working, because the page would look the same either way.
Key takeaways
Claude Code owns changed files and the proof they happened. Refuse a confident "done" until you see a diff, a command result, or the page itself.
- A confident "done" is a claim, not proof. Make it show you a diff, a command result, or the page rendered.
- Use Claude Code when the finished work is changed files. Use Claude chat when it is a brief, plan, or decision.
- Some fixes are invisible on the page, so ask it to show the rule working, not just a screenshot.
- Name the target, the change, and the proof up front, so nothing is left to guess.