6 Claude Code habits that stop it from getting dumber
The full guide from the video. Commit after every task, plan before you prompt, start a fresh chat for each task, cut your CLAUDE.md in half, have one agent review another, and make Claude prove its work. Every prompt is ready to copy.
These are the six habits from the video, with the exact prompts I use for each one. Five of them come straight from Anthropic's own best practices for Claude Code, and the first one is how Google ships code. Both are linked at the bottom.
1. Commits are save points
Commit after every single task. Each commit is a save point you can go back to. If Claude hallucinates its way through a refactor and breaks the app, you roll back one commit and lose ten minutes. If the whole day is one massive commit, rolling back the broken part means throwing away everything that worked too.
Google's engineering guide asks for small changes for the same reason. A small change is easier to review, and it's a lot easier to roll back.
## Commits
When you finish a task and the checks pass, commit right away with a short message that says what changed. One task per commit. Never bundle unrelated changes into the same commit.# find the commit that broke it
git log --oneline
# undo just that one, keep everything else
git revert <commit>2. Plan before you prompt
Explore, write a spec, then code. Anthropic's docs warn that letting Claude jump straight to coding can produce code that solves the wrong problem. Press Shift+Tab until the status bar says plan mode. In plan mode Claude can read your files and answer questions, but it can't change anything.
Have it explore the code first, then write the plan to a file. Read the plan and fix it before a single line gets written. Changing a plan takes a minute. Undoing the wrong feature can burn the whole session.
Don't write any code yet. First read the files involved in [the feature] and explain how they work today. Then write a plan to PLAN.md: which files change, how the data flows, the edge cases, and how we'll test it. Ask me about anything you're unsure of. Then stop and wait for me to approve the plan.3. New task, fresh chat
Protect your context window. It's your most valuable resource. Every file Claude reads, every failed attempt, and every correction stays in it. Anthropic's docs say performance drops as the window fills, and Claude starts forgetting earlier instructions and making more mistakes.
After about three rounds of fixing the same thing, the window is full of dead plans and bad code, and the model gets noticeably dumber. Anthropic's rule is that if you've corrected Claude more than twice on the same issue, you run /clear and start over with a better prompt.
So run /clear between tasks. Right before you do, have Claude write down what it learned, so the next chat starts with the useful parts and none of the junk.
We're about to start a fresh chat. Write a short handoff to HANDOFF.md: what we were doing, what's finished, what failed and why, and the exact next step. Leave out anything the next session doesn't need.4. Delete half your rules
Audit your CLAUDE.md file. Anthropic's test for every line is one question: would removing this cause Claude to make mistakes? If deleting a line doesn't cause an immediate mistake, delete it.
Lines like "write clean code" or "follow best practices" don't change anything Claude does. They take up space, and Anthropic says a bloated CLAUDE.md makes Claude ignore your actual instructions. Keep the rules that only apply to your project, like your package manager, your test command, and the folders it should never touch.
Read CLAUDE.md. For every line, ask whether removing it would make you do something wrong in this codebase. Make a table with three columns: the line, keep or cut, and why. Cut anything vague, anything you'd do anyway, and anything that repeats another line. Show me the table before you change the file.5. AI reviews AI
Use two coding agents. One drafts the architecture, then you spin up a second one in its own chat to act as a staff engineer and tear the plan apart. Anthropic calls this the Writer/Reviewer pattern. The reviewer does a better job because it starts with a clean context and didn't write the plan, so it has nothing to defend.
Paste the review back into the first chat and have it fix every issue before it starts building.
You're a staff engineer reviewing a plan someone else wrote. Read PLAN.md and find what will break: security holes, edge cases, race conditions, things that won't scale, and anything simpler that would do the same job. Rank each issue by how bad it is and say how to fix it. Don't rewrite the plan, just review it.6. Proof before finish
Give it a way to verify its own work. It's the first habit in Anthropic's best practices, and they say it's the difference between a session you have to watch and one you can walk away from.
Claude stops when the work looks done. It assumes it succeeded until a real test script proves it failed. So wire in Playwright or a headless browser MCP, and make it run a real test against the app before it's allowed to say done. When a test fails, it reads the error and fixes it on its own.
claude mcp add playwright npx @playwright/mcp@latestBefore you tell me this is done, prove it. Write a Playwright test that goes through the feature the way a user would, run it against the running app, and show me the output. If anything fails, fix it and run the test again. Only say done when the test passes.
