29
What does it mean for a programming language to be AI slop? (lemmy.ml)
submitted 2 months ago by to c/fuck_ai@lemmy.world
31 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] 15 points 2 months ago* (9 children)

"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.

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 4 points 2 months ago (1 child)

    +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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 2 months ago (3 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 2 months ago* (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 2 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 months ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 months ago (2 children)

    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...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 months ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •