My Experience with Claude Code

So I've been using Claude Code for a while now, and man, I wish someone had told me some of this stuff when I first started. Like, I spent way too much time fighting with it instead of working with it, you know?

I wanted to share some of the workflows and tricks I've picked up that actually make a difference. Not the theoretical stuff you read in docs, but the real day-to-day things that make Claude Code feel like it's actually helping instead of just... being there.

The Difference Between Claude Code and Cursor (And Why It Matters)

Okay so first thing - people keep asking me about Claude Code vs Cursor. They're really different tools, man. Cursor is more like having a really smart autocomplete that lives in your editor. Claude Code is more like having a coding partner who can actually think through problems with you.

With Cursor, you're still driving. You write some code, it suggests completions, you accept or reject. It's fast, it's helpful, but you're still doing most of the thinking.

Claude Code is different - it's more conversational. You can say "hey, I need to refactor this component to handle error states better" and it'll actually understand the context, read through your files, and come up with a plan. It's slower than Cursor for quick edits, but way better for complex changes.

I use both, honestly. Cursor for quick edits and everyday coding, Claude Code when I need to think through bigger problems or work on stuff I'm not familiar with.

The Workflows That Actually Work

The "Scratchpad Method" (This Changed Everything for Me)

So I picked up this technique from a tweet I saw, and it's honestly been a game changer. When I'm working on a complex change with Claude Code, I ask it to maintain a scratchpad.md file that's basically an append-only log of everything that happens.

It logs gotchas, decisions, files it discovers, questions, answers - everything. And here's the key part - it's append-only. No editing previous entries, just keep adding to it.

Why this works is that when Claude gets confused or goes down the wrong path (which happens), I can point it back to the scratchpad and say "look, we already tried that approach on line 47, it didn't work because X." It gives the conversation memory that actually persists.

The "Plan-Execute-Reflect" Loop

This one took me a while to figure out, but it's so much better than just asking Claude to "implement this feature." Here's how it works:

Make a plan first - Ask Claude to create a detailed plan before writing any code. Not just "implement user auth" but like "create user model with email/password fields, set up bcrypt for hashing, create login/register endpoints, add middleware for protected routes, etc."
Execute in pieces - Don't try to implement everything at once. Take the plan and work through it step by step.
Reflect and update - After each piece, ask Claude to update the plan with what it learned. "Okay we implemented the user model, but we discovered we also need a password reset token field. Update the plan."

This prevents those situations where you're halfway through implementing something and Claude realizes it needs to change a bunch of stuff it already wrote.

The "Multiple Models" Approach for Big Projects

For really complex changes on big codebases, I've started using multiple models. Yeah, it sounds overkill, but hear me out.

I'll use Gemini (because of the large context window) to map out the data flow and identify all the files that might be involved. Then I take that file list to Claude and ask it to create a detailed plan. Then I give that plan to a fresh Claude Code session to actually implement.

It sounds like a lot of work, but it's way faster than the alternative of Claude getting confused halfway through and having to start over.

The "Clean Restart" Technique

This one's huge. When Claude Code gets stuck in a loop or starts making weird decisions, don't just keep pushing. Sometimes the context has gotten "poisoned" - it's made some wrong assumptions early on and now everything is built on top of those assumptions.

Instead of switching to a more expensive model, try this:

Ask Claude to create a markdown file with all the decisions and false paths taken so far
Ask for a clean list of files that were touched
Ask for a clean spec that requotes your original problem and explains what was tried and why it didn't work
Start a fresh session with just those files

This gives you all the learning without the poisoned context. Works way better than just throwing more compute at the problem.

The Tips I Wish I Knew Earlier

Use /compact Sparingly (It's Not That Great)

The /compact command is supposed to help with context management, but honestly? It doesn't work that well. It's better to manually manage context by being explicit about what you want Claude to remember.

Instead of /compact, I'll say something like "before we continue, can you summarize the key decisions we've made so far and the current state of the implementation?" Much more reliable.

Be Specific About File Paths

Claude Code is really good at finding files, but it's even better when you're specific. Instead of saying "update the user component," say "update the UserProfile component in src/components/UserProfile.tsx." It saves time and prevents confusion.

Ask for Explanations of Unfamiliar Code

When Claude reads through files you're not familiar with, ask it to explain what it found. "I see you read through the auth middleware file - can you explain how the current authentication flow works before we modify it?"

This has saved me so many times from breaking things I didn't understand.

Use the Memory Features

Claude Code has this CLAUDE.md file for project-specific memory. Actually use it! Put your coding conventions, common patterns, deployment steps, whatever. It makes such a difference for consistency across sessions.

Don't Fight the Tool

This took me way too long to learn. Claude Code works best when you work with its strengths instead of trying to force it to work like a traditional editor.

It's really good at:

Understanding context and relationships between files
Thinking through complex problems step by step
Handling unfamiliar codebases
Refactoring and large-scale changes

It's not as good at:

Quick, simple edits (use Cursor for those)
Performance-critical optimizations
Very domain-specific code without context

The Stuff That Doesn't Work (Save Yourself Some Time)

Don't Ask It to "Just Fix Everything"

I used to dump a bunch of error messages at Claude and say "fix all these." It rarely works well. Instead, pick one error, understand why it's happening, fix it, then move to the next one.

Don't Trust It Blindly with Dependencies

Claude sometimes suggests adding dependencies that don't exist or using APIs that have been deprecated. Always verify external dependencies and API calls.

Don't Use It for Tiny Projects

For really small projects or quick scripts, Claude Code is overkill. The overhead of explaining context isn't worth it. Just write the code yourself.

Real Talk: When Claude Code Is Actually Worth It

Claude Code shines when:

You're working on a codebase you're not familiar with
You need to make changes that touch multiple files
You're learning a new framework or language
You need to refactor complex logic
You're debugging something gnarly and need a second pair of eyes

It's not worth it when:

You're making quick fixes to code you know well
You're working on performance-critical code that needs to be perfect
You're doing exploratory coding where you're not sure what you want

The Landscape Is Changing Fast

Man, things are moving so fast in this space. Google just leaked their Gemini CLI (which they quickly took down), and there are all these new tools popping up. OpenCode apparently ships with some Claude Code functionality now, though there's some debate about whether that's against the terms of service.

The whole agentic development thing is getting really interesting. We're moving from "AI that helps you code" to "AI that codes with you" to maybe even "AI that codes for you." It's wild to think about.

So yeah, that's my real experience with Claude Code so far. It's not perfect, but when you know how to work with it, it can be really powerful. The key is understanding what it's good at and not trying to force it to be something it's not.

I'm still learning new workflows and tricks all the time. The tool is evolving fast, and so are the ways we use it. But these are the things that have made the biggest difference for me so far.

That's all I wanted to share about Claude Code tips for now. Next I want to talk about the bigger picture - where AI agents are heading and what that means for how we build software. But that's a whole other conversation.