- Entry date
- 15 November 2024
- Category
- Operating systems
- Lead over the world
- ~1–2 years ahead
- Access
- 🔓 Public
We asked whether an AI could write a whole operating system, not a snippet. It wrote fifty thousand lines of Rust and compiled clean — then got the boot mode wrong.
- 50K+
- lines of Rust, AI-written
- 11
- kernel subsystems
- 0
- compile errors at freeze
- 1
- architecture decision that sank it
Honest evaluation
Compiling clean at 50K+ lines with 0 errors is proven; 'it's a working operating system' is disproven — it never booted.
What would prove or disprove it further
What would move the second claim to proven: fixing the boot-mode handoff and getting the kernel to actually boot on real or emulated hardware, at which point the "working OS" claim would have its own falsifiable test to pass or fail. That never happened — the project was archived as a superseded prototype instead, with the lesson (decide the bottom of the stack first) carried forward into later work rather than the kernel itself.
The evidence — full reasoning behind the verdict
Verdict: partly-proven. Two separate claims sit inside "an AI wrote an operating system," and they landed on opposite sides of the line. "An AI can write 50,000-plus lines of real systems Rust that compiles clean" is proven — the code exists, eleven subsystems, zero compile errors at freeze, a real and measured fact about a notoriously unforgiving compiler. "It's a working operating system" is disproven — it never booted, stuck at a 32-bit/64-bit handoff mismatch during the Multiboot stage.
It landed here because the project measured the right thing and didn't let a clean compile stand in for a working machine. Compiling clean tells you the code is internally consistent by Rust's rules; it says nothing about whether the processor comes up in the mode the kernel expects. Those are different bars, and the report keeps them separate rather than letting "zero compile errors" imply "it runs." The root cause named is process, not capability: the boot-mode decision — one of the very first architectural calls in an OS — was made too late to change cheaply, so everything built on top of it inherited the mistake.
A year before this, in August 2023, we had gone back to bare metal by hand — a 16-bit x86 bootloader and a toy kernel, written to understand what actually sits beneath every web app. That curiosity left a question hanging: if we understand the bottom of the stack, could an AI build the whole thing? Not a function. The operating system.
What it was
The bet was deliberately extreme. Most people in late 2024 used AI to autocomplete a line or draft a component. We wanted to know if the same tools could hold a bare-metal, 64-bit operating system in their head — memory management, interrupts, a scheduler, drivers, a boot path — and write it in Rust, a language that refuses to compile most of the mistakes a kernel invites.
It was as much a test of us as of the AI: could a single person, directing an AI, produce something that normally takes a team and years?
What we built
A 64-bit ELF kernel designed to boot via GRUB using Multiboot, structured into eleven subsystems and reaching over 50,000 lines of Rust. The architecture separated a universal agent base, a kernel-agent layer, the bootloader, and the kernel proper — an early sign of the "everything is an agent" instinct that would define the year after.
ResearchThe headline measured fact: at the point we froze it, the whole thing compiled with zero errors. Fifty thousand lines of systems Rust, generated and debugged with AI, that the Rust compiler accepted. For a language whose borrow-checker is famously unforgiving at this layer, a clean compile across a codebase this size is a real signal about what AI-assisted systems programming could do.
What we learned — including the honest negative
It did not boot. It got stuck on a 32-bit to 64-bit handoff mismatch at the Multiboot stage — the processor comes up in one mode, and the kernel expected to be entered in another.
The deeper lesson was about process, not the AI. The boot mode is one of the very first architectural decisions in an OS, and we had let it drift — made, effectively, too late to change without unwinding a lot of the 50,000 lines. The root cause was a decision made in the wrong order.
That produced a rule we still keep: get the lowest-level decisions right first — everything above them inherits the mistake. In safety-critical rail work, being wrong is a safety risk; here, being wrong at the bottom is a rewrite. Same discipline, cheaper stakes.
Where it went / status
Archived, honestly, as a superseded prototype. It was never resurrected as an OS — but the instincts it proved out carried directly forward: that one person directing an AI could hold systems-scale work; that the agent decomposition was the right shape; and that the bottom of the stack is where the real decisions live. The lab's later GPU-OS and inference work stands on this failure, not around it.
What is still open — kept visible
The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.
- It never booted end-to-end: a 32-bit/64-bit handoff mismatch stopped it at the GRUB Multiboot stage.
- Compiling clean is not running. Zero errors measured the code, not the machine.
- The lowest-level decision (boot mode) was made too late to change cheaply — the root cause was process, not the AI.
Where this connects
Sources
- vocabotics project audit — AIOS / VocabOS (Rust kernel), Nov 2024vocabotics internal project history · as of November 2024