The claim that LLMs are simply damage control for poor engineering decisions is a gross misrepresentation of the reality of maintaining a codebase the size of Linux. No human can hold the full state space of the kernel in their head. Memory safety is one class of bug, but the most subtle vulnerabilities are logic bugs such as race conditions, incorrect state transitions, misuse of APIs that cross module boundaries, or behavior changes during a refactor. None of these would be caught by Rust’s borrow checker or by typical static analysis tools. These problems emerge from interactions between subsystems written by different maintainers who were solving separate problems and weren’t aware of how features might interact in negative ways.
LLMs, by contrast, can look across a far larger context and identify interactions across the entire codebase. They can trace the execution of a path through a driver, spot where a lock is held too long, or detect that a function’s contract is violated by a caller many levels deep. Humans simply cannot scale this kind of analysis to millions of lines because we can only hold so much information in our heads. Calling LLMs damage control is frankly dishonest in the extreme.
Rust is a powerful tool for eliminating issues like buffer overflows and use-after-frees in new code, but it’s by no means a silver bullet. On top of that, the Linux kernel already has millions of lines of C that will never be rewritten. A Rust rewrite of the entire kernel would be a fantastical idea, and even if that magically happened you’d still have many kinds of problems such as logic errors, algorithmic complexity attacks, or unsafe blocks needed for hardware interaction which Rust would not help you with. The reality is that LLMs help find the same memory bugs in C code today, and many of these problems would simply not be found otherwise.
The whole idea of having multiple supported kernels to break the monoculture is likewise fantastical, and ignores the sheer amount of work that goes into maintaining a project of that scale. It’s also completely orthogonal to the LLM question. If we had ten kernels then each would still be a giant codebase needing the same kind of automated analysis.
Dismissing LLMs as damage control ignores the fact that much of all engineering is damage control, and the real question is which tools give us the best return on effort. LLMs currently provide a unique ability to surface hard to see interactions that no other tool catches.
The claim that LLMs are simply damage control for poor engineering decisions is a gross misrepresentation of the reality of maintaining a codebase the size of Linux. No human can hold the full state space of the kernel in their head. Memory safety is one class of bug, but the most subtle vulnerabilities are logic bugs such as race conditions, incorrect state transitions, misuse of APIs that cross module boundaries, or behavior changes during a refactor. None of these would be caught by Rust’s borrow checker or by typical static analysis tools. These problems emerge from interactions between subsystems written by different maintainers who were solving separate problems and weren’t aware of how features might interact in negative ways.
LLMs, by contrast, can look across a far larger context and identify interactions across the entire codebase. They can trace the execution of a path through a driver, spot where a lock is held too long, or detect that a function’s contract is violated by a caller many levels deep. Humans simply cannot scale this kind of analysis to millions of lines because we can only hold so much information in our heads. Calling LLMs damage control is frankly dishonest in the extreme.
Rust is a powerful tool for eliminating issues like buffer overflows and use-after-frees in new code, but it’s by no means a silver bullet. On top of that, the Linux kernel already has millions of lines of C that will never be rewritten. A Rust rewrite of the entire kernel would be a fantastical idea, and even if that magically happened you’d still have many kinds of problems such as logic errors, algorithmic complexity attacks, or unsafe blocks needed for hardware interaction which Rust would not help you with. The reality is that LLMs help find the same memory bugs in C code today, and many of these problems would simply not be found otherwise.
The whole idea of having multiple supported kernels to break the monoculture is likewise fantastical, and ignores the sheer amount of work that goes into maintaining a project of that scale. It’s also completely orthogonal to the LLM question. If we had ten kernels then each would still be a giant codebase needing the same kind of automated analysis.
Dismissing LLMs as damage control ignores the fact that much of all engineering is damage control, and the real question is which tools give us the best return on effort. LLMs currently provide a unique ability to surface hard to see interactions that no other tool catches.