It's been pretty disheartening to watch SWEs rediscover/reinvent the SDLC.

The most demoralising part of using LLMs is that now I spend most of my day on SDLC - even hobby projects.

>Having done step 2 & 3 by hand is the difference between being able to fix/extend it quickly with no further damage or fumbling around like an idiot and sometimes breaking more stuff in the process.

Plenty of shitty spaghetti code has been written by human hands.

LLMs can write good, maintainable code too, but they need to be kept on a shorter leash with focused goals.

I'm not talking about code quality (though indeed that could be a problem too), I'm talking about understanding the code - having written the code by hand means you don't need to rediscover it from scratch.

(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)

To be fair though:

"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.

I am talking more about the knowledge of the code rather than an objective/subjective measure of code "quality".

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.

  git blames
  sees their own name

  Isn't that an experience everybody makes?

Our fearless leader once did clang-assisted formatting of all of our code. Wherever we look with git blame, we see his name. Of course, we change code, etc, but for some year and a half it was fun.

(to actually go to the specific commit that authored the code I skip two specific revisions, both are formatting changes)

So you seeing your name next to the code you do not like can be an indentation change due to adding condition or something like that.

>having written the code by hand means you don't need to rediscover it from scratch.

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.

While that might be true, the more one equips LLMs for building the less one will be capable of keeping LLMs “on a shorter leash with focused goals” in the long run