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.
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.
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.
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.
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 things become automated, different things become relevant and that’s what people shift their attention to.
If this is primarily fixing old issues, over time we should see a sharp drop off and then even fewer security fixes then before due to fewer being introduced, due to being caught by AI upfront.
On the other hand, if AI is introducing more issues than it is resolving, we’ll see the baseline of security issues being found permanently addressed.
how many are introduced by new ai code?
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.
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.
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.
Right, the question is, if they’re changing the writing code practices, do you think there might be any change in the reviewing process?
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.
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.
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 things become automated, different things become relevant and that’s what people shift their attention to.
If this is primarily fixing old issues, over time we should see a sharp drop off and then even fewer security fixes then before due to fewer being introduced, due to being caught by AI upfront.
On the other hand, if AI is introducing more issues than it is resolving, we’ll see the baseline of security issues being found permanently addressed.