You must log in or # to comment.
I use AI coding tools, and I often find them quite useful, but I completely agree with this statement:
And if you think of LLMs as an extra teammate, there’s no fun in managing them either. Nurturing the personal growth of an LLM is an obvious waste of time.___
At first I found AI coding tools like a junior developer, in that it will keep trying to solve the problem, and never give up or grow frustrated. However, I can’t teach an LLM, yes I can give it guard rails and detailed prompts, but it can’t learn in the same way a teammate can. It will always require supervision and review of its output. Whereas, I can teach a teammate new or different ways to do things, and over time their skills and knowledge will grow, as will my trust in them.
+10000 to this comment
This is true outside of coding too, really anywhere where you’re trying to get an LLM to consistently perform any type of function (no matter how general), in my opinion.
This has been my experience too.
If you think of LLMs as an extra teammate, there’s no fun in managing them either. Nurturing the personal growth of an LLM is an obvious waste of time. Micromanaging them, watching to preempt slop and derailment, is frustrating and rage-inducing.
Finetuning LLMs for niche tasks is fun. It’s explorative, creative, cumulitive, and scratches a ‘must optimize’ part of my brain. It feels like you’re actually building and personalizing something, and teaches you how they work and where they fail, like making any good program or tool. It feels you’re part of a niche ‘old internet’ hacking community, not in the maw of Big Tech.
Using proprietary LLMs over APIs is indeed soul crushing. IMO this is why devs who have to use LLMs should strive to run finetunable, open weights models where they work, even if they aren’t as good as Claude Code.
But I think most don’t know they exist. Or had a terrible experience with terrible ollama defaults, hence assume that must be what the open model ecosystem is like.
Improving your input, and the system message can also be part of that. There are multiple optimizations available for these systems that people aren’t really good at yet.
It’s like watching Grandma google “Hi, I’d like a new shirt” back in the day and then having her complain that she’s getting absolutely terrible search results.
Mmmmm. Pure “prompt engineering” feels soulless to me. And you have zero control over the endpoint, so changes on their end can break your prompt at any time.
Messing with logprobs and raw completion syntax was fun, but the US proprietary models took that away. Even sampling is kind of restricted now, and primitive compared to what’s been developed in open source.
A simple, but succinct summary of the real cost of LLMs. Literally, everything human for something that is just a twisted reflection of the greed of the richest.
This person is right. But I think the methods we use to train them are what’s fundamentally wrong. Brute-force learning? Randomised datasets past the coherence/comprehension threshold? And the rationale is that this is done for the sake of optimisation and the name of efficiency? I can see that overfitting is a problem, but did anyone look hard enough at this problem? Or did someone just jump a fence at the time and then everyone decided to follow along and roll with it because it “worked” and it somehow became the golden standard that nobody can question at this point?
The generalized learning is usually just the first step. Coding LLMs typically go through more rounds of specialized learning afterwards in order to tune and focus it towards solving those types of problems. Then there’s RAG, MCP, and simulated reasoning which are technically not training methods but do further improve the relevance of the outputs. There’s a lot of ongoing work in this space still. We haven’t seen the standard even settle yet.
Yeah, but what I meant was: we took a wrong turn along the way, but now that it’s set in stone, sunk cost fallacy took over. We (as senior developers) are applying knowledge and approaches obtained through a trap we would absolutely caution and warn a junior against until the lesson sticks, because it IS a big deal.
Reminds me of this gem:
The researchers in the academic field of machine learning who came up with LLMs are certainly aware of their limitations and are exploring other possibilities, but unfortunately what happened in industry is that people noticed that one particular approach was good enough to look impressive and then everyone jumped on that bandwagon.
That’s not the problem though. Because if I apply my perspective I see this:
Someone took a shortcut because of an external time-crunch, left a comment about how this is a bad idea and how we should reimplement this properly later.
But the code worked and was deployed in a production environment despite the warning, and at that specific point it transformed from being “abstract procedural logic” to being “business logic”.
Disagree
Argument doesn’t check out. You can still manage people, and they can use whatever tools make them productive. Good understanding of the code & ability to pass PR reviews isn’t going anywhere, nor is programmer skill
Not unless the claims that companies are hiring less junior devs in favour of LLMs with senior coder oversight. If this is indeed a true trend and AGI is not achieved, we might have senior coder shortage in future.
I think this is true to some degree, but not exclusively true; new grads still get jobs. However, I think it’ll take some time for universities to catch up with the changes they need to make to refocus on architecture, systems design & skilled use of LLMs
My opinion is that the demand for software is still dramatically higher than what can be achieved by hiring every single senior dev + LLM. I.e. there will need to be more people doing it in the future regardless of efficiency gains
Nurturing the personal growth of an LLM is an obvious waste of time.
i think this is short sighted. engineers will spend years refineing nvim, tmux,zsh to be the tool they want. the same applies here. op is framing it like its a human, its a tool. learn the tool, understand why ot works the way it does. just like emacs or ripgrep or something.
I think you’re misunderstanding that paragraph. It’s specifically explaining how LLMs are not like humans, and one way is that you can’t “nurture growth” in them the way you can for a human. That’s not analogous to refining your nvim config and habits.
Ok, don’t use them…?
This could have been a facebook status
The problem is that many employers are requiring employees to use them.
Experts who enjoy doing [blank] the hard way don’t enjoy the tool that lets novices do [blank] at a junior level.
Somehow this means the tool is completely worthless and nobody should ever use it.
