How I Set Up Claude Code as a Daily Pair Programmer (Without Burning the Budget)

I went from "I'll just try it once" to "I have a whole process around it" in about three weeks. Here's the short version of what survived contact with real codebases.

1. One project, one CLAUDE.md, not a global bible

The default advice is "put a giant CLAUDE.md in your home directory." That sounds great until Claude Code starts apologizing for things in your side project while you're working on a Node script for work. A per-project CLAUDE.md is more honest. Mine is short:

• Stack + Node version, package manager, formatter, test command.
• Two or three "don't do this" lines (don't change lockfiles, don't add dependencies without asking, don't write tests for files I didn't ask about).
• A short "things I always forget" section. Mine says "this repo uses the new auth flow, not the legacy one."

That's it. ~30 lines. The shorter the better — long files become a tax on every single turn.

2. Treat it like a junior with a very long memory

Claude Code is good at pattern-matching across a whole repo. That means it will happily refactor a function and ten other functions that "look similar" if you don't fence the scope. Two habits saved me:

• "Look at this file. Do not edit any other file." Sounds restrictive, but for a 200-line patch it works.
• "Before editing, list the files you would touch." If the list is longer than I expected, I cut the request.

3. The real cost isn't the API — it's the context

Most people I know hit the budget limit not because Claude Code is slow, but because they paste the whole 800-line file into the prompt "just in case." Three tricks cut my token use by roughly half:

• Paste the failing test, not the implementation. The error message is usually enough.
• Tell it to read the file first, then propose a diff, then apply. The pause lets me catch a wrong direction early.
• /clear between unrelated tasks. The longest "I lost an hour" stories start with "it kept bringing up stuff from two requests ago."

4. Don't ask for tests you won't read

Auto-generated tests are seductive. They look productive, they run, the bar goes green. But tests Claude Code writes for me tend to test the implementation, not the contract — so they pass when the code is wrong. The pattern that works for me: I write the test first (one or two cases), then ask Claude Code to either implement against it or extend it. The test is the source of truth, the model fills in the body.

5. The one thing nobody mentions

The thing that actually moved the needle was using /rewind to recover from a bad turn. I expected to use git for that, but /rewind is faster for a single chat turn. It also teaches me what kind of prompt tends to go off the rails — I now know that "refactor this" is dangerous, and "rename this function and update callers" is safe.

Verdict

It's not magic. It won't write your app. But for the boring 80% — the "wire this up to that", the "explain this weird error", the "write a tiny script to massage this CSV" — it's the first tool in a while that's actually changed my daily loop.