I'm afraid this all gets thrown out the window nowadays.
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I ask them to write comments in ASD-STE100 Simplified Technical English, but all I really get from that is tersness.
Also the other day I stumbled upon a huge pile of documentation and I'm still trying to figure out if it's human or machine written. I stopped reading it half way through as I figured that perhaps it wasn't written for humans to read.
The most WTF comments are the ones that describe how the code looked during a rewrite session with no commits. It writes bad code, I ask it to rewrite it, and it leaves a comment saying why the previous implementation was bad, with no history in git of the previous implementation.
Edit: changed the LLMs pronoun to it.
LLMs do this to communicate with their future selves to avoid retracing what turned out to be the garden path.
Another pattern is where they put comments in multiple places in the code to say that those need to be kept in sync in a very particular way ...that sort of thing has always been considered a code smell, but seems to be the post-AI "new normal": it's cheaper for the AI to leave it to its future self to have to make every change in multiple places than it is for its present-day self to do the refactor.
Before AI, writing code that worked was costly and structuring it well, while you were at it, didn't increase your cost all that much. Now, AI has reduced the cost of writing badly-structured but working code, while it hasn't reduced the cost of writing well-structured code all that much. Since no one who decides about this sort of thing has given two craps about structure, ever, bad structure is just what we're left with now.
The day will come when codebases will be completely unintelligible to humans. The best example is when AI actually refers to code in comments with actual line numbers. No human would ever do that or find that useful if another human did it, because it would be next to impossible for a human to keep the line numbers properly updated after edits and they would soon all be wrong and meaningless.
You'd have to go very far back in computing history to get to where we learned not to do that. Was there ever programming with goto's referencing line numbers instead of named labels? If so, this would be that.
Who is this "he" you're talking about? Or were you referring to an LLM? If so, the correct pronoun would be "it".
Your english is really good, except for that little mistake.
I am 100% guitly of anthropomorphizing LLMs, sorry.
Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
I wonder if that's actually useful for an LLM though. It's additional context that should steer the LLM not to change the code to do something else.
> Unless I tell them not to, LLMs lean on slapping verbose comments of the worst kind - describing the code instead of the reasons for putting it there.
Well, my LLMs are "smarter" than yours. They'll describe why the code is there. They'll even try to keep these comments in sync with code as it makes changes.
This includes describing the "why" behind the change even on code affected only accidentally, e.g. by reformat or reindent. And, if it wrote some code and then later learned half of it is wrong, it'll remove the offending parts and leave comments telling what used to be there, and why it isn't anymore.
Same for commit/PR messages.
May or may not be related to a recent tendency in Opus/Fable models I noticed, to eagerly turn user feedback into rules, self-correct by adding more rules, and then when some rule fails, correct it by adding a counter-steering rule - accumulating rules until eventually getting lost in them.