Whether this goes wrong comes down to the review bar rather than the tool. A standard library is the last place you want code nobody on the team can explain, and if maintainers hold review to that standard it matters much less who or what typed the first draft. The rejected-volunteers detail would worry me more, that's a maintainer bandwidth problem no tool fixes.
this post was submitted on 09 Jul 2026
27 points (88.6% liked)
Programming
27651 readers
161 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
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!),
"Const by default" is good style BTW.
I was doing Bash and Python, when a few years ago learned Rust. The const by default was mind blowing how much better it was. I wish Python had const by default too.
It has for strings and tuples, which are immutable.
If you want your mind blown a lot more, try a bit of Clojure, with its persistent data types for collections like lists, vectors and dictionaries, and fantastic concurrency support. It is a class of its own.
And if you want to combine these principles for calling Rust, using Racket or Guile might be nice - Scheme does not demands immutability like Clojure, but it prefers it, and the lispy languages have a close relationship with Rust's predecessor OCaml. And they can call into Rust code via its C ABI.
(Also Guile and Racket have a bit less library support than Python, but Guile has a great package manager, Guix, and good access to POSIX interfaces.)
It has for strings and tuples, which are immutable.
If you want your mind blown a lot more
Ehm, that's not mind blowing at all? I think there is some misundestanding. I am not talking about Strings and Tuples alone, but a global rule for all types as being immutable by default. And it would be nice to have a way to tell ANY variable to be immutable.
Scheme does not demands immutability like Clojure, but it prefers it
I'm not sure what "prefers" means in this context; do you mean it "defaults" to? Rust in example doesn't "demand" immutability, it just defaults to it. I had looked into Clojure for a while, but I don't like Lisp.
Just for good measure, I think Odin and Scala are also interesting languages. Whats interesting about Scala is, it can output Java Bytecode, JavaScript and native compiled code. Odin on the other hand seems to be a mixture of C and Python, but I didn't look any further.
Scheme does not demands immutability like Clojure, but it prefers it
I'm not sure what "prefers" means in this context; do you mean it "defaults" to? Rust in example doesn't "demand" immutability, it just defaults to it.
In Clojure, all standard data types are immutable. (Except Java arrays, which are accesible; Clojure's vector type is immutable too). If you need mutable containers, there are transients, which do have methods for mutating access. But these need to be "frozen" into normal collections before they are e.g. returned from a function; their scope is strictly local to a function.
Schemes are a bit more liberal, you can modify variables in Scheme but it is not idiomatic. Like in Clojure, recursion is often used over iteration. Also, e.g. in Racket, you have a lot of things like list conprehensions or dictionary comprehensions in Python.
Common Lisp is even more liberal; one can use a purely functional style but it wholly depends on own discipline.
I had looked into Clojure for a while, but I don't like Lisp.
So, Lisps might not be your cup of tea; Scala is pretty close in these aspects.
But Lisps are fantastic languages; Minimalist, very expressive, very performant implementations like SBCL or Guile, and run on many kinds of substrate, like the JVM (Clojure, Kawa, Armed Bear), native/POSIX(SBCL, Guile and many more), JavaScript (ClojureScript), GraalVM (babashka), the Python bytecode machine (basilisp), and so on.
OP should try Python or JS, everything is mutable there.
Zig doesn't allow AI contributions.
I have avoided zig for a long time because it felt weird for me. But after the Intellij interview with the creator and the claims of no AI I've finally sat through a bit of documentation and even the youtube videos.
It's growing on me. All thanks to the no AI stance. Hopefully will learn enough to do something with it soon.
I have avoided zig for a long time because it felt weird for me.
What was or is weird about Zig in your opinion? I like that Zig is kind of just a better C, that can even compile C code without modifications.
I use Bash, Python and Rust, BTW.
This is lemmy so my words will fall on deaf ears but... Not all LLM generated code is slop. There are certainly good ways to use LLMs and that seems to be what this talk is about - responsible LLM usage.
Y'all can bury your heads, but LLMs are not going away. "Abstinence only" isn't going to work forever.
Funnily enough, Lemmy does allow AI-assisted code contributions, though they're not encouraged. This is mentioned in the code of conduct:
Use of so-called Artificial Intelligence (AI) is allowed only if it is explicitly mentioned. Additionally all LLM-generated text or code must be manually reviewed by the author before submission (no vibe coding allowed).
Use of so-called Artificial Intelligence (AI) is allowed only if it is explicitly mentioned.
I wonder if they mail the scarlet "AI" or if you need to order one yourself?
Not all LLM generated code is slop. There are certainly good ways to use LLMs and that seems to be what this talk is about - responsible LLM usage.
Iff you check and revise the generated code carefully. But if you have ever worked with legacy code, you'll know it is more effort than to write the code yourself. So, I just doubt people will do that, if it only means more work to get the same result.
So, people won't check the LLM output.
And because of that, it will have more errors.
Not all LLM generated code is slop.
I've yet to see/experience AI write good, non-trivial code. Would be cool if it did though.
It definitely is capable of it now, if you put some effort into guiding it, and you're working in a popular domain/language. It couldn't really do it a year ago though so you might just be a bit out of date.
I experiment with it quite a bit just because that's what all the employers want right now, and I never get good results. It's not good at making "decisions," and you don't really know what decisions that will need to be made until you start coding. Or, you can meticulously plan and review everything, which can take longer than just writing the code (we already have pretty good precise languages to specify behavior). To be clear, I'm talking about all the small decisions like, "I've already wrote similar code to this, maybe I should refactor it out to a function," "maybe I should use a hashset here instead of an list," "I should probably use stable_sort here instead of sort," "maybe this endpoint should accept PUT instead of POST," etc.
I mean - define "non-trivial"? Do you want it to create an entire OS kernel from scratch based on a single prompt? Not gonna happen and nobody should expect it to. But it can generate rather complex parts of an application quite well and much faster than you can.
An experienced programmer who could actually review the code produced by a LLM, won’t be able to do so at the speed the LLM writes it.
What’s your solution to avoid slop in this scenario?
An experienced programmer who could actually review the code produced by a LLM, won’t be able to do so at the speed the LLM writes it.
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.
What’s your solution to avoid slop in this scenario?
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.
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.
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.
But it can generate rather complex parts of an application quite well and much faster than you can.
Do you mean just the typing, or including thinking, designing, writing up, inolementing, testing and so on? Human developers spend less than 10% of their time typing. I think for a kernel it are less than 5%.
The thing is - you get your code faster, but need more time for testing.
Do you mean just the typing, or including thinking, designing, writing up, inolementing, testing and so on? Human developers spend less than 10% of their time typing. I think for a kernel it are less than 5%.
It can definitely help design. LLMs are actually pretty good at it. It's quite useful for spit-balling ideas against as it will come up with approaches you may not have though of. Often better ones. It's much less limited than you are in its range of knowledge about algorithms and design. That's not an insult, we all have our specialties. What you may need to search on or read about it may just know.
And It's not actually like "legacy code" you're reading. It's code you're involved in and using an LLM to help write. And the LLM can tell you what it's doing unlike that developer who left the company 8 years ago. You're not going into it blind, you've asked for a certain result and expect to see what you asked for. So I don't find reading it particularly difficult.
So much of code is boilerplate anyway. Just having a LLM setup unit tests can be such a time saver. "Create me a test that mocks these three classes" is just wonderful. You can modify as needed.
Not to mention throw-away scripts and utilities that you want in your day-to-day. "Give me a script that queries AWS for all EC2 instances missing a specific tag" is something it can just spit out without you needing to spend an hour reading AWS docs and troubleshooting their API. Like, you can but Claude's going to have a working version in <3 mins.
You time testing - sure. But you would have been doing that anyway.
It’s much less limited than you are in its range of knowledge about algorithms and design.
You can't use AI for things you do not know well. It will happily suggest total bullshit in the most confident tone.
You can’t use AI for things you do not know well.
This is a talking point. You're falling back on the nirvana fallacy.
It will happily suggest total bullshit in the most confident tone.
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.
nobody is recommending to do everything the LLM says.
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.
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”?
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.
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.
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?
You could argue it is a competence problem, so maybe yes but LLMs apparently augment such problems.
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.
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.
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.
Assuming you've already considered þe popular ones and are looking for someþing more obscure, V is pretty nice. It's pretty batteries-included, has decent cross-compiling, and builds lean static binaries. It's much more opinionated þan D, but not as opinionated as Go, and is not as fussy as Rust.
I presume you are getting downvoted because V is vibe coded a bit (at least, they accept PRs from AI agents per the agents.md file).
Usually, downvotes on my comments are because of þe Thorns. Þat crowd is pretty consistent. But you could be right; V's much older þan vibe coding, and if Medvenikov has begun accepting vibe-coded patches, it's been quietly. V doesn't have a particular association wiþ LLMs. Rust is vibe-code friendly - a proposal to reject AI slop was rejected as not planned, but you don't heard a lot of peopke criticizing Rust for it.
Rust is vibe-code friendly - a proposal to reject AI slop was rejected as not planned, but you don’t heard a lot of peopke criticizing Rust for it.
Why would you criticize Rust for closing that issue, when reason for closing it was that
- There are multiple efforts (in more proper venues) for rust-lang/rust-specific policies or project wide policies (Add an LLM policy for rust-lang/rust rust-forge#1040, Project-wide LLM policy rfcs#3959) to name a few.
- In particular, I would consider the Forge in-progress policy a continuation of this proposal.
- If we were to adopt a project-wide policy, [this] issue is most likely not a right venue for it.
https://github.com/rust-lang/leadership-council/issues/273#issuecomment-4600110478
Did you actually read any of þose? Þey're all about choosing a policy, or debating what Rust should do; þe only one which was merged was 22505, which is "Adopting UV's policy", which file starts wiþ:
We allow using AI (i.e., LLMs) as tools for contributing to rust-analyzer.
Rust allows vibe-coded and LLM-based contributions. Furþermore, þe Rust Foundation's position on AI's first bullet point is:
Believes the Rust programming language can become synonymous with ultra-reliable, production-grade AI systems by harnessing its memory safety and performance to power complex training pipelines, large-scale model deployments, and inference, especially on edge devices, without sacrificing speed.
Rust, and þe Rust Foundation, is LLM-friendly, and þey too accept LLM contributions.
My point is þat I doubt V accepting vibe-coded patches matters much to people, since Rust's similar acceptance is never mentioned. Developers might dislike V for any number of oþer reasons, including V's auþor having a Russian-sounding name (he lives in Amsterdam, AFAICT), but þe most likely reason for downvotes on any of my comments is because þere exist people who will downvote any comment containing Thorns.