Nineteen Observations on Claude Code

I've spent 10 days and $100 in credits on Claude Code writing javascript apps.

1. Markdown files do the work. I don’t like writing a lot into the command line, so I write in markdown files, then tell Claude Code to go and tackle a file.
2. You can run Claude Code from the command line in VSCode and watch the files change. You don’t have to flip back and forth!
3. The more writing and documentation there is for a language, the better Claude Code and any LLM is going to be at writing it. For my use cases, Javascript, Python, and Ruby are going to be great.
4. Software engineering is going to get boring. Don’t use anything that isn’t 18+ months old. If you want to visually see how bad new stuff is, try building something using Tailwind V4 like I did.
5. Compiled languages and linters let Claude Code see its errors.
6. Just paste any further errors into it. You don’t need to type anything.
7. It will brute force things and write unmaintainable code.
8. It will also refactor, make code more maintainable, and follow best practices if you tell it to do so.
9. Being less descriptive is sometimes better: “Refactor the codebase using best practices. Make components and do other things that improve the codebase like that.” is better than telling it to do specific things.
10. Treat Claude Code like a team member. Your team members can make lots of decisions if they understand the big picture goals. Give it a 1-2 page markdown file describing the north star and how what we’re building right now fits into it.
11. It isn’t great at writing microcopy. The context of coding seems to wash out its writing ability, so all the content is highly descriptive and flat. A text input for name does not need a verbose reason for why you’re inputing it.
12. Use your favorite LLM to clearly describe how your app will work and each page of the app. It doesn’t have to be perfect - Claude Code will improvise if you start a list and say “plus whatever else makes sense.” Put your description of how the app will work into a markdown file.
13. Find the right level of abstraction. I gave it a markdown describing a project step-by-step and asked it to “start with the header and footer” and it just went ahead and built out the 3 page app. Amazing!
14. “Fix the text” or “make the UX snappier” is a better way to get creative solutions than “make that into an accordion.”
15. Don't overdo it with context and rules: you need to give Claude Code big picture, what part of the big picture we’re working on now, and what we’re specifically doing right now. If overload Claude with a million rules and context, you make it dumber.
16. It’s early days, so nearly every day it gets an update that makes it meaningfully better. No longer do I have to type /compact to help it manage its context window.
17. Ask it to save /compact to a file every time. It has a really helpful “logical next steps” section.
18. It’s early days, so you’re still pushing buttons and pulling levers that Claude Code will eventually do on its own.
19. You can be concise. “build and git commit” is sufficient to get a build, fix errors in the build, and create a git commit with a well written commit message.