More unfiltered thoughts on Claude Code

Monday, March 24, 2025

Continuing from last time.

• Was very exciting to work with this yesterday. Then I kept waking up last night worrying about job security. The times, they are uncertain.
• I manifested the Claude Code automatic context management functionality
• I’m still waiting for my manifestation of it using PRs automatically. Supposedly it’ll retrieve the contents of a URL you give it and take instructions from there (fortunately I can see no security issues with this); if you take this idea just a little further you might think that running the god damned thing in my terminal makes no sense at all, and you should interact with it in a web page, and it should submit all its changes as PRs
• Which would allow you to have multiple of these things working on the same codebase at once! As you accept PRs, they each rebuild their own branches, and handle merge conflicts.
• I think both of these things are in the works from people familiar with the product space; I’m not having novel ideas, but using the product for a few minutes really makes you want this stuff.
• It doesn’t have as good an eye for making reviewable changes as you’d like. Sometimes all the tests change and it’s hard to understand why. For a side project, you probably just YOLO accept; for code that’ll run in production, this will get really boring.
• It really wants to maintain backwards compatibility, which would be nice sometimes, but I really don’t need that for a feature you just wrote 5 minutes ago
• Because there is so much time that Claude is churning away spending your money on tokens, this feels a lot less like programming flow state; it’s very easy to get distracted and half do 5 things as you keep an eye on Claude in case it got stuck or is asking you for help. In this way it is less enjoyable.
• … I appreciate that you’re asking for permission before running shell commands, but cd ... && ... is not a “cd command”.
  • 
• Really does not have a good idea of when to comment; if you provide no guidance it’ll shit out a whole file with no comments; if you tell it to comment everything it’ll provide inane comments like mainLogLevel := logging.InfoLevel // Default to INFO level (that’s a real example).
• Imagining a future version of this stuff
  • Don’t have the LLM comment any code
  • Strictly track what was LLM generated, and associate it with the prompt (could be a prompt from another LLM)
  • Strictly track human edits and associate with some comments or commit messages
  • Could use git for this, but Claude Code’s attempt at an implementation that does so is too ham-fisted for actual use, so I end up artisinally crafting all the commit messages
  • Have another LLM help you explain the code, including generating comments at viewing time. Explanations tailored to the user, and the context. The tool knows when you’re stepping into a codebase for the first time and when you’ve just viewed all the other relevant modules and provides “comments” that are appropriate to each case.
• The real power is having it write tests and test the code it writes. However, it is still pretty LLM-stupid, so you end up with Intro to Programming -level tests like TestInitializeDefaultLogLevelIsInfo.