Tag: Claude Code

Three months ago, I was skeptical. Another AI coding tool? I’d already tried GitHub Copilot, Cursor, and a handful of VS Code extensions that promised to “10x my productivity.” Most of them were glorified autocomplete — helpful for boilerplate, useless for anything that required actual understanding of a codebase. Then I installed Claude Code, and within the first hour, it did something none of the others had done: it read my entire project, understood the architecture, and fixed a bug I’d been ignoring for two weeks.

This isn’t a puff piece. I’ve been using Claude Code daily on production projects — Kubernetes deployments, FastAPI services, React dashboards — and I have strong opinions about where it shines and where it still falls short. Let me walk you through what I’ve learned.

What Makes Claude Code Different

Most AI coding assistants work at the file level. You highlight some code, ask a question, get an answer. Claude Code operates at the project level. It’s an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. It works in your terminal, IDE (VS Code and JetBrains), browser, and even as a desktop app.

The key word here is agentic. Unlike a chatbot that answers questions and waits, Claude Code can autonomously explore your codebase, plan changes across multiple files, run tests to verify its work, and iterate until things actually pass. You describe what you want; Claude figures out how to build it.

Here’s how I typically start a session:

# Navigate to your project
cd ~/projects/my-api

# Launch Claude Code
claude

# Ask it something real
> explain how authentication works in this codebase

That first command is where the magic happens. Claude doesn’t just grep for “auth” — it traces the entire flow from middleware to token validation to database queries. It builds a mental model of your code that persists throughout the session.

The Workflows That Actually Save Me Time

1. Onboarding to Unfamiliar Code

I recently inherited a Node.js monorepo with zero documentation. Instead of spending a week reading source files, I ran:

> give me an overview of this codebase
> how do these services communicate?
> trace a user login from the API gateway to the database

In 20 minutes, I had a better understanding of the architecture than I would have gotten from a week of code reading. Claude identified the service mesh pattern, pointed out the shared protobuf definitions, and even flagged a deprecated authentication path that was still being hit in production.

2. Bug Fixing With Context

Here’s where Claude Code absolutely destroys traditional AI tools. Instead of pasting error messages and hoping for the best, you can do this:

> I'm seeing a 500 error when users try to reset their password.
> The error only happens for accounts created before January 2025.
> Find the root cause and fix it.

Claude will read the relevant files, check the database migration history, identify that older accounts use a different hashing scheme, and propose a fix — complete with a migration script and updated tests. All in one shot.

3. The Plan-Then-Execute Pattern

For complex changes, I’ve adopted a two-phase workflow that dramatically reduces wasted effort:

# Phase 1: Plan Mode (read-only, no changes)
claude --permission-mode plan

> I need to add OAuth2 support. What files need to change?
> What about backward compatibility?
> How should we handle the database migration?

# Phase 2: Execute (switch to normal mode)
# Press Shift+Tab to exit Plan Mode

> Implement the OAuth flow from your plan.
> Write tests for the callback handler.
> Run the test suite and fix any failures.

Plan Mode is like having a senior architect review your approach before you write a single line of code. Claude reads the codebase with read-only access, asks clarifying questions, and produces a detailed implementation plan. Only when you’re satisfied do you let it start coding.

CLAUDE.md — Your Project’s Secret Weapon

This is the feature that separates power users from casual users. CLAUDE.md is a special file that Claude reads at the start of every conversation. Think of it as persistent context that tells Claude how your project works, what conventions to follow, and what to avoid.

Here’s what mine looks like for a typical project:

# Code Style
- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible
- All API responses must use the ResponseWrapper class

# Testing
- Run tests with: npm run test:unit
- Always run tests after making changes
- Use vitest, not jest

# Security
- Never commit .env files
- All API endpoints must validate JWT tokens
- Use parameterized queries — no string interpolation in SQL

# Architecture
- Services communicate via gRPC, not REST
- All database access goes through the repository pattern
- Scheduled jobs use BullMQ, not cron

The /init command can generate a starter CLAUDE.md by analyzing your project structure. But I’ve found that manually curating it produces much better results. Keep it concise — if it’s too long, Claude starts ignoring rules (just like humans ignore long READMEs).

Security Configuration — The Part Most People Skip

As a security engineer, this is where I get opinionated. Claude Code has a robust permission system, and you should use it. The default “ask for everything” mode is fine for exploration, but for daily use, you want to configure explicit allow/deny rules.

Here’s my .claude/settings.json for a typical project:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)",
      "Bash(wget *)",
      "WebFetch"
    ]
  }
}

The deny rules are critical. By default, Claude can read any file in your project — including your .env files with database passwords, API keys, and secrets. The permission rules above ensure Claude never sees those files, even accidentally.

For even stronger isolation, Claude Code supports OS-level sandboxing that restricts filesystem and network access:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "allowLocalBinding": true
    }
  }
}

With sandboxing enabled, Claude can work more freely within defined boundaries — no more clicking “approve” for every npm install.

Subagents and Parallel Execution

One of Claude Code’s most powerful features is subagents — specialized AI assistants that run in their own context window. This is huge for context management, which is the number one performance bottleneck in long sessions.

Here’s a custom security reviewer subagent I use on every project:

# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

Then in my main session:

> use the security-reviewer subagent to audit the authentication module

The subagent explores the codebase in its own context, reads all the relevant files, and reports back with findings — without cluttering my main conversation. I’ve caught three real vulnerabilities this way that I would have missed in manual review.

CI/CD Integration — Claude in Your Pipeline

Claude Code isn’t just an interactive tool. With claude -p "prompt", you can run it headlessly in CI/CD pipelines, pre-commit hooks, or any automated workflow.

Here’s how I use it as an automated code reviewer:

// package.json
{
  "scripts": {
    "lint:claude": "claude -p 'Review the changes vs main. Check for: 1) security issues, 2) missing error handling, 3) hardcoded secrets. Report filename, line number, and issue description. No other text.' --output-format json"
  }
}

And for batch operations across many files:

# Migrate 200 React components from class to functional
for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from class component to functional with hooks. Preserve all existing tests." \
    --allowedTools "Edit,Bash(npm run test *)"
done

The --allowedTools flag is essential here — it restricts what Claude can do when running unattended, which is exactly the kind of guardrail you want in automation.

MCP Integration — Connecting Claude to Everything

Model Context Protocol (MCP) servers let you connect Claude Code to external tools — databases, issue trackers, monitoring dashboards, design tools. This is where things get genuinely powerful.

# Add a GitHub MCP server
claude mcp add github

# Now Claude can directly interact with GitHub
> create a PR for my changes with a detailed description
> look at issue #42 and implement a fix

I’ve connected Claude to our Prometheus instance, and now I can say things like “check the error rate for the auth service over the last 24 hours” and get actual data, not hallucinated numbers. The MCP ecosystem is still young, but it’s growing fast.

What I Don’t Like (Honest Criticism)

No tool is perfect, and Claude Code has real limitations:

• Context window fills up fast. This is the single biggest constraint. A complex debugging session can burn through your entire context in 15-20 minutes. You need to actively manage it with /clear between tasks and /compact to summarize.
• Cost adds up. Claude Code uses Claude’s API, and complex sessions with extended thinking can get expensive. I’ve had single sessions cost $5-10 on deep architectural refactors.
• It can be confidently wrong. Claude sometimes produces plausible-looking code that doesn’t actually work. Always provide tests or verification criteria — don’t trust output you can’t verify.
• Initial setup friction. Getting permissions, CLAUDE.md, and MCP servers configured takes real effort upfront. The payoff is worth it, but the first day or two can be frustrating.

My Daily Workflow

After three months of daily use, here’s the pattern I’ve settled on:

1. Morning: Start Claude Code, resume yesterday’s session with claude --continue. Review what was done, check test results.
2. Feature work: Use Plan Mode for anything touching more than 3 files. Let Claude propose the approach, then execute.
3. Code review: Use a security-reviewer subagent on all PRs before merging. Catches things human reviewers miss.
4. Bug fixes: Paste the error, give Claude the reproduction steps, let it trace the root cause. Fix in one shot 80% of the time.
5. End of day: /rename the session with a descriptive name so I can find it tomorrow.

The productivity gain is real, but it’s not the “10x” that marketing departments love to claim. I’d estimate it’s a consistent 2-3x improvement, heavily weighted toward tasks that involve reading existing code, debugging, and refactoring. For greenfield development where I know exactly what I want, the improvement is smaller.

Key Takeaways

• Claude Code is an agentic tool, not autocomplete. It reads, plans, executes, and verifies. Treat it like a capable junior developer, not a fancy text expander.
• CLAUDE.md is essential. Invest time in curating project-specific instructions. Keep it short, focused on things Claude can’t infer.
• Configure security permissions from day one. Deny access to .env files, secrets, and credentials. Use sandboxing for automated workflows.
• Manage context aggressively. Use /clear between tasks, subagents for investigation, and Plan Mode for complex changes.
• Always provide verification. Tests, linting, screenshots — give Claude a way to check its own work. This is the single highest-leverage thing you can do.

Have you tried Claude Code? I’d love to hear about your setup — especially if you’ve found clever ways to use CLAUDE.md, subagents, or MCP integrations. Drop a comment or ping me. Next week, I’ll dive into setting up Claude Code with custom MCP servers for homelab monitoring. Stay tuned!