The pitch is simple. People are using AI to cut their dependence on big vendors, and an operating system is the hardest test of that idea. The projects below show how far it can go. They also show where it stops.
Three projects, three very different claims
These are not a coordinated movement. They differ in architecture, scope and ambition. The two "VibeOS" projects share a name and nothing else.
Kaan Şenol's VibeOS (ARM64)
The README calls it a hobby OS vibecoded from scratch with Claude Code, and it admits that not everything works and some of it is untested. It targets ARM64 and runs on QEMU and on a real Raspberry Pi Zero 2W. Claude built it over 64 sessions, which are documented in the repository's session logs.
The README lists a long feature set:
- A custom kernel with cooperative multitasking and a preemptive backup, plus a FAT32 filesystem.
- A desktop with draggable windows, a menu bar and a dock.
- A TCP/IP stack with DNS, an HTTP client and TLS 1.2.
- A browser, terminal, text editor, file manager, Tiny C Compiler, MicroPython and DOOM.
Two caveats matter for anyone tempted to try it on hardware:
- Pi limits: The README says the Pi build has no networking driver and no audio. MyBroadband also noted that networking only works in QEMU.
- DOOM: The game isn't bundled. The README says you must supply your own
doom1.wadfile.
MyBroadband tested VibeOS in QEMU and found it works as advertised, with significant caveats. Şenol told the outlet he no longer wanted to work on it, though he was fairly satisfied with the experiment.
SlopOS
SlopOS is a Rust-based system. The GitHub description reads "An operating system fully designed and written by AI agents." The How-To Geek piece highlights a photo of it running on bare metal, with the desktop drawn by its own Intel display driver. The project's README says it also has its own TCP/IP stack, an SMP preemptive scheduler and a custom ACPI interpreter. These are the developers' claims, not a hardware compatibility list.
The installation documentation adds the practical detail:
- Boot requirements: Installing needs UEFI firmware with Secure Boot turned off. The docs say the boot loader isn't signed.
- Disk support: The docs say it drives NVMe drives, virtio disks in a virtual machine and USB disks, but has no SATA driver. On real hardware, an install must therefore go onto an NVMe or USB disk.
- Other limits: The docs say it can't resize another system's partitions. The root filesystem is always ext4.
- Wheel of Fate: The boot "gamble" is a deliberate joke. A normal boot shows a boot screen and the Wheel of Fate, then a desktop. The docs also mention a build option that skips the Wheel of Fate.
The installer is more thought-out than the novelty suggests. It offers erase-the-disk, install-beside, and reinstall-while-keeping-accounts modes. It also offers a rescue shell from the live stick. That is more care than most weekend experiments get. It is still far short of a consumer installer.
gdoct's VibeOS (x86-64)
This one is the most architecturally interesting for PC users, because it targets x86-64 with UEFI boot. The README describes a higher-half SMP kernel, a writable filesystem called VibeFS, a TCP/IP stack and a userspace windowing system.
Its headline feature is Linux binary compatibility. The kernel follows the Linux x86_64 syscall ABI. That lets cross-compiled x86_64-linux-musl programs, static or dynamic, run unmodified. The README says this holds "as long as they only touch syscalls that are implemented."
That qualifier is important. This is a subset of Linux userspace behavior. It is not a general Linux or Windows application layer, and it doesn't mean arbitrary Linux software runs.
The most important fact is in the project's own status note. The README says it was vibe coded in about a week of evening sessions, roughly 100 commits across May and June 2026, and that active development has since stopped. The README's badge marks it as archived. The README describes it as an experiment in how far current frontier models can be pushed with expert guidance. It does not describe a product roadmap.
What the evidence does and doesn't show
A quick comparison:
| Project | Architecture | Real hardware claim | Notable limit |
|---|---|---|---|
| Şenol's VibeOS | ARM64 | Raspberry Pi Zero 2W | No Pi networking or audio |
| SlopOS | x86-64 (Rust) | A laptop, per project | No SATA driver; Secure Boot must be off |
| gdoct's VibeOS | x86-64 | Documented run environment is QEMU with OVMF | Development stopped; partial syscall coverage |
The headline question is whether these could become Windows alternatives. The documentation doesn't support that yet.
- Hardware coverage: Windows runs on a huge range of PCs because of decades of driver work. None of these projects documents anything close to that range.
- Application ecosystem: Windows is valuable because of the software it runs. A partial Linux syscall layer doesn't change that.
- Security maintenance: An OS needs ongoing patching. One project has stopped development, another's creator has said he moved on, and the third is a small project with a joke boot mechanism.
- Reliability: Running DOOM shows that one software and graphics path works. It says nothing about general stability.
Independent testing of a similar project is a useful warning. A project called Vib-OS was tested by a YouTuber, as reported by Futurism. He found it failed to connect to the internet, File Manager buttons didn't respond and Notepad refused to save documents. Tom's Hardware updated its story after the developer said the video focused on the buggy x86-64 build, which the README mentions. That is a different project from the three here. It still shows how far a feature list can be from daily use.
Why it matters anyway
The impressive part is the speed. Individual developers and tiny teams produced bootable kernels, network stacks and graphical desktops in weeks. That used to take far larger efforts.
It also raises real questions for IT readers:
- Trust and review: Code written by a model and verified mainly through boot tests needs scrutiny before anyone relies on it. gdoct's own README says features were verified on real boots. That is not the same as a security audit.
- Maintenance: Generating a kernel is the easy half. Keeping it patched is the hard half.
- Open licensing: The projects use MIT or GPL-style licenses. That makes them easy to study and fork, which is where their value probably lies.
The How-To Geek article's closing prediction is that you could someday have a personal OS coded overnight for your hardware. That is speculation. Nothing in these projects demonstrates it.
The bottom line
These are real, bootable experiments. They deserve credit as demonstrations of what AI-assisted development can produce, and they are fun to try in a virtual machine. Don't wipe your Windows PC for any of them. If you want to experiment safely, use QEMU, and read each project's documentation first. For anyone planning real hardware, the SlopOS no-SATA and Secure Boot notes are the first things to check.