You raise some good points here. When I write comments, I only write what is not obvious from code. Example: Imagine there is some bizarre business rule that some insurance contract is 6% cheaper to write on the last business day of the month. That is exactly the kind of thing I will write inline code comments about. Someone without deep knowledge of that code would be clueless about that specific business rule.
I forgot about the no comments rule. Yeah, that sounds insane.
That's exactly how I see it. And 99% of LLM-generated comments are just that: annoyingly wordy repetitions of what's already in the code. Just redundant noise that is a waste of time to read. Usually because the LLM has no concept of the information that might actually be helpful in a comment.
The same goes for LLM PR descriptions and documentation. Those spaces were meant for additional information not already in the code, not superfluous prose.
The point of his argument is that if it isn't obvious from code, there is usually an opportunity to make it obvious by rewriting the code. This is often not practical, but it doesn't make it less true in the abstract. E.g., in your example one could make a constant for the 6% multiplier and call it LAST_DAY_OF_MONTH_DISCOUNT and take every possible other similar steps to have that idea of that comment embedded into the running code, not in the comments. This way everyone who reads the code can gain that deep knowledge by just reading it.
Comments
You raise some good points here. When I write comments, I only write what is not obvious from code. Example: Imagine there is some bizarre business rule that some insurance contract is 6% cheaper to write on the last business day of the month. That is exactly the kind of thing I will write inline code comments about. Someone without deep knowledge of that code would be clueless about that specific business rule.
I forgot about the no comments rule. Yeah, that sounds insane.
That's exactly how I see it. And 99% of LLM-generated comments are just that: annoyingly wordy repetitions of what's already in the code. Just redundant noise that is a waste of time to read. Usually because the LLM has no concept of the information that might actually be helpful in a comment.
The same goes for LLM PR descriptions and documentation. Those spaces were meant for additional information not already in the code, not superfluous prose.
The point of his argument is that if it isn't obvious from code, there is usually an opportunity to make it obvious by rewriting the code. This is often not practical, but it doesn't make it less true in the abstract. E.g., in your example one could make a constant for the 6% multiplier and call it LAST_DAY_OF_MONTH_DISCOUNT and take every possible other similar steps to have that idea of that comment embedded into the running code, not in the comments. This way everyone who reads the code can gain that deep knowledge by just reading it.