Vibe coding an OS kernel into existence

I've been trying out Windsurf, which is a competitor to Cursor. I found that it's rather good, so I thought to myself, what's the most absurd thing I can try to code just using AI?

In other words, what can I try vibe coding that wouldn't appear to lend itself to vibe coding? Vibe coding being where you just ask the AI to write the code based on your gut and don't engage your brain.

Operating system kernels came to mind first of all. So I decided to try starting a kernel that runs inside a Firecracker microVM. The end result works quite nicely and it took very little time, but there are caveats.

I asked Claude from Anthropic via Windsurf to write me a bare metal program that can be booted inside a micro VM.

Failed Rust Attempt

On the first attempt, it decided to use Rust. This did not go well, and I'm not sure what is to blame the most.

Windsurf first tried to create a new Rust crate using Cargo. When it discovered that wasn't installed, it tried to install it using apt-get. That didn't work because I'm using NixOS.

In the process, it saw that I am using Nix because of the Nix paths in error output. It didn't think to try using Nix though to install the packages or to use a Nix flake.

So I helped it out to get Rust installed. It then generated the Rust code after checking the Rust version, but the code would not compile.

It then got into a loop trying to compile the code and doing various different things like using Rustup to install the toolchain, switching between nightly and stable, trying different compiler flags, modifying the code, etc.

I'm not that familiar with rust so it wasn't clear to me if it was making progress or just creating new problems and getting a different error message as a result.

Success with C and ASM

I asked it to start again and pick a different language. This time it picked C, which has the advantage of being a language that is very well established, doesn't change much, and is used extensively in operating systems.

This is good for large language models because there's high-quality training data available for C. It also chose NASM assembly for the entry code and created a linker script for LD.

It wrote some c code to output ASCII to the serial console and read an echo input from the serial console. It also made some scripts and config to run firecracker.

Apart from problems with nix again, which I fixed because I think it's unfair to expect AI to deal with Nix, it all worked.

However, the program polled the serial console in a tight loop which used 100% of one CPU core. I decided to try asking it to fix this so that it didn't constantly spin in a loop.

Initially it completely failed to do this; it first broke the program by halting the CPU indefinitely. Then it tried various ways of using the x86 pause instruction, skirting around the real solution which is to use interrupts.

Eventually I asked it why don't you just use interrupts? This nudged it into setting up an interrupt table and using interrupts. Initially there was a bug but it fixed it and subsequently the program worked.

Perhaps if I were more clueless about kernel development this could have been a sticking point. Then again, while the LLM did not attempt to implement interrupt handlers, it did mention their absence and someone could simply question that assumption without knowing what interrupt handlers are.

Final iterations

After this I asked it to add support for an exit command. It actually added a number of commands including help. Initially there were a couple of visible bugs but after providing descriptions of the bugs it solved the issues and got the code working. You can see the resulting code here: https://github.com/richiejp/vibekern-c

It would be quite easy to start picking the program apart. However what's incredible is that it worked at all. Also it's worth thinking about the trajectory and velocity of this technology. Machine learning models are improving quickly and at the same time the tooling around these probabilistic models is improving too.