How I use Claude Code in production every day

I've been shipping production code with Claude Code and Cursor for a year now — first across client engagements at my prior job, then as the only engineer at OwnStory. Some of what I expected has been right. Most of it hasn't.

The biggest miss: I thought "AI-native" meant "AI writes more of the code." That framing makes you measure the wrong thing. The real shift isn't volume — it's which decisions you delegate, and which ones you guard like they're load-bearing, because they are.

Here's the working version of that.

What I delegate

• Scaffolding and boilerplate. New API route with the same shape as the five existing ones. New Drizzle migration. CRUD UI from a typed schema. Anything where the structure is already decided and the only question is fingers-on-keys speed.
• Test scaffolds for known shapes. "Write Vitest tests for this function" works when the function has clear inputs and outputs. It doesn't work for tests where the assertion is "this matches my mental model" — Claude doesn't have that model.
• Refactors with explicit intent. "Pull this validation into a reusable Zod schema and update both call sites." Specific. Bounded. Verifiable.
• Reading large unfamiliar codebases. "Walk me through how requests flow from middleware to controller in this Django app, citing files." Claude is faster at this than I am, and I can verify each citation.

What I don't delegate

• Anything novel I haven't formed an opinion on yet. If I delegate before I've thought, I get a fluent answer that I then anchor on. The cost of that anchoring shows up two weeks later when the design assumption it baked in turns out to be wrong.
• Architecture decisions. I'll talk through them with Claude, but the decision stays mine. The tell: if I can't write down why I picked the approach in two sentences without using the model, I haven't decided yet.
• Anything where wrong-and-confident is worse than slow-and-correct. Auth flows, financial logic, tenant isolation. Claude can be confidently wrong about all three. I'd rather read the docs.
• The first version of a debugging hypothesis. When something's broken, I want to form my own theory before reading Claude's. Otherwise I'll spend an hour validating the wrong direction because the writeup sounded plausible.

The patterns that actually work

Plan mode > YOLO mode. For anything bigger than a 10-line edit, I have Claude write the plan first — files to touch, specific changes, what tests to add. I read the plan, push back, iterate. Then I let it execute. The plan is the artifact; the code is just the plan compiled.

Explain back to me. Before Claude touches the code, I make it summarise what it's about to do in plain English. Half the time that summary reveals a wrong assumption I would have caught only after the diff was written.

Git is the undo button. I commit before letting Claude do anything I'm not 100% sure about. The cost of one extra commit is nothing; the cost of losing twenty minutes of unrelated work to a git reset --hard is real.

Small, frequent context resets. Long sessions drift. Claude starts referencing files it half-remembers. When I notice the responses getting woolier, I start a new session with a tight prompt and the relevant files explicitly attached.

The biggest failure mode

The pattern that costs me the most isn't a wrong fix or a hallucinated function. It's using Claude to skip the part where I build understanding.

Specifically: Claude can give me a working solution to a problem I don't fully understand. The solution works. I ship it. Two months later there's a related issue and I'm starting from zero, because I never built the mental model — I only built the code.

The fix is boring and unglamorous: read the documentation. Step through the actual values in a debugger. Write the explanation in my own words before I let Claude write the code. The model accelerates the parts of engineering I already understand. It does not substitute for understanding.

The honest version

I ship more code than I would alone. Not 10x more, despite what the demos imply. Maybe 50%. The win isn't the volume — it's that I get to spend more of my actual thinking time on the parts that matter and less on the parts that are just typing.

That's a real productivity shift. It's also a smaller shift than the AI- native marketing implies, and pretending otherwise is how engineers ship broken code with confidence.