(with human-written code I can reach out to the person who wrote it and let them deal with it, and they will have the understanding of said code, even if it is bad by quality measures. With LLMs there is nobody who understands said code, regardless of its quality)
"That code is horrible! Who the hell wrote this?!"
git blames
sees their own name
Isn't that an experience everybody makes? For me it was like a year into working professionally. And I feel it's part of being a professional to know that you're not going to remember it in the long term and therefore provide proper documentation of why you did what.
Code might be bad by some objective/subjective measure, but if you (or the author) can understand, navigate and work on it, that's often better than good quality code that nobody understands because it was written by an agent, especially under the time pressure of an ongoing incident where you need to fix it now.
Even if the good code is easy to understand, you still need to read it and take it in, something you don't need to do because you got it implicitly by writing said code.
> to know that you're not going to remember it in the long term
From my personal experience, while I will not remember code character by character, a quick look is all it takes to refresh my memory and get the general gist of it and what the context was at the time, something I don't have if I'm reading someone else's (or an agent's) code.
Hard disagree. If you're in a small-to-medium size codebase every day, then sure, but I have a couple personal projects that are complex enough that even though I wrote them before LLMs, I still need to go back and discover/fumble around before I can confidently make changes.
I have definitely looked at my own hand-written code and had a "wtf does this even do" moment.