To comment on the post you linked:

I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist).

Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing.

Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.

i meant "working with" as i explained in the linked comment. the feedback and response i get from juniors is very different. and yes, sure every junior dev is different from the others, but i simply enjoy working with people and i can't stand working with machines in the same way.

what bothers me about LLMs is that they are not deterministic. that just drives me nuts. i do enjoy learning the ins and outs of a language or compiler to figure out how to write the code to get the results i need. but LLMs just don't work like that. the same instruction that produced good working code today could produce nonsense tomorrow.

this is not about quality. this is about trust. i can't trust LLMs and that makes it very uncomfortable for me to work with them.

That's because you try to look at LLM's as tools, and not as an intern.

LLM's are not deterministic, they can make mistakes, etc. You refuse to work with LLM's like you would work with interns, and then somehow you're frustrated that they don't work like a compiler?

Maybe shifting your expectations would solve a lot of your frustrations.

Look, every developer writes bugs. Me, you, everyone. There is no perfect developer that can churn out 100% quality code. That means you always have to take this into account. You are correct that I don't take compiler bugs into account, because they are very rare. But when working with LLM's, just take into account that it can go wrong, just like any human developer.

Basically, you have very fast and cheap interns at your disposal, with a huge amount of knowledge. Can you trust an intern? Of course not!

There's nothing wrong with that. Many of us do (or did) like programming and the problem-solving itch it scratched for us. But getting work done for pay is more than what we like. If an LLM can reliably solve a problem for me in a day that would have taken a project, a team of several people, and close to a month of work to build out manually, then I go with the tool that works.

And that "if" is the reality I live in. About a decade ago, I wrote a program to do analysis of config files for a product our team uses. It took me weeks of side-work to implement the idea of passing boolean python functions as checks for the configuration. Such an elegant way of creating new checks on our system! It was company work, and when I left to a new place, I didn't have that code, just the idea. Fast forward five years and I want to write the same thing at a new place. I asked an LLM to do the same task, and it wrote exactly my solution immediately. It just worked. It shocked me. In the last few months, I've had it write analysis tools against this product that would have taken me days or weeks. I am admittedly not a comp-sci level programmer.

There is no denying that LLMs are powerful coding tools. That can be true at the same time that we lament the end of manual-coding-for-pay, the death of programming education as we know it, and the worries about employment and society.