Claude Code gets dramatically better when you stop treating it like "a chatbot in a terminal" and start treating it like part of a repeatable engineering workflow.
The difference is usually not model quality. It is setup quality. Teams that get strong results do the same few things over and over: give the agent persistent context, write plans before prompting, isolate concurrent work, and review output like it came from a fast junior engineer.
This is the setup I recommend if you want Claude Code to be useful on real projects, not just impressive in demos.
TL;DR Setup Checklist
- Add a project-level
CLAUDE.md - Create short plan docs before starting implementation
- Use git worktrees for concurrent sessions
- Auto-approve safe operations, but keep risky ones gated
- Pick one review surface and use it consistently
Running concurrent sessions in one directory
Every serious Claude Code workflow starts here.
Without a root CLAUDE.md, every session has to rediscover your architecture, commands, conventions, and constraints. That wastes prompt budget and leads to avoidable mistakes. With it, the agent starts from a usable baseline.
A good CLAUDE.md is short, concrete, and opinionated:
# CLAUDE.md
## Project Overview
Monorepo for a React frontend, Node API, and PostgreSQL database.
## Development Commands
- Start web: `npm run dev:web`
- Start api: `npm run dev:api`
- Test: `npm run test`
- Lint: `npm run lint`
## Architecture
- `/apps/web` - React frontend
- `/apps/api` - HTTP API
- `/packages/ui` - shared components
- `/packages/db` - schema and queries
## Conventions
- TypeScript strict mode
- Zod for request validation
- Never query the DB directly from route handlers
## Guardrails
- Do not change auth middleware without explicit review
- Keep migrations backward compatible
- Prefer existing patterns over new abstractions
The key is specificity. "Use TypeScript" is weak. "Use TypeScript strict mode and validate requests with Zod" is useful.
Claude Code gets much better once it can inspect more than the current file tree.
The three categories that matter most are:
- Repository context: GitHub or git tooling so the agent can understand issues, PRs, and branch state
- Data context: schema or safe query access for local/dev databases
- Project context: any internal tools, docs, or MCP servers your team already relies on
The mistake here is over-configuring. Do not hand the agent ten tools you barely trust. Start with the few that meaningfully improve accuracy.
3. Set Permission Rules So the Agent Is Fast but Not Reckless
The default "ask me for everything" experience is safe and miserable. The opposite extreme, where the agent can do anything without friction, is how you end up approving bad work after the fact.
A practical default looks like this:
- Auto-approve reads inside the repo
- Auto-approve writes inside the repo
- Auto-approve test runs and other common safe commands
- Keep approvals for installs, git history rewrites, and anything outside the project
You want Claude Code to move quickly through normal implementation, but you still want a hard pause on operations that change system state or create cleanup work.
4. Write a Plan Before You Prompt
This is the highest-leverage habit in the entire workflow.
Do not start with:
build me user authentication
Start with a plan document in markdown that you iterate on with the agent:
# Feature: User Authentication
## Goal
Session-based auth with registration, login, and password reset.
## Constraints
- Use bcrypt
- Store sessions in PostgreSQL
- Rate limit login attempts
- All routes under `/api/auth/*`
## Acceptance Criteria
- [ ] User can register
- [ ] User can log in and get a session cookie
- [ ] User can reset password
- [ ] Failed logins are rate limited
Then point Claude Code at the file:
claude "implement docs/auth-plan.md"
This is better than a long natural-language prompt because the plan becomes reusable. You can refine it, hand it to another agent, or review the finished work against it.
5. Use Git Worktrees for Parallel Sessions
If you run more than one Claude Code session at a time in the same checkout, you are choosing pain.
Use worktrees instead:
git worktree add ../project-auth -b feature/auth
git worktree add ../project-tests -b feature/auth-tests
git worktree list
Now each session gets:
- its own branch
- its own working directory
- no file collisions with the others
That is the foundation for reliable parallel work.
Example:
# API work
cd ../project-auth
claude "implement docs/auth-plan.md"
# Test work
cd ../project-tests
claude "write tests for docs/auth-plan.md"
Worktrees are the single best upgrade for anyone moving from "one agent sometimes" to "multiple agents regularly."
6. Pick a Session Management Pattern
Once you have parallel sessions, you need a way to keep them straight.
Three reasonable options:
- Terminal tabs: fine for one or two sessions
- tmux: still the power-user default for keyboard-heavy workflows
- Nimbalyst: useful if you want a visual board for sessions, file changes, diffs, and plan artifacts in one place
The right choice depends on your failure mode.
If your issue is "I lose track of which session is running where," a visual session surface helps.
If your issue is "I want everything on one keyboard-first screen," tmux is still excellent.
7. Review Like the Agent Is Usually 90% Right
Claude Code is often right enough to feel finished before it actually is.
That is why review matters. The common misses are not obvious syntax errors. They are:
- slightly wrong edge-case handling
- assumptions about existing abstractions
- tests that prove the happy path but not the failure path
- code that works but does not match local conventions
For small changes, git diff or your editor is enough.
For larger changes, use a proper review surface:
- editor diff view
- draft pull request
- a tool that tracks per-session file changes and inline diffs
The more files an agent touches, the less acceptable "quick skim and merge" becomes.
8. My Default Claude Code Loop
This is the loop I would teach a team:
- Write or update a short plan
- Create a worktree
- Start Claude Code against that plan
- Let it run until it blocks or finishes
- Review the diff against the plan
- Fix or redirect
- Merge and remove the worktree
That is the whole system. Most of the value comes from doing that loop consistently.
Common Mistakes
Starting from a blank prompt
If you skip the plan, Claude Code fills in the blanks with its own assumptions.
Over-specifying implementation
Tell the agent what good looks like, what constraints matter, and what must not break. Do not micromanage every function unless there is a real reason.
Reviewing too late
Do not wait until a giant session is "done" before looking. Review earlier on bigger tasks.
Final Take
The best Claude Code workflow is not complicated. It is disciplined.
Persistent context, short plans, worktree isolation, and careful review beat almost every fancy trick. Once those pieces are in place, you can decide whether you want to stay in a terminal, live in tmux, or use a more visual workspace around the agent.
Without that foundation, the tool choice barely matters.
Karl Wirth is the founder of Nimbalyst, a local visual workspace for building with Claude Code and Codex.
