I built an x86_64 kernel from scratch, and it made me hate AI documentation tools. So I built my own.

A developer building an x86_64 kernel named TaterTOS64 found that AI documentation tools hallucinated incorrect code dependencies and failed to understand the project's repository structure. In response, they built TaterBookBuilder, a deterministic documentation compiler that resolves include directives to actual file locations and allows for local-first, perpetual ownership without cloud subscriptions. The tool is distributed as a 77MB Linux AppImage with a one-time purchase model, aiming to provide reliable, architecture-specific documentation for systems developers.

Six months ago, I started building TaterTOS64, an x86 64 kernel. As any systems dev knows, once you hit the 10,000-line mark across a mix of C, Assembly, and Linker scripts, your brain starts to leak. I needed a way to document the architectural "why"—how the interrupt vectors hand off to the scheduler, how the paging logic relates to the physical memory map. Naturally, I tried the modern approach: I fed the code to LLMs. The Result was a Disaster. Generic "AI Doc" tools failed me in three specific ways: .c file but completely hallucinate the include chain. They had no idea where the paging.h constants were actually defined in my repo structure.Building the Solution: TaterBookBuilder I decided to stop building the kernel for two weeks and build the documentation compiler I actually wanted. I call it TaterBookBuilder. Instead of a simple "text-to-prompt" wrapper, I built a deterministic analysis engine first. How it actually works: include C and %include Assembly to its canonical repository node. No more guessing where types come from.src/kernel/sched.c:L45-L120 .The Philosophy: Local-First and Perpetual Documentation is a permanent asset. It shouldn't depend on a cloud subscription. I'm shipping TaterBookBuilder as a 77MB Linux AppImage. It's completely turnkey—I even bundled a static binary of Pandoc inside it so you don't have to install a single dependency. And for the pricing? I'm using the JetBrains Model. You buy it once, you own that version forever. You get a year of maintenance, and if you don't want to renew, your documentation pipeline keeps working exactly as it did on day one. Documentation should be as rock-solid and local as the code it describes. Check out the workbench and download the trial here: https://taterlabs.shop/taterbook.html I'd love to hear from other systems devs—how are you handling the "trust gap" with AI-generated architecture maps?