15 Claude Code Tips Most Developers Never Figure Out

The Gap Between Installed and Effective

Most developers install Claude Code, try it for a few days, and settle into a narrow set of habits. They use it like a smarter autocomplete — one file, one task, short sessions.

The developers who get dramatically more out of it have figured out a different set of patterns. This post covers 15 of them.

---

1. Write a CLAUDE.md — It's Read First, Every Time

Claude Code reads a CLAUDE.md file in your project root before doing anything else. This is your most powerful configuration lever.

# CLAUDE.md

## Stack
- Next.js 15 App Router, TypeScript strict mode, Tailwind CSS
- Postgres via Drizzle ORM, Zod for validation
- Vitest + Testing Library for tests

## Commands
- `pnpm dev` — start dev server
- `pnpm test` — run test suite
- `pnpm typecheck` — run TypeScript compiler check
- `pnpm lint` — ESLint

## Conventions
- Server components by default — add "use client" only when needed
- All database queries go in src/lib/db/queries/
- Error handling: use Result types, not throw
- Never commit with failing tests or TypeScript errors

## Things to Avoid
- Don't use `any` types
- Don't use `console.log` in production code (use the logger)
- Don't modify files in src/generated/ — they're auto-generated

The time you spend writing this pays back on every single session.

---

2. Use /init to Generate CLAUDE.md Automatically

Don't want to write it from scratch? Run this inside any project:

claude
/init

Claude Code will read your project structure, package files, and existing code to generate a useful starting CLAUDE.md. Edit it to add conventions and preferences, then commit it to the repo.

---

3. Pre-Authorize Commands to Kill the Permission Friction

Every time Claude Code wants to run a shell command, it asks. This gets old fast. Add a .claude/settings.json to pre-approve commands you trust:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(pnpm *)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)"
    ]
  }
}

Keep destructive commands (push, reset, deploy) requiring approval. Everything else — tests, linting, type checks — can be pre-authorized.

---

4. Use /compact Before Context Gets Stale

Long sessions accumulate context. As the conversation grows, the early parts get compressed or dropped, and Claude Code starts making mistakes because it's forgotten what it decided earlier.

Before this happens, run /compact. It summarizes the session into a dense context snapshot that preserves the important decisions without wasting tokens on back-and-forth.

Make this a habit: run /compact every 20–30 exchanges, or whenever you finish one sub-task and start another.

---

5. One-Shot Tasks with -p Are Cheaper and Faster

Not everything needs an interactive session. For well-defined, single tasks:

claude -p "Add JSDoc comments to every exported function in src/lib/utils.ts"

The -p flag runs the task and exits. No session overhead, no context accumulation. For routine tasks (adding docs, formatting, small fixes) this is significantly cheaper and faster than opening a full session.

---

6. Pipe Files In for Context-Heavy Tasks

You can pass content directly to Claude Code:

# Give it a spec to implement
claude -p "Implement this feature" < spec.md

# Give it an error log to debug  
cat error.log | claude -p "Find the root cause of these errors and fix it"

# Give it a PR diff to review
git diff main | claude -p "Review this diff for bugs and security issues"

This is particularly useful for review and debugging workflows where the input is already in a file.

---

7. Write Task Files for Complex, Repeatable Work

For tasks you run regularly — weekly database cleanup, migration scripts, release checklists — write the task as a Markdown file and commit it to the repo:

# tasks/weekly-cleanup.md
## Weekly Database Cleanup

1. Find and archive orders older than 90 days with status "abandoned"
2. Delete soft-deleted user records older than 30 days
3. Vacuum the orders and users tables
4. Log the counts of records affected to the audit_log table
5. Run the test suite to verify nothing broke

Then run it:

claude < tasks/weekly-cleanup.md

Repeatable, version-controlled, reviewable by the team.

---

8. Use --continue to Resume Where You Left Off

Left in the middle of a session? Resume it:

claude --continue

Claude Code restores the last session's context. Useful when you get interrupted mid-task and want to pick up without re-explaining everything.

---

