Everybody's hating on LLMs, why can't I? https://drwho.virtadpt.net/archive/2026-03-10/everybodys-hating-on-llms-why-cant-i/ #misc #technology #llm #programming #work #wtf #infrastructure
Timeline
Post
Remote status
Context
3
@drwho Actually, interesting rule lawyering question: Does ncurses count as a TUI? :)
Possibly not, in which case I may have inadvertently proved your point.
@feoh I don't think it does, but something like Dialog might.
@drwho This is another for realz problem with LLM use in code generation:
They will ALWAYS, even if you tell them otherwise, fall back on 'native' abstractions and choose brute force code gen to solve a problem that may well be better or more readably solved by using a library instead.
This is the kind of thing that makes me queasy about the current LLM wave, even though I wind up talking a lot about how I use them for work and otherwise.
We really ARE cheapening the overall quality of our output when we use these things. We're often making a devil's bargain exchanging velocity for quality, because that's what the majority of what the industry wants.
There are bright spots though, I've been reading about a few people who reject the narrative of velocity and are using these tools to generate better quality code.
Replies
1
@feoh @drwho
> They will ALWAYS, even if you tell them otherwise, fall back on 'native' abstractions and choose brute force code gen to solve a problem that may well be better or more readably solved by using a library instead.
on the other hand, there have been security experts over the years arguing that this is actually a better and more secure approach because you do not want the risk of that third party library as a dependency if you do not need it as even if you don't use the whole library it still increases your attack surface. And then you have the library which pulls in another library problem...
Example: systemd and the xz backdoor
https://github.com/systemd/systemd/issues/32028
> They will ALWAYS, even if you tell them otherwise, fall back on 'native' abstractions and choose brute force code gen to solve a problem that may well be better or more readably solved by using a library instead.
on the other hand, there have been security experts over the years arguing that this is actually a better and more secure approach because you do not want the risk of that third party library as a dependency if you do not need it as even if you don't use the whole library it still increases your attack surface. And then you have the library which pulls in another library problem...
Example: systemd and the xz backdoor
https://github.com/systemd/systemd/issues/32028