Introduction

I’ve been using Claude Code as a regular part of my development workflow for a few months now. It’s Anthropic’s CLI tool that gives Claude access to your terminal, filesystem, and editor. Instead of copy-pasting code in and out of a chat window, it works directly in your project. These are just some notes on how I use it day to day and where it’s actually been useful.

Setup

Claude Code is configured through a settings.json file and per-project CLAUDE.md files. The settings file controls permissions (EG. which tools it can run without asking) and which plugins are enabled. Here’s a trimmed-down 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 matters too. I block rm outright so it can’t delete files without me stepping in. It has access to your shell, so it’s worth setting up some guardrails before you let it loose. The plugin ecosystem is still pretty young, but there are a few useful ones for commit workflows and code review.

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

What it’s good at

Codebase exploration. This is probably where I get the most value. Finding where something is defined, tracing how a function gets called, or getting my head around an unfamiliar part of a codebase is just faster than doing it by hand. It has grep, glob, and file reading, so it’ll churn through the code in a way I don’t have the patience for.

Multi-step debugging. When something’s broken and the fix means checking a few files, reading logs, and testing a theory or two, it does a decent job. It can SSH into a server, read configs, tail logs, and work through the problem on its own. I recently had my site serving stale content after a migration. Claude Code SSH’d into the box, checked the deploy logs, compared file contents inside and outside the Docker container, worked out that the volume mount wasn’t refreshing, and patched the deploy script. Watching it run that kind of investigation across local and remote systems was the point where it really clicked for me.

Repetitive modifications. Renaming things across a codebase, updating imports, migrating a config format. Anything where you’re making the same kind of change in a lot of places. It’s nothing you couldn’t do with sed or a decent IDE refactor, but it understands enough context to handle the edge cases that usually trip those up.

Where it falls short

It can be overly cautious. It’ll sometimes ask for confirmation on things that are obviously fine, or explain what it’s about to do in far more detail than I asked for. When I tell it to edit a file I don’t need a paragraph justifying the edit. This has gotten better over time, but it still shows up.

It occasionally goes in circles. If an approach fails, it’ll sometimes retry the same thing, or some minor variation of it, instead of stepping back and rethinking. You learn to spot when it’s stuck and redirect it.

Context window limits. On bigger projects it’ll lose track of things from earlier in the conversation. It compresses older messages to cope, but you can usually tell when something’s fallen out of context. Starting a fresh conversation for each distinct task helps a lot.

Generated code can be over-engineered. Left alone, it tends toward more error handling, more abstractions, and more comments than I’d ever write myself. A few lines in my CLAUDE.md telling it to keep things simple takes care of most of that, but it’s something you have to keep an eye on.

How I actually use it

My usual workflow is to start it in a project directory and work through things conversationally. For straightforward changes I’ll describe what I want and let it edit the files directly. For anything bigger I’ll have it explore first, propose an approach, and only then let it implement.

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

The one habit I’d recommend is treating the CLAUDE.md file as a living document. When it does something I don’t like (EG. adding co-authored-by lines to my commits), I add a rule and it sticks for future sessions. After a while it stops fighting you and starts to feel like it actually knows how you work.

Syncing settings across machines

One annoyance I’ve run into is keeping it configured consistently across machines. There’s no built-in sync, so your ~/.claude/ directory is just local files. The options are the same as for any other dotfiles:

1. A dotfiles repo with symlinks. Keep settings.json, your global CLAUDE.md, and whatever else in a git repo and symlink them into ~/.claude/. This is already how I handle most of my dotfiles, so it was an easy fit.
2. Syncthing or rsync if you’d rather have it sync automatically without committing anything by hand.

Project-specific CLAUDE.md files already live in the repo, so those sync through git on their own. You can also drop a per-project .claude/settings.json into individual repos, which lets you push more of the configuration down into the projects themselves and keep the global config thin.

Conclusion

Claude Code has turned into something I reach for most days. It takes some effort to set up, and you have to stay on top of directing it, but for the kind of work I’ve described it saves real time and cuts down on the constant context-switching between files, terminals, and docs.

If you’re comfortable on the command line and work on projects with a lot of exploration and multi-step problem solving, it’s worth a look. Just plan on spending some time up front dialing in your settings and CLAUDE.md to match the way you like to work.