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 won’t use AI to auto approve code for inclusion. And 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 (bugs / coding guideline issues) with the code. These don’t generate “slop” just find issues
  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

    • auzy1@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      11
      ·
      edit-2
      3 days ago

      The funny thing is that I wrote a Websocket server library years ago, and recently (as we scaled up), there were reports of bad performance in much larger systems

      AI actually basically called my code slop (and it was), and made changes that improved performance, and fixed issues with incomplete frames. The solution it came up with was far better, and far cleaner than mine. I never would have come up with it…

      And, I never would have guessed that’s where the performance issues were either

      I feel like there are people who are willing to point the finger instantly when AI generates bad code, but, it doesn’t get credit when it improves it

        • auzy1@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          3
          arrow-down
          2
          ·
          3 days ago

          I did profiling. But, there were many other more likely candidates, and, its a bit of a weird edgecase in our case (since we don’t control the entire environment… It’s middleware)…

      • Croquette@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        5
        ·
        2 days ago

        So you are just a terrible developer then. Not sure what you are trying to show here with your anecdote other than your inadequacies to do your job properly?

        • auzy1@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          2
          ·
          edit-2
          2 days ago

          What I said doesn’t indicate that at all. Not sure how many websocket servers you’ve written, but there is a reason that there are entire test suites to test them

          Even worse, there are all kinds of combinations of half finished frames, masking, etc. The data size isn’t predictable and you can also have fragmented frames too.

          We also need to connect to all kinds of clients which do things slightly different

          And, I had limited time to write it in as well.

          If you’re not getting any bugs, you’re either not doing anything new, or you’re designing really basic apps that offload the hard work to someone else.

          Big shocker, but the performance fixing came down to bit handling of the header… and yes, that made a huge difference overall. The code wasn’t wrong…

          We’re working with embedded systems limited by RAM and CPU that operates on a single thread for everything, with lots of clients .We don’t have the luxury of throwing in a better CPU or just pretending it’s an issue. Even simply enabling logging drastically changes the CPU usage

          • Croquette@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            5
            ·
            2 days ago

            What I said doesn’t indicate that at all.

            AI actually basically called my code slop (and it was), and made changes that improved performance, and fixed issues with incomplete frames. The solution it came up with was far better, and far cleaner than mine. I never would have come up with it…

            I mean, these are your words.

            • 9tr6gyp3@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              16 hours ago

              So by your logic, if you cant code better than Claude, you’re a terrible programmer. Got it.

              Guess I better let Claude code for me then. Dont want to add additional humanSlop code.

                • 9tr6gyp3@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  11 hours ago

                  We’re all terrible developers because Claude is patching all our slop. Are you intentionally not paying attention to the massive amount of security patching happening this year?

                  I have a feeling you probably arent keeping up with whats going on, and you telling someome they are a terrible developer doesn’t have a lot of weight behind it.