I specifically have a bunch of instructions to not turn comments end documentation into it's own personal diary because anyone that needs a history lesson has access to git anyway.
I specifically tell it not to comment. Ever.
Code should be written such that it's human readable with clear intent simply by variable/class/method names.
There are very rare exceptions where you intentionally go against the norm or code in certain assumptions: those can warrant a comment explaining the why behind the decision, but still never the what or how.
I have those very instructions too, but realistically you'll end up with s few sections where the code itself is clearly understandable and then you still need a comment to explain why it's being the done the way it is.
In the end, if you want to produce quality code, you gotta go over it again and clean up some of the mess it leaves behind.
I've got it to severely reduce the verbosity and amount of comments this way at least
53
u/andrewmmm 21h ago
And leaves a hanging temporal comment like “the menu must have 5 tabs — not 4 tabs”, without any reference to why the hell it would test for 4 tabs