Working with Claude Code

Before You Open a File

Before you write a single line of code, the most important decision you can make is where you're working from. Claude Code is folder-aware: it reads a CLAUDE.md file from your project root and uses it as a permanent briefing. This is how you stop repeating yourself across sessions.

Set up one folder per project. Name it clearly. Inside it, drop a CLAUDE.md that tells Claude: what this project is, what tech stack it uses, what the brand looks and sounds like, and any non-negotiable rules. Then every new session starts with Claude already oriented — no re-explaining.

The session discipline that saves hours

• One project per client or product. One session per task.
• Name your sessions descriptively ("build contact section" not "session 3").
• Use /compact when a session runs long — it summarizes context without losing it.
• When a task is done, start a fresh session. Don't sprawl.

Never start from scratch. Always copy a starter template. It saves 2–3 hours of boilerplate every time — folder structure, CLAUDE.md, config files, the works. The 8-step workflow that works:

1. Copy the template
2. Install dependencies
3. Build one real page (not placeholder)
4. Add sections top-down
5. Add animations last
6. Test at half speed to catch timing issues
7. Test mobile at 375px
8. Deploy

The biggest difference between a good camp week and a frustrating one: spend 30% of your time on the first 3 seconds of the experience. The load sequence sets the tone for everything that follows.

Choosing the Right Model

Claude comes in three tiers. Using the wrong one is like paying a consultant's hourly rate to fold laundry.

Opus — for thinking. Use it when you need taste, judgment, or architectural decisions. Multi-agent competitions, copy strategy, hard debugging, synthesis. If you're deciding what to build or how, use Opus.

Sonnet — for building. Once you know what to do, Sonnet executes it. Routine code edits, find-and-replace, builds, file cleanup, git commits, installs. This should be your default for about 80% of your session time.

Haiku — for repetition. Bulk operations, simple lookups, high-volume formatting tasks. 1/30th the cost of Opus. Perfect for troubleshooting loops where you're running the same check over and over.

The practical pattern most professionals use

Start a session in Opus to do the strategy and architecture. Once you've decided what to build, switch:

/model claude-sonnet-4-6

Switch back to Opus if you hit another decision point. You get Opus thinking and Sonnet execution — the best of both.

Quick decision rule

• Need judgment or taste? → Opus
• Need to execute a clear plan? → Sonnet
• Need to repeat something simple? → Haiku
• Over 20 turns into a session? → Start fresh (cost compounds)

Working Without Wasting Money

Every message you send in a long session re-sends the entire conversation history. That means a session that's 40 turns deep costs twice what a 20-turn session costs — for the same work.

The three habits that fix this

1. Use /compact proactively. Don't wait until the session is painfully long. Every time you finish a meaningful chunk of work, /compact. It summarizes what's been decided and clears the dead weight.

2. Start fresh sessions aggressively. "But I'll lose context" — you won't, if you have a good CLAUDE.md and you summarize the handoff in one message at the start of the new session. "We just finished the hero section. It's using GSAP with clip-path reveals. Now build the about section." That's all you need.

3. Don't spawn subagents for simple tasks. Subagents are powerful but expensive. Before spinning one up, ask: could a grep or a direct question to the main session answer this? If yes, do that. Subagents earn their cost when you need genuine parallelism — three things happening simultaneously that would each take 10+ minutes.

Model routing rule of thumb

• No judgment needed → Haiku or Sonnet
• No parallelism benefit → no subagent
• Over 20 turns → start fresh

Design competitions (multiple agents building different versions) cost 3× normal token usage. Worth it for important work. Not worth it for every iteration.

How to Not Get Stuck in Loops

Claude will sometimes get stuck. It'll try the same fix twice, add the same import three times, or spiral into increasingly complex solutions for a simple problem. This is the most frustrating thing about working with AI — and it's almost always preventable.

Rule 1: Call it out immediately. The moment Claude repeats a fix it already tried, say so explicitly: "You just tried that. It didn't work. Stop and think about why before trying again." This breaks the loop. Don't wait for the third attempt.

Rule 2: Use Haiku for debugging loops. When you're stuck on a bug and running the same check over and over, switch to Haiku. It's 1/30th the cost of Opus and perfectly capable of "try this, check the output, try the next thing" iteration. Save Opus for when you need a genuine insight.