9. Check /cost Early and Often

Token usage accumulates faster than you'd expect in long agentic sessions. Run /cost periodically to see where you stand:

/cost

Typical signals to watch for:

• A single session approaching $2+ — probably time to /compact or restart
• Model is defaulting to Opus when Sonnet would do — switch with /model
• Repeated read operations on the same large files — the task may be drifting

---

10. Switch Models for the Right Task

Claude Code defaults to Claude Sonnet. For most tasks, this is the right call — it's fast and capable. But you can switch mid-session:

/model claude-opus-4-7

Use Opus for:

• Complex architectural decisions
• Debugging subtle logic errors across many files
• Tasks that need extended thinking to get right

Use Sonnet for:

• Everything else — it's 5x cheaper and usually good enough

You can also set the model for a session at startup:

claude --model claude-sonnet-4-6

---

11. Give It Constraints, Not Just Goals

The best Claude Code prompts describe both what you want and what you don't want:

Migrate the authentication from JWT to session-based auth.

Constraints:
- Don't change the login/logout API endpoints (other services depend on them)
- Don't touch the test files — I'll update those separately
- Use the existing Redis instance for session storage (it's already configured)
- Run the full test suite after each file change, not just at the end

Without constraints, Claude Code will make reasonable assumptions — but they might not be your assumptions. Explicit constraints eliminate most re-do cycles.

---

12. Tell It the Failure Mode, Not Just the Task

When debugging, the most useful thing you can give Claude Code is the full error output plus the context of when it happens:

Getting this error only in production, not local:

Error: ECONNREFUSED 127.0.0.1:5432
  at TCPConnectWrap.afterConnect

This happens on the /api/orders endpoint, but only under load (>50 concurrent requests).
The connection pool is set to 10. Find the leak and fix it.

Specific failure mode + specific conditions + specific endpoint = fast diagnosis. Vague "it's broken" prompts lead to exploratory sessions that burn context.

---

13. Use MCP Servers to Connect Your Full Stack

MCP servers are the biggest productivity unlock most Claude Code users haven't discovered. Once configured, Claude Code can:

• Query your database directly
• Read and create GitHub issues
• Search Slack channels
• Query your observability platform

Add your first MCP server:

claude mcp add

The most useful ones to start with:

• @modelcontextprotocol/server-postgres — direct DB access
• @modelcontextprotocol/server-github — repository operations
• @modelcontextprotocol/server-filesystem — extended file operations

Once your DB is connected, prompts like this actually work:

Show me the top 10 users by order count in the last 30 days,
then create a Markdown report and save it to reports/top-users.md

---

14. Use Headless Mode for CI and Automation

Claude Code can run non-interactively in CI pipelines and scripts:

claude --headless -p "Run the test suite and fix any TypeScript errors. Commit the fixes."

The --headless flag disables interactive prompts. Combined with pre-authorized permissions in .claude/settings.json, you can run fully automated Claude Code tasks in GitHub Actions or similar.

Use cases:

• Automated code review on PRs
• Nightly refactor passes
• Automated documentation updates
• Dependency upgrade + fix cycles

---

15. Interrupt Early When It's Going Wrong

This is the habit that saves the most money and time: interrupt Claude Code as soon as you see it going in the wrong direction.

Signs it's drifting:

• It's reading files that have nothing to do with your task
• The plan it describes doesn't match what you asked for
• It's making changes that seem overly complex for the problem

Hit Ctrl+C and redirect:

Stop. You're changing the API layer but I only want changes to the UI.
The API is fine. Focus only on src/components/OrdersTable.tsx.

Early interruption saves more tokens than /compact does. The longer you let a wrong direction run, the more expensive the recovery.

---

The Compound Effect

None of these tips are individually dramatic. But combining them — a well-written CLAUDE.md, pre-authorized permissions, regular /compact calls, specific prompts with constraints, and early interruption when something drifts — turns Claude Code from a capable tool into a reliable development partner.

The developers who get 10x productivity from Claude Code aren't using a different tool. They're using the same tool with better habits.