Tuesday, July 21, 2026

Claude Code Tips: Get More Out of Your AI Coding Agent


Claude Code isn't a chatbot you interrupt with questions and wait patiently for answers. It reads your files, runs your commands, edits your code, and works through problems while you watch, redirect, or walk away entirely. That's a fundamentally different way of working — and it means the old habits of "write code, then ask AI to check it" don't get you very far.

Most of what separates a frustrating session from a great one comes down to one thing: managing Claude's context window well. Everything else — how you prompt, when you plan, when you delegate to subagents, when you clear the conversation — is really just context management in disguise. Keep that idea in your back pocket as you read, because it explains almost every tip below.

Give Claude something to verify against

Here's the core problem: Claude stops working when the task looks done. If there's no way to check whether it's actually correct, "looks done" is the only signal it has — which means you become the verification loop, catching every mistake after the fact.

The fix is simple: give Claude a pass/fail signal it can run itself.

  • Instead of "implement a function that validates email addresses," try "write a validateEmail function. Test cases: user@example.com is valid, 'invalid' is not, user@.com is not. Run the tests after implementing."
  • For UI work, paste a screenshot of the target design and ask Claude to implement it, screenshot the result, and compare the two.
  • For bugs, paste the actual error message and ask Claude to fix the root cause and verify the fix, rather than just describing the symptom.

Once that check exists, you can tighten the loop further: set it as a /goal condition so an evaluator re-checks it after every turn, or wire it into a Stop hook so the session literally can't end until the check passes. Reviewing evidence (test output, a screenshot, a green build) is also just faster than re-verifying everything yourself.

Explore, then plan, then code

Letting Claude jump straight into writing code is how you end up with a correct-looking solution to the wrong problem. For anything nontrivial, separate the three phases:

  1. Explore in plan mode — Claude reads and answers questions without touching anything.
  2. Plan — ask for a concrete implementation plan. You can even pop it open in your editor (Ctrl+G) and edit it directly before Claude proceeds.
  3. Implement — switch out of plan mode and let Claude build against the plan, running tests as it goes.

That said, planning has overhead. If you could describe the diff in one sentence — fix a typo, rename a variable, add a log line — skip the ceremony and just ask directly. Planning earns its keep when you're unsure of the approach, the change spans multiple files, or you don't know the code well yet.

Treat context as your scarcest resource

Every file Claude reads, every command output, every back-and-forth message eats into the same window. Performance quietly degrades as that window fills — Claude starts "forgetting" earlier instructions and making more mistakes. A few habits keep this in check:

  • /clear between unrelated tasks. Don't let a debugging session and a documentation request share the same context — it's the single biggest cause of a conversation that "went weird."
  • Delegate research to subagents. A prompt like "use subagents to investigate how our auth system handles token refresh" runs the exploration in a separate context and reports back only the summary, keeping your main conversation clean.
  • Correct early, and don't loop forever. If you've corrected the same mistake twice, the context is now cluttered with failed attempts. Cut your losses: /clear and write a sharper prompt that includes what you learned, rather than trying to argue Claude out of a bad approach a third time.
  • Use /btw for side questions. It answers in a dismissible overlay that never joins the conversation history — useful for a quick detail check that shouldn't cost you context later.

Turn down the interruption dial

By default, Claude asks permission before anything that could modify your system — every file write, every shell command. Safe, but by approval number ten you're not really reviewing, you're just clicking. Three ways to fix this, in order of how much control you give up:

  • Permission allowlists for commands you already trust, like npm run lint or git commit.
  • Auto mode, where a separate classifier reviews each action and only blocks the genuinely risky stuff — scope escalation, unfamiliar infrastructure, anything that smells like it was steered by hostile content in a file Claude read.
  • Sandboxing, which adds OS-level isolation on filesystem and network access, so Claude can move faster inside a boundary you've already defined.

Build a setup that compounds

A handful of configuration choices pay off across every future session, not just the current one:

  • Write a CLAUDE.md. This file loads automatically at the start of every conversation. Run /init to generate a starting point from your codebase, then prune it ruthlessly — bloated instructions get ignored, and a rule that keeps getting missed is a sign the file is too long, not that Claude wasn't listening. Put in things Claude genuinely can't infer (non-standard bash commands, house style, repo etiquette); leave out anything it could figure out by reading the code.
  • Add skills for anything situational. If it doesn't apply to every session, it doesn't belong in CLAUDE.md — it belongs in a SKILL.md under .claude/skills/, which Claude loads only when relevant.
  • Use hooks for zero-exception rules. CLAUDE.md is advisory; hooks are deterministic. If something must happen every single time — running a linter after every edit, blocking writes to a migrations folder — a hook guarantees it in a way a written instruction can't.
  • Create subagents for repeated specialist work. A security-reviewer or debugger subagent with its own restricted toolset keeps that kind of work out of your main context permanently, not just once.
  • Connect MCP servers for the tools you already live in — Notion, Figma, your database — so Claude can act on them directly instead of working around them.

Rewind instead of being careful

Every prompt you send creates a checkpoint. That changes the right level of caution: instead of triple-checking before every risky change, you can just try it. Double-tap Escape (or run /rewind) to restore conversation, code, or both to any earlier point — and checkpoints persist even after you close your terminal. It's not a replacement for git, but it makes "let's just try it and see" a much cheaper move than it used to be.

Scale past one conversation

Once single sessions feel natural, the real leverage is running more than one at a time:

  • Worktrees let you run separate CLI sessions in isolated git checkouts so parallel edits don't collide.
  • A Writer/Reviewer pattern — one session implements, a second (with fresh, unbiased context) reviews the diff — catches things a single session won't, because the reviewer isn't attached to the reasoning that produced the code.
  • Non-interactive mode (claude -p "prompt") drops Claude into CI pipelines, pre-commit hooks, or scripts, with JSON output you can parse programmatically.
  • Fan-out across a large batch — say, migrating two thousand files — by having Claude generate the file list, then looping claude -p over it with --allowedTools scoped tightly, since you're running unattended.

The quick-fire list

If you only take five things from this article:

  1. Give every task a way to verify itself — a test, a build, a screenshot.
  2. Plan before you implement anything you couldn't describe in one sentence.
  3. /clear between unrelated tasks; don't let context rot.
  4. Push repeated research into subagents so your main conversation stays clean.
  5. Checkpoints mean you can afford to try the risky thing — and rewind if it doesn't work.

None of this is a rigid formula. Some sessions genuinely benefit from letting context pile up because you're deep in one hard problem. The goal isn't to follow every rule — it's to notice, over time, what made a given session go well, and do more of that.

You can buy the book about Claude Code here.

No comments:

Search This Blog