> I figure that it's basically making notes for itself, when it has to revisit the same code in a fresh session.

That sounds like a great thing to do even if you are a human writing code for other humans. Most codebases out there are terrible for newcomers because of how little they explain why they are doing what they are doing, both in the code and in the often non-existent design notes.

▲

freedomben 10 hours ago | parent | next [-]

In principle, I would agree, however, the types of comments Claude writes are sometimes absurd. It will leave a 25 line comment above a variable talking about how in a debug session, it turned out that this value was too low, so it was increased on the current date to account for whatever. It will also leave giant comments like, reference security review from 2026-05-21. Even when that document is not committed

▲

mywittyname 9 hours ago | parent [-]

It will also inject a tons of information that it shouldn't. I do a lot of data pipelines and comments will be like, "this line is because there's 943,048,032 events in the blah table and it forms a conjunctive set with the 43,390,042 rows of the bar table..." but doesn't include the context that was run against a dev instance.

And if I don't catch these and remove the bad information, subsequent passes will flag those comments and get stuck on the fact that numbers don't match and start digging into that "problem" instead of staying on topic.

	▲	senderista 12 minutes ago \| parent [-]
		I have Sol do that for me and it does a decent job. When I ask Opus to rewrite its own prose the results are not much improved.

▲

whateveracct 10 hours ago | parent | prev | next [-]

these comments are not helpful and in fact hurt readability. i just delete them and would love to automatically do that honestly. cuz claude still drops long winded comments on every method even if i ask it not to

	▲	avereveard 8 hours ago \| parent [-]
		Post edit hook that reject edit based on comment density, mine is at 5% you will also need to heed deny file edit in automode as the rascal will try that to preserve prose

▲

zahlman 10 hours ago | parent | prev | next [-]

I'd much rather have it in the commit log than the code, though.

	▲	ionetan 9 hours ago \| parent [-]
		You may be interested in Epiq. Its is an issue tracker sourcing state from a log in state branch.

▲

myko 9 hours ago | parent | prev | next [-]

> That sounds like a great thing to do

I agree it _sounds like a great thing to do_ but the comments Claude creates make me want to never read code again. They're so obtuse and often completely pointless.

▲

rustystump 10 hours ago | parent | prev [-]

as others have pointed out, the reality is not this. id go further and say almost all comments are evil.

Excuse me if I am harsh, read the damn code. If you do not understand the language, that is a skill issue. If the code is confusing, then the code is bad and no amount of comments will ever change that. Professional engineering isnt an intro to databases class.

I am excusing language conventions which may have comments as part of its idiosyncratic nature.

▲

jnovek 9 hours ago | parent | next [-]

"If the code is confusing, then the code is bad and no amount of comments will ever change that."

I've worked on a lot of terrible legacy code in my career and I'm very thankful for the comments that others have left. This is becoming less necessary now that LLMs can explain a project, but comments have historically been a godsend in bad code.

▲

baq 9 hours ago | parent | prev | next [-]

Clean code considered harmful.

No, really: comments should be telling you what the code shouldn’t or physically can’t. Code is for execution and the exact details of what and how; it has no business knowing why or why not and that’s where comments are required.

▲

shawnz 7 hours ago | parent | prev | next [-]

If you are only encoding intent through "self-documenting code", and not with comments, then you are purposefully not using all the tools at your disposal to encode meaning as efficiently as possible.

Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.

▲

tarzcvf 7 hours ago | parent [-]

Not to mention complex numerical optimization code that mixes closed-form approximations and something like Newton.

Without guides as to why a particular hairy expression is a good idea as a first estimate, the code is pretty much unreadable. (E.g. is it setting derivatives to zero, using a polynomial approximation, or something else?)

	▲	rustystump 2 hours ago \| parent [-]
		i think people took this too literally. To put it another way, comments are for irreducible complexity ir external systems outside your control. I work between systems and app dev. Systems have comments more often esp in shaders but my god informing me that a variable named isActive is for if something is…active, is useless noise. Same with the majority of comments that a type system already tells you. In my career, these have been ~90% of the comments I see. Since ai, all new code it is 100%. Most of the replies examples are a sign of bad system/code but it is not always controllable. A legacy code comment of, the api requires strings for boolean values in the form “yes” and “no”. That is useful but it is also a code smell. A concrete example, a vendor decided to define a proto with a flattened array of objects so there are some 1800 uniquely named fields on it. In many downstream consumers, this is a real performance issue besides being confusing. A comment may be good there. The thing is, this was still solvable if up at the root of where this vendor’s hardware logs data remapped it to something sane so every downstream system wouldnt need a comment explaining wtf is going on. I see comments as when you want to explicitly answer why code smells right when a reader is smelling it.

▲

david-gpu 8 hours ago | parent | prev [-]

The code tells you what the code does. It does not explain why it is doing that, and not something else. That is, among other things, what documentation does, and that includes comments.