34

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.

you are viewing a single comment's thread
view the rest of the comments
[-] mabeledo@lemmy.world 4 points 1 day ago

I don’t think you understood my point.

Writing code faster was never something anyone with any real knowledge of their domain would think is desirable. I don’t care if more code is written faster, because that has never been a good indicator of productivity. In fact, I would argue that less code is better.

Anyway, it’s funny that you mention, in a somewhat patronising tone by the way, that we need to adapt and not be wary of AI because we have “other skills”.

If you want to keep a human in the loop, then fine. Now you have a choke point in your otherwise faster machine. A human who now needs to understand code they haven’t written, and with more and more datapoints coming up suggesting that LLM usage leads to skill atrophy, an eventually more fallible human at that.

[-] atzanteol@sh.itjust.works 0 points 1 day ago

I don’t think you understood my point.

Maybe.

Writing code faster was never something anyone with any real knowledge of their domain would think is desirable.

Sorry - that's bullshit. IDEs, code completion, syntax highlighting, editor macros, incremental compiling, editor syntax checking, debuggers, integrated debuggers in IDEs, code generators, RAD and "low code" tools, etc. The list goes on for tools we've created to do that exact thing. You're probably using many of the ones I've listed.

I don’t care if more code is written faster, because that has never been a good indicator of productivity. In fact, I would argue that less code is better.

Okay. I've had an LLM help simplify some logic by refactoring a bunch of things before. The sort of thing that isn't "hard" but is time consuming. I know you don't care about "speed" but it did this work much faster than I would have taken. And it also resulted in "less code".

It's also the sort of work that I may not have done because "man that's gonna bit a bit of work." But since it was easier to do, I did it. So the LLM helped me cleanup our source.

And that's another thing here. I can spend 15-30 mins writing a small script to fetch data from an AWS API, parsing the results, using those results to fetch yet other resources, format the output, etc. Most of which is going to require me to dig through the AWS docs and read a lot of JSON responses, or I can have Claude do it in <3 mins and it just works. I'll throw it away in a few days once I'm done with that task so it doesn't need to be perfect. You needed to hit some threshold of "utility" vs. "time to write the script" to do things like that and being able to do it faster means more utility scripts so I don't have to dig through the aweful AWS console looking for when a scheduled job last ran.

Anyway, it’s funny that you mention, in a somewhat patronising tone by the way, that we need to adapt and not be wary of AI because we have “other skills”.

Patronizing? I was being sincere.

If you want to keep a human in the loop, then fine. Now you have a choke point in your otherwise faster machine. A human who now needs to understand code they haven’t written

You already had that choke-point with code review. I review code I haven't written all the time - have for decades. As a result I've gotten very good at it. If you haven't been then maybe that's a skill you need to focus on since it sounds like you find reading code to be quite difficult (I only say that because you keep bringing it up).

with more and more datapoints coming up suggesting that LLM usage leads to skill atrophy, an eventually more fallible human at that.

Skill atrophy is only bad if that skill is needed. How're your assembly skills these days? I could do it but I haven't in decades. Most developers have very little knowledge about how their computer even works. Ask your average dev what L1, L2 and L3 cache are. They don't care and don't need to. Even memory allocation is something you don't need to care about unless you're writing in C still. And frankly that's a good thing. So a lost skill - but good riddance.

[-] mabeledo@lemmy.world 3 points 1 day ago* (last edited 1 day ago)

I was with you with the whole tooling thing until

RAD and "low code" tools, etc

These have always been terrible.

Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.

Because you said that you would instruct a LLM to refactor code because you didn’t feel like doing it. The irony here is three fold:

  • You would leave a poorly written and unnecessary larger piece of code in your code base, which would increase development time as reviews would take longer, which was precisely the reason why you would want a human in the software engineering loop in the first place.
  • You claim that the LLM would refactor the code for you, but LLMs, in general, are designed with the implied requirement of maximizing token usage.
  • Later in your comment, you said that you don’t care about losing skills that “aren’t needed anymore”, but I wonder, isn’t this the kind of skill, i.e. refactoring inefficiently written code, that you would want a senior developer to maintain? Even more, in the long term, how would you guarantee that you could tell a good refactor from a bad one?

In short, I think you are wrong, but I don’t think you would know why until it bites you.

And further proof of it is this.

Even memory allocation is something you don't need to care about unless you're writing in C still.

This is why we get shitty software, Java apps that blow up once a week and websites that freeze your browser. Because “memory allocation is something you don’t need to care about”.

I guess it won’t make any difference if you replace your skills with a LLM, since it sure sounds like you didn’t have that many to begin with.

[-] atzanteol@sh.itjust.works 1 points 1 day ago

These have always been terrible.

Yeah - I'm not a fan of low-code stuff either.

Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.

I'm not saying you want tools to produce "large volumes of code faster" though. Just that they do code faster. Sometimes that's deletion.

You took this out of context

Apologies - not my intent.

You would leave a poorly written and unnecessary larger piece of code in your code base, which would increase development time as reviews would take longer, which was precisely the reason why you would want a human in the software engineering loop in the first place.

We all make this trade-off. "Do I refactor this now and introduce risk and take more time, or do I leave it for now to be done later?" The LLM helps with the "take more time" component.

You claim that the LLM would refactor the code for you, but LLMs, in general, are designed with the implied requirement of maximizing token usage.

I... What? This isn't even wrong it's just weird. To begin with "token usage" has nothing to do with the amount of code in our code base, removing and modifying code also uses tokens. Secondly this just sounds far to "conspiracy theory" for me to entertain.

Later in your comment, you said that you don’t care about losing skills that “aren’t needed anymore”, but I wonder, isn’t this the kind of skill, i.e. refactoring inefficiently written code, that you would want a senior developer to maintain? Even more, in the long term, how would you guarantee that you could tell a good refactor from a bad one?

That's fair - better developers do and will continue to understand these things. Most developers, however, aren't "better" developers. But it's not a barrier to entry was my primary point.

In short, I think you are wrong, but I don’t think you would know why until it bites you.

I'm curious - what is it you think I'm wrong about?

this post was submitted on 09 Jul 2026
34 points (88.6% liked)

Programming

27651 readers
283 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS