189
Linux security vulnerabilities fixed per kernel version (lemmy.ml)
submitted 1 week ago by to c/linux@lemmy.ml
88 comments fedilink hide all child comments
 

Something good coming out of AI, it seems.

you are viewing a single comment's thread
view the rest of the comments
[–] 36 points 1 week ago* (6 children)

Assuming that Linux kernel team continues to use the same review process they always had, there's zero reason to think that there would be an increased rates of bugs due to LLM generated code. This seems to be something people without programming experience don't understand. Code quality isn't premised on trust, it's a product of the development process. Projects ensure quality by having specifications, tests, doing code reviews, and so on. As long as the practices the kernel team has established continue to be applied, they will catch the bugs made by LLMs or humans exactly the same way.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 14 points 1 week ago (1 child)

    Idk man. I've certainly become more lenient in Code Reviews because I have to do like 5 a day instead of 2-3 a week, all with like 2k lines of changes. I literally don't have the time to fully read tests anymore, I mostly just skim them and check whether they have an assess statement that looks somewhat reasonable.

    Hell, I've recently had a meatpuppet of a coworker brag about how his implementation of a Card component for the UI library had 199 tests. I'm so glad I wasn't assigned to review that shit. But it sure looks great to the higher-ups 🫠

    Hopefully working on the Linux Kernel doesn't suck as much as working for a big corp.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 points 1 week ago

    Large corps always end up implementing shitty practices because business practices are driven by pencil pushers. Even before LLMs, some of the most soul crushing jobs were found at large corps working with shit like J2EE. That's nothing new really.

    At my job, we use LLMs, but nobody is making 2k loc PRs all of a sudden, and we still pair up to review code, and generally work at human speed.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 week ago (3 children)

    As long as the practices the kernel team has established continue to be applied,

    Right, the question is, if they're changing the writing code practices, do you think there might be any change in the reviewing process?

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

    I've seen no evidence of that so far. I also fail to see how writing code practices are related to the review and quality control process. These things aren't linked in any way that I'm aware of.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 1 week ago (1 child)

    The ability to comprehend code underlies both of those and is trained by both. Doing less of one reduces your training.

    LLM use leads to skill deficits, it's shown up in studies but also just, use it or lose it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 week ago*

    The only studies I'm aware of used tiny samples and produced muddled conclusions. If you have some conclusive empirical research then do feel free to share it though. Meanwhile, using LLMs doesn't mean doing less, it just means focusing on different things. The skill deficit here is the same kind as the skill deficit people have using punch cards or writing assembly by hand today. As more aspects of coding become automated, different things become relevant and that's what people shift their attention to.

  • permalink
  • fedilink
  • source
  • parent