Rule 3: Evidence before action. Before Claude theorizes about what's wrong, make it read the actual evidence. "Read the error log first. Then tell me what you think is happening." This single habit eliminates half of all wasted debugging cycles. Read → theorize → act. Never act → theorize → read.

Rule 4: Don't let Claude install infrastructure to solve simple problems. If Claude suggests installing a new service, configuring a server, or adding a networking layer — pause. The answer to most problems is simpler than the solution Claude proposes when it's stuck. The answer is usually one setting, one command, or one file change.

Running Multi-Agent Competitions

The most powerful thing Claude Code can do isn't run one agent. It's run three agents simultaneously with fundamentally different worldviews — and then synthesize what they found.

Most people approach this wrong. They say: "Agent A, be creative. Agent B, be practical. Agent C, be brief." That produces three flavors of the same answer.

The recipe that works

1. Give them different professions, not different moods. These three always produce something useful:

• A plain-language writer (medical/government background) — protects the reader's understanding
• A product designer (audit and cut philosophy) — protects the reader's time
• A conversion copywriter (emotional state modeler) — protects the reader's emotions

These aren't moods. These are professions with conflicting worldviews. They cannot all be right — and where they disagree is where the insight lives.

2. Give every agent the exact same source material verbatim. No summaries, no interpretations. The same raw input, word for word.

3. Force them to declare reasoning AND output separately. "First explain your thinking. Then write the deliverable." Otherwise you get output without understanding why.

4. Tell them it's a competition. Output improves 15–20% when agents know they're being judged against alternatives.

5. Pre-bias one agent toward the heretical answer. "Your job is to cut everything that doesn't need to be there. Be ruthless." The most interesting insights often come from the agent that was told to destroy things.

6. Synthesize, don't pick a winner. The best output almost never comes from one agent wholesale. It comes from combining the structural clarity of one, the emotional accuracy of another, and the ruthless cuts of the third.

When you're not sure how to set up the competition lenses, ask Claude: "What three conflicting professional worldviews would produce the most interesting tension for this problem?"

When Things Break

Things will appear broken that aren't. Understanding why saves hours of anxiety.

The four-copy problem. When you're developing an app, four versions can exist simultaneously: the source code, the debug build, the installed version, and the browser/WebView cache. If you're looking at the wrong one, you'll spend an hour "fixing" something that was already fixed. The solution: always develop in hot-reload mode (the dev server). It updates in seconds and you always know you're looking at current code. Production builds are only for releases.

Add a build stamp. Put the git commit hash and build time somewhere visible in your app — a small line in the corner, a console.log, anywhere. When you're confused about which version you're looking at, you'll know immediately.

Permission prompts — which ones to trust. Claude Code will ask for permission before taking certain actions. Some prompts are correct and you should approve them. Some are worth pausing on. Two things are safe to pre-allow: directory listings (dir *) and TypeScript checks (npx tsc). Everything else — running scripts, installing packages, moving or deleting files — keep those prompts on. They're protecting you.

When it looks totally broken: check the obvious things first. Is it the right file? Is there a cached version? Did the build actually run? Read the error message word for word before theorizing.

Stop Wasting Time

The single most effective habit change you can make during your week at Claude Camp: commit every time something works.

git commit + tag known-good

When it breaks ten minutes later (and it will), you don't need to remember what changed. You run:

git diff known-good

And you see exactly what changed. What would have been an hour of detective work becomes a two-minute read.

"Done" means verified in the real app. Not "it compiles." Not "it looks right in the editor." Not "Claude said it should work." Done means you ran it, saw it, confirmed it. Until then, it's just a theory.

One source of truth. When you have a reference document, a design file, an approved copy — build to that artifact. Don't reinvent it from memory. Don't summarize it and build from the summary. Use the actual thing.

Separate hardware problems from software problems. If something is mysteriously broken and the code looks fine, consider whether the problem might not be in the code at all. A dying drive, a bad cable, a network issue — these produce symptoms that look like software bugs and waste days. If you can't explain why the code should fail, look outside the code.

The 20 Hard-Won Lessons

A reference card. Pin it above your desk for the week.