LLMs (mostly Claude Code) have been used during development, but I learned early on that it's not _great_ at code at this level, so I've restricted its use to mostly documentation and tests. There's _a little_ AI code in the user space, but I have a strict "no AI code" rule in the kernel itself. I find this helps not only with the quality / functionality of the code, but also with learning - for example, even though I've written multiple kernels in the past, it wasn't until Anos that I _truly_ grokked pagetable management and what was possible with a good VMM interface, and if I'd outsourced that implementation to an LLM I probably wouldn't have learned any of that.
In terms of approach, Anos avoids legacy platform features and outdated wiki / tutorial resources, and instead tries to implement as much as possible from manuals and datasheets, and it's definitely worked out well so far. There's no support for legacy platform features or peripherals, with all IO being memory mapped and MSI/MSI-X interrupts (no PIC), for example, which has helped keep the codebase focused and easy to work on. The kernel compiles to about 100KiB on x86-64, with enough features to be able to support multitasking and device drivers in user space.
As a hobby project, progress ebbs and flows with pressures of my day job etc, and the main branch has been quiet for the last few months. I have however been working on a USB stack as time allows, and hopefully will soon have at least basic HID support to allow me to take the next step and make Anos interactive.
I don't know how useful projects like Anos are any more, given we now live in the age of AI coding, but it's a fun learning experience and helps keep me technically grounded, and I'll carry on with it for as long as those things remain true.
rgbrgb•1h ago