I wonder how far we are from having a GPT-X.Y operating in a loop, creating a fully Linux-compatible kernel with all 437 system calls in Rust within a day, which includes testing, debugging, and recompiling.
I still think perhaps not too soon. I think the problem that there are many things to optimize for. One of them is correctness, but if a program runs this does not mean it is correct. Another thing is security. How to test the system for security? Have another LLM playing an adversary and try to hack the system?
This said, I wonder if someone manages to pull this off what the implications might be.
One of them: Have this system re-run automatically everytime as long as the Linux kernel is maintained.
Then why should anybody invest the effort of continuing development of the Linux kernel?
Then how to advance the development? Just tell the LLM to add a feature?
Look at things like ebpf and uring for examples of meeting real needs with new development in the kernel.
I doubt that a LLM will be able to come up with the ideas, and implement these things without substantial prompting.
For the every day stuff. Yeah, sure. Though you'd be amazed how many strange corner conditions POSIX and Linux have even around "simple" things like pipes.
... Understanding the whole context may be beyond where we are today based on what I have seen from LLMs, there may day where they can come closer. But as the Klingons say: "Not today."
«Gee what if the kernel could do clairvoyance? Implement a syscall! Specify the parameters and the structure of the data being returned!»
</s>
A more realistic scenario is just imitating Linux' syscalls.
EDIT: Just had an idea what could happen. Some guy can't do kernel development but is annoyed that a feature request got declined. Someone else set up an LLM-driven kernel development system. That guy now tells the system to implement said feature. The rest of the story: even more community fracture.