I've had Claude Code in my day-to-day loop for about a year now. The framing that works for me — and that I had to unlearn the autocomplete framing to find — is that it behaves more like a junior architect with a perfect memory of the repo than like a smarter Tab key. The implications cascade from there.

Brief it like a person, not a prompt

The single largest productivity shift I made was to stop writing terse imperative prompts and start writing the kind of context I would write for a teammate I trusted but who had been on vacation for a week. Goal, constraints, what I've already tried, and what "done" looks like.

A bad brief: "Add pagination to the posts route."

A good brief: "Add cursor-based pagination to GET /posts. We're already doing offset pagination on /users — please match that file's structure but use _id as the cursor since posts have a stable insert order. Return nextCursor as null when exhausted. Don't touch the schema. Tests live next to the route."

The second one gets a working PR on the first pass roughly nine times in ten. The first one gets something that compiles and that I have to reject on style grounds.

Treat the plan as the artifact

For anything bigger than a single file, I ask for a plan first and review the plan as if it were code. The plan is where bad decisions are cheap. Once the plan is approved, the implementation is mostly mechanical, and I'm reviewing for execution rather than design.

This is also where I catch the most subtle hallucinations — invented APIs, misremembered library versions, the wrong storage primitive. Catching those at plan time costs a sentence. Catching them in a 600-line diff costs an afternoon.

What I do not delegate

  • Schema design. The data model is the part of the system that compounds — every wrong shape gets harder to fix. I write schemas by hand and ask Claude to critique them.
  • Auth and billing. Anything where a bug is silent and expensive. I'm happy to take suggestions; I do the writing.
  • The first commit on a new module. The first commit sets the conventions for everything that follows. I want my fingerprints on it.

What I happily delegate

  • Test scaffolding and fixture generation.
  • Refactors that are mechanical but tedious — renaming a concept across forty files, extracting a hook, splitting a fat module along the seams I point out.
  • The first draft of documentation. I write the structure; Claude fills the prose; I edit. This is roughly three times faster than writing prose from scratch and the output is more consistent.
  • Reading code I didn't write. "Walk me through what this module does and what would break if I removed function X" is a stunningly effective onboarding aid for legacy code.

The diff review habit

I read every line. Every line. The moment I stopped reading every line was the moment a misnamed environment variable shipped to staging. The speedup is not "I write less code"; it is "I write the same amount of code with less wrist pain and more time spent on the parts that matter." That's a real productivity gain, and treating it as one keeps the trust calibrated.

The tool is fast. The judgment still has to be mine. That trade is the whole job.