cross-posted from: https://lemmy.world/post/49193875
DConf2026 mostly has proAI talks, with the biggest standout being Adam Wilson’s talk about integrating LLMs into developing the next version of the standard library.
This lead to a lot of debate within the community, with even some pro-genAI people calling it out, and there’s even an open letter calling for rethinking the use of genAI, and some increased interest in the OpenD fork. It is also found out that people did try to volunteer for the new standard library (including me), but were rejected with the excuse of “we already have things in the works”.
I’m also interested into some D alternatives that’s not Rust (🤮🤮🤮🤮🤮 - no I’m not a Lunduke fan, but a gamedev, also no “const by default” languages!), has metaprogramming capabilities, and no (mandatory) header files (🤮🤮🤮🤮🤮), in case I decide to leave. I have a game engine that could be ported, its resource management needs to decoupled for D’s garbage collection though.
This is a talking point. You’re falling back on the nirvana fallacy.
Yes - absolutely nobody is recommending you do everything the LLM says. You still need to have critical thinking when using an LLM. I still use my many years of experience to gauge the quality of the responses. But it definitely has recommended solutions that I found to be quite good and better than what I was thinking of implementing. Do you think you can’t recognize whether a solution would be a better or worse fit when recommended by either an LLM or a person if done “confidently”?
But even for “just coding” - I offer an example. It will happily convert an old Apache Tiles application to using Apache Thymeleaf (the former being unsupported). And it does it very well, and much faster than people can. The solution is very cookie cutter and we’ve established a pattern. It’s very easy to recognize the changes being made are following the pattern and QA is testing all of the changes. What was going to take nearly a year will take weeks. It’s an absolute win here.
You can tell yourself whatever you need to make yourself feel better, but there are real benefits to LLMs in software development.
In theory, people ought to check every LLM output. This collides with reality in different points;
people are lazy and being diligent just passively checking results is hard - and can be very tiring
people are under pressure to work faster
if they really check everything, the result is often slower.
As a result, careful checks of each result won’t happen.
I know that by experience because I have a coworker who uses LLMs heavily. I am relying on interfaces he should provide and he is often not able to describe them in an usable way. Thinks that should take a day or two often take many weeks.
You could argue it is a competence problem, so maybe yes but LLMs apparently augment such problems.
We evaluate suggestions from people differently. For example, we use cues like use of language, certificates, reputation, personality, prior experience with them, and insitutions to evaluate their competence - and we trust then, with a reason. You won’t go to a barber shop and ask a random person working there for a stomach surgery.
LLMs are more like a surgeon with fake certificates, using language from medical textbooks.
God yes I can relate to that. I have a similar “full vibe-coder” coworker who sent me a PR for something that amounted to 1,000’s of lines of code changes. I rejected it out-of-hand. We had a long conversation about readable PRs, breaking work up into chunks, etc. Of course he had Claude do all that for him but… at least the PR was “better”.
And the same trouble with him not having any clue what he just produced actually did. I 100% agree that’s a problem. But it’s kinda the same problem we had before LLM, though maybe a bit super-charged. That fella’s code before Claude was terrible as well. So technically the code itself is better now so… I guess that’s a win?
Yeah - give bad drivers faster cars and people will die faster. I hear that. We do need to train people better on how to use these tools. It’s definitely NOT “go vibe code a thing into existence and then drop it on others to maintain”. But I don’t think “bury your head in the sand and hope it goes away” is the right approach either.
Sure. But you can do that with LLMs too. They have strengths and weaknesses as well. But to understand how to use these tools appropriately you need to gain experience with them. To know when they tend to produce good results (well known and well documented languages and libraries) and when to be more “sus” about them (obscure libraries, poorly documented applications (coughOraclecough)).
The more you use them the more you get to see when it’s struggling.