There appears to be a few bad actors in the Lemmy community spreading ragebait for personal gain

In fact, the same mechanisms added at the beginning to catch bad human written code are the exact same that catch bad AI code

  1. No, the Linux kernel DOES NOT use AI to automatically approve code for inclusion. As far as I can tell, there are no plans to do so
  2. The Kernel actually has a huge number of maintainers. As part of the process, all patches are reviewed by a human who provide feedback as part of the process, and patches get bounced back and forth multiple time.
  3. Patches don’t just magically go straight to master. The maintainers generally have their own branches where it goes to, then it goes to staging trees like Linux-Next. It goes through many eyes, and many tests by the end. The idea that AI code is overrunning the kernel is rediculous
  4. Maintainers also check that the code meets coding guidelines and is written properly, and solves the problem they are trying to solve. Yes, they also ensure the code isn’t slop
  5. LLM’s though might be used to identify obvious problems with the code (which they are VERY good at), or even identify code that doesn’t follow coding guidelines.
  6. The only thing that matters is the human who submitted the code, as they should be checking the code submitted anyway (including LLM generated code)

Writing bad code isn’t something new, and isn’t unique to LLM’s. Coders (and it seems some “journalists”) have been writing slop since computers were invented.

The process hasn’t gotten less stringent (probably even MORE stringent as there is an additional set of robotic eyes that can also check), and the same mechanisms that were put in place to catch badly written code 10 years ago, are still there now… With no changes.

  • auzy1@lemmy.worldOP
    link
    fedilink
    arrow-up
    9
    arrow-down
    3
    ·
    11 hours ago

    True, but its still not enough to handle all slop. The number of maintainers have also grown though dramatically… Also, don’t forget that LLM’s can also be used to identify bugs in patches more quickly too… So, more are getting submitted, but, lots of bad patches are being rejected faster too, with less effort (that required human intervention in the past).

    This might be true, but that is not a reason to accept or normalize slop. Define Slop…

    The difference to before is, that nowadays its easier and faster to write (or generate) slop in mass that looks legit. Finding out its bad code or wrong can suck up huge amount of time of maintainers, which would have worked on something more productive instead. We’ve all spent hours doing that though on our own code. Again, the buck stops with maintainers. One thing that Maintainers are going to do though, is get them to prove the code first and test the code in other trees first, before even trying to push to main

    There’s always been code that has been bad, like Linus never liked the Con Kalivas performance patches, or Reiser4.

    It is also finding a lot of security issues and bugs faster too though

    I’ve actually written optimisations for code that I thought would be faster, and turned out to be a waste of time in production

    For you maybe, but there are issues using Ai regardless of how the code looks. Both sets of code need the same level of examination by humans anyway. In fact, in some cases, the AI code I’ve seen has been better than the code i wrote

    I mean stuff like how the LLM was trained on in example, and if the licensing will become an issue one day. That is true, and I agree with that. That’s the one point that does stand out, but doesn’t have anything to do with the claim by certain people in the community about the Linux Kernel being overrun with bad code.

    What I would like to see is a LLM that’s developed exclusively using Open source compatibility licences with FULL traceability to sources uses, and a way to specify licencing allowed (or something similar).

    There is one issue with AI that you didn’t mention however. The biggest problem with AI is that it adversely benefits closed source companies via Open source code. Because closed source code isn’t easily accessed by the AI for training, but Open source is. The other issue is that hackers won’t avoid LLM’s based on the ethical issues, so, unfortunately, it forces developers to use them to keep up with the cat and mouse game.

    As a developer, am I happy about AI? For code review yes, but, it makes my job suck and not fun. And no, I’m not happy about the ethics… There are a lot of things that sh** me, like AI companies SHOULD be forced to pay royalties to everyone they stole info from.

    However, what sucks, is that we can’t pretend it’s not a thing, and if Linux wants to remain competitive, it does need to use it.

    The best thing we can do though, is petition to tax AI companies and pay producers of the information. That would make AI unprofitable immediately and kill the industry

    • naught101@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      2
      ·
      9 hours ago

      What I would like to see is a LLM that’s developed … with FULL traceability to sources uses,

      That’s not really possible. I mean, you can list the training data, but you can’t attribute a specific output to a specific piece of training data, because all of the training data influences all of the weights. It’s not possible to know which training data influenced which weights and how, because that data is not retained (and it would be massive and difficult to interpret if it was -on the order of weights × number of training context windows, and the weights alone are already terabytes)

    • thingsiplay@lemmy.ml
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      11 hours ago

      Because closed source code isn’t easily accessed by the AI for training, but Open source i

      Besides all those Ai users, where code is uploaded to their servers.

      • auzy1@lemmy.worldOP
        link
        fedilink
        arrow-up
        6
        arrow-down
        1
        ·
        11 hours ago

        On commercial accounts, you can turn off training, and they have policies generally to avoid code leaks (another bad thing for open source, the free accounts you generally can’t, because you are the product).

        • eestileib@sh.itjust.works
          link
          fedilink
          arrow-up
          8
          ·
          10 hours ago

          If you believe that they’re not using corporate code to train their models… These guys are all total lying sociopaths who think they’re on a mission from the machine god, everything is permissible in their minds.

          • Riskable@programming.dev
            link
            fedilink
            English
            arrow-up
            6
            arrow-down
            1
            ·
            9 hours ago

            I work for a HUGE organization that uses all the big AI companies products. We have a contract for each that specifies that they MUST NOT train their models with our code.

            If they do it anyway, my employer’s vast teams of lawyers will make them take out brand new billion dollar loans to pay off the settlements. They might not even survive such a lawsuit because if they were caught using our code you can bet your ass they used everyone else’s that has a similar contract.

            • eestileib@sh.itjust.works
              link
              fedilink
              arrow-up
              5
              ·
              9 hours ago

              I think in a sane world that would be the outcome. But this world (and particularly the AI cultists) is not sane.

              I also worked at a couple of huge corporations (which are both major hyperscalers) and they tried to steal ip from each other pretty much continuously, that was one of the reasons that you had to keep switching companies to advance your career.

              Look at how open AI straight expected candidates to bring development models of upcoming Apple devices to interviews. These dudes are more degenerate than you think, I promise.