Introduction

I’ve been using Claude Code as part of my development workflow for a few months now. It’s Anthropic’s CLI tool that gives Claude direct access to your terminal, filesystem, and editor. Rather than copy-pasting code into a chat window, it operates directly in your project. This is just an example of how I use it day to day and how it’s become useful to me.

Setup

Claude Code is configured through a settings.json file and per-project CLAUDE.md files. The settings file controls permissions (which tools it can use without asking) and which plugins are enabled. Here’s a trimmed version of mine:

{
  "permissions": {
    "allow": [
      "Bash",
      "Edit",
      "Write",
      "Grep",
      "Read",
      "Glob",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm *)"
    ]
  },
  "enabledPlugins": {
    "superpowers@claude-plugins-official": true,
    "commit-commands@claude-plugins-official": true,
    "feature-dev@claude-plugins-official": true,
    "frontend-design@claude-plugins-official": true,
    "pr-review-toolkit@claude-plugins-official": true
  }
}

I have most of the common tools set to auto-allow so I’m not constantly approving file reads and grep searches. The deny list is important too. I explicitly block rm commands so Claude can’t delete files without me intervening. It has access to your shell, so setting guardrails like this is worth thinking about. The plugin ecosystem is still young but there are a few useful ones for commit workflows and code review.

The CLAUDE.md file is where things get interesting. You drop one in your project root (or your home directory for global settings) and it acts as persistent instructions. I use it to define my preferred communication style, commit conventions, and project-specific context. It’s basically a system prompt that lives with your code.

What it’s good at

Codebase exploration. This is probably where I get the most value. Asking it to find where something is defined, trace how a function is called, or understand an unfamiliar part of a codebase is genuinely faster than doing it manually. It has access to grep, glob, and file reading, so it can systematically search through code in a way that’s tedious to do by hand.

Multi-step debugging. When something is broken and the fix requires checking multiple files, reading logs, and testing hypotheses, Claude Code handles this well. It can SSH into servers, read configs, check logs, and work through the problem methodically. I recently had an issue where my site was serving stale content after a migration. Claude Code SSH’d into the server, checked the deploy logs, compared file contents inside and outside a Docker container, identified that the volume mount wasn’t refreshing, and fixed the deploy script. That kind of multi-step investigation across local and remote systems is where it really shines.

Repetitive modifications. Renaming things across a codebase, updating imports, migrating config formats. Anything that requires the same type of change in many places. It’s not doing anything you couldn’t do with sed or a good IDE refactor, but it understands context so it handles edge cases better.

Where it falls short

It can be overly cautious. Claude Code will sometimes ask for confirmation on things that are obviously fine, or explain what it’s about to do in unnecessary detail. When I ask it to edit a file, I don’t need a paragraph about why the edit is correct. This has gotten better over time but it’s still noticeable.

It occasionally goes in circles. If an approach fails, it will sometimes retry the same thing or try minor variations instead of stepping back and rethinking. You learn to recognize when this is happening and redirect it.

Context window limits. On larger projects, it can lose track of things discussed earlier in the conversation. It handles this by compressing older messages, but you can sometimes tell when context has been lost. Starting a fresh conversation for distinct tasks helps.

Generated code can be over-engineered. Left to its own devices, it tends to add more error handling, more abstractions, and more comments than necessary. I’ve added explicit instructions in my CLAUDE.md to keep things simple, and that helps a lot. But it’s something you have to actively manage.

How I actually use it

My typical workflow is to start Claude Code in a project directory and work through tasks conversationally. For straightforward changes, I’ll just describe what I want and let it edit the files directly. For anything more complex, I’ll ask it to explore first, propose an approach, and then implement.

I don’t use it for everything. Quick edits where I already know exactly what to change are faster to do manually. Same with anything that requires a lot of visual feedback, like CSS tweaking. But for investigation, debugging, writing new features, and anything that touches multiple files, it’s become a pretty natural part of how I work.

One thing I’ve found useful is treating the CLAUDE.md file as a living document. When Claude does something I don’t like (EG. adding co-authored-by lines to commits), I add a rule and it sticks for future sessions. Over time, it starts to feel more like a tool that knows your preferences.

Syncing settings across machines

One challenge I’ve run into is keeping Claude Code configured consistently across multiple machines. There’s no built-in sync mechanism, so your ~/.claude/ directory is just local files. The options are the same as syncing any dotfiles:

1. Dotfiles repo with symlinks. Keep settings.json, your global CLAUDE.md, and any other config in a git repo and symlink them into ~/.claude/. This is what I do for most of my dotfiles already, so it was a natural fit.
2. Syncthing or rsync if you want automatic sync without manually committing changes.

For project-specific CLAUDE.md files, those already live in the repo, so they sync naturally via git. You can also use per-project .claude/settings.json files, which means you can push more configuration into individual repos and reduce what needs to be synced globally.

Conclusion

Claude Code is a genuinely useful development tool. It’s not magic, and it requires some effort to configure and direct effectively. But for the types of tasks I described above, it saves real time and reduces the mental overhead of context-switching between files, terminals, and documentation.

If you’re comfortable on the command line and work on projects that involve a lot of file exploration and multi-step problem solving, it’s worth trying. Just be prepared to spend some time dialing in your settings and CLAUDE.md to match how you like to work.