TomVL

Top 10 Tips for Working with Claude Code

Writing | Nov 15 2025 | Tom Von Lahndorff

Working with Claude Code (Anthropic's official CLI for AI-assisted development) has been a game-changer for my development workflow. Over the past few months, I've used it across several projects - refactoring legacy code, building new features, and optimizing performance. Through trial and error, I've learned what works (and what doesn't) when collaborating with AI. Here's what I've discovered.

1. Start Small, Think Modular

Don't try to build Rome in a day. Start with a basic framework and iterate from there. Claude works much better when tackling focused, well-defined problems rather than sprawling "build everything" requests.

Why it matters: Large monolithic projects have too many interdependencies for Claude to track effectively. Breaking things into smaller pieces means each component can be developed, tested, and refined independently.

Example: Instead of "build a music player app," try "create a module that handles audio playback state" first, then add features incrementally.

2. Respect the Token Limits

Claude can't read files that are too large (roughly 3,000+ lines or 25,000+ tokens). If your files are getting massive, it's time to break them into modules.

Real example: I had a JavaScript file that grew to over 3,000 lines. Claude kept hitting errors trying to read it. So I split it into focused modules: one for state management (~75 lines), one for utility functions (~380 lines), one for data (~130 lines), and one for save/load operations (~275 lines).

Now Claude can read each module entirely. Problem solved.

3. Invoke KISS & DRY When You're Stuck

If you're experiencing frequent errors, or one fix breaks an earlier fix, step back and remind Claude to "Keep It Simple, Stupid" and "Don't Repeat Yourself."

Real example: I had three nearly identical functions for saving data to different places (localStorage, database, cloud). Each one was slightly different and bugs kept popping up. I asked Claude to consolidate them using DRY principles. Result: one clean function that takes a destination parameter. Simpler, fewer bugs.

4. Give Context, Not Just Commands

Claude works significantly better with specific information rather than vague requests.

Bad: "Fix the bug" Good: "The save function errors when the song name contains quotes - see line 1920 in save-load.js"

Include file paths, line numbers, error messages, and what you've already tried. The more context you provide, the better the solution.

5. Let Claude Plan Before Coding

Use the TodoWrite tool to break down complex tasks into steps. Review the plan together before executing. This prevents the "oops, didn't think about that" moments halfway through implementation.

Real example: I asked Claude to refactor a complex feature. Instead of diving in, it created a 6-step plan: extract module A, test, extract module B, test, update imports, final test. I spotted a potential issue in step 3 before any code changed. We adjusted the plan, then executed flawlessly.

6. CSS Requires Extra Patience

Claude struggles with CSS more than logic code. Why? Because CSS is inherently visual, and Claude can't see your browser.

Best approach:

• Describe what you see: "The button is 20px too far left"
• Take screenshots and reference them
• Expect more iteration than with JavaScript/Python
• Be specific about measurements and colors

Real example: I was trying to fix a layout issue where cards weren't aligning properly. Instead of saying "fix the layout," I said: "The third card in the grid is pushed down 50px below the others. It should align at the top. The issue appears when the viewport is between 800-1000px wide." Claude fixed it in one try because I gave visual details and context.

Remember: Humans struggle with CSS too! It's not just a Claude problem.

7. Use Progressive Disclosure

Don't dump all requirements at once. Start with core functionality, then enhance.

The process:

1. Get basic feature working
2. Test it
3. Add refinements
4. Test again
5. Add edge cases
6. Polish

Real example: When building a search feature, I didn't start with "build a search with autocomplete, filters, sorting, and pagination." Instead: First, get basic text search working. Test it. Then add autocomplete. Test it. Then add filters. Test it. Each step was manageable, and bugs were easy to isolate.

This prevents overwhelming Claude with too many concerns simultaneously.

8. Version Control is Your Safety Net

Make git commits before big refactors. Claude can't undo changes once made - only you can roll back.

My workflow: git add . && git commit -m "Working state before module extraction" - Now experiment fearlessly

If something breaks, you can always git reset --hard back to safety.

9. Test Incrementally

After each significant change, test before moving on. Catching issues early means they're easier to fix.

Real example: When refactoring code into modules, I tested after extracting each piece. First the data module, test. Then the save/load functions, test. Then the UI helpers, test. This way, if something broke, I knew exactly which change caused it.

Don't wait until the end to discover 10 different things broke!

10. Document for Future You (and Claude)

README files, CLAUDE.md in your project root, and inline comments help Claude understand your project structure. Good docs = better suggestions.

Real example: I created a CLAUDE.md file explaining that my music player uses a cache-based system and files should never be added directly to the cache JSON. Six months later when I came back to add features, Claude read that file and immediately understood not to modify the cache directly. Saved me from explaining the architecture every time.

Bonus: When you return to a project months later, you'll thank yourself for the documentation too.

Practical Insights from Claude

Having worked with hundreds of developers, I've (Claude) noticed some patterns:

Humans are better at:

• Seeing the UI (use this advantage!)
• Understanding business logic and user needs
• Knowing when something "feels wrong"

Claude is better at:

• Spotting syntax errors instantly
• Remembering obscure API details
• Executing repetitive tasks without fatigue

The best results come from collaboration, not delegation.

Real Example: Refactoring a Legacy Codebase

One recent project involved tackling a monolithic JavaScript file that had grown to over 3,000 lines. Working with Claude Code, I was able to:

1. Break it into focused modules (state, helpers, data, persistence)
2. Reduce the main file by nearly 400 lines
3. Make every module small enough for AI to read entirely
4. Maintain zero breaking changes throughout

Time investment: About 5 minutes of my time (Claude did the heavy lifting) Result: Much more maintainable codebase that's easier for both humans and AI to work with

The key was doing it incrementally - extract one module, test, move to the next. No big bang refactors that break everything.

The Bottom Line

Working with Claude Code is a collaboration. You bring the vision, domain knowledge, and ability to see/test the UI. Claude brings tireless coding assistance, instant recall, and the ability to execute plans precisely.

Treat it like pair programming with a very capable (but occasionally literal) colleague. Set clear expectations, provide good context, test frequently, and you'll be amazed at what you can build together.