Working with Claude Code

I’ve been using Claude Code for the last two weeks to move several small side projects that I couldn’t prioritize before. Here are some things I learned. Shout out to Mason Egger for sharing some of his findings as well. He’s always a great thought partner.

1. Claude Code works exceptionally well when you know exactly what to build and can guide it. If you are not clear on what you’re looking to do, you’re going to spend a lot of time and tokens refining work.
2. Update the CLAUDE.md file you generated at the start. I didn’t do that and had to explain how to run the test web server a few times before I realized why; Claude didn’t know about it.
3. Good software practices absolutely matter. Use branches. Commit often.
4. Claude doesn’t always clean up after itself. It’ll try things and leave dead code around. You should review every change before you make a commit.
5. Don’t outsource critical thinking to Claude Code. It does not “know.” It pattern matches. That’s it. So don’t let it “think” for you. You do the thinking, tell it to do the “doing.” It can find dead code. It can reformat code. It can even identify some gaps. But it doesn’t think.
6. Related to point 5, if you’re doing a very common thing in a very common language, Claude does it very well and very fast. Like CSS stuff, common JS event handling, and even stuff in PHP. But if you’re trying to do something with a Go library like Goldmark, where there are fewer examples, Claude struggles a lot.
7. Tell it to test and tell it how to test. Claude Code, if directed well, can test local URLs and live URLs to verify output. It can run tests automatically when you make changes. This shouldn’t surprise me, but it does.
8. You probably don’t need an MCP server for a lot of things. Claude Code can run bash commands. I saw a LinkedIn post where someone was saying the same thing; a lot of “tools” can just be shell scripts you tell Claude to run. Need something from product docs? Download ’em and tell Claude Code where they are. This is working surprisingly well.
9. Probably my favorite tip from Mason: Have Claude Code create a plan, and save that plan to a text file. Then start a new session and have Claude Code read the plan in and execute it. It’s a bit of the “two-shot” approach others talk about, but it also gives you a chance to review the plan in detail and just make textual adjustments to add more clarity between sessions.
10. You can tell it to summarize your work. My content writing workflow often consists of me building an example and copying the commands or code I run. But I’ve now had Claude Code write the body of three mini tutorials for me based on my sessions, and while they need a lot of work, they took less time than my previous manual note-taking efforts.
11. Use tmux. Have a pane with Claude Code and use tmux with a big scrollback buffer. Then have another pane where you run Git commands and other shell commands.

What did I miss? What would you add?