Linus Torvalds used Claude Code to build a Linux page cache fix that hit 23x read throughput, but kernel reviewers found a race before anything merged.
LLMs make slop code faster than humans can meaningfully review. If you make LLMs the only review layer, then slop gets through because they have similar biases. Stop making slop.
Cool assumption. But pretty sure it’s not how things work at all but sounds great…
What actually happens is that you have a long list of multiple maintainers reviewing , and multiple branches for testing, and multiple layers of review too.
Yes this means the review process is working. What is important to track is if LLM code causes a disproportionately large number of reviews or reviews that take longer because whoever generated the code doesn’t actually know what it is doing. Hopefully not the case here but it does happen a lot with LLM coding.
LLMs make slop code faster than humans can meaningfully review. If you make LLMs the only review layer, then slop gets through because they have similar biases. Stop making slop.
You had to lean on that assumption that there’s a massive amount being produced to make this point though.
The actual operating point is that the slop is made faster than humans can WRITE it.
Reviewing 100 lines of code thats 90% there and took 3 minutes to produce is faster than writing it from scratch, there’s no getting around that.
For me the issue with it is that all (hyperbole) work is about to become reading instead of creating, dull.
You might save time in writing the code, but you lose time from the code doing things that aren’t in your mental model of the program
Cool assumption. But pretty sure it’s not how things work at all but sounds great…
What actually happens is that you have a long list of multiple maintainers reviewing , and multiple branches for testing, and multiple layers of review too.
https://www.kernel.org/doc/html/next/process/maintainers.html . See that long list of maintainers for a start.
The actual policy is that everything ends up getting reviewed by a human. If I post a patch, it doesn’t go straight to master
If it’s not being properly tested and maintained, it gets dropped irrespective of what it is (remember devfs?)
Also, I’m not sure about the kernel specifically, but on projects I submitted code to, they often wanted complex patches broken down if possible.
Yes this means the review process is working. What is important to track is if LLM code causes a disproportionately large number of reviews or reviews that take longer because whoever generated the code doesn’t actually know what it is doing. Hopefully not the case here but it does happen a lot with LLM coding.
Linus secretly understands nothing about the Linux kernel
XZ Utils made it past all those checks with malicious code from a human.
If they’d been more careful with their tarball commits it probably would have made it into the final and commercial distros.
It made into Homebrew for instance.
Correct me if I’m wrong, but that’s not the kernel…
You are correct, also has nothing to do with AI, just malicious actors.
Yep. And the kernel did actually have a backdoor attempt at some point. And it was noticed too https://www.infoq.com/news/2013/10/Linux-Backdoor/