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’re going to need to review any code you and other members of your team write anyway. Or are you just skipping code review? If so then you’re already vibe-coding old-school. Reviewing others code and soliciting feedback on your own is an integral part of software development.
And I dispute the whole “it’s harder to read code than to write it” thing. It’s a helpful aphorism to get Jr. devs to write good code because you can certainly make your life a lot harder by writing bad code (hint: an LLM can help you understand that 15-yr old code that some apprentice wrote).
But code review doesn’t generally take twice as long as it took the developer to create the PR to begin with. Why is that? Because the developer who worked on the code had to solve a bunch of problems, fix bugs they wrote, etc. as you pointed out. The LLM helps with all that as well and the “code, test, fix” loop is a lot shorter. Finding “all those places where I need to make this change” is a lot easier. Refactoring code is a lot easier. Debugging code is easier. Looking up documentation is easier.
I do understand your frustration though - I really do. I’ve been a developer for, well, a long time and I’ve honed my craft over those decades. To see it commoditized like this is…difficult. But we have other skills besides just writing code. The technical knowledge of what that code should look like, how it should work, security best practices, etc.
Keeping the human in the loop. Using AI as a tool but not abandoning software development best practices. If you’re doing those then the source of the code kinda doesn’t matter. Open source projects accept PRs from random sources on the internet for example. They already have processes in place to review code and apply it. It’s already part of the system.
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.
Maybe.
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.
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.
Patronizing? I was being sincere.
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).
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.
I was with you with the whole tooling thing until
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:
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.
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.
Yeah - I’m not a fan of low-code stuff either.
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.
Apologies - not my intent.
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.
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.
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.
I’m curious - what is it you think I’m wrong about?