Two people can run the same Claude Code session on the same task and get very different afternoons out of it.
A session is the real unit of work, one focused stretch of you and the agent going back and forth and building. Treat each one with a little structure and the tool feels great. Treat every session like a free for all and it slowly turns on you. Here's how I keep mine on the rails.
Decide what one session is for before you start
The biggest mistake people make is opening a session with a vague goal and just vibing outward from there. "Improve the dashboard" is not a session. "Add a date filter to the dashboard table" is. Pick one outcome small enough that you'd recognize the exact moment it's done, and make that the whole job. When you catch yourself three unrelated tangents deep in the same conversation, that's not productivity, that's drift, and drift is where sessions go to die.
One outcome per session also makes everything downstream easier. Easier to review, easier to commit, easier to throw away if it goes wrong. Scope is the lever that controls all the others.
Plan before you prompt
For anything past a trivial change, do not just ask and let it rip. Use plan mode, where Claude Code reads your code and lays out what it intends to do before it changes a single file. No edits hit disk until you approve the plan. You press Shift+Tab to get into it.
This is the highest leverage habit in the whole workflow and it's the one beginners skip the most. Reading a plan takes thirty seconds. Catching a wrong approach in that plan saves you the twenty minutes of letting it build the wrong thing, plus the cleanup, plus the second attempt. When the plan looks off, you're not stuck, you just tell it what's wrong and it revises before any damage is done. Cheap to steer at the plan stage, expensive to steer after the edits land.
Read the diffs, don't rubber-stamp them
Claude Code asks for your approval before it changes files, showing you the exact edit each time. That approval prompt is not a speed bump to mash through, it's the whole point of staying in control. Actually look at what it's about to do. Most of the time you'll wave it through in a second, but the times you don't are exactly why you're there.
The trap is "accept all" mode, where it stops asking and just goes. It feels amazing for about ten minutes and then you realize you have no idea what changed across the last fifteen edits, and one of them quietly did something you didn't want. There's a place for accept-all, on tiny mechanical stuff you fully understand, but in a normal building session, watching the diffs is how you keep the session honest. The moment you stop reading them, you're not running the session anymore, it's running you.
Commit to Git at every green checkpoint
This one habit will save you more grief than any other. Every time the session reaches a spot where things actually work, a feature does its thing, the tests pass, the page loads, commit it right then. Claude Code is happy to do this for you, just say "commit this" and it writes the message and all. Git operations are just part of the conversation.
Why it matters so much: AI sessions can go sideways fast, and when one does, a recent commit is your undo button. You roll back to the last good state and you've lost five minutes instead of an hour. People who commit constantly experiment fearlessly because they can always get back. People who go a whole session without committing are one bad approve away from a genuinely bad afternoon.
Clear the context when the topic changes
Within one session, all the back and forth stays in the conversation, which is exactly what you want while you're on one thing. The second you finish that thing and move to something unrelated, that history turns from helpful into clutter. Old details about the last task start bleeding into the new one and the tool gets vaguer and worse. Type /clear to wipe the slate and start the next task clean. It clears the conversation history so you get a fresh head.
Rule of thumb, one task per conversation. When you notice the answers getting mushy late in a long session, it's very often just a stale, overstuffed context, and a clear fixes it instantly. Don't try to ride one heroic mega-conversation all day.
Make it prove the work, don't take its word
Claude Code will happily tell you it's done. Done and working are different claims. Part of running a good session is closing the loop, ask it to run the tests, open the page, hit the endpoint, whatever actually demonstrates the thing works. It can run those commands and see the results itself, so put that to use instead of trusting the confident summary. A session isn't finished when the agent says it's finished, it's finished when you've watched the thing actually do its job.
Know when to stop and start over
Sometimes a session just gets stuck. Same bug, third or fourth lap around, each "fix" breaking something new, the context now a swamp of failed attempts. When you feel that spiral, the move is not to keep grinding in the same conversation, because at that point the pile of dead ends in the context is actively making things worse. Bail out. Roll back to your last good commit, run /clear or start a fresh session, and come at the problem clean with a tighter prompt, maybe broken into smaller pieces. A fresh start beats a poisoned context almost every time, and learning to spot the spiral early is a skill worth building.
The TLDR version
One outcome per session. Plan before you prompt. Read the diffs instead of rubber-stamping them. Commit every time you're green. Clear your context when the topic changes. Make it prove the work, and when a session spirals, start fresh instead of grinding. None of this slows you down, it's what lets you actually move fast without the wheels coming off.
And keep in mind this is all about running the build well, which is a separate thing from whether what you built is ready for real users. That's its own conversation, the one about how "it runs" and "it's done" are different sentences, and it pairs with the questions worth asking before you ship anything.
Sources
Claude Code Common Workflows (official documentation) - Plan mode, where Claude Code reads your code and proposes a plan while making no edits to disk until you approve, and the Shift+Tab toggle used to enter it.
Claude Code Quickstart (official documentation) - Git operations handled conversationally inside Claude Code, the permission prompt that shows each change and asks before modifying files along with accept-all mode, and the /clear command for clearing conversation history between tasks.
