Last Updated on July 10, 2026
I have been working in cloud architecture for over twelve years. In the last two, Claude Code has become one of the most important tools in how I work — not as a convenience, but as something that has genuinely changed what I can accomplish and how fast. I use it every day, across client work, side projects, and building my own agentic systems.
That means I have also made most of the mistakes there are to make with it. The thing I keep coming back to is this: the way most people use Claude Code is the reason they are not getting more out of it. They treat it like a tool you pick up and put down. It works better when you treat it like a relationship: something you build, configure, and manage over time.
Here is what I have figured out.
Start with plan mode, every time
There is a command in Claude Code called /plan. When you run it, Claude enters a conversation-only mode. It will not write files, run commands, or modify anything. It will only talk with you.
This is where the most important work happens.
When I pick up a new project or a complex task, I do not jump straight to execution. I open plan mode and I talk. I tell Claude everything: the context, the constraints, what I am trying to accomplish, what I have already tried, what I am worried about. I ask Claude to set up a council of domain experts relevant to the task and interview me through their lens. That sounds unusual, but it works. The questions surface gaps in my thinking that I would not have found on my own.
Once I have built the full picture, Claude generates a plan. Then I read it. The whole thing. There is no shortcut here. You have to spend time with the plan before you approve it. That patience is what determines whether what comes next is useful or just fast.
Try talking instead of tying
The transcription button in Claude Code is underused. I use it constantly.
When I type out a thought, I edit myself. I compress it. I leave out context because it feels obvious. When I speak, I do not do that. I explain naturally, I follow tangents that turn out to matter, I include the “by the way” details that end up being the most important things Claude needs to understand.
I work from home. When I have to go somewhere, an airport or a library, and I cannot speak out loud, I genuinely feel the constraint. Dictating is not a convenience feature. It is the difference between giving Claude a job posting and actually onboarding someone.
Treat Claude Code like a new hire, not a tool
The analogy I keep coming back to is onboarding. When you bring on a new employee, you do not just hand them a task and walk away. You give them context: what the team does, how decisions are made, what the work culture is, where the files live, what success looks like.
Claude Code has the equivalent of all of this. The CLAUDE.md file is the job description. It defines what Claude should know and how it should behave in that workspace. Every work environment I run has one. I use them to set language profiles (British English with pounds for UK clients, different register for social media versus business proposals), define workflow rules, and establish what Claude should capture and store versus what it can let go.
If you skip the onboarding, you will keep re-explaining the same context. That is not Claude Code failing. That is you managing without documentation.
Manage your context window aggressively
Bigger context windows sound like a straightforward advantage. They are not.
The larger the context window grows, the more factors the model has to weigh with every response. Quality degrades. I have seen it consistently: a fresh, focused context produces sharper output than a long, sprawling one.
My rule is to keep the context window as tight as possible for as long as possible. When a conversation accumulates too much (background, tangents, resolved decisions), I summarize it down. I extract the high-value signal into a document and let the rest go. Claude starts the next session reading that document rather than carrying the whole previous session.
This is uncomfortable at first because it feels like losing work. You are not. You are keeping the model sharp.
Know when to use Claude Code versus Claude Chat
I use Claude Chat for one-time tasks that do not have a future. If I need to reply to a complex email, I go to Claude Chat, give it the thread, ask for a draft, send it. Done.
I use Claude Code when I know I will come back. Even if it seems like a one-off, say drafting that same email, if there is any chance the project behind it continues, I want the persistent context. I want Claude to remember what we built, what decisions we made, what the next step was.
The question I ask myself is: is this a transaction, or a relationship? Transactions go to Chat. Relationships go to Code.
Do not let agents run without a job description
I have been building what I think of as a chief of staff in Claude Code. It is an agent that manages the different areas of my life (work, volunteering, side projects, personal commitments), each handled by a sub-agent with its own access, persona, and context.
When it breaks, and it has broken, the cause is almost always the same: I did not give the agent a clear enough boundary. I did not specify what it had access to, who was allowed to talk to it, and what protocol it should follow when another agent made a request. My work agent should not be able to query my personal agent about what is in my bank account. That sounds obvious. But without explicit guardrails, the agents will happily share whatever is accessible.
The fix is the same as the setup: treat each agent like an employee. Write the job description. Define the scope. Specify the escalation protocol.
Decide where you need to be in the loop
Not every agent task needs your approval before it executes. Some do.
My rule: if something is reversible, I can be out of the loop. Reading an email, compiling a research summary, drafting a post, let the agent handle it. If something is irreversible (sending an email, modifying a system, publishing something), I want to approve it first.
I call this being “human in the lead” rather than human in the loop. In the loop means you are giving direction constantly. In the lead means you have set the systems up correctly, you are monitoring, but you are not interrupting. You are the manager who does not get their hands dirty but knows what their team is doing.
The architecture changes depending on which mode you need. For irreversible actions, build in an approval step. For reversible ones, let it run. Getting in the loop there is just wasting time.
What this looks like in practice
Right now, my setup is a harness that functions as the chief of staff, fed by sub-agents that each own a slice of my life. I give the harness a prompt, it routes to the right agent, the agent acts within its permissions. I stay mostly in the lead unless something requires my sign-off.
Getting here took time. The agents broke. The guardrails were wrong. The context windows bloated. I learned from all of it.
The consistent theme: Claude Code rewards the same thing good management rewards. Clarity about roles, explicit expectations, and patience with the setup phase so the execution phase does not require you to be everywhere at once.
Most people use AI for one-time tasks a hundred times and wonder why nothing has changed. The shift happens when you stop asking Claude to do a thing and start giving Claude a job. If you want to go deeper on how to build that kind of setup in production, that is the core of what the AI Engineering with Claude Nanodegree program covers.
