I Thought I Knew Claude Code. Then I Learned How Advanced Users Actually Run It

Source: Image by the authorAfter publishing my Claude Code setup checklist, I made a mistake my checklist couldn’t prevent.I turned on /effort max for a complicated architecture decision. And it worked.Claude slowed down, explored different approaches, compared trade-offs, and gave me the...

Source: Image by the authorAfter publishing my Claude Code setup checklist, I made a mistake my checklist couldn’t prevent.I turned on /effort max for a complicated architecture decision. And it worked.Claude slowed down, explored different approaches, compared trade-offs, and gave me the deeper reasoning I actually needed.The problem came after. I forgot to turn it off.For the rest of the afternoon, I used the same setting for small fixes, simple changes, and tasks that never needed that much thinking. By the end of the day, I had burned through far more usage than necessary.My setup checklist didn’t catch this. And it wasn’t supposed to. That checklist solved a different problem: making Claude Code safer, cleaner, and easier to work with.But once your environment is ready, a new challenge appears. How do you actually operate Claude Code efficiently every day? That question pushed me beyond the basic setup and into the habits that experienced Claude Code users rely on after the foundation is already in place.The small decisions around reasoning levels, context, workflows, and daily usage that don’t matter much on day one — but completely change the experience once Claude Code becomes part of your real engineering process.These are the next ten things I changed.1. Stop Running One Claude Session at a TimeFor months, I used Claude Code the same way I used every other coding assistant.One session. One task. Wait for it to finish. Then move to the next thing.It worked, but I eventually realized I was still creating the bottleneck.Claude could work faster than I could hand it tasks.The bigger shift came when I stopped treating Claude like one assistant and started running multiple isolated sessions in parallel.Each session gets its own git worktree, which means one agent can investigate an authentication bug while another explores a refactor or writes tests — without touching the same files.For example:claude --worktree # start a session in a fresh, isolated worktreeclaude --worktree auth-fix # name it, so you can find it againclaude --worktree --tmux # launch it in its own tmux sessionThe important part is not just running more sessions. It’s keeping them organized.Multiple agents without structure quickly become chaos.What helped me:give every worktree a clear namecreate shortcuts to jump between themseparate terminal sessions visuallyenable notifications when Claude needs inputRunning five sessions you cannot track is worse than running one. The goal is not having more agents.The goal is managing multiple streams of work without them getting in each other’s way.2. Don’t Manually Repeat the Same Change. Batch ItSome engineering tasks look big, but they are really the same small change repeated many times.Migrating a framework. Updating an API pattern. Changing a dependency. Refactoring the same logic across dozens of files.I used to handle these the normal way:Pick one file. Change it. Test it. Move to the next. Repeat.Even with Claude helping, I was still managing every step manually. That changed when I started batching these tasks.Instead of asking Claude to modify one file at a time, I describe the migration once:> /batch migrate src/ from Solid to ReactThe workflow changes completely.Claude understands the migration, breaks the work into smaller pieces, and distributes them across isolated worktrees.Each agent handles its own part. Each one makes changes. Each one verifies the result. Each one produces something reviewable.Now my job changes from managing every edit to reviewing completed work.That difference matters. For large migrations, the bottleneck usually isn’t writing the code. It’s coordinating hundreds of small, repetitive changes without losing track.Batching turns Claude from a code generator into something closer to a team of focused workers.3. Stop Using Maximum Reasoning for EverythingOne mistake I made with Claude Code was assuming more reasoning always meant better results.It doesn’t.The right amount of thinking depends on the task. A complicated architecture decision and a simple variable rename should not use the same level of reasoning.That’s what /effort controls.> /effort# low# Fastest, lowest reasoning.# Best for tiny fixes, formatting, comments,# simple scripts, and repetitive edits.# medium# Balanced speed and reasoning.# Best for normal development,# debugging, and feature changes.# high# Stronger reasoning before coding.# Best for complex bugs, refactoring,# architecture decisions, and tricky logic.# xhigh# Extra deep reasoning.# Best for difficult engineering tasks,# large codebases, migrations,# and long-running coding sessions.# max# Maximum reasoning budget.# Best when accuracy matters more than cost/speed:# critical fixes, security, production decisions,# and very hard debugging.# ultracode# xhigh reasoning + automatic workflow orchestration.# Lets Claude Code use agent-style workflows for# large multi-step engineering tasks.# Best for big projects, deep codebase analysis,# major rewrites, and autonomous implementation.max is genuinely useful.For a difficult debugging session, a design decision, or a change where mistakes are expensive, the extra reasoning is worth it.The problem starts when you forget it is still enabled. That’s exactly how I ended up using maximum reasoning on routine tasks that never needed it.More thinking is not always better. Sometimes it is just more expensive.The habit that changed my workflow was treating effort level as a decision I make for every session, not a setting I change once and forget.4. Stop Approving Every Step. Build a Safer Environment Instead.My first approach to safety was simple:Block the dangerous things. That’s why I created hooks to prevent commands like force pushes, destructive deletes, and risky operations.And those guardrails still matter. But there was another problem. Once Claude started handling longer tasks, constantly approving every small action became a bottleneck.Review this file. Allow this command. Approve this step.After a while, I wasn’t really adding safety. I was just clicking through interruptions.The better approach was moving supervision into the system itself.claude --enable-auto-mode> /sandboxAuto mode lets safe actions continue automatically while still stopping actions that need attention. The sandbox adds another layer by controlling what the agent can access in the first place.That changes the workflow.Instead of manually watching every move Claude makes, you define the environment where it is allowed to operate.The goal is not removing human review.The goal is reviewing the decisions that matter instead of approving every tiny step along the way. For longer tasks, that difference is huge.5. Don’t Just Let Claude Build. Make It VerifyIf I had to pick the most important habit from this list, it would probably be this one.Give Claude a way to check its own work. Without verification, Claude can produce something that looks complete but still has hidden problems.The code compiles. The explanation sounds right. The implementation looks reasonable. But that doesn’t always mean the solution actually works.A feedback loop changes that. For frontend work, that means letting Claude inspect what it built instead of guessing. If it can open the application, check the UI, and see the result, it can catch problems that would otherwise come back to you.For code changes, I usually add a verification step before considering anything finished:> make this change, then run /simplifyThe idea is simple:Don’t stop at the first working version. Review it. Simplify it. Check whether it matches the rest of the codebase. The exact verification method depends on what you are building.Sometimes it’s:automated testsa browser checka simulatora linteranother review agentThe tool does not matter as much as the habit. Every agent needs a way to answer:“Did I actually solve the problem?” Without that feedback loop, Claude is only generating. With it, Claude can improve.6. Stop Undoing Mistakes. Rewind to a Safe PointOne habit I had to unlearn was reaching for undo every time something went wrong. Undo works when the mistake is obvious.The last edit broke something. The last change was wrong. The last command needs to be reversed. But real coding problems usually don’t happen that way.Most of the time, the change that caused the issue happened several steps earlier. Claude made one edit. Then another. Then another.Everything looked fine until later, when the problem finally appeared. That’s where /rewind is different.> /rewindClaude already creates checkpoints before making changes. Instead of trying to manually undo everything one step at a time, you can return to a previous known state.That matters more than it sounds. Sometimes the best fix is not another prompt asking Claude to repair the damage.Sometimes the best fix is going back to the moment before the wrong path started. Recovering quickly is just as important as building quickly.7. Don’t Remove Permissions. Make Them SmarterOne mistake that is easy to make:Claude asks for approval too often. It gets annoying. So you turn permissions off completely. That solves the interruption problem, but it creates a much bigger one.The better approach is not removing boundaries. It’s making those boundaries more specific.That’s what /permissions is for.> /permissionsInstead of approving the same safe actions again and again, you define what Claude is allowed to do ahead of time.Bash(bun run *)Allow all package scripts.Edit(/docs/**)Allow edits only inside documentation files.Now Claude can move quickly where it should. But it still stops when it reaches something outside those limits. You get fewer interruptions without giving unlimited access.And because those rules live in your project configuration, the entire team works with the same safety boundaries. That’s the balance I try to keep:Don’t slow the agent down with unnecessary approvals. But don’t remove the guardrails that protect you either.8. Automate Repeated Work, But Choose the Right Kind of LoopOnce you trust your Claude Code setup, the next step is obvious:Stop manually starting the same tasks again and again. But not every recurring task should run the same way. That difference matters. For short-term background work, I use /loop./loop 30m /pr-prunerThis keeps a task running locally. Claude wakes up on a schedule, does the work, and keeps checking while that session is active. It’s useful for things you want running while you are still working.But there is one important limitation: Close your laptop, and the loop stops. For work that needs to continue without you, use scheduling instead.> /schedule a daily job that looks at all PRs shipped since yesterday and updates our docs based on the changesScheduled jobs run independently, so they continue even after you step away. That’s where I put things like:documentation updatesPR cleanuprecurring codebase checksThe mistake I made early was treating all automation the same. It isn’t. Some tasks need a temporary assistant sitting beside you. Others need a process that keeps running after you leave. Knowing the difference prevents your “automated” workflow from quietly stopping the moment you close your laptop.9. Stop Keeping Claude Tied to One MachineOne assumption I had early: If Claude was working on something, I needed to stay near my laptop. That turned out to be true far less often than I expected. A lot of the time, Claude doesn’t need constant supervision.It just needs occasional direction. A decision. A confirmation. A small correction when it starts moving in the wrong direction. That’s where moving sessions between environments becomes useful.claude --teleport> /remote-controlI can review progress, approve something, check a failure, or redirect Claude without being sitting in front of my development machine.It sounds like a small convenience. Until the first time a long-running task needs one decision and you are nowhere near your laptop.The goal is not to watch Claude every second. It’s to stay involved only at the moments where your judgment actually matters.10. Stop Treating Claude Code Like a Terminal Chat WindowMost people start Claude Code the same way. Open it. Type a task. Wait for the result. Review what changed. And for interactive work, that makes sense. But eventually you reach a point where Claude Code becomes part of the engineering workflow itself.Scripts. Automation. CI jobs. Multi-repository tasks.At that stage, the normal startup process becomes unnecessary overhead. By default, Claude Code checks project files, settings, and available tools every time it starts. That’s useful when you are sitting there working with it.It’s not always needed when another system is calling Claude automatically. For those cases:claude -p "summarize this codebase" \ --output-format=stream-json \ --bare--bare skips the extra setup process and starts much faster, which matters when Claude is running repeatedly inside scripts or automation.For larger workflows, you can go further. Use --add-dir when Claude needs access to multiple repositories without constantly switching directories.Use /branch when you want to test a different approach without losing your current session. These are not features most people need on day one.But they become important once Claude Code stops being something you manually use and becomes something your engineering process depends on.That is the bigger shift: Claude Code starts as an assistant. Eventually, it becomes infrastructure.The advanced checklist[ ] 1. run 3-5 sessions in parallel, each in its own named worktree[ ] 2. reach for /batch the moment a change touches more than a handful of files[ ] 3. set /effort deliberately per task, and remember to turn max back down[ ] 4. turn on auto mode + /sandbox for anything you'd otherwise babysit[ ] 5. give every domain a real verification loop — Chrome extension, /simplify, tests[ ] 6. reach for /rewind before you reach for manual undo[ ] 7. build a real /permissions allowlist instead of skipping permissions[ ] 8. know the difference between /loop (local) and /schedule (survives a closed laptop)[ ] 9. use --teleport and /remote-control before you assume you need to be at your desk[ ] 10. run scripted sessions with --bare, and --add-dir across reposBefore you go!If you enjoyed this breakdown:Throw some Medium love. A few claps, comments, or highlights genuinely help and let me know what topics you’d like me to explore next.Follow me on Medium and subscribe to get my latest article. Find me on X at @nitinbisht96.This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!I Thought I Knew Claude Code. Then I Learned How Advanced Users Actually Run It was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Generative AI Pub — Published July 13, 2026 at 11:03 UTC — Category: Image AI