I have seen people on the Fediverse saying that Rust, Python and some other languages are AI slop now.
Apart from the numerous ethical problems with AI, what are the practical implications of this? If a language itself is vibe coded, does that mean any software written in that language will also be buggy and perform worse? Or is it fine to use a vibe coded language like Rust as long as I don’t use AI myself?
“Vibe coded” should mean “generated by people who aren’t coders.”
Its often a red flag for sprawling, buggy, over hyped projects with questionable functionality.
This does not apply to Python, Rust, the Linux kernel and such because the maintainer teams have been coding forever, and know what they’re doing. They have contribution standards. They have institutional structure that doesn’t change at the drop of a hat. If there are regressions or missed quality checks, they will deal with it, like always.
These languages are not vibe coded. You should not lose sleep over this as a user. With Python/Rust in particular, pip/cargo security is a MUCH larger existential threat.
Now, smaller projects?
Theres definitely a risk of tiny maintainer teams going off the rails with “AI psychosis.” Thats a real thing. You should still evaluate, not automatically reject, but an obsession with AI is definitely a red flag for a project.
+1 to the pip and cargo security issues.
Mind boggling that they don’t fix these, even after major companies offer them tons of money to do it
Python is stubborn.
Rust is… I dunno.
But yeah. It feels existential. The repositories cannot go on like this, now that theres blood in the water for hackers there.
They have institutional structure that doesn’t change at the drop of a hat.
But could the institutional structure erode over time? For example if some of the maintainers get fed up with the AI hype and leave, and the remaining ones lean into AI even more?
Would it affect the stability of my project in the long run if that happens, even if things are relatively okay right now because of the standards and institutional structures?
lean into AI even more
I think its important to distinguish:
-
Leaning into ML-driven tooling for utilitarian automation.
-
Leaning into vibecoding, or going down weird chat rabbit holes.
Many (most?) maintainers are doing the former already. That’s fine, IMO. It’s not uniquely dangerous; its yet another set of tools to integrate over time. But if you aren’t okay with that, you’re going to have to be very, very selective with the software you use.
The later is rarer among established developers, mostly because those devs tend to not to vibecode if they already know what they’re doing. Maintainer status tends to be on merit and history, and so on.
It’s possible some projects face significant drama and are left with 1-2 maintainers deep in AI psychosis, but I think that’s extremely unlikely with projects as large as Linux, Python, Rust, Debian, Arch and so on. And ultimately it’s the human that has to irreversably degrade a project; LLMs won’t do that by themselves in any sane workflow.
Leaning into ML-driven tooling for utilitarian automation.
I am worried specifically about LLMs/chatbots, not machine learning in general.
The later is rarer among established developers, mostly because those devs tend to not to vibecode if they already know what they’re doing. Maintainer status tends to be on merit and history, and so on.
What about outside contributors submitting massive patches using AI, and overwhelming the maintainers? This recently happened with Linux, and the maintainers said they will use LLMs to review submissions going forward. Does that increase the risk of bugs creeping in?
I apologize if I seem argumentative. I am trying to understand the risks of AI generated code, and you seem quite knowledgeable on the subject.
Nah its perfectly reasonable to worry, and honestly a lot of what I assert is just opinion.
LLMs are very good at playing utilitarian, “helper” roles, like a program. Parsing big blocks of text to flag things for humans, categorization, search, workflow automation; text models were doing this before we started calling them LLMs.
I honestly don’t know the details, but getting LLMs to screen PRs sounds like wonderful automation to me. “Is this a vibecoded mess, and why?” “Does this conform to X standard?” Security issues. Raising flags before reviewing. I’d guess the kernel maintainers are using LLMs for “bulk prescreening,” but maintainers are still going to look at every line of code with their eyeballs before it goes into the kernel. An analogy might me an LLM that flags issues for Wikpedia editors (spam, malicious edits, categorization, formatting nagging, citation requirements) to speed up “busywork,” but ultimately every consequential action has to go through a human.
LLMs also great at generating boilerplate, refactoring a line, making a testing script; small, focused tasks. I bet the kernel devs will use it for that, and IMO that’s harmless.
I just don’t think they will allow vibecoded slop into the kernel. They’ve been draconian about code quality for decades, and they aren’t going to change. And the way I see it, the LLM submission reviewing is fighting fire with fire.
-
python has had surprisingly few security issues compared to other, often newer, packaging systems. the big one in pypi from last year turned out to be because of a vulnerability in github actions that allowed people to hijack the production pipeline from a pull request, and i wouldn’t really class “person with the maintainer’s key can push new versions from the maintainer’s repository” as something they need to fix…
Thats exactly the issue, though!
Python package installers can do basically anything when they run. Thats an unreasonable security risk; I shouldnt wonder if upgrading a package has infested every inch of userspace, or have to run Python in docker, as maintainer keys or major packages are going to get compromised one way or another.
In other words, I think sandboxing should become a more central, default approach. At least for installation. But perhaps for execution, too.
yeah the setup.py method is a bit scary. but then again we also have build.zig, autoconf, and package.js
with acceptance of vibecoded contributions, the trustworthiness of the tool - and things built with it - goes down. it pushes the burden of verification downstream, unless the maintainers can show that they have full understanding of and legal rights to, the contributions.
ken thompson (of unix and c) demonstrated in the 80’s how he could add code to a compiler binary that in turn added code to everything built with it, including itself, without any visible traces in source code. researchers at the university of minnesota created deliberate exploits in the linux kernel for years without consent to test out the reliability of the reviewers, and the entire university was banned from contributing as a result.
when running tools with ai contributions, you risk doing both of these things on accident because when prs become hundreds of files big nobody can verify everything, and we’ve already seen ai inject seemingly nonsense code into projects which can be used as a backdoor.
Do you have evidence of these languages embracing AI contributions?
…huh?
surely if this interested you, you could find it with a single web search? i’m not even the one making the claim.
Yes, you are the one making the claim.
???
What the fuck is even reading comprehension anymore u were just answering the main question 😭
its a primary school in berkshire i think
tbh, imo the major languages’ maintainers are probably mostly competent enough to not fuck up the codebase much even when using llm for codes. they’d reject slop code from llm just like how they’ve rejected slop merge requests from humans till now.
random “html programmer” doing “vibecoding” is whole different from old veteran greybeards using llm
I hope so. But we have seen how Andrew Tridgell, a competent, veteran greybeard, turned rsync into an unusable mess when he embraced AI.
that’s not really what happened. bugs in rsync happened as always, and they didn’t have a test case to catch it. in fact, (afaik) they were developing a robust test by the time that ‘news’ came out.
Removed by mod
Though Rust suffers from the same kind of toxic positive hype that is also driving AI, it’s not slop so far.
D has some bigger issues, as some community members, especially discord member Serg Gini, think we need to embrace AI as much as possible, including straight out vibe coding in the standard library and the compiler, this allegedly already led to issues with the lesser used Dcompute (GPU, etc.) target. Some community members (including me) are thinking about creating a fork, with our own improvements on the language that would make it better to use (such as fixing
opApply) rather than chasing trends dictated by tech oligarchs in the hopes of getting tech oligarch money, and hustlebro users that like to LARP as software devs.Such big claims require very thick reports with evidence.
The Open Slopware repository on Codeberg has a section on programming languages that use AI, with citations.
https://codeberg.org/ethical-foss/open-slopware#programming-languages
How exactly are these languages that were around before vibe coding vibe coded?
The maintainers accept LLM generated patches or use LLMs for code review or finding bugs.
Those are not the same. There’s no problems with using AI to find security bugs and then having a human verify and patch it
Removed by mod
Ignoring whether these languages are implemented using AI (I think Rust’s LLM policy prohibits AI code atm), some of the properties of these languages might make them appealing to AI users.
Rust has its safety guarantees, detailed error messages and the “if it compiles it probably works” mentality, which I assume makes it easy to use with AI. And Python probably just had a humongous amount of training data available, so LLM outputs for Python might be higher quality?
It’s why I think I see these two languages pop up in a lot of vibe coded projects. Which sucks for me since I actually enjoy programming in Rust like you do and have to put up with all the AI hype bros in the community
python is also the main language ai stuff is built in, due to its popularity with researchers.
I think that’s mainly due to the fact it was (and is) popular for doing data science. And it’s kinda good at it. Hence we got the AI people use it as well, because a lot of AI (and machine learning in general) is concerned with preparing all the data that goes in.
The argument is that those languages are incorporating ai code into the codebase sometimes without documentation. That’s all it means is that they don’t differentiate for before this codebase started using AI code (slop).
