BooleOS: building a bare-metal x86 OS without writing a single line of it myself

A developer has built BooleOS, a bare-metal 32-bit x86 hobby operating system written in C99 and NASM with no Linux, BSD, or libc underneath, where every line of implementation is AI-generated via Claude Code. The project boots through Multiboot2 and includes its own heap manager, a FAT16/VFS layer, and a cooperative scheduler, with roughly 20 tagged pre-release versions so far. The developer directs the agent, reviews every diff, and does all testing personally in QEMU, with AI-generated contributions required by the project's CONTRIBUTING.md.

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. <stdint.h , 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.