Yes. But the important thing is that now disfunctional organizations have access to tools to write unmaintainable code really fast.

Every bad decision in my code bases were because I didn't have enough time to do things the right way

Please tell me the software patent in that project is copylefted

Yus [good image]. Use it to assist and expedite learning (mostly by double checking its output, and debugging its code) to get better. Not as a slave to do your work for you.

This is a bold claim I will not make.

But, I didn't check any of mine in?

Haha. As the saying goes, "I still get paid."

"You need to try your best" "This was my best...."

The biggest problem with using AI instead of junior developers is that junior developers eventually become senior developers. LLMs .... don't.

sir, this is programmer_humor

With LLMs I get work done about 3-5x faster. Same level of maintainability and readability I'd have gotten writing it myself. Where LLMs fail is architecting stuff out- they can't see the blind alleys their architecture decisions being them down. They also can't remember to activate python virtual environments, like, ever.

😞 Sir this is a Wendy’s.

I actually laughed out loud at this meme.

Exactly. I've been sabotaging the AI with shitty code output since long before LLMs existed. That's how I play 4D chess. (This is just meant to get a laugh. Some of my code is even quite nice, actually.)

Had to scroll way too much for this comment.

Infinite loop and hard coded magic constant; this should have a configurable timeout and a resource file the string is read from so we can internationalize the application. Additionally, the use of a goto with a hard coded line number is a runtime bug waiting to happen after unrelated refactors; it's best to use a looping construct that has more deterministic bounds.

In my experience, the biggest problem is that maintainable code necessarily requires extending/adapting existing structures rather than just slapping a feature onto the side.

And if we're not just talking boilerplate, then this necessarily requires understanding the existing logic, which problems it solves, and how you can mold it to continue to solve those problems, while also solving the new problem.

For that, you can't just review the code afterwards. You have to do the understanding yourself.
And once you have a clear understanding, it's likely that the actual code change is rather trivial. At least more trivial than trying to convey your precise understanding to an LLM/intern/etc..

I'll use an LLM to write bulk code, unit tests, other boring stuff.. but, I specifically only have it write code I'm already very familiar with, and even then, I hand-code it every so often, like 1 in every 3 times I'll do it by hand to make sure I'm still able to. If I have to look something up, then I'll stop using an LLM for that task for a long while.

Yeah, a lot of maintainability is about understanding how it works. Architectural decisions are the other half. Someone who's paying attention can do well on both of these even using AI tools.

Most of the unmaintainable code I've seen is because businesses don't appreciate the need to occasionally refactor/rewrite or do anything to maintain code. They only appreciate piling more on. They'd do away with bug fixing too if they could.

Can I, sure. Do I give af since my company doesn’t care about me as anything other than a number in a spreadsheet, no.

It really depends on the situation. Can I write maintainable code? Yes, to the extent that the average senior dev can.

But that isn’t the same as being afforded the chance to write maintainable code. I’ve been part of teams where the timeline is so tight that technical debt is just a thing that builds up to be dealt with “later” and more stress is put on getting things done instead of keeping things maintainable.

The fact of the matter is that humans can while LLMs currently can’t.

On top of that, a human dev is going to be able to understand context a hell of a lot easier if they’ve previously worked on it, even if the code is less maintainable.

Every decision I've made to write code with poor maintainability was driven by time pressure to deliver

That is outrunning the bear, isn't it. Outrunning the other guy is being the guy that makes 10 other jobs redundant by running the LLM.

Not that I think that works.

What are these books you speak of? Do they have special features?