Comment by Retr0id
3 days ago
It's a surprising change from my perspective, because in the past it felt like they understood that Claude should be pleasant to interact with.
3 days ago
It's a surprising change from my perspective, because in the past it felt like they understood that Claude should be pleasant to interact with.
It's bad enough that I've seen dedicated skills to do comment hygiene scrubbing and consolidation.
I've tried telling it to "fix" comments with varying degrees of specificity and in my experience it just... fundamentally doesn't get it. Presumably using a different model for it would help.
My theory is that Claude's learned approach to comments is to treat them as a sort of persistent in-band thinking trace, or a "memory" tied to an in-code location, which is a little at odds with the way humans use comments (human comments are intended to be read and understood by other humans, whereas Claude comments are their own dialect).
I bet this is a result of iteratively training Claude on output from other successful Claude sessions. Presumably it's good for making benchmark scores go up.
It also seeps into all documents and artefacts it creates.
Claude will include actual comments ("// ...") into Excel sheets, and include the thinking that led to the output, instead of just focusing on the final result.
So if Claude questioned whether a vendor should be replaced, and you said "oh no, they are critical and we're already negotiating a great price") you'll now need to be careful to not send your vendor a document that contain text like ("Cost: X. // Management confirmed to not fire this vendor as they are critical to infrastructure and a better price will be negotiated later")
I also suspect comments are very much tied to how Claude reasons because not only are they bad comments, I can't get rid of them. Commenting is the one area in which I've been unable to get Claude to respect any rules. It can follow code conventions I prefer, it can do other things, but it can't keep the comment volume down.
My CLAUDE.md has rules about not including any redundant comments in the code that are obvious from the code itself. I reiterate that occasionally while working. It's absolutely disregarded and any Claude-written code is full of comments. Some of them are simply redundant, like "Collect Foos and pass them to the requested sink" on a function that's void CollectFoos(IFooSink sink). But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.
I haven't found any way to stop Claude from doing these, so I have to tell Claude afterwards to clean the comments up. Which it does, making a note in memory to comment less, and it still does the exact same thing next time.
4 replies →
I'm not sure why you all have issues with CC commenting too much. My rules in the CLAUDE.md specify that comments are evil, never comment unless there is an actual need to explain a WHY and since I do read what CC writes, if I spot it still adding such WHY comments and they make no sense, I'll have it adjust, in many cases by removing them.
Given the code base has a minimal amount of such comments, it's also less likely to go "copy what the rest of the codebase does".
Of course I've now jinxed it and some update will cause it to ignore the instructions coz I didn't write them in the new model's style or something.
1 reply →
I have had some luck telling Sol to concisely rephrase Opus 5’s comments.
I built my own skill to somewhat follow the Simplified Technical English guidelines (loosely adapted to my work context)
The problem I’ve been finding is that you can do this but within a few messages, the instructions in the skill will be ignored.
Absolutely infuriating if you’re using Claude in an environment where you can’t run hooks.
Exactly. Sad to see them falling behind on this because it's exactly why I chose to use Claude initially.