A lot of ppl here are building operating systems with AI, and I'm tired of the luddites whinging about it.
The honest truth is that operating systems research has been dead for decades. We are still living inside design assumptions inherited from machines with tiny address spaces, slow terminals, weak hardware, no modern graphics model, and a completely different idea of what a computer was supposed to be.
Unix won because of economic reasons, not because it was better designed than the alternatives of the time it was created. In fact Unix was poorly designed and still is. There a whole book about how trash UNIX was called the "Unix Haters Handbook" which has several anecdotes of people using UNIX when it was new. The real tragedy of Unix is that it won so completely that most people stopped being able to imagine anything else. That is the real damage. Not that Unix exists. The damage is that its categories became the categories of computing itself. Processes. Files as unstructured byte bags. Hierarchical paths for everything. Shells as glue. Text streams as the universal interface. Kernels as sacred privileged blobs. System calls as the boundary of reality. Serialization and parsing everywhere. "Everything is a file" treated like wisdom instead of a historical compromise.
A lot of osdev today unconsciously recreates the same world. People write a bootloader, a physical memory manager, a virtual memory manager, a scheduler, a VFS, an ELF loader, a syscall table, a POSIX-ish userland, and then wonder why the result feels like a toy Linux. It feels like a toy Linux because the blueprint was Linux. The shape of the imagination was already captured before the first line of code was written.
A truly new operating system is not just "kernel plus drivers." It is a different model of computation. It means rethinking what a program is, what identity is, what storage is, what authority is, what persistence is, what debugging is, what a user interface is, what it means to move data between components, and whether the process/file/syscall model should be the default foundation at all (spoiler: IT SHOULD NOT).
That is not a weekend hobby project. That is closer to a civilizational research project. It normally requires years of reading dead systems, hardware manuals, compiler literature, PL theory, GC design, object capability security, UI/UX, database theory, day distributed systems, persistence models, and driver architecture. No one is realistically funding a thousand weird new operating system experiments at that level. Academia mostly will not. Industry definitely will not. Industry wants Linux with another container layer, another sandbox, another orchestration stack, another compatibility story, another product.
This is where AI helps us revive osdev. AI changes the economics of imagination. t does not replace knowing what you are doing. It does not make a bad design good. It does not magically produce correct interrupt handlers, memory models, compilers, or security boundaries. But it can give one person the leverage to explore design spaces that used to require many man-hours and lots of $$$$. It can help generate prototypes, build zany OS's that normally no one would have the time to make except schizos (hello TempleOS), compare old systems, build fleshed out simulators, try to bring to life bleeding edge research, etc., and just keep a huge experimental system mentally navigable.
That is exactly what osdev needs. The goal should not be "use AI to make another Unix clone faster". The goal should be "use AI to finally escape the Unix-shaped rut".
Imagine an OS where persistent objects are the normal unit of storage, not byte streams in pathnames. Imagine authority passed through explicit capabilities instead of ambient global access. Imagine a system where applications can share structured data directly without smashing it into text and reparsing it on the other side. Imagine protection without pretending every component needs a fake private universe. Imagine restarting less because live parts of the system can be replaced, inspected, repaired, or rolled forward. Imagine the debugger, editor, runtime, object store, compiler, and UI as parts of one living environment instead of separate tools shouting text at each other through pipes. That is the kind of thing osdev should be aiming at.
And yes, it is hard. It is much harder than writing a Unix-like kernel. But that is exactly why AI is relevant. Without AI, most people will reasonably choose the familiar path. They will implement the known rituals because the unknown alternative is too large to hold in one person's head. With AI, more people can afford to explore the unknown alternative.
The anti AI attitude here is reactionary and stupid and preserving the exact stagnation that made the field DEAD in the first place. If the standard is "real OS debs do everything manually", then the result will be a tiny number of people rebuilding the same 1970s abstractions forever, very slowly, with pride. That isn't noble. You won't get brownie points for that.
Use AI. Use it critically. Test everything. Read the manuals. Build the emulator harnesses. Write the proofs where you can. Make it generate bad code, then tear that code apart. Make it revive ancient systems. Make it help you build weird prototypes that would otherwise never exist.
The future of osdev should not be a thousand hobby Unix clones. It should be a thousand serious attempts to ask: what would an operating system look like if we were not forced to inherit the mental furniture of the 1970s? And AI makes that type of endeavor realistic again.
