# BooleOS: building a bare-metal x86 OS without writing a single line of it myself > Source: > Published: 2026-09-26 03:38:04+00:00 BooleOS is a hobby operating system for x86 (32-bit), written in C99 and NASM, no Linux or BSD underneath, no libc. It boots via Multiboot2, has its own heap manager (no raw malloc), a FAT16/VFS layer, and a cooperative scheduler so far. Repo: [https://github.com/BooleSystems/BooleOS](https://github.com/BooleSystems/BooleOS) I don't write the code. I direct Claude Code, review every diff, and decide what gets built next, but the implementation, every commit, is AI-generated. This isn't a detail I'm downplaying, it's written into the project's own CONTRIBUTING.md: contributions have to be AI-generated too, with a verifiable co-author trailer in the commit, or they get closed on sight. Most "I built this with AI" posts are about apps with a framework, a runtime, a garbage collector, and years of guardrails baked in. Bare-metal has none of that. There's no libc to catch a bad pointer, no OS underneath to kill a runaway process, and the debugger you'd normally reach for doesn't exist yet because you're the one building the platform it would run on. That changes what "reviewing AI output" actually means here. A few constraints I hold non-negotiable, written into the project's own CLAUDE.md so every session (including future me) doesn't have to relearn them: `sizeof(void*) == 8` assumptions, ever.``, never `size_t` or `long`. The two mistakes an AI agent keeps drifting toward, if I don't stay strict about it: reaching for `pthread` and `malloc` because they're convenient on Linux, and treating the 64-bit dev build as the one that matters because that's where the debugger runs. I don't hand off a feature request and walk away. For anything that touches the kernel, I write out the constraint set in the prompt explicitly (32-bit gate, fixed-width types, no libc), it implements, I boot it in QEMU myself, read the serial output myself, and only then decide the next step. Testing is never delegated, ever. Pre-release, not a 1.0, but with ~20 tagged versions and real changelogs behind each one. Currently at about USB HID input work, heading toward a custom graphics API (Cathode) and eventually a minimal GUI on top of it. Happy to go deeper on any part of this, the constraint-writing process, the heap wrapper design, or what a "cooperative scheduler now, real SMP model later" migration path looks like when none of the code was hand-typed to begin with.